Modding - hooking into bp.Display.Tarmacs.Width for example

I'm having an issue hooking into nested variables/properties (unsure of the correct terminology, so I'll use variable in this post).

I can hook normally into variables that are only nested inside once; example given:

if bp.Categories 
				and table.find(bp.Categories,'STRUCTURE')
				and not table.find(bp.Categories,'HYDROCARBON') 
				and table.find(bp.Categories,'ENERGYPRODUCTION') then
     
                    if bp.Economy then
                        if bp.Economy.ProductionPerSecondEnergy then
                            bp.Economy.ProductionPerSecondEnergy = bp.Economy.ProductionPerSecondEnergy * energy
                        end
                    end
                end

In this case, the variable I'm modifying ProductionPerSecondEnergy is nested inside Economy and this works perfectly.
However, if there is another nested layer; example given:

if bp.Categories 
				and table.find(bp.Categories,'STRUCTURE') then
     
                    if bp.Display then
                        if bp.Display.Tarmacs then
							if bp.Display.Tarmacs.Width then
								bp.Display.Tarmacs.Width = bp.Display.Tarmacs.Width * tarwmod
						end
                    end
                end

In this case, the variable I'm modifying Width is first nested under Tarmacs and then under Display. This code doesn't change the Width variable.

There is another example which is slightly different as well:

if bp.Categories 
				and table.find(bp.Categories,'STRUCTURE')
				and table.find(bp.Categories,'ANTIMISSILE') then
     
                    if bp.Weapon then
                        if bp.Weapon.MaxRadius then
                            bp.Weapon.MaxRadius = bp.Weapon.MaxRadius * tmdefrange
						end
                    end
                end

In this case, the variable I'm modifying is MaxRadius, but in the original .bp file for the structure the bp.Weapon has a set of extra { } enclosing many of it's variables, which I believe is why I cannot access these with hooks.

If I try and change the variables inside bp.Weapons by creating a "mod_units.bp" and manually specifying the units and the variable it works - but this is a very time consuming process if I wish to go through every structure that has Tarmacs.Width and Tarmacs.Length.

Anyone with more experience have any ideas how to get these extra nested hooks working? I must be missing something obvious.

Regards, Hey Babe

Small correction, but this is important. I checked the Display.Tarmac.Width and Legth variables and, it is the exact same way that the Weapon.MaxRadius is enclosed in an extra pair of { }, so this is two examples of - not of a similar, but - exactly the same problem.

@heybabe

I solved it, it seems when confronted with { internal variables } you have to loop through all the preceding level to find these inside, then you can just change them, like this:

if bp.Weapon then
                        for k,v in bp.Weapon do
							if v.MaxRadius then
									v.MaxRadius = v.MaxRadius * artyrangemodexample

@heybabe

It's not necessary to loop through all the preceding levels. The extra pair of { } is declaring an integer indexed array which you can access the elements of with SomeArray[1].

See the lua docs on tables, specifically:
"A common mistake for beginners is to confuse a.x with a[x]. The first form represents a["x"], that is, a table indexed by the string 'x'. The second form is a table indexed by the value of the variable x. ... To represent a conventional array, you simply use a table with integer keys."

In this case, "Weapon" and "Tarmac" in the blueprint (which could be more intuitively named "Weapons" and "Tarmacs") are convential arrays, indexed by integers. containing a subtable of the data for each weapon/tarmac on the unit. When you declare a table of tables in lua without specifying a key for each, lua automatically integer indexes them.

Take this hypothetical table declaring two weapons:

UnitBlueprint = {
    Weapon = {
        {
            Damage = 10
            Range = 5
        }
        {
            Damage = 1
            Range = 2
        }
}

Because the Weapon table is declared with a non-integer key ("Weapon"), you can access it with UnitBlueprint.Weapon, as shown in the lua docs. But what happens if you try to access UnitBlueprint.Weapon.Damage? There's two values for damage in there, each declared without a key, in which case lua has secretly done something like this (the following code is wrong, used just as an example to demonstrate the integer indexing, do not try to replicate it) :

UnitBlueprint = {
    Weapon = {
        1 = {
            Damage = 10
            Range = 5
        }
        2 = {
            Damage = 1
            Range = 2
        }
}

In which case (depending on how familiar you are with typical methods of accessing array elements from Python et al) you may intuit that you can grab the first weapon with UnitBlueprint.Weapon[1]. See the lua docs again for why you can access an integer indexed array with SomeArray[1] but not SomeArray.1.

The reason why your loop solution works is because the loop is iterating through the subtables, even though in this case there is only one subtable, which is where I think your confusion arose. Think of Weapon and Tarmac as lists of an arbitrary length (the extra set of "{ }" surrounding them as the giveaway), the elements of which need to be accessed with integer indexes, and I think the solution will become clear to you.

@slicknixon
This is an amazing explanation, I'm very grateful! I just started 3 days ago and got lost pretty quickly.

There's also these:

They're made by Balthazar, author of the Brewlan package

A work of art is never finished, merely abandoned

@jip Thank you.