The case of ordering family effects AFTER object effects, not before.

0 favourites
  • 4 posts
From the Asset Store
A collection of various zombie characters sprites for creating a 2D platformer or sidescroller game
  • Ashley

    Currently, family effects are ordered before its objects' effects, which can result in effects that do not stack as intended.

    Please consider the following example:

    Since the 'brightness' effect belongs to a family, and the 'replace color' effect belongs to the the object inside the family, the result is a sprite with brighter original colors, not brighter replaced colors as it should be.

    Would it not make sense for family effects to be ordered AFTER its objects' effects, so that the object's own effects are accounted for?

    Ideally, we would have the option to choose if family effects should go before or after, since the above case will not always be what is intended. However, I would argue that it is much more often the case than not. Thoughts?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • It's out of the question to change the default since it would be a wide-ranging breaking change.

    Further, I think this is more complicated than stated - there is currently no UI to arrange the order, and there is also the question of if an object belongs to multiple families, what is the ordering between families? There is no way to arrange that order either, and I'm not sure how that could even be managed in the editor.

    Another option is to use all the effects on the object instead of the family, if that can be workable.

  • I think your response just proves my point that we need more control over this lol.

    The "simplest" implementation is just having the inherited family effects show up in the objects' effect lists, allowing us to reorder all effects as needed at the object-level regardless of where they come from.

  • The engine doesn't support that internally though, so I doubt it's a simple solution. That would probably be a pretty complicated overhaul.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)