Gate Concatenate String will concatenate incorrectly in some cases

[GrecoSorcerer]

Describe the bug The gate Concatenate (String) seems to concatenate incorrectly in some cases.

I found one such case when building a register with SR-latches with XOR-ed outputs. Where those outputs were converted to strings and concatenated to read as a binary string more clearly for debugging.

To Reproduce Upon request I can provide dupes or videos.

Module A has 8 numeric outputs, outputting 0 or 1. Module A has 10 numeric (bitwise) inputs. 8 Data lines, a reset line and an XOR line called SUB.

When SUB is TRUE, then each data line is xor-ed bitwise. Each output is converted to a string.

Each string is concatenated.

The output may be observed.

Set SUB to TRUE

The error should be seen.

Expected behavior Match the Indicator module output.

Screenshots Demo of issue: Initial State, Xor off

After using Xor

After turning off xor

After XOR-ing the Registers Output, the NumToString gate array converts each digit to a string to concatenate. This operations seems to cause incorrect concatenation in some cases.

I've found flipping the leading bit LMB, the concatenation is correct again.

[thegrb93]

The problem is each input is produces a calculation and a gate can only produce a certain number a calculations per frame. So once it reaches its max number of calculations, it gets stuck with the unfinished result.

[GrecoSorcerer]

Interesting, do you have any suggestions on how to mitigate this issue?

Perhaps I could use two concat gates instead, and see if that helps. I could use E2, but I'm looking to avoid scripts where I can.

[thegrb93]

Maybe output ports can get an increased number of outputs per frame.

[GrecoSorcerer]

Maybe output ports can get an increased number of outputs per frame.

Are you suggesting there is something I should try? Or are you suggesting that this is something that would be evaluated for changes?

[GrecoSorcerer]

Do you mean the data port?

[thegrb93]

@GrecoSorcerer you can try increasing this to 8 and see if it fixes the issue you're seeing. https://github.com/wiremod/wire/blob/master/lua/wire/server/wirelib.lua#L650

[thegrb93]

Imo outputs shouldn't have a trigger limit, only inputs. @wiremod/wiremod-core @wiremod/developers would need to give opinions on that though.

[thegrb93]

Actually, you'd need inputs increased too, because that output will trigger 8 times, and whatever its connected to will only take up to the 4th one.

[GrecoSorcerer]

you can try increasing this to 8 and see if it fixes the issue you're seeing. https://github.com/wiremod/wire/blob/master/lua/wire/server/wirelib.lua#L650

Ah so download the src, edit that line, with the value of output.TriggerLimit = 8 instead of 4? If I have Wiremod through the workshop, will I need to unsubscribe from the WS versions?

Imo outputs shouldn't have a trigger limit, only inputs. @wiremod/wiremod-core @wiremod/developers would need to give opinions on that though.

Yeah.. I might try something round about where concatenate is not checking the output of the numbertostring gates until Clk, and find out if delaying the read helps, as I'd like to use this on servers as a demo.

Thankfully I only need to concatenate for certain modules, so it really only effects my debugging modules right now. Indicators work fine, but are could be spawn limited.

[thegrb93]

We should increase from 4 to 8 I think. Since so many gates have 8 inputs.

[GrecoSorcerer]

Unless there is some performance reason, I think so as well.

For the gate to lock up and give no warning or info about why either, is frustrating.

[Anticept]

Actually, you'd need inputs increased too, because that output will trigger 8 times, and whatever its connected to will only take up to the 4th one.

This seems like trigger limits should be an sv_ var