Inventory indices/defines

[FuryoftheStars]

https://lua-api.factorio.com/latest/Lua ... _inventory

Return values

:: LuaInventory?

The inventory or nil if none with the given index was found.

I may be incorrect in my thinking, but this led me to believe that calling ".get_inventory(defines.inventory.character_main)" on say, a steel-chest, would give me an actual nil result. Instead, with serpent.block(), I get this:

Code: Select all

{
  {
    __self = "userdata"
  },
  {
    __self = 0
  },
  {
    __self = 0
  },
  [...]
  -- repeats 44 more times
  [...]
  {
    __self = 0
  },
  __self = 0
}

I feel as though the actual return result should be clarified better. This makes a difference, especially with other commands like .mine{}, which will behave differently if the inventory parameter is left blank/fed "nil" vs... whatever that actual result above is.


Edit: Ok, sorry, it seems that no matter what I give it, it returns with the chest's inventory? I'm confused now.

[Silari]

I may be incorrect in my thinking, but this led me to believe that calling ".get_inventory(defines.inventory.character_main)" on say, a steel-chest, would give me an actual nil result.

The defines are just a value soft coded into the game with a more human readable name. For defines.inventory, I believe it's an integer. It's similar to the concept of enums in several languages. Several of those defines lead to the same integer, and thus using a different inventory define can give you the same inventory. inventory.character_main is just a 1. inventory.chest is also a 1. Thus, right now they could be used interchangeably.

The reason the defines exist is that if the engine changes in a way where the internal inventory is organized differently, any mod using defines.inventory.chest to grab the chest inventory will still work, as the define would be changed to whatever new integer is appropriate. If it were hardcoded as a 1, it wouldn't work if they had to change that to a 2 for some reason.

You can see the internal values easily by just printing them:

Code: Select all

246.883 Script log(serpent.block(defines.inventory)):1: {
  artillery_turret_ammo = 1,
  artillery_wagon_ammo = 1,
  assembling_machine_input = 2,
  assembling_machine_modules = 4,
  assembling_machine_output = 3,
  beacon_modules = 1,
  burnt_result = 6,
  car_ammo = 3,
  car_trunk = 2,
  cargo_wagon = 1,
  character_ammo = 4,
  character_armor = 5,
  character_corpse = 1,
  character_guns = 3,
  character_main = 1,
  character_trash = 8,
  character_vehicle = 7,
  chest = 1,
  editor_ammo = 4,
  editor_armor = 5,
  editor_guns = 3,
  editor_main = 1,
  fuel = 1,
  furnace_modules = 4,
  furnace_result = 3,
  furnace_source = 2,
  god_main = 2,
  item_main = 1,
  lab_input = 2,
  lab_modules = 3,
  mining_drill_modules = 2,
  roboport_material = 2,
  roboport_robot = 1,
  robot_cargo = 1,
  robot_repair = 2,
  rocket = 1,
  rocket_silo_result = 6,
  rocket_silo_rocket = 5,
  spider_ammo = 3,
  spider_trash = 4,
  spider_trunk = 2,
  turret_ammo = 1
}

EDIT: I thought there was something somewhere saying that using a defines value with something it's not intended for will have undefined effects - ie using one meant for characters on a chest could work, it could not. Can't find it now though. Might've been lost in the docs change.

[FuryoftheStars]

I may be incorrect in my thinking, but this led me to believe that calling ".get_inventory(defines.inventory.character_main)" on say, a steel-chest, would give me an actual nil result.

The defines are just a value soft coded into the game with a more human readable name. For defines.inventory, I believe it's an integer. It's similar to the concept of enums in several languages. Several of those defines lead to the same integer, and thus using a different inventory define can give you the same inventory. inventory.character_main is just a 1. inventory.chest is also a 1. Thus, right now they could be used interchangeably.

The reason the defines exist is that if the engine changes in a way where the internal inventory is organized differently, any mod using defines.inventory.chest to grab the chest inventory will still work, as the define would be changed to whatever new integer is appropriate. If it were hardcoded as a 1, it wouldn't work if they had to change that to a 2 for some reason.

You can see the internal values easily by just printing them:

Code: Select all

246.883 Script log(serpent.block(defines.inventory)):1: {
  artillery_turret_ammo = 1,
  artillery_wagon_ammo = 1,
  assembling_machine_input = 2,
  assembling_machine_modules = 4,
  assembling_machine_output = 3,
  beacon_modules = 1,
  burnt_result = 6,
  car_ammo = 3,
  car_trunk = 2,
  cargo_wagon = 1,
  character_ammo = 4,
  character_armor = 5,
  character_corpse = 1,
  character_guns = 3,
  character_main = 1,
  character_trash = 8,
  character_vehicle = 7,
  chest = 1,
  editor_ammo = 4,
  editor_armor = 5,
  editor_guns = 3,
  editor_main = 1,
  fuel = 1,
  furnace_modules = 4,
  furnace_result = 3,
  furnace_source = 2,
  god_main = 2,
  item_main = 1,
  lab_input = 2,
  lab_modules = 3,
  mining_drill_modules = 2,
  roboport_material = 2,
  roboport_robot = 1,
  robot_cargo = 1,
  robot_repair = 2,
  rocket = 1,
  rocket_silo_result = 6,
  rocket_silo_rocket = 5,
  spider_ammo = 3,
  spider_trash = 4,
  spider_trunk = 2,
  turret_ammo = 1
}

EDIT: I thought there was something somewhere saying that using a defines value with something it's not intended for will have undefined effects - ie using one meant for characters on a chest could work, it could not. Can't find it now though. Might've been lost in the docs change.

Yeah, I got that they were enums, but the fact that some had the same value as others I was not aware of (and isn't typically what I'm used to), so that's probably what was throwing me. (Correction, that's exactly what was throwing me. I just reviewed the list you posted and every enum I tried had the same value (1). *sigh*)