Timer Problems.

I have been having this problem for quite a while. When ever I try to use a timer property and apply it anywhere it does not work. i posted a test blend see if you can fix it.

Ps. Sorry if this was posted before.

Test Blend.blend (129 KB)

For timers it is better to check for equals and greater (>=). Because it is not likely that the timer hits exactly 5.0000000000000.

You can also do this with logic bricks:
property sensor:

  • [Inv] activated
  • Prop = your prop
  • min = 0 (or less)
  • max = your maximum

-> AND controller -> EndObjectActuator

I hope it helps

and dont forget pythons mighty time.time() for framerate independence:

import time
g = GameLogic
c = g.getCurrentController()
o = c.owner

import time

if o["init"] == 0:
	o["init"] = 1
	g.globalDict["timerstart"] = time.time()

timeoffset = time.time() - g.globalDict["timerstart"]
g.globalDict["currentTime"] = timeoffset
print "current Time = ",g.globalDict["currentTime"]

this will start at “0” counting up. the object which inherits this codecontroller must have an property named init and set to 0 (as an int) or false (as a bool)

what does time.time() do? does it starts counting like a clock?

time.time() returns the current time. The rest of the calculations determine what I’ll call “local time”, and store it in GameLogic’s “globalDict” property with the key “currentTime”. If you put this script on an object and started the game, currentTime should equate to 5 seconds after 5 seconds has actually passed.

However, I’ll argue against his statement that this allows for “framerate independence.” Regardless of how you’re calculating time, the script can only be run once per logic tic, and it can only calculate differences once per logic tic. A conventional timer property should, in theory, do the same thing.

Test it! Create a timer property, enable debugging, and try and lower the framerate to 10 or 15 FPS by adding a bunch of high poly objects. Now start the game and notice that after 1 real second, the timer property also shows 1 second.


sooo if i use time.time i can get the current time on the computer??

this script allows framerate independence, or something very close to it, when you fetch the time value whenever it passes >= 0.5 steps or >= 1.0 steps

i could post the script here, but i think it will be relatively easy to write.

that way you will get an “relatively” (speaking in milliseconds) accurate timer.

the problem, that the script only runs once per tick is no problem, since the timesteps between script execution will just get biggger in that case. thats a real clock we are talking about here :slight_smile:

for example (numbers not accurate :no:)

60 fps:

5 fps:

that means, that you can make it happen framerate independent :wink:
i didnt think about framerate independence untill yesterday i started a blend which had a framerate of 5.
i then fastly took the timer properties out of the blend and implemented a time script using time.time()
only disadvantage: at 5 frames there might be skips of up to 200 milliseconds since there are only five possibillities to update g.globalDict[“currentTime”] per second

I’m still not really understanding your line of thought…

The timer property, AFAIK, functions already independent of frame rate. If you disagree, give me an example. In general, logic tics should happen independent of framerate as well (and supposedly have been since version like… 2.3 something). Regardless of framerate, an always sensor attached to a property actuator will activate that actuator 60 times a second (by default).

Not that time.time() doesn’t have its uses… but for basic timer stuff it’s unnecessary.


all i know is, that at 5 frames one timersensor second was extremely long,
while one time.time() second still equaled one second.

i wont be making a testblend for this, and the one i am using is full of artwork which should not be shown right now, so i cant prove my point, but at 5 frames the difference was visible.
i just tested again with a blend which reaches 10 frames and the timer seems to work fine there, so maybe its a bug which only happens at 5 frames or less?

will be investigating this further :smiley: