Event Controller does not properly track block states in normal ("OR") mode

Nevcairiel shared this bug 20 months ago
Solved

In the "normal" mode (eg. not AND), lets call it "OR" mode, the Event Controller does not properly track the state of blocks its monitoring.

Instead of applying a logical OR operation to the blocks, the latest state change of any block is used. This results in very inconsistent behavior and states. This is unnoticeable with a single block being monitored, but when monitoring multiple blocks, the state is inconsistent and basically unusable.

For example, consider monitoring two doors with the Door Opened event on the Event Controller.

- Initially, the doors are closed, and the EC is in the "Unsignaled" state.

- Open one door, the EC goes "Signaled"

- Open the second door, EC remains "Signaled"

- Close one door, EC goes "Unsignaled", while one door remains open

In this last state, one door remains open, and one is closed. Yet the EC is "Unsignaled" while a door is still open. This is the same state as one of the earlier steps, but with a different outcome in the EC.

This behavior is very inconsistent, and basically makes the "OR" condition useless for tracking multiple blocks. You can never know what the state of the entire system is, because you just know what happened last.

The "AND" mode actually works fine, as the EC checks the state of all blocks here. The "OR" (Normal) mode should do the same, just with a different logic.

Replies (11)

photo
4

I ran into this aswell, not sure if this is by design or just a bug.


If it is by design then we desperately need more logic gates.

For example a dropdown with: AND, OR, XOR, NOT

photo
1

I really hope Keen responds to this thread. I want to know if it's by design because it makes the thing totally unusable.

photo
1

same issue here, the OR function seems to only update on when block is updated through external interactions

photo
1

i saw the mod https://steamcommunity.com/workshop/filedetails/?id=2962619034 and read thru to find the bug report at the bottom, i didnt play much after the update and didnt notice this issue as i have yet to play with the event controller so i made a new world with this mod and set up a small area to check the OR gate 'default' using the DOOR OPEN, CONNECTOR CONNECTED, and THRUST %. i used both the mod and vanilla and have found that what the bug report is stating is true, the default state will only track the most recently updated block which is annoying as if u want to use the event controller u will need one for each block u want to watch that state for (using the OR gate). as stated by the mod author (also bug reporter) in the mods comment section, the AND gate works as intended checking the states of all blocks when something updates so there isnt a reason for the event controller to do the same for the OR gate. if this was by design, it was an oversight, but i would think this is just something that slipped thru as the main focus was just to get the AI to work......better. for now using the event controller for singular blocks works ok, for the more complex tasks i shall be using timers for now

photo
1

Well, the block is called "Event Controller", not "Block State Tracking Controller". It fires when an event happens, a door opening, or cargo amount changing, etc I can't say if this is better or worse then what you guys (and probably many other people) expected, but it is by design,

More logic gates would definitely be great!

photo
1

Monitoring an entire group of blocks vs one block adds a LOT of complexity. Perhaps too much. If the event controller was limited to monitoring one block and perhaps... reduce the PCU cost a little? That might make things easier to manage.

photo
4

it watches the whole group already with the AND gate, so i dont see much of a issue to just have it run for the OR gate also

photo
photo
2

Besides the wrong signals for the OR gate some extra (unneeded) signals are sent as shown below.

Sequence of events signalled:

OR - Gate
A  B    Observed   Expected
0  0     (unset)          -
1  0     Signal 1      Signal 1
1  1     Signal 1         (%)
0  1     Signal 2         (%)
0  0     Signal 2      Signal 2

AND - Gate
A  B    Observed   Expected
0  0     (unset)          -
1  0       (%)              (%)
1  1     Signal 1      Signal 1
0  1     Signal 2      Signal 2
0  0     Signal 2         (%)

(%) = no signal expected when state is the same.

photo
3

They need to change the AND Mode checkbox to a dropdown containing multiple modes, including the default, AND and OR. Default mode still has its uses, but the inability to reliably trigger an action when none of the conditions is true is an oversight. Preferably, they would add all the basic logic gates.


Otherwise, they could add a checkbox called "Inverted" which would check for the inverse of the selected condition. Then the AND gate would act line a NAND.

photo
3

Hello, Nevcairiel,


thank you for contacting us and thank you everyone for your comments. I was able to reproduce the bug and I reported it into our internal system.


Kind regards,

Keen Software House: QA Department

photo
2

Honestly, this may be an unpopular opnion - I prefer this behaviour.


When not in AND mode, it reacts to events, with no state tracking. This is actually useful.

You can also achieve a lot of stuff simply by swapping the two actions, whether that's in AND mode or not.

This, in most cases, can effectively turn an AND mode controller into a proper OR gate.


Furthermore, current implementation allows for NAND gates - and by extension, any gate using NAND logic.


Changing behaviour at all, aside from of course fixing bugs such as merge block events often just not working, will break many setups.

It also risks making the current behaviour when not in AND mode MUCH harder to produce.


As such, I believe that the current behaviour regarding the AND toggle should remain the same, though a dropdown for further options certainly could benefit if it's implemented without breaking existing behaviour, as the gates added directly to the controller will stop needing NAND logic.

photo
1

This is already fixed since the last update dropped, I don’t know why they didn't marked it as fixed here, bud they did advertise it in the change log as a new feature.

I personally like the change, it makes stuff easier, I already updated my guide on Event Controller logic gates https://steamcommunity.com/sharedfiles/filedetails/?id=3008744122 and it includes a way of restoring the original behavior

photo
1

I did some testing and indeed the issue seems to be resolved in 1.203. I have still yet to hear a proper use-case of the original behavior, but if someone desperately wants it..

photo
photo
1

Dear Player,

We have reviewed our internal tickets and noticed that your issue seems to have been resolved with the release of version 1.203.

As a result, I am closing this thread as Solved. However, if you experience this issue again or encounter any new problems, please don’t hesitate to contact us.

Happy Engineering!

Kind regards,

Keen Software House: QA Department

Leave a Comment
 
Attach a file