Code: Select all
for i = #belt.get_transport_line(1), 1, -1 do
stack = belt.get_transport_line(1)[i]
stack.do-stuff()
stack.clear()
endYou definitely don't want to do it like that. Call get_transport_line once and then operate on that for the lifetime of the entity with the transport line.Nexela wrote:The inventory is dynamic so remember to iterate in reverse order if you are removing things.
Code: Select all
for i = #belt.get_transport_line(1), 1, -1 do stack = belt.get_transport_line(1)[i] stack.do-stuff() stack.clear() end
So if you do it once, do it like this:Rseding91 wrote:You definitely don't want to do it like that. Call get_transport_line once and then operate on that for the lifetime of the entity with the transport line.Nexela wrote:The inventory is dynamic so remember to iterate in reverse order if you are removing things.
Code: Select all
for i = #belt.get_transport_line(1), 1, -1 do stack = belt.get_transport_line(1)[i] stack.do-stuff() stack.clear() end
With a few exceptions every object you get from the game can be persisted through multiple ticks/saved in global and will give you improved performance by doing so.
Code: Select all
local tline = belt.get_transport_line(1)
for i = #tline, 1, -1 do
local stack = tline[i]
stack.do-stuff()
stack.clear()
endCode: Select all
local obj = {...}
obj.belt = belt -- from somewhere
obj.belt_tl1 = belt.get_transport_line(1)
obj.belt_tl2 = belt.get_transport_line(2)
Code: Select all
local lane = belt.get_transport_line(1)
for i = #lane, 1, -1 do
stack = lane[i]
stack.do_stuff()
stack.clear()
end
Code: Select all
global.belt = global.belt or {}
-- Belt from somewhere
global.belt[belt.unit_number] = {
belt=belt
lane1=belt.get_transport_line(1)
lane2=belt.get_transport_line(2)
}
-- Later on
for _, belt in pairs(global.belt) do
if belt.lane1.valid then --make sure it still exists
do_stuff()
endI knew you could use it throughout the action of a single mod on a single tick until it was intentionally destroyed. I did not know you could use it across ticks.Rseding91 wrote:Call get_transport_line once and then operate on that for the lifetime of the entity with the transport line.
With a few exceptions every object you get from the game can be persisted through multiple ticks/saved in global and will give you improved performance by doing so.
It is more the other way around. By storing this data in global.variable it is preserved during save/load or on multiplayer join. By storing information in a normal global variable, you have to restore these during init/load and be careful to reach the same state as other players in multiplayer.sparr wrote:However, there's a difference in a global variable and a global.variable. Am I right to say that putting it in the `global` table would be bad, because it won't serialize usefully when the game is saved?
I know what global. is used for. My point is that you can't put game entity references in global. because they will all be not-valid when the global table gets deserialized in a new load.gheift wrote:It is more the other way around. By storing this data in global.variable it is preserved during save/load or on multiplayer join. By storing information in a normal global variable, you have to restore these during init/load and be careful to reach the same state as other players in multiplayer.sparr wrote:However, there's a difference in a global variable and a global.variable. Am I right to say that putting it in the `global` table would be bad, because it won't serialize usefully when the game is saved?
So string LuaTransportLine objects in the global table should be fine.Only specific data can be saved and loaded using this table:
- Basic data: nil, strings, numbers, booleans
- Tables, but not meta tables; tables with metatables become plain tables when saved and loaded.
- References to builtin Factorio LuaObjects