Official Soldat Forums
Server Talk => Scripting Discussions and Help => Topic started by: urraka on November 12, 2007, 12:33:16 pm
-
Well, frustrated by the buggyness of making threads in scripts, I come here with this suggestion. It consists of 2 functions and one event:
SetTimer(ID, time: integer);
Sets up a timer, time in milliseconds.
KillTimer(ID: integer);
Unsets a timer.
OnTimer(ID: integer);
Event called for each timer.
This would be great, it'd give the possibility of creating scripts that control the game flow with a precision of milliseconds.
AppOnIdle is useless in some cases (example: PerroRACE (http://forums.soldat.pl/index.php?topic=20940.msg256836#msg256836)), that's why I suggest this.
I hope this is taken into consideration.
-
You can make those functions yourself.
-
I can't get a function getting called each X milliseconds without using a separate thread. And the point is to avoid using a thread. AppOnIdle is called every 1 second, and that's not enough precision.
Another way this could be done is having a function to set the time interval of AppOnIdle, maybe that's a better and easier approach.
-
AppOnIdle is the closest you will get, 1 second. Milliseconds will rape your server too much
-
Why will a shorter interval rape your server so much if people would do what they are already doing in threadfunc and it runs fine there (aside from the issues with soldat not being thread safe for whatever reason)?
-
AppOnIdle is the closest you will get, 1 second. Milliseconds will rape your server too much
Raping or not the server would be a responsability of the scripter. Anyway, I'm sure my server would love it by the ass.
-
lol
-
lol
This user was warned for this post.
-
IMO, i think we could try it tho. I agree on the fact its the server scripter own responsability.
-
So is there any chance to get this implemented? Or the definitive answer is NO! GTFO!?
It's not a complex thing, just a couple of lines [pigtail]
-
It's not a complex thing, just a couple of lines [pigtail]
All the more reason to just do it yourself ;)
one could say that there's a reason it is called a "scripting core" not a "scripting everything-you-will-ever-need-in-one-place"
-
It's not a complex thing, just a couple of lines [pigtail]
All the more reason to just do it yourself ;)
He just stated he needs a time resolution smaller than a second, and currently that is not possible. You can't do that yourself because it needs changes in the server app. Not saying they should or should not be made, that's up to EnEsCe.
-
You could always give me the server code and I'll do it myself :P
-
You could always give me the server code and I'll do it myself :P
He's totally going to give you the server code...
-
It's not a complex thing, just a couple of lines [pigtail]
All the more reason to just do it yourself ;)
He just stated he needs a time resolution smaller than a second, and currently that is not possible. You can't do that yourself because it needs changes in the server app. Not saying they should or should not be made, that's up to EnEsCe.
I didn't see him say anywhere that he needed a resolution better than 1s, but your point is made either way
-
You could always give me the server code and I'll do it myself :P
He's totally going to give you the server code...
I hope so.
I didn't see him say anywhere that he needed a resolution better than 1s, but your point is made either way
I thought I made that clear:
This would be great, it'd give the possibility of creating scripts that control the game flow with a precision of milliseconds.
Anyway, he said 1 second is the closest I'd get.. so I guess that means he will implement it! Yay!
/retarded_mode off
-
Do you still want these timer functions now that they don't have any added advantage over regular apponidle anymore?
-
You missed the "/retardedmode off" part
-
This isn't, as some people might think, an easy thing to do; as it is, the server itself only runs about every second (I say about, because sleep(1000)[windows] or usleep(1000000)[linux] only guarantee you will sleep for AT LEAST 1000ms, it's very possible you will exceed that amount of time, particularily under load), so to get AppOnIdle to be called every millisecond would require the server to also run every ms as well. Which is not going to happen, the server spends so much of it's time sleeping for a reason, so it doesn't saturate the CPU.
As for actual timers, they have their own issues; they would also only be accurate to one second, unless they were run as a seperate thread, which also adds a whole lot of complication to deal with locking of resources, race conditions, etc. Anyone that's used the scripting thread functions knows what kind of instability results there. (Mostly due to the script engine not being re-entrant).
Most of this is invalid, server only sleeps for (at least) 1 ms. But still partially valid.
-
Time resolution increase always increases load and one millisecond is absurd. And yes of course. It wouldn't do much good having timers of 100 milliseconds if the variables we have access to with scriptcore aren't updated at that resolution. Haha and yeah, writing good multithread code is a skill in itself. Is there a tech doc anywhere with the global layout of the server code?
-
what about tick timers (1/60 second)
-
what about tick timers (1/60 second)
The ticks are done in batches every second, so while it appears it runs at 1 tick / 1/60th of a second, it really runs at 60 ticks every second. If you are trying to time things, you aren't going to do very well.
-
Well, my intention with this suggestion was only meant to get a better time resolution for game flow checking. I don't really care if the timers are accurate themselves. And also, as sai'ke said, it would be pointless to use timers that have better resolution than the server. So I think it would be enough to have timers that could run at least at the server time resolution. I suggested milliseconds because that was my first thought, but 1ms resolution isn't needed.
-
Whoops, I made a mistake; the server only sleeps for (at least) 1 ms, my bad, and ticks aren't done in batches. Was confusing 2 completely seperate pieces of code, ignore the above.
Doing the timing with the script engine may still result in too much load, so I don't think it will be done. Make do with what you have, and if it gets added, it gets added, if not... then it doesn't.
-
I don't see how it could result in too much load. The timer would just be an if that compares 2 times (current and time of last call to the timer) and the call to the timer event for each timer. Of course, if the scripter missuses the timers it could result in overhead, but that's the scripter fault.
-
The problem is with the scripting integration part, every time a script call is made that's a lot of overhead. Which is why AppOnIdle was set to only run once every second, running every millisecond made the server unplayable, even if it didn't do anything.
On a simple level yes, it's not that much of a problem, but in this system it is.
-
Even if it doesn't get implemented, I'm still interested in why this is a problem in the soldat server.
I reckon that with hard coded timers in the server application (not by means of scripting of course!!) the only script call would be on the onTimer event. Furthermore, I reckon it wouldn't be the same as a thread since it could be running in series with the server processes rather than in parallel. I don't have the code nor do I know how it's built up, so this is just guesswork on my part.
-
The problem is with the scripting integration part, every time a script call is made that's a lot of overhead. Which is why AppOnIdle was set to only run once every second, running every millisecond made the server unplayable, even if it didn't do anything.
On a simple level yes, it's not that much of a problem, but in this system it is.
I was guessing that the script calling would give some overhead, but in this case the overhead would only come when the scripter sets a timer to 1 millisecond (for example). I'm not sure how many milliseconds would be ideal to avoid the overhead and have a good time resolution as well. So again, I insist, it would be the scripter's resoponsability not to set timers with a high time resolution like 1ms. If no timers were set, there wouldn't be any overhead at all and the server would run just like it always does.
-
You can create your own timer by placing a special Dummytype bot somewhere out of the map (map roof) using my PlaceBot function and then start spawning 0 damage bullets over him. Whenever he is hit and receives 0 damage, you can call that special timer event in OnPlayerDamage and continue by spawning another bullet. Frequency can be measured by drop height of the bullets. This however of course is a very sloppy and unconventional work-around, but, if you do it correct (and find a way to find out where a map's roof is ;) ), it should absoluteley bug free.
-
lol.. yea thats what you call a workaround :P
-
I guess that could work, but I really prefer not to do stuff like that. I prefer the buggy thread.
-
Balls, I just realised how timers work. It's so easy yet I couldn't work them out.
-
Dunno if you might find this useful or not, but heres an undocumented function:
function GetTickCount():Cardinal
Obviously, it gets the current tick count.
-
Hmm well, not for the porpouse of this suggestion, but it comes handy for something else. That can be used insetead of FormatDate to measure time intervals in a more efficient way I guess.
-
Dunno if you might find this useful or not, but heres an undocumented function:
function GetTickCount():Cardinal
Obviously, it gets the current tick count.
Why is the datatype for Ticks under AppOnIdle integer if GetTickCount results cardinal?
-
Sorry, didn't read all, but i have just one question :
What's the point to use a variable in "Ticks" in the AppOnIdle procedure (1/60th of sec) if AppOnIdle is called only every second ? Why not use directly a variable in "seconds" as it seems that you can t have a shorter interval ?