Info about transport line item order

[sparr]

I want to remove the first or last item from a transport line. If the line contains multiple item types, I can't currently tell what order they are in. Maybe a variation of get_contents that returns a list of items in order, rather than a dictionary?

[sparr]

I still need this to make Belt Overflow mod behave correctly in situations of mixed belts

[gheift]

Is transportline not sorted? http://lua-api.factorio.com/latest/LuaT ... Line.owner

[sparr]

I don't think [] was implemented last time I asked this.

If it's sorted, I need to know which end is the front vs the back (which I will be experimenting with later, but thought I should ask here first in case someone just knows)

[gheift]

Just had a quick look, it came with 0.15.0.

[sparr]

confirming that [1] is the farthest-along item on the transport line, and that remove_items() starts removing from that end.

[Nexela]

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

[Rseding91]

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

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.

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.

[gheift]

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

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.

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.

So if you do it once, do it like this:

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()
end

Otherwise, store the transport_line near your belt:

Code: 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)

[Nexela]

Yes that was a bad example on my part . That is what I get for laying down and typing sideways on a laptop. I didn't feel like re-editing the post

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

For saving/persistance you would use global

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()
end

[sparr]

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.

I 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.

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?

[gheift]

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?

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]

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?

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.

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]

http://lua-api.factorio.com/latest/Global.html:

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

So string LuaTransportLine objects in the global table should be fine.

[sparr]

I need to do a major overhaul of the belt-overflow mod to take advantage of this. I'm calling get_transport_line so many times...