[0.13][API] index property in LuaCircuitNetwork.signals

[justarandomgeek]

It would be nice if the array returned by LuaCircuitNetwork.signals had a .index property (even if it is nearly meaningless) on each value. This is useful in mods when mirroring signals, as is desirable in all the new mods using surfaces - especially since I was told connecting poles across surfaces is probably map-corrupty, this seems to be the only alternative.

The current code to do this looks like this:

Code: Select all

local rxNet = sconn.from.get_circuit_network(defines.wire_type.red) or sconn.from.get_circuit_network(defines.wire_type.green)
if rxNet and rxNet.valid then 
  local txControl = sconn.to.get_or_create_control_behavior()
  local txSignals = rxNet.signals
  local n = 1
  for k,_ in pairs(txSignals) do
    txSignals[k].index = n
    n = n+1 
  end
  txControl.parameters={parameters = txSignals}
end

but if .signals had an index property already, it would collapse down to just

Code: Select all

local rxNet = sconn.from.get_circuit_network(defines.wire_type.red) or sconn.from.get_circuit_network(defines.wire_type.green)
if rxNet and rxNet.valid then 
  sconn.to.get_or_create_control_behavior().parameters={parameters = rxNet.signals}
end

yielding significant performance improvements (as this is in an on_tick handler for each instance of the paired entities, and circuits actually need every tick).

[ssilk]

Moved from Suggestions to Modding Interface Requests

[justarandomgeek]

Moved from Suggestions to Modding Interface Requests

Thanks, I wasn't entirely sure where I should sort it to!

[Rseding91]

I don't get it, the index of the signal is it's position in the table...

If you're talking about taking the output signals of a network and assigning them to a constant combinator - those are 2 completely different things and of course the data formats aren't directly compatible.

[justarandomgeek]

If you're talking about taking the output signals of a network and assigning them to a constant combinator - those are 2 completely different things and of course the data formats aren't directly compatible.

Yes, that's exactly what I'm talking about, and I'm just saying it would be nice if they *were* close enough to allow direct copying when that's a useful thing to do - right now such mirroring is *very* heavy (to the point of being nearly impractical due to performance for any large signal packets) in the script update due to needing to loop through each signal for each mirror device to add the index property. Obviously index on the read signals would be meaningless by itself, but it would allow direct copying (into a sufficiently large constant combinator) in a single line/operation rather than the additional loop.

But again, this is just a "it sure would be nice if" If you disagree, I'll deal with it and keep the loop!


Edit: I feel I still haven't explained this clearly: they're two different things, but they so *nearly* compatible (only one missing property, .index), and they're logically at least connected, so it would be *nice* if A) the signals came with an .index property so they could be assigned to a CC directly or B) CC accepted a table without the .index property and just filled them in the first available slots

[justarandomgeek]

Having given this some more thought, the original request was approaching the problem from the wrong side. A better request that achieves the same end result would be to for the .index property of the entries in a Constant Combinator's parametersbe an optional property when setting, and to just fill in the grid as space is available.