[0.12.33;mod API] LuaItemStack.blueprint_icons

[AenAllAin]

I don't know if this is a bug or not, but the LuaItemStack.blueprint_icons array is empty for my blueprints that only use one icon.

[daniel34]

LuaItemStack.blueprint_icons does return an array that is zero-based.
The first icon will be stored in blueprint_icons[0], the second in blueprint_icons[1] and so forth.
Therefore using the # operator to get the length of the array will return 1 less than the actual length, as lua starts counting at 1.

According to the modding API:

Code: Select all

index :: uint: Index of the icon in the blueprint icons slots. Has to be in {1, 2, 3, 4}.

so this looks like a bug to me.

[Rseding91]

http://i.imgur.com/lSXFbrm.jpg

It looks correct to me. The index key is correct and it has 1 item in the table returned.

[daniel34]

http://i.imgur.com/lSXFbrm.jpg

It looks correct to me. The index key is correct and it has 1 item in the table returned.

Just so I understand this correctly, calling .index on blueprint_icons[3] should actually return 4? (and #blueprint_icons also returns 3, although it has 4 icons?)

[Rseding91]

http://i.imgur.com/lSXFbrm.jpg

It looks correct to me. The index key is correct and it has 1 item in the table returned.

Just so I understand this correctly, calling .index on blueprint_icons[3] should actually return 4? (and #blueprint_icons also returns 3, although it has 4 icons?)

Yes, the reason being: you can end up with blueprints that have icons set for slots 2, and 4. That means the blueprint would have 2 icons but technically the icons are in index 2 and 4 of the blueprint. It's a little confusing but that's just currently how the blueprint icon system works.

[AenAllAin]

Ok. Thank you for the help guys. I think I finally figured out what is going on. First here's the code:

Code: Select all

    local l_player = game.players[event.element.player_index]
    local s_stack = l_player.cursor_stack
...
  if s_stack and s_stack.valid_for_read and s_stack.type == "blueprint" and s_stack.is_blueprint_setup() then
...
    if #s_stack.blueprint_icons > 0 then
        local icon_quad = l_schematic.add{type="table", name="icons", colspan=2, style="slot_table_style"}
        for ii, iv in ipairs(s_stack.blueprint_icons) do
            icon_quad.add{type="button", name="icon_"..iv.name, style="bpr_gs_"..iv.name.."_small"}
        end
    else
        l_schematic.add{type="label", name="icons", caption="WTF"}
    end
...
  end

PSEUDO:
1. Get the players cursor_stack
2. Check that it is a blueprint
3a. Try to add the blueprint icons as little icon/buttons to a custom gui element, or
3b. (when 3a fails) just add a label element that says "WTF"

*. The result is "WTF" whenever it is a blueprint with one icon

So, in a nutsack, "#s_stack.blueprint_icons" is returning '0', which I think means it is trying to say the 0th element has the icon, not that there are no icons; and, yes, when I access "s_stack.blueprint_icons[0]" it does indeed return the proper icon. My only problem then is how to tell the difference between 0 icons and icons[0]. Also, this breaks the "ipairs" for loop, which will just do 0 iterations.

Solution:
I just switched it to a standard "pairs" for loop (even though it is supposed to be an array ), and it works.

Code: Select all

    for ik, iv in pairs(s_stack.blueprint_icons) do
        icon_quad.add{type="button",
                        name="icon_"..iv.name,
                        style="bpr_gs_"..iv.name.."_small"}
    end

So for me, I guess problem solved although you Devs may feel different; at least there is a workaround.

...this did bring a different issue to light though, but I will make a separate thread for that potential bug.

[Rseding91]

... Solution:
I just switched it to a standard "pairs" for loop (even though it is supposed to be an array ), and it works.

Code: Select all

    for ik, iv in pairs(s_stack.blueprint_icons) do
        icon_quad.add{type="button",
                        name="icon_"..iv.name,
                        style="bpr_gs_"..iv.name.."_small"}
    end

So for me, I guess problem solved although you Devs may feel different; at least there is a workaround.

...this did bring a different issue to light though, but I will make a separate thread for that potential bug.

Just don't ever use ipairs... ever. There's no reason to use it over pairs and in fact In 0.13 it won't work on some of the returned collections from Factorio's API.