[0.12.4][Twinsen] - combinator madness

[@xi@g@me]

Hi,

I updated to 0.12.4 today and experienced a strange combinator behavior...
With a single image it is a bit hard to explain, so I updated a video showing the bug you can see here :

https://www.youtube.com/watch?v=_D1kUhnfFb8

Here are the repro steps I found :
first, setup a 3 combinators loop which generate a signal from 1 to 50 and loops back :
1 - One combinator making blue + 1 => blue
2 - One combinator making if (blue < 50) => green
3 - One combinator making blue * green => blue

1 is connected to 2, 2 to 3, 3 to 1 with green wires
1 is connected to 3 with a red wire.

Untill there, everything works fine.

Now, I add a constant combinator (4) which outputs 1 petroleum gas (in my movie it is the output of a more complex compute system, but the output is a stable 1)

I also crate a maths combinator (5) which makes blue * gas => blue.
I connect 1 and 4 to 5.

So 5 outputs a blue signal from 1 to 50 with a loop.

The bug is there : when I remove the combinator 5, the 3 first combinators completely go mad and have a non expected behavior. The video will show you.

I also uploaded the save file with the bug, and a picture showing which combinator to remove in order to trigger the bug.

[GopherAtl]

was just playing with your bug save, that is indeed very strange.

Made a replica, same behavior. Tried just removing the red wire connecting 1 and 5, and just removing the wire seems to cause the same - though not 100% of the time. Then tried replacing combinator 5 with just a power pole and connecting it with red wire - removing the power pole has the same behavior as removing combinator 5.

So I slowed the game speed down to 0.1 so I could try and see what's actually happening.

The end result seems to be that the values in the loop 1-2-3 get into a screwed up state; it normally takes 2 cycles for the output from #1 to make the trip through #2 and #3 and arrive back at input to reset it when it hits 50, while it takes only 1 extra cycle for the red directly back from #1 to #3 to make it back, so every 2 cycles it increment its output. Somehow this normal flow is being interrupted, and for 1 cycle #1 gets no input at all, even though it's inputs should not have been affected. As a result it outputs 1 the next tick, but then normal input is restored. This injects a bogus 1 for 1 tick into the middle of whatever count it was supposed to be there. speed .1 isn't fast enough for me to really tell exactly what happens during that first tick to the other combinators (for combinator debugging, I really wish you coudl force game speed even slower than .1 sometimes... .01 or even .001 would be nice sometimes XD)

Anyway, tl;dr: it seems it's removing the output wire that's having unintended side-effects.

:edit: as a work-around for now, and a general tip, you can do a counter like that with just 1 decider and 1 constant combinator - though it counts twice as fast. Like so in this spoiler...

work-around

This seems not to be affected by the bug, for whatever reason, and you can use it as a replacement until the bug is fixed.

[s]... did the spoiler tags get changed? that's.. annoying. Reddit style spoilers are fine for reddit, but they suck for spoilering images.[/s] nope, just uses that form in the unnamed mode. Had never noticed that.

[@xi@g@me]

I get it ! So the signal restored is the lone signal, and the other one increase without any reset. This indeed correspond to the behavior I get.

So this really is a bug I guess that there is no valid reason for #1 to have its input lost for one cycle.

[Twinsen]

Good find.
You were right.
When removing something from that red wire network, in some situations the network associated with the red wire was recreated, meaning it contained no signals for 1 tick. The first combinator would read a value of 0 and then the whole setup broke.

The state is now properly preserved when the new network is created.
Fixed in 0.12.5.
Thanks for the report and the save.

[@xi@g@me]

Glad to have been able to bring my modest contribution