Timer problems, native and timer.lua

Hi everyone,

I’m having issues with both the native timer module and the timer.lua module Britzl made here:

https://gist.github.com/britzl/0f6291990b0b11f92775

If anyone has any ideas, here’s what I’m seeing:

Native timer module:

  1. Doing a build while simulator is running and there are timers active crashes dmengine.exe, if you close the running simulator and build there is no crash. Now I know the timers need housekeeping and all that but should re-building be crashing dmengine.exe or is it a bug?

  2. I have 2 timers repeating, 2 and 6 seconds. There appears to be triggering drift the longer the timers run.

timer.lua module:

  1. Including timer.lua locally in multiple game objects seems to cause the timer script to interfere with the timers in the other game object when including a second instance of the same script. I could be flat out missing something here but even though it’s the same script file, they have different URL’s. Should they interfere with each other?

I have made a sample app to illustrate this:

Native timer module (First two columns of dots):
Column 1 - spawned every 2 seconds
Column 2 - spawned ever 6 seconds
Dots are simply gravity falling from a factory using the same prototype, notice the time drift. After about 20 seconds you can see the drift as they spawn.

timer.lua module:
Column 3 - spawned every 2 seconds
Column 4 - spawned ever 6 seconds
The two scripts just seem to be cross spawning in the other GO with no apparent pattern.

Also test project attached:
Timer Test.zip (1.8 MB)

Any insight would be greatly appreciated!

1 Like

Do you have the timer variables on a self. statement? Otherwise, it might blend the variables.

This sounds like a bug (on my end, not the engine).

Yes, this could be a problem. I looked at your example and you have two local variables:

local childIds = {}
local timerIds = {}

Both declared outside the lifecycle functions. This means that multiple instances of the same script will share these.

Wow, that’s some impressive response time!

No luck with this, changed both the native timer and timer.lua scripts so they use self:

local function spawnChild(self)

	local childId = factory.create('#factory', nil, nil, {velocityX = self.velocityX, flame = self.flame}, 1)
	table.insert(self.childIds, childId)

	local timerId = timer.seconds(self.frequency, function()
		spawnChild(self)

	end)

	table.insert(self.timerIds, timerId)

end


local function start(self)

	spawnChild(self)

end

function init(self)
	-- Add initialization code here
	-- Remove this function if not needed

	self.childIds = {}
	self.timerIds = {}

	start(self)

end

Still the same results :persevere:

1 Like

And the problem is that the timers interfere somehow? What happens exactly?

So, looking at columns 3 and 4, this is with timer.lua not the native timer extension.

Column 3 (go3) spawns a factory object every 2 seconds
Column 4 (go4) spawns a factory object every 6 seconds

But as you can see from the screenshot, this is not happening correctly.

The timer triggers are actually spawning at the correct times, but the go they spawn in is random if that go contains the same script.

So:
/go3#script is spawning factory objects in /go4
/go4#script is spawning factory objects in /go3

As stated this is with your old timer.lua, I know this module is obsolete, so would use the native timer if not for the drift and crash issue.

Ah, I see now. That old timer.lua module is like a singleton. It’s a single instance and list of timers, shared between all users. So when you call timer.update(dt) from multiple scripts the timer will count down faster than it should (it’s not dependant on real time but based on the dt values you pass in). You could adapt it so that you get one timer instance per script, but that’s not how it was designed. If you wish to use timer.lua, then I’d recommend that you call timer.update() only from a single place (perhaps a separate timer.script).

2 Likes

Thanks a lot, this makes sense @britzl.

I’ll have a bash at modifying for the one timer instance per script route.

Any idea why the drift occurs in columns 1 & 2 which use the native timer?