Wait or Sleep Function in LUA

[bmandudeman]

I was just wondering if there was any sort of solution to delay my lua script for a certain amount of time. Thanks for the help!

[eryk500]

Why do you need a sleep function? Just use a timer "looped" through the composite input and output, if you realy need a delay, and it's not like you can't set them to wait for a few ticks.

[bmandudeman]

The problem is that I want a specific function which inputs and outputs global variables from a script, I guess it is a possibility to use two different lua controllers but it would complicate things.

[jalopeelo]

i also need help with this one :S

[Father_Andriy]

i use counter variable inside onTick, which increases by 1 every tick and condition: if counter == 60 then do script. it's delays script by 1 second

[jalopeelo]

Originally posted by Father_Andriy:

i use counter variable inside onTick, which increases by 1 every tick and condition: if counter == 60 then do script. it's delays script by 1 second

i cant really understand

[eryk500]

Originally posted by Jansuk:

Originally posted by Father_Andriy:

i use counter variable inside onTick, which increases by 1 every tick and condition: if counter == 60 then do script. it's delays script by 1 second

i cant really understand

Just do this:

i = 0 -- this is before any functions

function onTick()
if i == X then -- set X to a number
--add something here
end
i = (i + 1)%Y -- set Y to the tick on which the counter will reset (Y must be greather than X)
end

[bmandudeman]

Thanks for all the responses, I have a few questions regarding the tick rate. First of all, is the tick rate constant between all systems? Secondly, if the tick rate is constant, does anyone have an estimation as to how many ticks there are per second? Thanks again.

[Tajin]

Exactly 60 ticks per ingame second.
If performance is bad, ingame time slows down so the 60 ticks are constant.

That beeing said, lua in sw basically works with event scripts, there is no point trying to use delays there.

[bmandudeman]

Originally posted by Tajin:

Exactly 60 ticks per ingame second.
If performance is bad, ingame time slows down so the 60 ticks are constant.

That beeing said, lua in sw basically works with event scripts, there is no point trying to use delays there.

Sweet, thanks for the help man

[Woe]

Originally posted by Tajin:

Exactly 60 ticks per ingame second.
If performance is bad, ingame time slows down so the 60 ticks are constant.

That beeing said, lua in sw basically works with event scripts, there is no point trying to use delays there.

My game runs at 62.5 ticks per second.

[Ra-Ra-Rasputin]

Originally posted by woekin_up:

My game runs at 62.5 ticks per second.

You've replied this to about 5 irrelevant threads now. Your physics is reporting 62FPS because it's 62 physics iterations per second. Ticks are still 60/s because they're hardwired to do so.

[Woe]

Originally posted by Ra-Ra-Rasputin:

Originally posted by woekin_up:

My game runs at 62.5 ticks per second.

You've replied this to about 5 irrelevant threads now. Your physics is reporting 62FPS because it's 62 physics iterations per second. Ticks are still 60/s because they're hardwired to do so.

no i counted up ticks, via a micro controller, for minutes and divided that by seconds. For example, 18750 tick was exactly 5 minutes.

[Ra-Ra-Rasputin]

Originally posted by woekin_up:

no i counted up ticks, via a micro controller, for minutes and divided that by seconds. For example, 18750 tick was exactly 5 minutes.

That's one late reply!
I'm happy to admit i was wrong in that reply. I did some tests at some point after that, and while the ticks absolutely should be hardcoded in an async way from other stuff, it looks like they're strictly tied to the physics update rate.

Which means they can do 62 ticks / s. I tested this by using a handheld stopwatch and noticed the game's timer was running slow when using 60 tick/s

[Tajin]

The 60 ticks per second rules refers to ingame time. The game itself can still slowdown based on performance and the ticks will scale accordingly.

Originally posted by Ra-Ra-Rasputin:

while the ticks absolutely should be hardcoded in an async way from other stuff, it looks like they're strictly tied to the physics update rate

Performance issues would mess up logic if that wasn't the case.

[Ra-Ra-Rasputin]

Originally posted by Tajin:

Performance issues would mess up logic if that wasn't the case.

True to a degree. It'd just need sanitization or handling, though admittedly that would need an extra line for inputs. You could opt for either with "wait for sync" or just not bothering. Speedo for instance could run asynch just fine.