After some logic activity, the inputs that swap rails blow out, their visual connections retain but the block itself is bricked and reconnecting to the rails will create a duplicate connection visual on-top of the ones before it bricked.
This bug can happen anywhere with rails and logic connected.
Description
Details
- Task Type
- Bug
- Affected Gamemode(s)
- Single and Multi
- Reproducible
- Yes
- Last tested (version)
- 0.199.357
- Category
- Logic Gates
- OS-Specific
- No
- Hardware-Specific
- No
- Video Card Vendor
- uncertain
(Most reliable/easy method to reproduce, although it is not similar to a usual environment)
1. set FPS limit to 30, this is crucial as higher FPS limits cannot reproduce it in this manner
- Build Alterintel's shootout rail clock (Instructions on how to build said clock)
- Activate it if you haven't already
- Observe the clock. However, you won't have to wait long for the entity to come off and the logic blocks to brick.
Event Timeline
-Feedback-
Can you reproduce this without using an exploit clock?
As any signal triggering more than usual updates (especially visual active updates) it will run into an anti-spam mode and if it does not recover from slower operation it will stop working completely.
I have not been able to reproduce this on non-rail clocks as their frequency is far too low for this to happen.
That is exactly my thought.
Regular clocks do not run in the "logic lag detection" and thus usually do not trigger the "emergency exit" from logic processing because it would affect global server performance.
So yeah, its a side effect of that exploit clock, buffering up signal or signal-changes that cannot be processed that fast.
I'm inclined to reject the report then, as we cannot allow higher limits to logic processing without allowing a way larger impact on server performance.
(As their actual use is rarely for precise timing, mostly for running jumpdrive charge circuits.)