[Resolved] Display Group Object Index Order Keeps Moving (Not A Question About Display Order)

Pace · March 20, 2013, 9:52am

I have made a display group and inserted image objects into it using a for loop like this:

(there may be mistakes here, the code is just to get the point accross :unsure: )

for x = 1,4 do local object = display.newImage("object.png") object.x = math.random(20,100) object.y = math.random(20,100) object.isBodyActive = true &nbsp;&nbsp; physics.addBody(object, "static", {density = 1, friction = 0, bounce =0, radius = (object.contentWidth\*.33)}) objectGroup.insert(objectGroup,object) end &nbsp;

The objects in the objectGroup are not meant to move on screen, just detect collisions.

I have not set the objectGroup’s x and y

Later I loop through the objects in another for loop, and use their x and y positions in calculations.

for x = 1,4 do &nbsp;&nbsp; local deltaX = objectGroup[x].x - player.x &nbsp;&nbsp; local deltaY = objectGroup[x].y - player.y --- other stuff here end &nbsp;

So to my question, I am finding that some of my calculations are not repeatable because the objects for some reason are moving in the table.

for example in one call to the for loop the order is {obj1, obj2, obj3} and the next call to the for loop, the order ends up being something like {obj2, obj1, obj3}

So, to sum it up, why are the elements of the display group changing position? The only thing my code does with them is read the object’s properties.

Thanks for any help,

Pace

roaminggamer · March 20, 2013, 6:05pm

@Pace,

Do you mean the indices of the objects are changing? This is a what I gather from your statement:

“in one call to the for loop the order is {obj1, obj2, obj3} and the next call to the for loop, the order ends up being something like {obj2, obj1, obj3}”

If so, I’m not sure why, but can offer an alternative till you get an answer.

In addition to adding the objects to the display group, create an index table for them and use that to iterate over the objects. Those indices will not change.

See code w/ my initials (EFM)

local myIndexTable = {} -- EFM Create the index table for x = 1,4 do &nbsp; &nbsp;local object = display.newImage("object.png") &nbsp; &nbsp;object.x = math.random(20,100) &nbsp; &nbsp;object.y = math.random(20,100) &nbsp; &nbsp;object.isBodyActive = true &nbsp; &nbsp;physics.addBody(object, "static", {density = 1, friction = 0, bounce =0, radius = (object.contentWidth\*.33)}) &nbsp; &nbsp;--objectGroup.insert(objectGroup,object) -- Side note: Your code will work, but this is more standard ==\> --EFM objectGroup:insert(object) myIndexTable[#myIndexTable+1] = object -- EFM Fill the index table end

Then later,

for i = 1, #myIndexTable do local object = myIndexTable[i] ... Some code using 'object' here end

Pace · March 20, 2013, 6:41pm

@roaminggamer

Thanks for the reply.

You are correct in your understanding. The indices are changing.

The reason it is a problem is if you can imagine sending a ball down a path to hit a target. The path has wind from various objects pushing the ball in different directions,

as well as sloped holes pulling it depending on how close you are. Each object’s effect on the ball have to be calculated and will change the ball’s positon.

If the order of the calculations changes then the ball’s path changes, even if the player makes no changes to the ball before sending it.

I have thought of putting the necessary properties into a new table, but it seems like coding around a problem that I don’t understand (and may be a bug, err… feature), and I was wondering if there is just something that I might be doing to cause the re-ordering.

Another thing I will try when I get back to it is explicitly setting the index to the loop’s index:

for x=1,4 do ....... objectGroup.insert(x,objectGroup,object) end

Mayber that will nail them in place.

Thanks again, I will update this with what works.

Pace

Pace · March 21, 2013, 6:01am

@roaminggamer

I finally figured it out (I think). After creating the display group, I use :toFront and :toBack calls on some of the objects.

I believe this is what is causing the change in indices because the z order is determined by the inex of the object in the display group.

To get around this I made a new table to preserve the order of the objects, as you suggested, which is working as it should.

Thanks for your help,

Pace

roaminggamer · March 21, 2013, 4:40pm

@Pace,

Congrats and that is good to know. I generally use tables to track large groups of objects that I want to iterate over and it is good to know that caution should be used if use a group’s indexing methodology instead.

Cheers,

Ed

roaminggamer · March 20, 2013, 6:05pm

@Pace,

Do you mean the indices of the objects are changing? This is a what I gather from your statement:

“in one call to the for loop the order is {obj1, obj2, obj3} and the next call to the for loop, the order ends up being something like {obj2, obj1, obj3}”

If so, I’m not sure why, but can offer an alternative till you get an answer.

In addition to adding the objects to the display group, create an index table for them and use that to iterate over the objects. Those indices will not change.

See code w/ my initials (EFM)

local myIndexTable = {} -- EFM Create the index table for x = 1,4 do &nbsp; &nbsp;local object = display.newImage("object.png") &nbsp; &nbsp;object.x = math.random(20,100) &nbsp; &nbsp;object.y = math.random(20,100) &nbsp; &nbsp;object.isBodyActive = true &nbsp; &nbsp;physics.addBody(object, "static", {density = 1, friction = 0, bounce =0, radius = (object.contentWidth\*.33)}) &nbsp; &nbsp;--objectGroup.insert(objectGroup,object) -- Side note: Your code will work, but this is more standard ==\> --EFM objectGroup:insert(object) myIndexTable[#myIndexTable+1] = object -- EFM Fill the index table end

Then later,

for i = 1, #myIndexTable do local object = myIndexTable[i] ... Some code using 'object' here end

Pace · March 20, 2013, 6:41pm

@roaminggamer

Thanks for the reply.

You are correct in your understanding. The indices are changing.

The reason it is a problem is if you can imagine sending a ball down a path to hit a target. The path has wind from various objects pushing the ball in different directions,

as well as sloped holes pulling it depending on how close you are. Each object’s effect on the ball have to be calculated and will change the ball’s positon.

If the order of the calculations changes then the ball’s path changes, even if the player makes no changes to the ball before sending it.

I have thought of putting the necessary properties into a new table, but it seems like coding around a problem that I don’t understand (and may be a bug, err… feature), and I was wondering if there is just something that I might be doing to cause the re-ordering.

Another thing I will try when I get back to it is explicitly setting the index to the loop’s index:

for x=1,4 do ....... objectGroup.insert(x,objectGroup,object) end

Mayber that will nail them in place.

Thanks again, I will update this with what works.

Pace

Pace · March 21, 2013, 6:01am

@roaminggamer

I finally figured it out (I think). After creating the display group, I use :toFront and :toBack calls on some of the objects.

I believe this is what is causing the change in indices because the z order is determined by the inex of the object in the display group.

To get around this I made a new table to preserve the order of the objects, as you suggested, which is working as it should.

Thanks for your help,

Pace

roaminggamer · March 21, 2013, 4:40pm

@Pace,

Congrats and that is good to know. I generally use tables to track large groups of objects that I want to iterate over and it is good to know that caution should be used if use a group’s indexing methodology instead.

Cheers,

Ed