# Every X Milliseconds problem

### » Tue Jun 01, 2010 12:59 am

[quote="Ashley":ypm3073b]It's a tricky area... what do you think should happen? Do you think the current system (capped at once per tick) is OK?[/quote:ypm3073b]

I can't really think of any good way for Construct to try and handle such a situation, other than how it does now. Since it really depends upon what one is doing at each interval, I don't think that there can be a catch-all solution.

I would implement a variation of TimeDelta, as a function, which would report the time elapsed since the last call. Like so:

[code:ypm3073b]+ Function: On function "TimePeriodDelta"
+ System: Is global variable 'previousTime' Different to 0
-> System: Set global variable 'currentTime' to Timer
-> Function: Set return value to (global('currentTime') - global('previousTime')) / Function.Param(1)
-> System: Set global variable 'previousTime' to global('currentTime')
+ System: Else
-> System: Set global variable 'previousTime' to Timer
-> Function: Set return value to 0[/code:ypm3073b]

This uses two globals, though it would also be good enough without 'currentTime', and accessing the Timer twice instead of once. Anyway, the first time it's called, it returns zero and starts counting time, then every call after will return the difference since last call. It takes one parameter, which the difference in milliseconds is divided by. Pass it the value 1 and it will return milliseconds, or pass it the same interval as your 'every ... milliseconds' condition, and the desired result would be one.

For instance, for a '5 damage per 50ms' event, I pass the function 50, using it in expression form as a multiplier for the desired damage. Much like the TimeDelta.

[code:ypm3073b]+ System: Every 50 milliseconds
-> System: Subtract 5 * Function.TimePeriodDelta(50) from global variable 'Health'[/code:ypm3073b]

I think a built-in such as this could be useful, but it's not difficult to implement anyway.

I made a simple .cap to test this, which simply appends each result into an EditBox. I did get some odd intervals with low fixed frame rates.

v0.99.84: [url:ypm3073b]http://dl.dropbox.com/u/5868916/TimePeriodDelta.cap[/url:ypm3073b]
B
3
S
2
G
2
Posts: 187
Reputation: 1,449

### » Sat Jul 31, 2010 11:42 am

If I use "Every 50 milliseconds" -> add 1 to value "counter" and fps is low (15 for example) then it calculates the value too slow. It works if fps is about 50.

Why this depends on fps? Any idea how to fix this?

I just would like to calculate time after object X has been destroyed and when time has passed for 12 seconds (equally 1200 milliseconds) after that, something happens :S
B
5
S
2
G
8
Posts: 53
Reputation: 3,227

### » Sat Jul 31, 2010 7:55 pm

[quote="Jarzka":3eoldl8u]I just would like to calculate time after object X has been destroyed and when time has passed for 12 seconds (equally 1200 milliseconds) after that, something happens :S[/quote:3eoldl8u]
That's not, what "every x milliseconds" is designed for. It should be used to repeat actions in regular intervals (like a stop light flashing red every 20 seconds, etc.).
For actions like the one described you have other tools. I suggest using the system expression "Get timer". It returns the amount of time the current layout has been running. I am used to create a pv/global I call "timestamp". Just fill it with "Get Timer" whenever you want to mark a point in time. To test if 12 seconds have passed you compare "Get Timer" - "timestamp" >= 12000.

If you are dealing with many objects you should setup an index for every object and a 1-dimensional array, where the x-dimension corresponds to the index of the object. Instead of just comparing one object you then need to loop-compare. Or, if you just make the objects invisible and place them outside the layout instead of destroying them, you could test for the passed time via the above timestamp pv example and destroy them not until these 12 seconds have passed.

Edit: typo, 1200 corrected to 12000
B
24
S
8
G
10
Posts: 1,822
Reputation: 8,291

### » Mon Aug 02, 2010 6:08 pm

A simple way to deal with the original problem:

B
18
S
8
G
4
Posts: 137
Reputation: 3,196

Previous