And it would solve the longstanding issue that there is no way to create Performant Signals supporting multiple parameters that can trigger multiple event blocks efficiently. Which is a shame in a Eventsheet based game engine.

But anyway regarding Better Signals this would probably be a better solution : construct23.ideas.aha.io/ideas/C23-I-165

Yeah, That would be nice.

Then you could add "unpredictable tick order", "single timer only mode", etc. all to make up the performance difference... and now what's meant to be a simple feature is full of complicated configuration options, which makes it harder to use, unfriendly to beginners, makes the code much more complicated, and usually ends in lots more bugs. It's not worth it. It's pretty much the approach we took with Construct Classic years ago, and it ended in development hell.

Yeah, I agree with all of that - I think it would be way better to have to have a seperate behavior/or custom script altogether. Which incidentally is the way I already went.

I did not expect timers to be this complex :V

Haha, Ashley #2 point is super important in some types of situations. Many times not, but when it is, it def is.

But, I understand that it does all that, but why does the tween not have the overhead for "OnFinished" that the "OnTimer" does? I haven't looked through the tween code, but I assumed it handles its time in a similarly accurate manner?

It would be nice if both tween and timer had built a built in dt scale though. Sometimes it would be nice to scale dt for per obejct slow motion or speed up.

Thanks, great post!

I use a billion timers throughout my events, they're so efficiently convenient!

Sounds like it's better to let them go and to just use the old fashioned DT event method, I need all the performance I can get.

I mean, the ease of use might trump the performance. In my case I was using them on bullets in a bullet hell and well... performance was getting chewed up the way I was using them for EVERYTHING.

I'm looking over the behaviors code, I can understand why one might want a fake trigger for order of events stuff. (Right, true triggers can fire at any time? Or is the order in the event sheet still protected?)

But it still seems like there should be a true trigger for performance reasons.

I realized I'm using JSON object for almost everything now. It's not perfect, but so much easier to work with than C3 arrays.

We have dozens of large array files in the project because it's easier to edit the data in table format, but in runtime I convert them all to JSONs.

I'll have to look into this. My current project has arrays acting as an inventory of effects affecting the instance the array is connected to. I assumed it was better for performance reasons, but I haven't trie using json for it.

jup I brought this up before and wrote a suggestion to turn timers into true triggers.

It's not only bad for perf it also leads to the weird case where -> on timer triggers with multiple instances picked. (this lead to c3 user actually adding for each to every trigger as they stopped trusting triggers altogether, leading to even worse performance xD)

Was there a discussion at that time? How long ago was it? Is there a way to know if a trigger is fake? In c2 you could always check the behaviors code... because, you know... it was useful like that :p

Yeah it's kind of a pain: why can't conditions apply to all objects that it's valid for? For me, "Pick all" doesn't really act the same as "for each object" and it's difficult to tweak the code to make it act the same along with the benefit of lower CPU usage.

It really depends on what you are doing with each object after it is picked and what other objects you are referencing. So you have an example in psuedo code you could share?

Do you use the keyword "self" while writing expressions and events? If not, that would be an important reason things weren't working as you wanted.

I've noticed that the Moveto behavior maintains its speed when the target changes to the opposite direction... that it maintains its speed and "instantly" changes directions without regard to accelerations and deceleration seems like a bug. Even if you set rotation to > 0, the object weirdly hitches when the target switches to behind it.

I've already got my own moveto behavior so my work around is obvious, but it just seems like it shouldn't act like that.

Looks like subpixels are not rendered correctly when scaled down? But I dunno, someone with more knowledge gotta weigh in on that.

Originally I thought it was an issue with pixel stepping and the like, which was the first thing on the list of supsects, but you may be right. As I play with it more, it does indeed seem to be a rendering issue with sub pixels.

I mean, that's cool, but it is still a 3rd party plugin for what should probably be vanilla. At least its from a user with a grand reputation.

And donkey doughnuts UIDtoAnything! Yeah, that's another thing construct always needed.... handling references without having to pick objects over and over.

If I have an object that needs to do something in 10 seconds...

I can set a tween "" from x->y for 10 seconds.

I can set a timer "" for 10 seconds.

I can use a instance variable, set it to 10, and subtract dt every tick.

(If I didn't need bulletTime / scaled dt, I could also just store the current timestamp and check that against the current time.

For both tween and timer I can use the trigger onTimer "" and OnFinished "".

For the event based method, I can simply check if variable <= 0;

I wasn't too surprised that tweens perform worse than events. They have alot of extra fluff not needed for a simple linear 1:1 dt:value change.

But timers!!!! They are the worst even though the tween is mimicking a timer and can do so much more.

In a project with 20k objects tested with event based timers, tween based timers, and timer based timers... the event based timers were the only ones that could run at 60fps. The downside is that they had the overhead of needing to check if the timer variable was <= 0 every tick. The suprise is that the "trigger" for ontimer has exactly the same overhead, but the tween doesn't.

With the timer test, if no timers are running, the "OnTimer" trigger alone causes 30% cpu usage. When activating all timers, the project runs at around 27 fps.

With the Tween test, if no tweens are being run, the project sits at o-1% cpu usage. PERFECT... until you run the tweens and then you get around 27 fps. This indicates that tweens ARE slower than timers, but since timers have the overhead for the trigger, it evens out.

Events use around 30% cpu for the conditional check to see if a timer is done, and an additional 15% to simply add dt to the timer. Total 45%.

So basically, at scale, depending on needs and how often the timer is operational vs inactive, I would use either custom events or tweens.

HOW can events outperform the timer behavior!!!! The timer should be king in performance for all timer related needs... but it isn't.