Memory component inconsistencies

[DarthPointer]

Disclaimers

• [X] I have searched the issue tracker to check if the issue has already been reported.
• [ ] My issue happened while using mods.

What happened?

Memory component behaviour seems to be volatile to installation order or other irrelevant-context things. Edge cases may involve the circuit boxes changing their behaviour after removing the component and placing it back in the editor test run.

I was trying to setup logics for an airlock, but the components did not behave as I expected them to. In the process I have found 2 issues.

• In simple circuits with a button pulse sent to a mem, the memory writes the value recieved next tick after the pulse reaching its lock pin.
• If I run a sub editor test of my sub, the behaviour of my airlock circuit changes if I remove and install back one of the memory components.

Reproduction steps

Delayed memory update:

• Create following circuits in any boat.
• CB image for reference, using inputs and outputs 1/2 for buttons and displays with a CB yields same results.
• Clicking the top button sets its memory to 0, whereas the bottom button sets it memory to 1. It indicates that memory elements indeed get overwritten with 1 sent to LOCK_STATE, but they happen to fetch the new value next tick after receiving the overwrite flag. I have no proof that they always behave this way, but whenever I build these simple circuits I get this behaviour every time.

Glitched memory component:

• Download this submarine. Reaktorboot I.zip

• Open it in the ingame sub editor.

• Proceed to the upper airlock. (only left door is operational, click its buttons to toggle it)

• Click the "open upper hatch" button.

• See the debug displays react, but the hatch does not open.

• Enter the upper Circuit Box.

• Remove, place again and rewire this memory component left-down of the middle column.

• Click the hatch button again - now it will toggle the outer hatch as it is designed to.

Note that in the editor the mem component in question is set to always accept new values. Attaching a display to its output gives a pulse reading according to button hits, even prior to the replacement. Copy-pasting the related buttons and circuit boxes into a new submarine makes the replacement not fix the issue completely, which may or may not be an issue on the side CB schematics.

Just in case, the undervoltage event that happens a few seconds with this boat in simulation is not connected with the issue.

Bug prevalence

Happens every time I play

Single player or multiplayer?

Other

-

Sub editor tests (not tested it outside the editor)

Version

v1.1.19.3 (Treacherous Tides Hotfix 2)

-

No response

Which operating system did you encounter this bug on?

Windows

Relevant error messages and crash reports

No response

[Regalis11]

Thank you for the report!

This sounds like the known issue of the order of signals sometimes affecting circuit behavior. Since this seems to come up periodically, I decided to make a kind of "general ticket" explaining why this happens.

In this case, I'm not entirely sure what the expected behavior would be. In the first circuit for example, you're locking the memory component at the same time as setting the value. Which one should take precedence? In my opinion, it's arguably correct that the behavior of the circuit is unpredictable.

[DarthPointer]

@Regalis11 Regarding the first circuit - there is no direct control over the signal order provided by the ingame tools, thus the components should behave connection-order-invariant. Otherwise the components would be impossible to use reliably without the routine overhead of timing management, that will just bloat the schemes and make the entire signals system too frustrating to deal with.

The second case likely is another symptom of signal orders, and it doubles down on lack of tools to view and control the timings.

[Regalis11]

I get where you're coming from, but the way I see it, this circuit is doing something that doesn't make much sense: it's telling the memory component to store a value and to not store a value (= lock the state) at the same time. What would the expected behavior be here?

But anyway, I agree that even if there wasn't a "correct" answer to how it should behave, it could make sense to add some kind of a rule that makes the behavior consistent. But we would need to figure out what that rule would be, what takes precedence when multiple signals are interfering with each other?

[Regalis11]

Closing as a duplicate of https://github.com/Regalis11/Barotrauma/issues/12993, I think the discussion can be continued there