Pick by UID change question

0 favourites
  • 12 posts
From the Asset Store
Simplistic hyper-casual game with nature elements. Tap to switch between the 4 elements and reach a better score.
  • Hello everyone, loving the new patch. One quick question though.

    The new patch has the following change:

    <font color=green>'Pick by UID' is now not invertible (use 'Object UID exists' system condition instead)</font>

    Can we still use ELSE events after it and would they enter if the Pick by UID failed to pick an object with that UID?

    Thanks, again loving the change. I am a big Pick by UID user (I use this to do event inheritances in families and better modularize my code).

  • It should do, just make a quick test and see if it works. It was just specifically that if you inverted the condition, that condition itself would never be true.

  • Just did, I can confirm that it works.

    Thanks Ashley

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ashley

    It's sad but there's no real equivalent to

    Sprite: [invert] pick by UID 

    anymore.

    I was actually using it a lot for connecting nodes (spliting games, node base system, etc)

    The basic pattern I was using was:

    // create a new edge and save the UID of first node
    + Mouse: on left click on node
       -> System: create object edge at node.X,node.Y
       -> edge: set new to true
       -> edge: set firstNode to node.UID
    
    // a new edge as been created
    + Edge: Is new
       // a close node other than the first Node -> we snap the edge to it
       + node: [invert] pick instance with UID edge.firstNode // so I pick every other
       + node: Pick nearest to (mouse.X, mouse.Y) // amongst every other node, the closest to the mouse
       + distance(mouse.X,mouse.Y,node.X,node.Y) < SNAP_RADIUS
          -> edge: Set angle toward(node.X, node.Y)
          -> edge: set width to distance(self.X,self.Y,node.X,node.Y)
          -> edge: set secondNode to node.UID
    
       // no close second node -> we follow the mouse
       + else
          -> edge: set secondNode to -1
          -> edge: set angle toward(Mouse.X,Mouse.Y)
          -> edge: set width to distance(self.X,self.Y,Mouse.X,Mouse.Y)
    ....

    Now, to be able to do the same I'll probably have to foreach through all the node, flag them with a boolean and then pick using this boolean, and to the nearest thing.

    That's kinda sad (:

    Also it seems that [invert] pick by UID does... the same as without inversion

    Test capx

  • Whilst I love this update, It's broken my whole clothing engine, along with my combat system in my project. I'll work with it though, it's better in the long run :P

    EDIT: Actually, No, this is so difficult to work around. Rolling back to previous update :(

  • Jase00

    Maybe you could show a sample of the code that is breaking.

    I'm wondering if removing the ability to invert pick by UID is a problem or not.

    In my situation explained above, I could solve the problem with a boolean.

    So it's less "sad" as I thought at first.

    But if you really found a case where the work around is messy, it would be a good argument to convince Ashley of the necessity of it (:

    also, I don't really understand how using Object UID exists is really equivalent to Pick by UID as suggested in the changelog.Pick by UID' is now not invertible (use 'Object UID exists' system condition instead)nless Ash meant it as "now you don't need to use Pick by UID to check if an object's UID exists" But I don't think it was the principal use of this action.

  • Using "Object UID exists" isn't good as I can't refer to the specific object. There's probably a way round it but I'm failing to figure it out in my mind.

    Yann I am pretty much having the same problem as you with your nodal system; I NEED to "Unpick" an object. My combat system requires the attacker to be unpicked from being attacked. Now all the characters just hit themselves since they are no longer "unpicked", rather than hitting the character in front of them. :(

  • Jase00

    Can't you add a boolean like attacker.ignored and switch it to true (somehow), and then use attacker: [invert] is ignored instead of attacker: [invert] pick by UID someUID ?

  • Yann

    Hmm, that sounds like it might work actually. However, I'm currently on the version below and don't really feel like tampering with this just yet XD Thanks!

  • I didn't know anyone used 'Pick by UID' inverted, it seems like a strange thing to do. But since people used it I'll try and get it working again for the next beta.

  • Is it bad practice/inefficient to use inverted 'Pick by UID'?

    Thank you! :D

  • Jase00

    As far as I know, all "object condition" (meaning, not the system conditions) behaves like this:

    - loop through all instances
    [ul]
    	[li]if an instance match the condition, add the instance to a picking list[/li]
    [/ul]  -> then apply action to this picking list

    So with a pick by UID, C2 was looping through all the instances just to add one to the picking list (also called SOL for Selected Object List I believe)

    Which (unexpectedly for Ashley) worked well the other way around: if you invert the condition, you'll loop through all instances, and add all those which don't have the given UID.

    But in the last release, I think Ash added a way to get an instance via its UID directly.

    Maybe he has an Array with all the instances indexed via their UID, or rather a hashtable (another name for dictionary).

    Anyway, it's a faster way to use this condition since you don't need to loop through all the instances anymore.

    However, if there's no looping anymore and you use the inverted condition, you can't really get hold of all the other objects.

    In my opinion, since it not only breaks the use of [invert] pick by UID but also breaks the untold rule (or hidden contract maybe) of "if you use an object's condition there's a hidden loop going on to build a picking list", I think the old behavior should go back.

    But that doesn't mean he can't keep the optimisation for when you use pick by UID I think.

    He can probably do something like "use the old behavior, except for this tiny little situation where you use picked by UID not inverted" (:

    (although exceptions like this in programming are always kinda sad (: )

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