Compatibility issue with redstone debugging tools
SpaceWalkerRS opened this issue ยท 5 comments
Version Information
lithium-fabric-mc1.17.1-0.7.3
redstone-multimeter-fabric-mc1.17-1.3.0
Expected Behavior
When a short-pulsed repeater depowers, RSMM reports a tick priority value of -2.
Actual Behavior
RSMM reports a tick priority value of -1 or -3 (whichever was the priority value when the repeater powered on).
Reproduction Steps
Since the bug does not change vanilla behavior and only surfaces when using redstone debugging tools, a mod like Redstone Multimeter (RSMM) is required to observe it. Because of this the reproduction steps will include a mini tutorial on how to use RSMM. Apologies for this. I have highlighted the steps to induce the bug in bold.
1. Place down a repeater and set its delay to 4gt or more. Place an observer behind it, its output pointing into the back of the repeater.
2. Look at the repeater and press M to place a meter on it. A HUD should appear in the top left, an overview of events that occurred within the last 60 ticks, with one row titled repeater 0.
3. Press G to open the Multimeter screen.
4. Click on repeater 0 to open its controls.
5. Scroll down to the Metered Events section and enable scheduled_tick.
6. Press esc to close the Multimeter screen, then press N to un-pause the HUD.
7. Update the observer.
8. Open the Multimeter screen again.
9. Scroll through the HUD (using , and . or by clicking and dragging the HUD) until the tick in which the repeater depowers is highlighted. An extra overview should appear to the right.
10. Hover over the events this overview and a tooltip should appear with information about the events. One of these events will read
event type: scheduled_tick
priority: -1
...
Other Information
Looking through the code for LithiumServerTickScheduler, I believe the bug occurs in the addScheduledTick method. On line 299 a TickEntry is retrieved from the scheduledTicks map, or a new one is created. If no new TickEntry is created, its priority field is not updated to match the new ScheduledTick. This means that any redstone debugging tool, like RSMM, RedLog, TIS Carpet, etc. that intercepts these TickEntrys will log incorrect information.
I think this should be fixed by b93b597
Thank you for your own debugging work. This sounds like Lithium is switching up the tick priorities, keeping the outdated values, unlike vanilla. Or do you think this only happens when redstone debugging tools are present?
Lithium is reusing old objects, but the outdated data is not used by lithium, since the priority is determined by the collection the tick object is stored in. Of course mods like RSSM might be using that outdated data. This has to be fixed on lithium's side. Can you describe where/when you are collecting data on the scheduled ticks?