"On fade finished" activates for other fade behaviors

Problem Description

An object has 2 fade behaviors.

Fade 1 activates.

Fade 2 has an "on fade finished" event.

When Fade 1 finishes, Fade 2's "on fade finished" event activates.

Expected behavior: Fade 1 finishes and Fade 2's on fade finished event does not activate.

Attach a Capx

https://ufile.io/fnxkw

Description of Capx

Extremely simple: runs a fade, and sets text if the other fade behavior is finished.

Steps to Reproduce Bug

Play the layout and watch.

Observed Result

The text changes even though it should only change when the corresponding fade behavior is finished.

Expected Result

Nothing.

Affected Browsers

• Chrome: Yes
• FireFox: Yes

Operating System and Service Pack

Windows 10 Home

Construct 2 Version ID

r243

happening for me as well.

Once any fade-in, wait or fade-out finishes it triggers for all the fades.

using r244

happening for me as well.

Once any fade-in, wait or fade-out finishes it triggers for all the fades.

using r244

Thanks for confirming. (Didn't even notice a r244 was out.)

I'm curious if there are any workarounds for this... can't think of any, and since the Fade behavior isn't a 3rd-party one, I'm less inclined to try and fix it myself... (though I also know Scirra is busy and all, so at least for a short bit, I'm stumped, haha, guess I'll wait for now)

EDIT: Took a brief look at the behavior code.

It seems like it doesn't account at all for multiple fade behaviors—it triggers stuff based purely on the object instance the Fade behavior belongs to—and I'm not even sure i t would be possible to "retrieve" the name of the Fade behavior since it seems like it's not a variable in the behavior but rather something that Construct 2 handles (and possibly internal, not sure and would have to look more into it, I'm just guessing here).

If my guesses are right though then one solution would be to add something like a "Name" or "ID" to the fade behavior and have the trigger events require a parameter for that, such that they only trigger for a fade with the corresponding name/ID.

I could probably do this myself given enough time, but it could be messier than something official, and in general I prefer not to mess with official plugins (for various reasons)—even if I did, I'd be inclined to make a copy, but changing my project to use said copy could be... tedious, if not problematic, so I'm once again stumped on what I should do. I thought about just using different objects for the different fade behaviors, but trying to work with both when they serve different purposes seems like an inefficient solution/general hassle. Hm...

Maybe I can work around the problem using some combination of instance variables/conditions (going to try now), but it'd be nice if this were upgraded to support multiple fade behavior instances attached to a single object instance.

well for a work-around you'd start the fade and set a flag and then in your OnFinished, just check the flag as well and that's how you'd manually figure out which fade had finished. You'd create a bool for each Fade.

well for a work-around you'd start the fade and set a flag and then in your OnFinished, just check the flag as well and that's how you'd manually figure out which fade had finished. You'd create a bool for each Fade.

Yeah that's what I did, it's just a little confusing to manage that for each one in a big project like mine, haha.

> well for a work-around you'd start the fade and set a flag and then in your OnFinished, just check the flag as well and that's how you'd manually figure out which fade had finished. You'd create a bool for each Fade.

>

Yeah that's what I did, it's just a little confusing to manage that for each one in a big project like mine, haha.

it's not too bad though, 2 extra Actions and only one extra Event Condition.

Start Fade

Set fade1 to true

OnFade Finished AND fade1 is true Then

reset fade1 to false

but I guess it depends on exactly how many objects you have fading and watching, then trigger when finished. I almost never use onFadeFinished usually for me it's fade and forget.

yeah exactly, it's just that it adds up when you have a lot and if I forget it could be problematic haha, it's not bad individually

Original project link unavailable so closing.

It seems like it doesn't account at all for multiple fade behaviors—it triggers stuff based purely on the object instance the Fade behavior belongs to

You're right, this sounds like it would explain it from the description, and it's an architectural oversight more than a bug. The proper fix would involve re-architecting all behavior triggers which would be quite a lot of work, and possibly cause compatibility problems with third-party behaviors. So I think it would be easiest to fix this in the upcoming C3 runtime which is being rewritten anyway.

I'm not sure why you'd want to use two of the same behavior anyway - why not just adjust the settings of one?

Original project link unavailable so closing.

> It seems like it doesn't account at all for multiple fade behaviors—it triggers stuff based purely on the object instance the Fade behavior belongs to

>

You're right, this sounds like it would explain it from the description, and it's an architectural oversight more than a bug. The proper fix would involve re-architecting all behavior triggers which would be quite a lot of work, and possibly cause compatibility problems with third-party behaviors. So I think it would be easiest to fix this in the upcoming C3 runtime which is being rewritten anyway.

I'm not sure why you'd want to use two of the same behavior anyway - why not just adjust the settings of one?

Ehhmm, so C2 fade behavior will still bugged?

Original project link unavailable so closing.

> It seems like it doesn't account at all for multiple fade behaviors—it triggers stuff based purely on the object instance the Fade behavior belongs to

>

You're right, this sounds like it would explain it from the description, and it's an architectural oversight more than a bug. The proper fix would involve re-architecting all behavior triggers which would be quite a lot of work, and possibly cause compatibility problems with third-party behaviors. So I think it would be easiest to fix this in the upcoming C3 runtime which is being rewritten anyway.

I'm not sure why you'd want to use two of the same behavior anyway - why not just adjust the settings of one?

Whoop, didn't think the link would die out, sorry about that. Though you responded anyway, so it's not a big deal.

Yeah, it's not a bug per se, just intended to work differently than what I expected. Sorry if I worded any of my posts poorly. I understand the situation and as you implied, I think a C3 adjustment would be the best course here, it's not a problem that can't be worked around in C2 and it's not a simple fix per se, nor is it an issue of much significance.

As for the answer to your question—ease of use/organization.

Let's say I have an object that fades in and out, each at 2 different speeds, meaning there are basically 4 ways it could fade. For each given fade, I could set all the values first before fading, but this would get a bit tedious/cluttered if I call a given fade more than once.

I could then put it in a function to fix that, but then I need to write (preferably using local variables) and call said function before every fade, and I'd rather have that information preset as part of the object/behavior since I'd be able to find it easily, rather than having to look up and edit a function.

Since I can rename behaviors, I thought it effective to name each Fade based on the type it is (e.g. "FadeIn", "FadeInQuick", "FadeOut", "FadeOutQuick"), then just call said fade, thus making it clear what kind of fade is happening, without adding the extra work/clutter of fade functions—C2 lets me set the values to start, anyway.

I'm not sure if there's a notable overhead for having multiple fade behaviors like that, but I can't think of any reason there would be. And if there's an easier way to do it than I've brought up, I apologize for having not been aware of it (and not coming up with it myself).

tl;dr, the issue could easily be considered a matter of convenience/organization and not essential, but might be appreciated in C3 should you find the time. Thank you kindly for responding and for your support.