entity.input_signals / entity.output_signals

[ljdp]

Interface to get the input and output signals for any entity that uses the logic system.

Code: Select all

-- read / write
entity.input_signals
entity.output_signals

[ratchetfreak]

Interface to get the input and output signals for any entity that uses the logic system.

Code: Select all

-- read / write
entity.input_signals
entity.output_signals

is the output read/write? as in can you set the output to whatever you want

[DaveMcW]

local condition = game.player.selected.get_circuit_condition(1)
condition.parameters.first_signal.name = "signal-B"
game.player.selected.set_circuit_condition(1, condition)

The 1 can be replaced by any integer, it does not seem to matter. But it wants an integer as the first parameter.

[ljdp]

local condition = game.player.selected.get_circuit_condition(1)
condition.parameters.first_signal.name = "signal-B"
game.player.selected.set_circuit_condition(1, condition)

The 1 can be replaced by any integer, it does not seem to matter. But it wants an integer as the first parameter.

That doesn't seem to do what I mean. What I mean is getting the real-time signal information (for example when you hover over decider combinator the GUI will show you what the input signals are) whereas get_circuit_condition returns the 'query' inside the logic entity.

For example, in the screenshot:

game.player.selected.input_signals should return:

Code: Select all

{
  { name = "signal-C", count = 10 },
  { name = signal-B", count = 5 },
  { name = "signal-A", count = 1 }
}

[DaveMcW]

Ah.

I handle writing by temporarily reprogramming the combinator for 1 tick. But there does not seem to be a way to read it.

[GopherAtl]

Ah.

I handle writing by temporarily reprogramming the combinator for 1 tick. But there does not seem to be a way to read it.

Oh, *now* I notice this thread and see your comment XD somehow this topic managed to avoid the search terms I tried earlier. Just arrived at the same approach, though it doesn't seem like you have to wait a tick, unless either get_circuit_condition or set_circuit_condition are, internally, waiting a tick without me realising it - but actually, no, can't be because I tested it by writing a function that does a binary search to determine the value of a specific signal by doing 32 tests, and that would take half a second if it were waiting a tick each time. Even though the effects don't spread across circuit networks until the next tick, changing the condition seems to immediately cause a new call to get_circuit_condition to return the updated value for fulfilled.

[DaveMcW]

I tested it by writing a function that does a binary search to determine the value of a specific signal by doing 32 tests

Very clever! So we have hacks for both reading and writing.

Now we just need a library that wraps them with a simple API.

[JasonC]

Very clever! So we have hacks for both reading and writing.

What's the hack for reading? I don't see it here.

[ratchetfreak]

Very clever! So we have hacks for both reading and writing.

What's the hack for reading? I don't see it here.

binary search using a less then and testing active

[JasonC]

Very clever! So we have hacks for both reading and writing.

What's the hack for reading? I don't see it here.

binary search using a less then and testing active

Oh. That wouldn't work, though. It takes multiple ticks. If the signal value changes during the middle of the search the "read" can fail. That'd be very likely to happen for e.g. item counts, tanker levels, etc.

[ratchetfreak]

Very clever! So we have hacks for both reading and writing.

What's the hack for reading? I don't see it here.

binary search using a less then and testing active

Oh. That wouldn't work, though. It takes multiple ticks. If the signal value changes during the middle of the search the "read" can fail. That'd be very likely to happen for e.g. item counts, tanker levels, etc.

Actually according to tests the active property updates with the condition so a binary search in one tick will converge on the value.

[JasonC]

binary search using a less then and testing active

Oh. That wouldn't work, though. It takes multiple ticks. If the signal value changes during the middle of the search the "read" can fail. That'd be very likely to happen for e.g. item counts, tanker levels, etc.

Actually according to tests the active property updates with the condition so a binary search in one tick will converge on the value.

Now that is cool. I will play with it later on my own; but how is performance? Is it pretty forgiving? I can definitely use that active update behavior to simplify this inserter.

BTW are you also ratchetfreak on Stack Exchange? If so, *fist bump*.

[Choumiko]

Oh. That wouldn't work, though. It takes multiple ticks. If the signal value changes during the middle of the search the "read" can fail. That'd be very likely to happen for e.g. item counts, tanker levels, etc.

It works https://github.com/Choumiko/SmartTrains ... l.lua#L552 (all credits for this function to GopherAtl), just do it in one tick.
Assuming entity is a lamp with a condition set, call it like: deduceSignalValue(entity,entity.get_circuit_condition(1).condition.first_signal,1) to get the value of the signal that is set in the lamp

[Rseding91]

I'm planning on adding a "LuaCircuitNetwork" object in 0.13 but I've got some internal things to sort out before doing so. It would solve all of the requests here plus some additional ones.

[JasonC]

I'm planning on adding a "LuaCircuitNetwork" object in 0.13 but I've got some internal things to sort out before doing so. It would solve all of the requests here plus some additional ones.

The new possibilities that will open up for mods will be awesome. Yet another thing on the list of reasons I'm super excited for 0.13!

[binbinhfr]

I'm planning on adding a "LuaCircuitNetwork" object in 0.13 but I've got some internal things to sort out before doing so. It would solve all of the requests here plus some additional ones.

Oh yes, please add this !