Something I'd like to share about timer behaviour

Hi,

So I'm making a "minions" game. My minions would mine. Every time one of them would arrive at the mining place, timer would kicked in, and on timer out, he would go back to the base. But the thing is from time to time, some of them would just "stuck" at mining place, and even with all variables set appropriately, would not move at all. So after whole day of frustration, I switched Timer to Wait action, and everything started working fine. Bug?

Might not be that, but you need a for each with the On Timer trigger if multiple instances have this triggering at the same time, not sure why but I remember it.

Might not be that, but you need a for each with the On Timer trigger if multiple instances have this triggering at the same time, not sure why but I remember it.

That's exactly how I had it set up. I had it Outside For Each, then inside For Each ( this one didn't work at all). Just gaved up.

It might be actually a bug in Timer behavior. Few days ago i had similar situation, where each instance of same object had a different value set in Timer behavior.

And usually when On Timer triggers other instances (with it's own Timer still running) started to do some strange things - things they not supposed to do . And also For Each did not helped at all. After removing a Timer and making the same behavior using normal instance variable fixed everything up.

use

foreach  object
object is on screen              - do something
[/code:3k8uogfx]

It might be actually a bug in Timer behavior. Few days ago i had similar situation, where each instance of same object had a different value set in Timer behavior.

And usually when On Timer triggers other instances (with it's own Timer still running) started to do some strange things - things they not supposed to do . And also For Each did not helped at all. After removing a Timer and making the same behavior using normal instance variable fixed everything up.

Now I'm thinking that maybe even Wait action is more imprecise then ever. But I'm tiered, so might be just imagining that without seeing the game. But could you tell me how you did the timer? I'm pretty sure I used to do those in the past, before such thing as timer was a reality, but I can't remember XD

saiyadjin Not sure how this would suppose to help, but thanks anyway!

use

> foreach  object
object is on screen              - do something
[/code:14sec8jy]

Yes, That is indeed "for each" condition. Thanks!

megatronx

Nothing fancy really.

-On star of layout

--for each sprite -> set Timer "xxx" to int(random(5)

-On timer "xxx" -> set Timer "xxx" to int(random(5) and do something with sprite.

With all possible combinations with for each xD

megatronx

Maybe post a small example of what you are doing so people can have a look.

> use

>

> > foreach  object
> object is on screen              - do something
> [/code:1f9quwyt]
> 

Yes, That is indeed "for each" condition.  Thanks!

megatronx [/p]
[/p]
Nothing fancy really. [/p]
[/p]
-On star of layout[/p]
--for each sprite ->  set Timer "xxx" to int(random(5)[/p]
[/p]
-On timer  "xxx" -> set Timer "xxx" to int(random(5)   and do something with sprite.[/p]
[/p]
With all possible combinations with for each  xD[/p]

Cool. I thought you went with something like this:

Object with varTimerTime set to N, and boolean Timer

For Each

-Is Timer

-Every 1 sec remove 1 from varTimerTime

---TimerTime less or equal 0 : do stuff

Ha! thanks for reminding me

If you have to use "for each" then that is a bug.

I suspect this may be something else however.

Possibly how the tags are set up.

It may be possible that an instance may be created after a tag is created, which could cause an issue.

megatronx

Maybe post a small example of what you are doing so people can have a look.

Not doing anything complicated. Basically have minions walking from base to the resources point, where timer is suppose to trigger their time working or offloading, and stop movement condition. On timer they suppose to get back to the base, one by one, each with own timer. When each one of them is at the base, the timer starts again stopping movement for short while, ( state is changed to Offload etc), and that's how they continue traveling back and forth. Units movement conditions where under For Each, Timer trigger was not, and at the end of mining or delivering conditions, timer was starting, on timer calling couple of functions responsible for setting targets. But after a while it would always drop one, or two, then three etc units, which would stand there with all the variables set to make a move, but doing nothing. And so I noticed that issue appear to happen at the time trigger moment. Removed it, replace with wait ( duplicated couple of actions unfortunately :/ ), and everything works as it supposed to.

Anyway, I don't even have original version of the events anymore I spent whole day trying to sort it out, moving things around. Nothing fixed the issue! I'll probably keep timer for simpler tasks from now on.

newt If you have to use "for each" then that is a bug. No, when I placed a timer under For Each, it didn't work at all. Thought there was no error message either.

Possibly how the tags are set up. I sometimes set tags like this :< "name" & str(object.uid) > , but in both cases, weather it was just a name or name paired with uid, it didn't work, or rather, was bugy. It did display the tag properly in the debug, thought now I realised I didn't look up if tag's name uid is the same as the instance's.

Yeah its does not work with concatenate or variables, and expressions I think.

You need just a plain string.

See if this helps.

blackhornettechnologies.com/Construct2Stuff/TimerExample20150424.capx

sorry i haven't even read the first post.

anyway it's not bugged as much as i know, but it's 99% that you've made a mistake somewhere and it's hardly reachable / understandable where. that happens because we have events based engine which is sometimes hard to decrypt what happens.

anyway this could also happen if timers use threading. using many threads (each minion owning a thread) could cause issues if undelayin' performance is bad or optimization is not perfect. i've had my share of playin' with threading in c# where lots of stuff is perfectly declared what you can do and can't do, and trust me, it becomes a pain in the ass over some time to sync events.

using wait probably pauses that single picked instance and blocks that thread until time runs out and continues the thread then. using timer probably creates a new thread for counting down the time and stuff gets easily bugged. if wait works for you, then use it. if you really really really want to use timer, at least supply the part of code where we could see what happens and direct you into fixing stuff (or waste another day finding why it happens).

(it's the same as when i optimized 6 events shooting into 1 event (works like a charm ) )

also why would you use "timer.time - 1 sec" thing?

i'm a show you a part of my code how i set how often my enemies shoot. (Timers)

behold:

oh yeah, difficulty - easy, medium and hard are described by 1,2,3.

so you get 1.2*(8/3*1) = ~ 3.2 sec for easy, ~2 sec for medium and 1.2 sec for hard.

oh yeah, i think i could have done this differently too - set a timer that is called every those sec, and call the upper function (swap places of on timer ) - but i think that would be slower. why? timer would fire it's part of code every time. and this way i check if fireing is disabled, if it is don't fire timer. else fire it.

So to conclude:

Setting timer within For Each loop doesn't work.

Timer trigger only works with strings, and doesn't work with changing variable, scaling functions and such.

Right?

saiyadjin thanks, I'll use Wait for current events.