Construct 3 suggestions & ideas

Suggest and vote on ideas for Construct 3! Please note this is only one aspect of planning. We do not guarantee any features here will be implemented, even if they are top-voted ideas. The aim is just to collect feedback. Remember to search for existing submissions before adding an idea, describe your ideas as comprehensively as possible, and vote for plausible ideas that are well thought out. Please see our full guidelines on suggesting features.


Behaviors have lots of conditions that are only found when using "Compare Two Values" - Please add to behavior condition lists.

Almost every behavior has parameters/variables that can only be retrieved when using "Compare Two Values". This makes things difficult when picking/filtering the correct objects.

For example, if I want to retrieve an object's bullet.angleofmotion, I have to use "Compare Two Values". I cannot retrieve this from the normal list of conditions for the bullet behavior.

I've attached some examples showing the list of conditions for bullet and platform behavior when using "Compare To Values" VS. otherwise.


  • Matt Gruber
  • Oct 27 2018
  • No status
  • Attach files
  • Admin
    Ashley Gullen commented
    October 29, 2018 12:56

    The bullet angle of motion is a tricky example, because angles are cyclical instead of linear, and so it's usually incorrect to use the "Compare two values" condition with angles (you'll get weird results around the 0/360 degree crossover point). The angle-aware comparison conditions that e.g. Sprite has are "Is between angles", "Is clockwise from" and "Is within angle". Ideally we can find a way to avoid reimplementing the same three angle conditions every time there needs to be an angle comparison. There are already system conditions for these which are re-usable, but then since they don't pick instances, you have to precede them with a "For each" condition. So in this case there seems to be a trade-off between either copying sets of conditions, which we'd prefer to avoid, vs. convenience using events. I don't think it's particularly clear that one way is definitely better than the other right now.

    You can also use the 'Pick by comparison' system condition to pick anything that has an expression but not a condition, so there's a workaround there.

  • Matt Gruber commented
    November 07, 2018 17:11

    It just seems like common sense that anything with a behavior should be able to retrieve its own parameters without having to use system conditions or extra picking conditions. As it stands, the line between what can be retrieved with 'compare two values' vs. through the object itself is a bit blurry.


    The bullet angle of motion example is kind of an outlier due to it being cyclical. Even so, you can only retrieve it using "compare two values" or "is between angles", not through the object itself.

    All of the platform movement's parameters are only retrievable through "compare two values". Despite this, you can retrieve "Speed" through the object itself...which I'm pretty sure is just the vectorX anyway so that's kind of confusing. Or perhaps it combines vector X & Y to return the angular velocity?

    Another odd case is the sinewave behavior where there is some overlap. For example, you can retrieve both magnitude and cycle position via 'compare two values' or through the object itself. Perhaps there is some difference between the similarly named conditions I'm unaware of?


    Again, it just feels like the line between the two is blurry. If I were to write a custom event-based behavior then all of the parameters would be found in private variables, and I'd be able to retrieve them all through the object itself. Seems more simple and streamlined that way. I always looked at "Compare Two Values" as a condition that excludes instances and is reserved for more specialized comparisons. To use it in the way you described feels like a workaround.