As far as I know, all "object condition" (meaning, not the system conditions) behaves like this:[code]- loop through all instances
- if an instance match the condition, add the instance to a picking list
-> then apply action to this picking list[/code]
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 (: )