Picking: are instances ordered

Discussion and feedback on Construct 2

Post » Sun Nov 11, 2012 6:04 am

Each time an event is run, it's action are applies to each picked instance until all picked instances have been affected.

Assuming I set up an event's conditions so that the same instances are picked each time, can I rely on the instances being affected in the same order each time, or do I need to use an ordered for each loop (sorted by IID) to guarantee the order?


For example, let's say I have conditions such that MyEvent picks instances we'll nickname Foo, Bar and Baz (which are all instances of MySprite) on each iteration and that on the first pass through the event sheet actions are applied first to Bar, then to Foo, and finally to Baz. Can I rely on actions being applied in the same order (first Bar, then Foo, and finally Baz) on each subsequent pass through the event sheet, assuming of course I don't do anything to intentionally alter that order or pick different instances?


I know I can definitely achieve this using an ordered for loop, but my event sheet will be a lot cleaner if I don't need to do so.


Thanks in advance again!
B
24
S
5
G
2
Posts: 104
Reputation: 3,136

Post » Sun Nov 11, 2012 6:43 am

My working knowledge of picking is, each object is ran in order that it was created(uid).
That is unless you change how it was picked, for each ordered, etc.
As always keep in mind that uid is assigned to all objects, so one instance of a sprite might have a uid of say 1, but the next instance of that sprite might have a uid of 3 if some other object was created before it.
Image Image
B
161
S
48
G
90
Posts: 7,347
Reputation: 66,749

Post » Sun Nov 11, 2012 8:15 am

Thanks newt, I expected as much myself -- and testing seems to indicate this to be the case -- but I want to confirm it rather than rely on an apparent behaviour that might not always work reliably.

It doesn't matter what the UIDs actually are as long as the logic is always applied to the items in the same order.
B
24
S
5
G
2
Posts: 104
Reputation: 3,136

Post » Sun Nov 11, 2012 2:16 pm

It is generally the case that instances are run in IID order, but not always - using families will mean the instance order is a mish mash of different object types, and I can't think off the top of my head how that is handled. Still, I wouldn't rely on this behavior at all, because it could change in future engine updates.

To be honest, it's a very unusual question. Why would the order the instances are run in be important? If you have two separate events, as far as each instance is concerned they are affected in the order of the events, even if the engine ran the instances in a random order. It's actually quite difficult to make an event where the order instances are run affects anything. Why are you asking and are you sure your events have this requirement? You might be mistaken, and in fact the order instances are run in does not affect your events at all, even if you think it does.Ashley2012-11-11 14:16:37
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,544

Post » Mon Nov 12, 2012 12:17 am

I'm pretty sure the order is important -- however I've also realised that the most elegant solution also utilises the loopindex of an ordered for loop.

It's not that I have two separate events, but that I have one event where the instances need to be ordered correctly on each tick: I have a number of sprite instances, and I have a list of coordinates (actually two arrays) that I'm using to adjust the positions of those instances. If the instances were re-ordered between ticks they would be given a value meant for one of the other instances and therefore jump to the wrong position. This has all nicely been solved by using an ordered for loop sorted by IID however, which should be nice reliable behaviour.


To briefly explain, I'm making a game where:
- The game is played with an overhead view, and the player character is controlled via the 8-direction movement.
- The player has 6 "turns" to accomplish a set of goals, and each turn has a fixed time-limit.
- On each subsequent turn, a "ghost player" is spawned which carries out the same actions the player took previously, so that for example on turn 3 there is one ghost for turn 1 and one ghost for turn 2.

I've got it working beautifully by recording the player's position several times per second and then lerping between those coordinates to reproduce smooth movement of the "ghost" characters.


Thanks again for your input Ashley!
B
24
S
5
G
2
Posts: 104
Reputation: 3,136

Post » Mon Nov 12, 2012 1:41 am

@jbadams Awesome, you're one step away from a Super Meat Boy replay system ;)
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Mon Nov 12, 2012 3:31 am

@squiddster:

I haven't actually played Super Meat Boy, but I am actually planning to re-use my functionality to allow players to re-watch their run-through as well if that's anything similar. I had the idea that allowing users to upload videos of their run-through to YouTube might make for a good premium feature -- everyone would get a small number of uploads, but you could buy more for a small price.
B
24
S
5
G
2
Posts: 104
Reputation: 3,136


Return to Construct 2 General

Who is online

Users browsing this forum: Artpunk, humanescape, newt, Yahoo [Bot] and 8 guests