The variable that holds the green signals zeems to have random value. Sometimes it is ok, sometimes it is empty table({}) somtimes some internal structure.
The red wire variable I didn't tested.

Do you lookup signals in it by key, or use pairs()?

It should be a read-only table with cached accesses, and I've added special pairs() in the env to iterate over it properly, but didn't test latter much, so suspect it might have some issues.

I used serpent.block to print them.
But in the first place I want to do things like this:

if green["signal-1"] and green["signal-1"] > 0 then
var.State = "mining"
delay = 0
end

There I found that everything was nil. Even if the signal had a value according to monitor in ML-window

Oh yeah, serpent.block definitely won't work on these.
Hm, wonder if it should be jury-rigged, or maybe it'd be easier to just pre-fetch all signals and use regular tables, to avoid such confusion.

Didn't expect "delay = 0", but that should work too, I think.
Default for it is 1, i.e. "run on next tick again", but guess it's unclear from the help text.

green["signal-1"] and green["signal-1"] > 0 can be simplified in two ways:

• (green["signal-1"] or 0) > 0 - more concise, same result.
• Just green["signal-1"] > 0 should work too, as these ro-tables should never return nil, same 0 for missing signals.

Should probably also be mentioned in the help text.

Not sure about the bug though, will need to check.
Thanks for uncovering all these things.

Because of you last bugfix, I have a trace for you:

green={
cache = {
["blueprint-book"] = 1,
["signal-R"] = 2,
["signal-blue"] = 0
},
_cache_tick = 2528370,
_debug = false,
_e = {
__self = "userdata"
},
_iter = ((loadstring or load)("\27LuaR\0\1\4\8\4\8\0\25貼13\n\26\n~\0\0\0€\0\0\0\1\0\5\9\0\0\0E\0\0\0€\0\0\0ﾆ\0ﾀ\0ﾇ@ﾀ\1\7　\0ﾇ\0―1^\0€\1\0\0\0\31\0€\0\3\0\0\0\4\8\0\0\0\0\0\0\0defines\0\4\n\0\0\0\0\0\0\0wire_type\0\4\6\0\0\0\0\0\0\0_wire\0\0\0\0\0\2\0\0\0\1\9\0\0\28\0\0\0\0\0\0\0@Moon_Logic/control.lua\0\9\0\0\0\127\0\0\0\127\0\0\0\127\0\0\0\127\0\0\0\127\0\0\0\127\0\0\0\127\0\0\0\127\0\0\0€\0\0\0\1\0\0\0\5\0\0\0\0\0\0\0wenv\0\0\0\0\0\9\0\0\0\2\0\0\0\16\0\0\0\0\0\0\0cn_input_signal\0\5\0\0\0\0\0\0\0_ENV\0",'@serialized')),
_out = {
["signal-blue"] = 1
},
_wire = "green"
}

Um, where is that from?

game.log("green.cache="..serpent.block(green._cache)):

97: green.cache={
["blueprint-book"] = 1,
["signal-R"] = 2,
["signal-blue"] = 0
}

And now it writes the program to log a every run

debug=true should print something like this btw:

-- moon-logic [29]: --- debug-run start [tick=6206] ---
-- moon-logic [29]: env-before :: {delay = 1, var = {}}
-- moon-logic [29]: out-before :: {["signal-A"] = 0}
-- moon-logic [29]: used-inputs :: {["blue[signal-B]"] = 0}
-- moon-logic [29]: env-after :: {delay = 1, var = {}}
-- moon-logic [29]: out-after :: {["signal-A"] = 1}
-- moon-logic [29]: out-sync=true out-diff :: {["signal-A"] = 1}
-- moon-logic [29]: --- debug-run end [tick=6206] ---

Don't use serpent.block on these things, it does weird stuff, idk what it prints or what it might mess up :)
Which was kinda what I meant by "Oh yeah, serpent.block definitely won't work on these".

1149.241 Script @Moon_Logic/control.lua:333: -- moon-logic [35428]: --- debug-run start [tick=2584977] ---
1149.241 Script @Moon_Logic/control.lua:333: -- moon-logic [35428]: env-before :: {delay = 1, var = {Direction = 2, Position = 0, State = "building"}}
1149.241 Script @Moon_Logic/control.lua:333: -- moon-logic [35428]: out-before :: {["signal-blue"] = 1}
1149.241 Script @Moon_Logic/control.lua:333: -- moon-logic [35428]: used-inputs :: {["green[signal-0]"] = 0, ["green[signal-1]"] = 0, ["green[signal-D]"] = 0}
1149.242 Script @Moon_Logic/control.lua:333: -- moon-logic [35428]: env-after :: {debug = true, delay = 0, var = {Direction = 2, Position = 0, State = "building"}}
1149.242 Script @Moon_Logic/control.lua:333: -- moon-logic [35428]: out-after :: {["signal-blue"] = 1}
1149.242 Script @Moon_Logic/control.lua:333: -- moon-logic [35428]: out-sync=false out-diff :: {}
1149.242 Script @Moon_Logic/control.lua:333: -- moon-logic [35428]: --- debug-run end [tick=2584977] ---

You can see, that ["green[signal-1]"] = 0, but this is not true. It is 1. It was 0. Is it a cache problem?

Screenshot
Better one!

You can see, that ["green[signal-1]"] = 0, but this is not true. It is 1. It was 0. Is it a cache problem?

Huh, probably some bug, yeah, not sure if it's the cache though.
Cache there is just "if inputs weren't read on this tick, read and cache them" - https://github.com/mk-fg/games/blob/4dfa068/factorio/Moon_Logic/control.lua#L109-L111
This is so that multiple accesses from running same script will just be querying keys in same table, or, if logic doesn't query input signals, they won't be queried from factorio either.

Found one minor issue where I forgot to log input signals in debug=true on pairs() iteration ( https://github.com/mk-fg/games/commit/782589e , will bundle something else in there).

But can't seem to reproduce the issue with the input signals that you're having, unfortunately - they all seem to work as expected, and match stuff displayed on the right (which is built via same cn_wire_signals call), so don't know what else to check here.

I'd probably check if it's only this one combinator that is bugged, try different code there (like simple "if signal then log end" stuff), see if that works, and if not, check same on other combinators, then try replacing this one, to see if it's state is bugged somehow, or save/reload the game.
Though iirc only things that persist on these in globals (between reloads) are loaded code string, gui text (can be different from loaded code), entity ref, environment table, outputs, and whatever open gui state(s). There's nothing persistent related to input signals, so can't think of why they might be bugged on one particular combinator atm.

While testing stuff earlier, realized that it's very confusing to report outputs + inputs in GUI on the right, as intuitively it looks like it prints wire color + signal + value, like you'd use in lua inputs, but that is definitely not the case, as values there were actually inputs + outputs, like ones shown in factorio GUI if you hover over combinator.
So fixed that in 0.0.11, but that's just a display thing, should not affect actual values in any way.

I also was a bit confused above when talking about cache - it's not used for values displayed in GUI at all, so as you have 0 on the right on screenshot, it definitely has nothing to do with cache. Should be what control_behavior.circuit_network table has, so maybe double-check if factorio GUIs don't also report it as 0 at exact same time, or maybe connect a speaker to get an audio beep if it gets to 0 on even one specific tick.

Pretty sure change to arithmetic combinator base in 0.0.12 should not affect this issue, as inputs are read in exactly same way there.

I tried hard to reproduce this problem but without success. For me it is ok to close this.