Event Controller does not properly track block states in normal ("OR") mode
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.
I have the same bug
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
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
I really hope Keen responds to this thread. I want to know if it's by design because it makes the thing totally unusable.
I really hope Keen responds to this thread. I want to know if it's by design because it makes the thing totally unusable.
same issue here, the OR function seems to only update on when block is updated through external interactions
same issue here, the OR function seems to only update on when block is updated through external interactions
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
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
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!
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!
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.
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.
Besides the wrong signals for the OR gate some extra (unneeded) signals are sent as shown below.
Besides the wrong signals for the OR gate some extra (unneeded) signals are sent as shown below.
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.
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.
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
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
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.
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.
Replies have been locked on this page!