Suggestion: Timers

[Kavukamari]

what about tick timers (1/60 second)

[chrisgbk]

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.

[urraka]

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.

[chrisgbk]

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.

[urraka]

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.

[chrisgbk]

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.

[sai`ke]

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.

[urraka]

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.

[Avarax]

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.

[BombSki]

lol.. yea thats what you call a workaround

[urraka]

I guess that could work, but I really prefer not to do stuff like that. I prefer the buggy thread.

[ghg]

Balls, I just realised how timers work. It's so easy yet I couldn't work them out.

[EnEsCe]

Dunno if you might find this useful or not, but heres an undocumented function:

function GetTickCount():Cardinal

Obviously, it gets the current tick count.

[urraka]

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.

[DorkeyDear]

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?

[poutch]

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 ?