Why does Pick by UID has to be instance specific?

  • Why oh why oh why?

    When it's a completely unique identifier, why does it require you to select which sprites you want to choose the instance? Why not simply a broad "pick by UID" behaviour in the systems behaviours, and you are done?

    Would make many different peoples lives much simpler, and save some kittens from being nuked, and by that, I mean help me a lot :)

  • Agreed! Workarounds are possible, but all involve pain....

  • If there is a solid reason behind this that I haven't thought of, then fine, but I can't seem to find any reasons, and it's much simpler, more intuitive, without unnecessary boundaries if you don't specify object.

  • It's related to Object Definition and related values. Goes back to how programming works.

    class Fruit{

    int weight;

    int grower;

    }

    class Apple extends Fruit{

    string softness;

    }

    class orange extends Fruit{

    string juicyness;

    }

    you can access Apple Object based on the shared version

    Fruit current = *Apple;

    class Vehicle{

    string company;

    string mode;

    }

    class Bike extends Vehilcle{

    int wheels = 2;

    }

    Fruit current = Bike; BROKEN. That's a no.

    That's why UID must be specified with an object type. C2 doesn't have a root object type. You as the developer do that.

  • Well, logically, they could do it, but it has to do with picking. A pick by UID (as it currently is), sets the object type in the editor, so it knows exactly what actions to offer.

    A global pick by UID can definately happen, but with out some type detection events (like, if object is PlayerSprite), then only common events would be allowed. And I don't even think Destroy is common, because that isn't available to Mouse, etc.

    So you could pick, but without some type detection events, I don't think you could do anything with it. Now, if we get filtering type detection events, that could work...

    But then you could have done the selective pick that it currently does. I just don't think that works with their editor paradigm.

  • damjancd Wouldn't putting all the objects in a family and picking the family solve your problem?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • That's what I do when that comes up, I put all the objects in a family, and use it as the subject of the pick.

  • Families should be a good workaround for this. There are two reasons why there isn't a generic system action for picking by UID which does not specify an object type:

    1) suppose it exists, and you use the condition. Which object do you put the action under? You don't actually have a way to use the object you just picked.

    2) there are some pretty complicated optimisations in the event engine to ensure picking happens fast when it comes to subevents. One of the things it needs to know in order to optimise this well is which objects might have their picked objects changed. A condition which could pick from *any* object type therefore means no optimisation can happen. Due to how the engine works, running that event would take O(n) time, where n is the number of object types in the project. So the bigger your project gets, the slower that condition would get. It is more important to make bigger projects fast than smaller ones, so that's not acceptable.

  • Thank you for your replies, it makes sense now. Especially the two unbeatable reasons explained by Ashley

  • Yeah man, put them in to families, add variable to it, so later you can pick an object in the family and check if the object has particular variable value and you're ready to go ;)

  • megatronx That makes a lot of sense, using this I can just specify a family without going into the details of exactly what object I'm hunting for?

  • Yes. Just make sure you will have a way of checking if that's the object you want by using variable.

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