Something I'd like to share about timer behaviour

Never used any variables inside Timers, never needed to so can't say much about that :/

For me it always work with integers and floats (1, 5, 23, 0.5 4.52 etc.... obviously xD) and expressions choose(), random() - at least these are the ones i usually use in Timers.

And For Each did not work with Timers on my last project (like I said few posts back).

Here is a capx that seems to do what Megatronx described in his post on top of that page.

No bug as far as I can tell, everything is working as intended.

And obviously, you can't "set a timer in a for each loop". "On timer" is a trigger. It will be the event triggered first. You can't run a "for each" loop every tick and have it recognize a trigger event inside it. That's not how events work, and it's not specific to the Timer behavior.

And no need to add a for each loop under it either, C2 does it internally (proof in my capx when you see the three workers you've created on the same tick moving away at the same time).

It all sounds as unproper events rather than actual bugs in C2 itself. Without a capx to look into though, no way to tell for sure.

Also if you try something like different tag names relying on the UID of the objects, it is just bad design on your part I'm afraid.

It obviously can't work, since, as mentioned, you would indeed need to loop through each instance to get its UID, and it can't work with the trigger system.

It's also, not required.

For each may be needed, depending on the circumstances.

Here is a capx that seems to do what Megatronx described in his post on top of that page.

No bug as far as I can tell, everything is working as intended.

And obviously, you can't "set a timer in a for each loop". "On timer" is a trigger. It will be the event triggered first. You can't run a "for each" loop every tick and have it recognize a trigger event inside it. That's not how events work, and it's not specific to the Timer behavior.

And no need to add a for each loop under it either, C2 does it internally (proof in my capx when you see the three workers you've created on the same tick moving away at the same time).

It all sounds as unproper events rather than actual bugs in C2 itself. Without a capx to look into though, no way to tell for sure.

Also if you try something like different tag names relying on the UID of the objects, it is just bad design on your part I'm afraid.

It obviously can't work, since, as mentioned, you would indeed need to loop through each instance to get its UID, and it can't work with the trigger system.

It's also, not required.

Don't have beta installed, otherwise would check the capx.

Originally I had system like this:

For Each "Dude"

|State="A"

|| Distance between dude and his current target less/equal X

|| - Change State to "B"

|| - set Timer "Time" to Seconds

||Else

|| - Do Stuff, walk towards target etc

On Timer "Time" : Call functions, Change Target, Set state to "A"

Everything else I did later on, all the changes, those were just an act of desperation. You all say this should work, and I also thought so, and it did for a bit, then started slowly dropping characters one by one.

You all say this should work, and I also thought so, and it did for a bit, then started slowly dropping characters one by one.

So it is fair to assume that you just messed up your code.

Since the examples of code that were provided in this topic do work as intended.

> You all say this should work, and I also thought so, and it did for a bit, then started slowly dropping characters one by one.

>

So it is fair to assume that you just messed up your code.

Since the examples of code that were provided in this topic do work as intended.

Yeah, it's possible.

i just made a quick example to test how it behaves in r203 and most times it works fine... but not always. There are 10 instances of Sprite and from time to time

"On Timer "go"" will not trigger for random sprite. It will just move in one direction and timer is not present/visible in debugger.

i just made a quick example to test how it behaves in r203 and most times it works fine... but not always. There are 10 instances of Sprite and from time to time

"On Timer "go"" will not trigger for random sprite. It will just move in one direction and timer is not present/visible in debugger.

Maybe sometimes random selects 0?

I just added timer to my new events, For each of course, and it's working fine. Basically created boolean Wait, that goes true after triggering timer. More hustle. There should be conditions really. I don't really remember how I used to set up timers in the past, but they seam to work fine without "On Timer" and without extra variable. But hey, anyway, it works now, at least in my ocd setup.

random (1,3) if 0 rustles your jimmies.

check my example on last page.

each tick my event is hit in this order:

1. if any enemy that is in family Enemies has a line of sight towards boatPlayer (your boat that you controll)

a) what is important here is that engine already checks on ALL of them on screen! (no need for foreaches)

b) if one has no line of sight - there's no need to check other conditions so it moves on to next

c) when all enemies are iterated and checked in that TICK - those who have all conditions met will shoot, others won't

2. check if FiringDisabled = 0 (it's a instance var which describes if some enemy can shoot at that moment, used it to set up timer) - if it's 0 - firing is not disabled - therefore you can shoot. if(1) - can't shoot - will SKIP that enemy again! and internal foreach will move on to the next enemy (in that tick)

3. check if kamikaze = 0 (another instance var which describes if my boat shoots or doesn't shoot) - kamikazes (where kamikaze = 1) rush into you, other boats shoot. if that condition is not met next - again in that tick it skips all the enemies that are kamikazes.

4. if animation death is not playing (checking if enemy is dead)

now what happens next?

in that same tick if all 4 conditions are met - has line of sight + firingDisabled = 0 + kamikaze = 0 + is NOT playing "death" animation

THEN - that one enemy that met all those conditions - spawns a cannonball, sets it's angle towards me, bullet speed, and runs a timer that says "Enable firing" for some time..

now what is important here is - THIS TIMER IS LIKE A LOCAL VARIABLE. it's bound to the instance it's called from.

internally an ENEMY that has timer has only his local timer.

now another important part here - i SET FiringDisabled = 1 FOR THAT INSTANCE (which is automatically selected internally) - right after timer kicks in. now as i watch this code i come to a conclusion - timer kicks in, but my event moves on - therefore timer works on another thread waiting for some time to end.

anyway setting firingdisabled to 1 i've disabled this instances shooting, because in the NEXT TICK when this instance is selected again and it's conditions are checked - it will FAIL on condition 2. (CHECK UP in the post) - because it can shoot only when firingDisabled =0. now the timer is counting and that boat isnt' shooting, but once the time has passed, internal TIMER of that single instance (let's say for example it was set to 1SEC and we have 60FPS whole time), will call a function and set THAT INSTANCES variable firingDisabled back to 0. once it does, IN NEXT TICK - when your enemy is selected again and all 4 conditions up there are met - he will shoot again, set the variables and call timer again.

now you probably wonder why i metioned 60FPS and 1SEC. if your timer is let's say 1 SEC for something and you have 60FPS ingame, that means 60 TICKS per second when everything is recalculated. that means that THAT INSTANCE OF BOAT is selected 60 times in a sec and it's conditions for shooting are evaluated 60 times, AND THEY MUST BE written really good - because one condition is false - SKIP, all are true - enter into event!

and selection is already done internally by engine.

There are chances the <on timer> picks more than one instances. So you'll need to put a for each inside the <on timer> trigger.