Is there a limit to the number of inserts to a group?

Hi

I've been adding objects to a group without issue until the set I'm trying to insert.
I can add them to the stage fine, but any attempts to insert them into the main group then prevents that file from loading.

Does anyone know if there's a limit to the number of children that can be inserted into a group?

(I'm using Version 2011.484 (2011.4.12) - I don't want to upgrade this till I've finished my current project)

Thanks

Hey there,

Could use some more info on how you're setting things up; are you using modularized code and director? Are you getting any errors?

Peach

You'd be surprised....

1
2
3
4
5
6
7
8
local insert = 0
local group = display.newGroup()
while 1 do
 local rect = display.newRect(group,10,10,10,10)
   rect:setFillColor(255,0,0)
  insert = insert + 1
  print(insert)
end

Hi

Thanks for your responses.

It's quite strange. I've done this hundreds of times, but this time it's just not playing :

I'm using the Director class with 4 externals required in.

I have a few objects (40 or so) and all have inserted into the Director group fine.
But this last one, inserted just as the others, prevents that .lua file launching from the mainMenu.lua.

I've deleted all other references to it, so there's only 2 lines of code for this object at present - the one that defines it and the one that inserts it.

If I comment out the insert in the target .lua, that .lua launches fine it appears on the stage.
Strangely, if I try to do anything - such as position it (objectType5.x = 200, for example) - it also prevents the .lua from loading.

There's no errors - my mainMenu goes into the loading cycle as it normally does, but doesn't succeed in launching the target .lua (screen12.lua).

I've tried renaming the object and also replacing it with other instances of objects already working, all without success.

I'll keep at it, but bet me know if you have any thoughts..

Thanks again.

Hi

UPDATE : The file also began displaying the timer counting up in multiples of 4 seconds, rather than 1 second, even though I haven't been anywhere near the code for this.

So, I went back to a previous version from the 2nd Sept and have built all the newer elements again. The timer works fine now (?), but the main problem remains - it looks like any more than 51 inserts is the limit, though this depends on the object :

For example, I couldn't get the gfx objects to insert, so I tried commenting out some text objects (on screen feedback for me while developing) without success. However, when I commented out a gfx object, I could then insert one of those that I couldn't before.

This seems to point to a limit on the number of gfx objects that can be inserted. I'll test this some more but it'd be great to get around this, as I need to add another 3 or 4 objects before the level can be complete. Otherwise, it'll need to be re-designed with a few less elements..

kind regards

Perhaps you are getting a collision in your table keys? Or mixing numerical and non-numerical keys in a table where you use table.insert or #table?

I've found that I tend to use two types of tables for data (like display objects).

Type 1:

t = {}
t[1] = a
t[2] = b

for i=#t, 10000 do
t[i] = x
end

Everything in this table is inserted numerically, and I can add/subtract elements without ever creating holes. No holes means I can use #t all day long to find the next place I want to insert some data.

Type 2:

t = {}
t.var = 256
t.newkey = "data"

In this table, I have a bunch of keys, like player profile data or a Class Object. Some keys might be nil. The point is that every key is a string, which I need to look up specifically when calling that data back.

If you ever mix numerical and non-numerical keys in a table, you can start to run into serious issues. For example, display groups can hold lots of display objects which you reference by name, but which are stored numerically. Mixing types also makes #t unreliable, and pretty much eliminates any useful function of table.insert or table.sort

My gut reaction to your problem is to suspect that you are mixing up your table keys, which is leaving gaps in a table somewhere which you expect to have no gaps - or clobbering some key with some wrong type of data, which has the same effect.

All of this is a long way of saying - you probably shouldn't be working directly with display group insertions. Have your objects return a handle, and store those handles in a number-key tables. If you set that up properly, display group insertions / removals should handle themselves.

Hi Simon

Thanks for the reply, that's awesome.

I do use one table which stores only numeric values for the positioning of the objects and this works great. To be honest, I didn't expect to need 50+ items on the stage, so haven't included a way to define them from within a loop, though I may do that.

I'm using Director, so the objects are all inserted following that structure and this has been working for months. The strange thing (and I'd love your feedback on this) is that if I try to insert one more item it fails - regardless of what the item is.

Note that I can add these elements to the screen, it's simply using them (inserting, positioning or referencing in any way) that prevents the .lua loading. This means that it's not just the insert command that is causing issue, it's just happens to be the first operation prior to positioning etc.

The items I'm wanting to add are duplicates of items used before, so I know they are fine - and if I comment out any of the graphical items (display.newImage or display.newRect or display.newAnim) I can then insert a new one. This is true for each new item, which seems to point to a limit on gfx objects allowed, though this can't be true looking at some of the spawning samples. Funnily, commenting out a newText item has no effect.

So at present I'm reworking the screen to use less graphical objects to build the level. This is working fine, it's just baffling why I can't use a few more items. I'd love to find out why, if nothing else.

kind regards

I guess I can't believe that the number of inserted objects really matters, so I'm inclined to believe that somehow, earlier, an object was removed partially, or otherwise adjusted such that your list of display objects gets screwed up. But you don't notice it until you try to reference something which touches that corrupted data.

The situation just sounds like the classic "delete all entries starting from the front" problem - where you add items like this:

for i=1, 10 do
t[i] = "data"
end

and then later try to delete them all like this:

for i=1, 10 do
t[i] = nil
end

The problem, of course, is that when you nil out that first bit of data, the positioning of everything after becomes indeterminate.

Anyway, I'd scrutinize the places where, prior to this problem, you are deleting objects. I'll bet you find a smoking gun in there somewhere.

Hi Simon

Thanks again.

There's no deletion of any objects on the fly, in fact I'm not deleting any items when I test this, I'm simply not 'insert'ing them into the group by commenting-out the line. All works fine - they appear on stage - until I try to insert any one of the items, or position them even when not inserted.

I did try going back to a version of the file from the 2nd Sept, which had none of the new items, and re-coded the new elements one at a time. Again, all was fine till I went past a certain number and then it just stops working, regardless of what the object is. Even if I simply use duplicates of an existing item, it works till I get to that number and then fails to launch.

It's peculiar. I'll go through the process again backwards and forwards, or save one of the other levels as this one and adapt it from scratch if nothing else.

If I get to the bottom of it I'll update this tread. If I don't, I'll re-work the level with less elements.

Thanks so much for all you help with this, it's much appreciated.

Cheers

views:2091 update:2011/10/15 14:27:43
corona forums © 2003-2011