Issue type:

Using multiple ID cards to the same source card results in erronous or outdated values being sent to all but one of the ID childs

Short description:

The ID function doesnt resolve correctly when multiple are assigned to the same source card
so far seems to be a bug with display panels on complex networks

Steps to reproduce the problem:

Make a source card of some kind, in my case I was using redstone comparator's, and then create two or more ID cards with this as the source, put these cards into seperate display panels, change the source value in some way (such as inserting or emptying a chest), the values in the displays will then nolonger match

Expected behaviour:

ID cards on the same source should resolve normally

Versions:

• This mod: 1.22.1
• Minecraft: 1.20.1
• Forge: neo 47.1.106

Log file:

none generated/not applicable

This is bank 1 of redstone comparators, of two banks that use the same design and go to a central control store where all banks are &&'ed together with other values to form a final TRUE signal, however the ID cards that are simply for printing the comparator bank values on independant panels results in the ID < threshold comparison not resolving correctly, from adding a 3rd ID card to the ID card used in the comparison it shows that said ID is always a value of 0, whereas the ID on the panel is always the correct value.
If the ID card used in the independant panel is removed from the panel, the ID < threshold comparison suddenly behaves normally, but adding it back in will result in the value being locked up to the last value it was.

ok so I reworked the logic and wiped all ID cards so that the comparison is done directly from the source without an ID card, however even still if I create a new ID card on the value source that goes into the comparison, if this ID card is present in a display it breaks the comparison logic the exact same way as before, so ID cards are essentially just not usable...

ok no, so it turns out its not related to the ID function, its actually to do with how the values are resolved entirely, so if just the final ADD card is cloned and the clone is used on a display, it breaks the original ADD card, in the exact same way as the previous methods...
which is really strange considering I havnt seen this behavior in other networks, is there a problem specifically with how redstone comparitor values are evaluated over multiple var stores to multiple outputs and multiple displays??

Delayer is also affected, again in the exact same way, except this time its generating an array of values of which once placed in the display triggers the cascade failure which is reflected in the growing values on the display

The Materialiser... simply doesnt work, it will appear that it does but the values do not update except for only once when you open its UI, or move the materialised card around

BUT, so far, putting the cloned ADD into the DELAYER, generating the DELAY card (array), putting the DELAY card into the MATERIALISER, and then generating a MATERIALISED DELAYED card, and putting THAT card into the display... WORKS NORMALLY??
so I guess i at least have a absolutely whacked workaround for some really really weird undefined behavior...

further continued; I used the clone of the ADD in a proxy block, and created a proxy card for the display, and yet further still, having the PROXY card in the display, breaks the network just the same as before, but removing the PROXY card from the display immediately fixes the network...
im at a loss

... continued a little more, the workaround of delayer > materialiser > display works for only one bank, if I do the same on the other bank it breaks the whole network logic, even though theres no way that it should

oh boy, so the materialised delay card was a partial red herring, the undefined behavior gets even wilder

put cloned ADD into delayer, keep it there
place a materialiser next to the delayer, dont use it yet
create a DELAY card, put it in the display
the values will climb as the storage value does, but the comparison from the original ADD will be broken, thus the value will continue to climb above the limit
now create a second DELAY card, a very huge thing happens here as the entire network logic shuts down, all cards fail to resolve correct values, either holding their last for certain integer operations, but all boolean operations return false at all times
now, place this card into the materialiser, dont create a materialised card, the network suddenly returns to normal operation and, the two ADD cards now work!? this could be yet another herring but either way this certainly establishes how completely broken the network is somehow

so far the "fix" I ended up using in the given setup was to split the network into 4 seperate ones with individual single variable store blocks with their assortment of cards, and these linked up to the main network of the 4 via redstone modules sending into solid blocks, so each network uses its own displays and delayers for their own variable logs, everything has been working normal as expected just like the dozen other small networks I have elsewhere.

The problem seems like it might be specific to large networks consisting of multiple variable stores (3+) with variable cards at least close to 3 digits, i think this one had 50-100 cards before I split it apart. Cant really think though how this number of var stores and cards could cause these issues however, other than possibly a very specific kind of race condition across multiple var stores or with comparator inputs, or some other issue with the way card values are updated

So it sounds like there's some kind of problem with large networks that break variable resolution.

Can you share your forge logs when the problem actively occurs?

Also, could you share a world (with only ID+CC+CommonCaps installed) in which this problem occurs?

Since I already tore apart the faulty network and rebuilt new ones I dont think I have a copy of the world anymore with it, also there was nothing at all mentioned in the logs, no warnings or exceptions

Ok, no worries. Closing this issue then in the meantime, until new information arises.