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.

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

I'm having the same problem as the user above.

Going to (userdirectory)\AppData\Local\Chromium\User Data\Crashpad\reports

and loading the dump file there results in:

https://gyazo.com/00410cda75a0ce828febfe9cc0581ee1

Sadly this does not really give me any hints as to what could be happening, so <img src="{SMILIES_PATH}/icon_e_sad.gif" alt=":(" title="Sad">

Hey Guys. I just saw Spriter Pro available in Steam:

For those who can't afford it, you can buy it here for a $1.00:

https://www.humblebundle.com/game-devel ... ero_image0

This is pretty cool but it's a shame it's Steam only, I've had serious issues in the past with using software through Steam (namely Construct 2 itself with the weird opt-in/opt-out of beta policy). Price is a steal though so I bought a bundle anyway.

I see I see. yeah, being able to completely manipulate every object could be useful/helpful here.

there's a tiny bit of maintenance work for me, but very little. I basically just import an object once, add it to a family, and I'm set, so long as the object names stay the same. It ultimately depends on your system and what you're trying to do though.

anyway, sorry I can't be of any help.

12/26/2016 Download new version

• Fixed a bug that would cause a javascript error when using the transitional old style version of the plugin (doesn't apply to most. If you have no idea what this means, it probably didn't/won't affect you)
• Fixed a bug that would cause a javascript error when attempting to start a layout where scml objects had no scon or scml file set.

BBaller1337 - so are you saying if scml returned negative width when it was set to mirror that would solve our issues? Or is it something more. If that's it, I'll see what I can do - I need to make sure that there aren't any unforeseen issues with changing that, but nothing immediately comes to mind.

Yes, it almost certainly would (unless stricky knows of something else/some complications)

sagispin I think objectX/Y and objectAngle would come in handy here? I'm not sure for the other properties though, and I'm guessing there's some reason you want the fireball as its own SCML object and not as an object within the character project, huh? I guess I'm just having a hard time seeing what you're trying to do.

As far as attaching an object (e.g. a sprite) to one of an SCML's object though, it's possible, as I've done it: but I put the actual sprites/collision boxes I want to attach stuff to into their own family, then basically pin effects to that sprite family, and I know which sprites to pick because each one is associated with the SCML object that owns it... but it's a little complicated and my situation is a bit different I think, so eh. But a lot is possible with a bit of creativity

---

P.S.: I got a new error recently but I haven't been able to replicate it

Since the game works even with it, I can't replicate it, and I don't have any real info besides the above (that it's trying to set the sound volume of a triggered Spriter sound to a float before returning it, I think, and somehow that's causing an error), I'm not going to worry about it too much, but if anyone somehow knows anything, feel free to let me know~

BBaller1337, I came across the exact issue you describe and many others because I was applying my logic to directly to C2 sprites or SCML objects. I made the painful decision to redo everything and pin my sprite/spriter objects to a C2 sprite first and it makes everything much cleaner and eliminates many, many issues like this.

Trust me, the further you go down this route the more painful it will become.

Hmm. Interesting response. And I am grateful for your post/indirect advice, but do you mind if I ask some questions?

By "directly to C2 sprites", you mean to the objects that Spriter creates?

Are you pinning every spriter/sprite object to a single Sprite object that you create? (Just trying to clarify what you meant)

Is having more objects as a result not a concern for you/is it just better than the alternative? What about the complications in logic and handling objects caused by abstraction?

Probably most importantly: what other issues do you have?

My current project is very far into development, the code works and it works well, and after some recent (much-needed) polish/optimizations/clean-up is at a point it's easy to understand, makes sense, is flexible, etc.

I quickly fixed the issue I shared above by making a mod of line of sight as I kind of needed to anyway because the default line of sight doesn't have all the functionality I would like anyway (e.g. sorry Ashley, but why can't we have line of sight in a direction different than the object angle? ). I could have maybe done something about it on the SCML side but I'm a little bit more intimidated by that code (i.e. afraid of breaking it) and I needed the LoS Mod anyway

But I'm curious what other concerns/issues there could be. Over 6 months back I did run into issues with things like... for instance, picking the hurtboxes (collision boxes) belonging to an SCML object when both objects are encapsulated by families, i.e.

PICK SCMLFAMILY | DO THING WITH HURTBOXES FAMILY

would not know to pick the hurtbox(es) that are in the container of the SCML object picked in the SCML family, but I resolved this ages ago as well. And I don't think abstraction through a sprite object would fix this anyway...

In other words, if you're willing to help, more information would help me make a more informed decision. Time is money and all that and trying to recode things would be an extreme setback that would kill both progress and motivation, but based on what you say it may be worth it anyway, haha. I guess I'm just skeptical because I've managed to get everything working pretty well so far, even if it took some working around things, and I don't think the abstraction would have helped with anything anyway--with the exception of this issue, but I can also see a lot of cons to it when I draft it up in my head...

Ditto, I think complete search functionality really helps with workflow. If you wanted a stretch goal after, find/replace can be useful too, in certain contexts. XP

lucid Seems like my initialization time is also faster, and I don't even have a lot of instances (yet), though I didn't measure it or anything

Unfortunately I did come across a bit of an issue if you will... though I'm not sure this is something you'll want to solve.

Down to it: if you mirror the scml object, the width does not change to negative: what changes are the widths of the attached sprite objects. Thus if you try to use line of sight on the scml object, it will not work properly because the LoS behavior will not update the angle to reflect the mirroring. In other words, it will always detect line of sight in one direction, but not the other.

My expected response to this is "why are you using line of sight directly on the scml object? you should be mapping the scml object to a sprite first and doing everything on that"... or something, but let's just say I'm not for whatever reasons, since such an answer wouldn't really tackle the issue as I'd like (and I don't want to argue about the alleged usefulness of abstracting every scml object with a sprite object).

I'm going to think about how I can fix this—preferably without modding the line of sight plugin itself, since it's not really at fault here (I think I'll just change my general approach instead) but in the mean time, I thought I'd let you know to see what you think.

It's hard to say. You haven't said what the complete mechanic is supposed to do.

I can tell you that the for each is probably not needed, and that it will definitely cause a slow down with a lot of instances.

btw, didn't mean to ignore you earlier, just kinda slipped my mind

the complete mechanic is irrelevant IMO since the problem is only "how to detect line of sight between two objects in the same family based on instance variables", not "what to do once line of sight has been detected"

and the for each is needed logically as mentioned (but not picking-wise since C2 does that already), and generally there won't be more than 5 instances of a "Fighter" object at once so I don't think scaling is an issue: even at 10 instances it should be fine, and the code and other such things are generally optimized throughout.

I have a problem with the logic of the assumption.

Say, the goal is to minimise lines of code.

Starting from 1 object. Addressing is no problem.

Need many, use instances.

Need many objects and there instances, use a family.

Next logical step would be a group containing 2 family's. Cant have a group of family's, but can use 2 family's.

unfortunately I did not understand the last sentence. what do you mean by a "group"? and what is the "problem" that you are trying to solve as you see it?

Thanks for the update! That should prove helpful.

Thanks also for the details, I'll look into what you said when I have a chance. =)

99Instances2Go haha sorry, I knew that code would not work, I just wanted to illustrate the logical conundrum, since I came to the same conclusion that you did... but did not have a solution besides my hacky one.

As for your solution, thanks a lot, it looks cool... but it does kind of defeat the premise of the problem, which as the topic states, is that they are in the same family, not different ones. I could arbitrarily create another family, but it feels more like avoiding the problem. Still, it's basically a solution, so thanks.