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.

69 Vote

sprite(0).X for UID

I would like to have a similar index expression like sprite(0).X for UID's and SOL ID's

Currently you can pick an object in an expression based on it's IID like this sprite(0).X , that's a great feature but the IID is the least used index as far as i know. In my opinion this would be a lot more useful with UID's and SOL (selected object list) ID's.

UID's are reliable and stay the same over the lifetime of the application. Imagine as an example a 2 player co-op game and at the end of the level you want to show the overall score of all players combined, you can simply do score_text | Set text to "overall score: " & player(player1UID).score + player(player2UID).score 

With SOL ID's, in case it isn't clear, i mean the Pick nth instance condition but in expression form. This would be very useful for example to distinguish objects in an collision event between two instances of the same object. fireball | On collision with fireball -> Functions | call explosion ( strength: fireball(0).size + fireball(1).size ) , without this you would need to create a local variable, pick the first instance, save it's information in the local variable, reset the SOL, pick the other object and then you can call your function and send the information from the local variable and from the object that is now picked.

So to sum it up, both of them are useful in different situations to distinguish and access different instances of the same object in expressions, it can eliminate or reduce the need of repeated filtering and resetting of the SOL just to temporarily save information about them in local variables.

Now i know it can't work the way i wrote it here, sprite(0).X can't refer to the IID,UID and SOL ID at the same time. sprite(0).X also has to stay the same and refer to IID's so it doesn't break backwards compatibility. I have 2 suggestions on how it could work and a 3rd one i don't like so much.

1st option is to use different symbols

sprite(0).X = IID

sprite[0].X = UID

sprite{0}.X = SOL ID

but i can imagine it's likely problematic to have these kind of symbols [] {} in expressions, i do like this version because it is nice and short, and is consistent with the way it's done with IID's. Maybe there are other symbols that could be used?

2nd option is to write it like a parameter list

sprite( IID, UID, SOL ID ).X

sprite(0).X = IID still backwards compatible

sprite(,0).X = UID leaving the first parameter empty 

sprite(,,0).X = SOL ID leaving the first 2 parameters empty

This version is not as nice, but it is still short, and consistent with IID's. It is extensible as well, and would make it possible to mix and match sprite( 0, 1, 2 ).X even though i can't think of a use case for this at the moment.

The 3rd option i can think of would be something like this

sprite(0).X = IID

sprite.pickInstanceUID(0).X = UID

sprite.pickInstanceNumber(0).X = SOL ID

It would do, but it's long, not pretty and not consistent with IID

  • Tacker Tacker
  • Nov 30 2019
  • No status
  • Attach files
  • Tacker Tacker commented
    5 May 06:07pm

    I since moved on to Godot, so I'm no longer used to Construct.

    But I remember there were some workflow cases that are difficult to manage, and since there are multiple similar suggestions on here I think I wasn't the only one. I hope the discussion keeps going without me, and that there will be a solution found for these cases, even if it's completely different to my proposed implementation.


  • Admin
    Ashley Gullen commented
    5 May 02:36pm

    The Sprite(N).X feature already works by what you call SOL IDs. Sprite(0).X gives you the first picked sprite instance's X, Sprite(1).X gives you the second picked sprite instance's X, and so on. So this part of your suggestion appears to already exist.

    As for some other syntax for pick-by-UID, I feel this goes against the design philosophy of Construct. Actions work on the picked instances - anything not meeting the condition is removed from consideration. If you can pick by UID regardless of the conditions, this seems to go against the picking system and allow you to "break out" of conditions and pick something that didn't meet the conditions anyway. The existing Sprite(N).X feature works within picked instances, so stays within the picking system - allowing you to access expressions of all the picked instances, not just the first. I think that within the design of Construct, it's the job of conditions to do picking, and that's what the existing 'Pick by unique ID' condition is for.

  • Tacker Tacker commented
    14 Jan 08:37pm

    a 4th option could be

    sprite(0).X = IID

    sprite((0)).X = UID

    sprite(((0))).X = SOL ID

    I think I like this better than the version with the different bracket types (){}[], since it is easier to tell apart.
    Imo it's much easier to mistake these for the same thing

    sprite(0).X =/= sprite{0}.X

    versus these

    sprite(0).X =/= sprite((0)).X

  • Jase00 commented
    2 Dec, 2020 06:52pm

    This would be so useful

  • Tacker Tacker commented
    6 Dec, 2019 04:13am

    Oh yea, they are pretty similar from the idea, however i think the tags make it very different in detail, having both strength and weaknesses.
    Tags would be something that needs to be newly created, while UID's and SOL ID's are already part of every object. UID's and SOL ID's can't be set or changed by a user. Tags would need new UI to make it possible to set tags in the editor, new actions for every object to set them on runtime and conditions to pick/filter by them. Tags would be more readable/easier to understand.

  • dop2000 commented
    5 Dec, 2019 02:39am

    I posted a similar suggestion, but with tags:

  • +41