Moon Logic deprecated

by mk-fg

Adds Lua-programmable circuit network combinator. Based on Sandboxed LuaCombinator and LuaCombinator2 mods. Probably won't work in multiplayer games.

Content
2 years ago
1.0 - 1.1
4.97K
Circuit network

g [fixed] output not reseting

4 years ago

Hello, I am experiencing a bug where output wont reset.
What I did is I made an arbitration system with a central arbitrator.
It is a moon logic combinator that counts up "signal-1". To that I have connected latches that each activate for one of the values of "signal-1". At a certain "signal-1" value I reset all latches. I put a print inside the section of code that does that and I see all the latches printing reset. However they don't reset their output with out={} for some reason. I can provide a save if you want.
Not sure if i'm doing something wrong or there is indeed a bug.

4 years ago

Update:
by pressing save on the combinator when it is printing reset and should be resetting actually maker it reset. This makes me think that what I am experiencing is in fact a bug.

4 years ago
(updated 4 years ago)

I do not understand what is the situation that you are describing.

  • You mention that there are latches, which can mean different things that have to clarified.

  • These latches activate at a certain signal-1 value, then reset at another signal-1 value, and then write that "they don't reset their output with out={} for some reason". Obvious reason would be that they only reset on some specific signal-1 value, as you yourself mentioned, which you don't supply by out = {} (send no signals). This seem to be a puzzling contradiction.

  • Initial problem seem to say output wont reset, not "latches won't reset", like you write after that.

  • don't reset their output with out={} - that'd make sense if there were no separate latches, and you simply set/reset signals in moon logic combinator output.

  • "by pressing save on the combinator when it is printing reset and should be resetting actually maker it reset" - when you press save, you run the code on it, maybe that's what is not happening otherwise due to delay= set. Also I think that resets output, but not 100% sure - check the help text or do a quick test to confirm.

I think it'd help if you can describe the issue using this template:

  • I build MLC and put this code on it: ...
  • These are the inputs it gets provided (and how/if/when they change): ...
  • Expected output: ...
  • Actual output: ...

Don't see a need for a save, since as far as I can tell, only thing that matters here is code and its inputs/outputs.

It also often helps to take a moment to fill out template like one above (without cheating, in actual correct english, as if you are going to send it to someone) even if you don't plan to post it anywhere, as writing stuff down doesn't allow you to do mental shortcuts like "that gotta be right" and you have to fill logic/information gaps to build a correct sentence, often finding and solving the issue withough the need to actually report it anywhere.
In software development, such concept is often called "rubber duck debugging" (as in "explain the problem to a bath rubber duck toy to fix it").

4 years ago
(updated 4 years ago)

It also occured to me that if the issue is simply "outputs do not reset when I do out = {}", then you can easily test it with e.g.:
if out.wood ~= 0 then out = {} else out.wood = 1 end; delay = 120

Run that code and see if it flaps "wood" signal between 1 and 0 every 2s (on the right of the code or via e.g. lamp indicator).
If that works, then resetting all outputs that way clearly works with the mod, and it's likely a bug in the presumably-more-complicated lua code that you are running there for such arbitration system, which just does not do same out = {} thing.

Asking me to debug code for that system would probably be weird (not my code, what'd I know about it?), which is why simplifying the problem to just mod combinator + something trivial like the code line above might be a good idea.

4 years ago
(updated 4 years ago)

Seems to be an copying issue, for me at least.

Simplest reproduction case:
if red.wood == 1 then out.wood = 1 else out = {} end; delay = 120
Create a constant combinator, with wood = 1, and red wire it to the MLC. Toggle it on and off. It works fine.
Then red wire the output of that MLC to a new MLC and use shift-click to copy the original MLC to it. Toggle the constant and the new MLC will get stuck outputting wood = 1.
The second MLC will show, in the debug output, out-before and out-after both equal to an empty table and out_sync will never get triggered.
I'm thinking maybe the _out table of the original gets copied over to the second one and they become entangled. So when the first one clears its output it is also clearing the second ones output.

EDIT: I should also mention that this does not happen if you just copy paste the code from the first MLC.
EDIT2: It is also permanent. If you've done it to an MLC, it won't get fixed just by saving the code again. You have to remove and replace the MLC.

4 years ago
(updated 4 years ago)

oops, wrong button

4 years ago

Hello,
I did try simplifying the code to a degree, but at this point I don't see a way to simplify more without breaking the core functionality. I did also try to simplify the system by reducing the number of latches in the chain and with just one it works, but with more it only works sporadically. Again I don't see why.

I also tried to debug the code, but so far only by printing. I will also try the debug in log option today, but since it only print before-after it isn't immediately useful.
However as I said in the first post printing works correctly which makes me think that out={} is being called as I have a print and this in the same block of code. Of course I wont be able to just explain what I have in text,
that is why I provide an image of the system with code. Maybe you can check it out if you have any idea on why it might not work. Of course it might be a problem in my code, but I just don't see how, as printing works correctly.

Image:
https://svgshare.com/s/S9D
Code:
https://pastebin.pl/view/11fa230e
Also I will try what erkle64 suggested.

4 years ago

Thanks for clarification, I'll check what happens there.
Did change settings copy-pasting routine recently to also work for surface cloning, maybe replaced deepcopy with copy there or something.

4 years ago

Hello again. Ignore what I posted previously, what erkle64 posted fixes it, so it is indeed an issue with copying combinators.

Thanks for the solution.

4 years ago
(updated 4 years ago)

Toggle the constant and the new MLC will get stuck outputting wood = 1.

More than that, it shows "wood" as invalid output there for me:

Definitely a bug somewhere.

4 years ago
(updated 4 years ago)

It was an issue with table-deepcopy, but not due to it being missing, but because of lua metatable attached to that output table.

Factorio deepcopy routine checks if table has __self key to avoid copying API object references, and metatable attached there returned __self=0, which is why that table wasn't copied properly.
And copying is needed there, as it's a part of combinator state and should be present/updated in save files, unlike most other metatable-heavy stuff in mlc_env, which can all just be re-initialized on game load (maybe desyncing multiplayer, but oh well).

Should be fixed in 0.0.46+.

EDIT:
Oh, also, I think this bug have been there since the very first versions of this mod.
But it might be a bit hard to notice, as on game save/load, these tables get de-linked (initialized as separate ones, or maybe due to re-init of metatables).

New response