[1.2.10] ContainerTable max limit reached

[TkER]

Hi this message is for ED team and developers.

 

On 1.2.9 and 1.2.10 new Mig21 has added over 90 new objects on "ContainerTable" there are a problem with custom mods, if I add more than 30 new tanks or pods etc... the "ContainerTable" it's full and create a lot of problem like loading a different 3D model instead the desidered and create a lot of errors like this on logs

 

00007.705 ERROR EDOBJECTS: Object PTB_N3DF16ADF with id=178 already declared in table ContainerTable

 

Removing the \CoreMods\aircraft\MiG-21 directory fix that problem

 

Is possible enhance the limit for "ContainerTable", "PlaneTable" and ShapeTable for the next version ?

 

Is also possible enhance the limit on 1.2.10 on any lua file ?

 

This is not a bug for current not mods user, but can be a serious bug with new planes and objects added for third partys in the future.

 

Thanks.

[Flagrum]

How exactly do you come to the conclusion that the table is "full"? You have added your own objects, did I understand you correctly? Couldn't it then just be that these mods cause the problems? The error message - as I interprete it - only says that an id 178 already exists. Perhaps your objects use that id although they should not?

[TkER]

How exactly do you come to the conclusion that the table is "full"? You have added your own objects, did I understand you correctly? Couldn't it then just be that these mods cause the problems? The error message - as I interprete it - only says that an id 178 already exists. Perhaps your objects use that id although they should not?

 

Yes the log says this but is not true

 

I'm pretty sure the problem is the "ContainerTable" full because the ID can't be setted on custom lua, but the ID are automatically set by the sim when start.

On lua you can only set an unique CLSID that is impossible are used more times.

 

With mig21 directory I have also this error on ED shapes, without the directory I have no error in log.

 

Also with 100 and more plane addon I have same error on "PlaneTable" removing a random numer of airplane fix this error.

 

The problem for me is DCSW have a limit of PlaneTable and ContainerTable

 

I think "PlaneTable" is limit to 99 and "ContainerTable" to 999 but I can be wrong on this numbers.

Edited August 24, 2014 by T@kER

[NRG-Vampire]

...create a lot of problem...

 

that's why the "index = WSTYPE_PLACEHOLDER" been made ;)

[TkER]

that's why the "index = WSTYPE_PLACEHOLDER" been made ;)

 

Yes i'm using this, do you have a solution NRG-Vampire ? :)

[Flagrum]

that's why the "index = WSTYPE_PLACEHOLDER" been made ;)

That was a good hint...

 

I poked around in the luas a bit, this is what I found so far:

 

In wsTypes.lua are unique IDs defined for every object in the game. They are unique per object type, i.e. A2A missiles, rockets, bombs, etc. The highest ID for any of those object types is: 178 for "Контейнеры и баки. Балочные держатели." (google: "Containers and tanks. Racks.")

 

Interesting. But "we must go deeper".

 

In db_mods.lua are functions defined that are used by modules (newer ones like the Fw190 or the F-86) to define new weapons, weapon containers and all kind of other stuff. The function "declare_loadout()" and "declare_adapter()" use the function "next_container()" to generate a new ID that is used as a table index for the new object, replacing the temporary index "WSTYPE_PLACEHOLDER" that was used by the respective module.

 

function declare_adapter(tbl)
   
   if Pylons[tbl.ShapeName] ~= nil then
      return
   end
   
   local [color=Blue][b]wstype_name[/b][/color]       = [color=Red][b]next_container()[/b][/color]
   
   Pylons[tbl.ShapeName] = [color=Blue][b]wstype_name[/b][/color]
   
   if tbl.animation then
       Pylons_animation[[b][color=Blue]wstype_name[/color][/b]] = tbl.animation
   end
   
   wstype_containers[[color=Blue][b]wstype_name[/b][/color]] = {wsType_Weapon,wsType_GContainer,wsType_Support,wstype_name}
   tbl.shape_table_data =
   {
       {
           file       = tbl.ShapeName;
           life       = 60;

... (snip) ...

Yeah, we must go deeper!

 

function next_container()
   local v = next_container_index
   next_container_index = [b][color=Red]next_container_index - 1[/color][/b]
   return v
end

The function generates a new ID by counting down from a starting value "next_container_index". This variable is defined and initalized earlier as

local next_airplane_index    = 150
local next_helicopter_index  = 255
local next_bomb_index          = 255
local next_missile_index      = 255
[color=Blue][b]local next_container_index     = 255[/b][/color]

So, there we are, I think. 255 is the highest ID that is used by a plugin and it is counted down ... until the generated ID clashes with already used IDs or table entries - which happens first with the "ContainerTable" as this table is the largest so far and uses indices/IDs already up to 178.

 

I don't know why the IDs are counted backwards. I would let them start at the next free ID (i.e. 179) and let them grow as they please. But perhaps there is a hard limit of 255 of how many entries a LUA table can hold? Maybe the OP want's to experiment with that a bit ... :o)

 

 

edit:

From the LUA documentation (http://www.lua.org):

"The table type implements associative arrays. An associative array is an array that can be indexed not only with numbers, but also with strings or any other value of the language, except nil. Moreover, tables have no fixed size; you can add as many elements as you want to a table dynamically."

 

That suggests that it should be safe to change the "next_xxx_value" to any value greater than 255. Worth a try, I'd say.

Edited August 24, 2014 by Flagrum

[TkER]

Thanks Flagrum, today I made some test and report :)

 

Really don't know why counting down, interesting

[NRG-Vampire]

yep, as Flagrum Wrote

but

you can define index = "number" as well

instead of

"index = WSTYPE_PLACEHOLDER"

but you need to be careful not allow to bring other object using the same number

or using already used index number what you can find in Bazar\ContainerTable.sht

Edited August 24, 2014 by NRG-Vampire

[TkER]

Thanks NRG-Vampire

 

I have tested first with a modification to local next_container_index = 510

 

But don't work, I have now no error on logs but 3D model remain not loaded or load another model, only removing the mig21 directory fix the problem :noexpression:

 

Doing another tests...

[TkER]

OK tested:

 

index = prova123

 

and

 

Index = 9934556

 

Generate no errors on logs but 3D model continue showing wrong...

 

Removed Mig21 directory and work perfectly....

 

I realy don't understand...

[Flagrum]

OK tested:

 

index = prova123

 

and

 

Index = 9934556

 

Generate no errors on logs but 3D model continue showing wrong...

 

Removed Mig21 directory and work perfectly....

 

I realy don't understand...

 

Seems there is another starting index used. I haven't analysed it in depth, yet, but it seems it is related to "Shapes" ...

 

See db_mods.lua around line 250: local parts_index_start = 255

 

This is used in several functions that deal with "shapes", i.e. "shape_table_data"-table and the like.

[TkER]

Seems there is another starting index used. I haven't analysed it in depth, yet, but it seems it is related to "Shapes" ...

 

See db_mods.lua around line 250: local parts_index_start = 255

 

This is used in several functions that deal with "shapes", i.e. "shape_table_data"-table and the like.

 

Yes I see try change that value to the same new value of local next_container_index but don't work

 

Also every time I change any number for next_container_index he change completly all model, so it's all wrong.

 

I think is not so easy :noexpression:

 

But the problem is right is a max limit reached for the containertable...

 

I think ED must be enhance the value