Reika_Mods_Issues
Reika_Mods_Issues copied to clipboard
ReikaKalseki
[Expanded Redstone] Wireless receivers break after an unknown amount of time
When first placed and configured the wireless transmitter and receiver work fine but after a while changes in the signal are no longer registered. The receiver is stuck in either the on or off state until you change the channel or replace it.
Changing the channel on the transmitter has no effect on this, only the receiver gets stuck.
There is no way simple time is causing it to fail; what about things like chunkloading?
The chunk is loaded, it may perhaps be when there's no players in the chunk with the receiver even when chunkloaded. I'll try to get a case that can cause it to trigger.
So I tested leaving the dimension and coming back, no other players were nearby but it was automatically chunkloaded still like the first time this happened. It still worked fine after coming back.
Next I tried restarting the server. Lo and behold it broke immediately when the server was done loading. This makes sense since we have the server set to automatically restart at intervals which would make it seem like time passing was the cause.
I manage to replicate this bug on Singleplayer world. It broke every time I finish loading into the world. Just as OP describe, to either update the channel or replace it to get it working.
It therefore sounds like there is some sort of persistence issue on the data.
The issue still exists in the current version of Expanded Redstone.
Looking through the code, the first issue I noticed was in AnalogWireless.java updateEntity:
if (arr[channel] == null || !arr[channel].contains(this)): arr is an ArrayList of WorldLocations, so never contains an AnalogWireless class (and as far as I can see, you also don't override AnalogWireless.equals to match WorldLocation objects).
AnalogWireless.add checks again, so this doesn't cause a memory leak / any issues.
Next, TileEntityAnalogTransmitter.recalculateChannel considers all transmitter WorldLocations independent of their UUID, so having UUID-specific channel arrays seems a bit pointless.
In theory, the TEAT.recalculate method should call TEAR.update through TEAT.updateReceivers whenever the redstone value changes; somehow, this only seems to happen correctly when the channel of the receiver was changed via UI since the last server restart. Occasionally calling update() on the receivers syncs them to their channel, but doesn't allow them to be affected by updateReceivers. Periodically calling setChannel from TEAR.updateEntity at first allows the receivers to work again, but then "breaks" them on the next call (sometimes they stay broken, sometimes they oscillate between broken and working - this seems to depend on the order of the periodic setChannel calls and when you manually changed the channel).
With some more testing/logging, it seems like the cachedValue variable of TEAR is actually correctly updated by updateReceivers (logging at the end of update shows the updated value), yet the block output (and seemingly stored NBT data) remain stuck. Beyond that, I can't say what the problem is - my current class editor/recompiler (Recaf) can't deal with the BlockRedstoneBase etc. classes to insert logging, and switching to WR-CBE for wireless communication seems much more convenient than extensive bytecode debugging.
With some more testing/logging, it seems like the cachedValue variable of TEAR is actually correctly updated by updateReceivers (logging at the end of update shows the updated value), yet the block output (and seemingly stored NBT data) remain stuck. Beyond that, I can't say what the problem is - my current class editor/recompiler (Recaf) can't deal with the BlockRedstoneBase etc. classes to insert logging, and switching to WR-CBE for wireless communication seems much more convenient than extensive bytecode debugging.
Just wanted to add that I'm having the same issue with WR-CBE receivers. Only happens on server restarts, and seemingly only affects receivers that aren't in the same chunk as their corresponding transmitter. Have to test this aspect further but I believe it to be the case as of now.
