Selecting last created Object

Is there any easy way of selecting the last created Active Object?

I'm going to say there's an easier way than this... but when you create an object you could just update a global value with the fixed ID of that object, and to select it, you just run through the objects to find the matching fixed ID.

I think my original question was a bit unclear.
When i said 'last created Object' i actually meant 'first created Object'

Example:
My Projectile generates Smoke Particles as it moves.
The Smoke particles are destroyed after their animation is complete.
I then want to select the 'backmost' or first created Smoke particle

...
Im wondering if

- Compair two genreal values: Smoke flag31 is OFF

will do the trick...?

If you spread the value 1 across all instances of the object, then the first created object, will always have an ID equal to the total number of those objects.

that doesnt make sense.. @kingcools post
the way you probably should do particles and selections etc. is follow these basic steps;

#1 create a particle/object
#2 always add 1 to a alt value of that particle/object
#3 when the alt value of a particle reaches (x) then you can directly work with that object; either deleting it, or even creating another particle/object from that one etc.

here the oldest particles/objects will always have the highest alt value, hence reaching a target number first.

now: finding a created object in any order can be done like konidias suggested with fixed values. BUT, you can also use a list object, which stores the ID's as they're created. that way you can directly pick ANY of the (n)th instance created.

Alternatively, you can give your smoke particle object only 1 animation, the Destroy animation. Once this animation is over, the object is automatically destroyed.

yes, but if you need to [select] that particle for some reason, you shouldnt put it in there.

Put what in where?

Its not exactly hard to find the latest created object, but its hard to find it in linear time. If you spread a value and compare to it, you'll be iterating through the entire list of objects in comparisons. I've got that problem in my level editor that uses the Create by Name object to create objects, but needs to assign values to them as they're spawned, looking at all objects as being in a single qualifier and applying the actions to that. If the CBN works properly, the qualifier will reference only that object. But if it fails because of a malformed or null parameter, or the maximum object limit, that code will scope every object in the qualifier, and shortly implode the program.

I'm curious on that note, if the line of code for "Compare to Fixed Value" needs to iterate through each object to check its fixed value (like alterable values), or if it is specifically coded to use that fixed value as a pointer to it and skip all that extra processing. Then you could basically do it like this:


+On Condition
= Set counter to # objects
= Create Object
= Set some buffer to Fixed("Object")

+# objects > counter
+Fixed("Object") = buffer
= Set value of object to whatever


Hence even if the system fails, it would fail gracefully. But if the fixed value needs an iterator to check, then its O(N) instead of O(1), which in a level editor that spawns N objects is O(N^2) vs O(N) and kablooey, makes the whole thing take 20 seconds to load a large level instead of a single frame
I'll try some testing to see how fixed values behave but I can only confirm if it works, not that it doesn't

Mmm im not sure after testing it. It was faster than an alterable value check, and at the same speed as the test case empty loop, but the FPS changes were only 10 to 15, not the order of magnitude you'd expect. CT just had to go and program their engine optimized enough to thwart me :(

Well... I was just thinking, since i often had troiubble in the past with Object Instance selection, where i wanted to handle Instances seperatly but instead only the first or last ( cant remember wich ) created Instance would be selected, and i though maybe this could be used to select first/ lest instance....

Pixelthief, I did a test, and it seems that finding an object by fixed value does in fact iterate through all the objects of that type. I tested this by creating a large number of objects with a loop, then using another loop that finds a random object by fixed value each time. Look at the file attached, run the application, then press Space. Note how long a pause you observe in the counter. Then go into the events and increase the number of objects created, and you should see a proportionally longer pause. I changed it from 1000 to 3000 objects, and the pause was about three times longer, so it seems like MMF does iterate through every object to find the one with the right fixed value. :)

Derp, no file attached. But I take your word on it, so I constructed one of my own. I hadn't thought about judging the time based on increasing the # of objects

If you watch it, for whatever reason, checking by fixed values is faster than by alt. values, but not exponentially as you would expect- it scales up by # of objects like you say. But its always about 3x faster than alt values. So indeed, its not an O(N) way of checking it, its still O(N^2) for sure, but its 3N^2 vs N^2. So yeah, it wouldn't be stable for a critical component of my engine. Which gives me a toughy, do I edit my code so that it might perform marginally faster, when its already 60 FPS and doesn't show any signs of slowdown, or do I make it more stable, when I've scoured my whole engine to make sure theres never any possible bad input anyway? Either one does nothing perceivable off the bat, but a year from now might be a crucial difference. So I'll run with the faster one and comment out but not delete the other :)

Check out the attachment