Triggers and Activation Gates. Dev question.

[Aynslei]

Trigger area controllers, Step Triggers, and now Activation gates all respond to an object entering their area, but have no reaction to anything leaving their area. If a core passes through an activation gate it turns an adjacent activator on, but the next core to fly through turns it off.

Why?
Why don't any of these logic devices change their state to off when the object that activated it leaves?

There are ways to work around this using other bits of logic, but the utility of having a constant on until the area is empty is absent without a rather large set up of logic systems.

My suggestion is to make all three types change to an off state when their area is empty. (Old functions that rely on the past way can use flip-flops, a single block fix)

 

[TomW1605]

there are 3 other options

1. add a different computer that uses the same modules but is only on when the aria is occupied
   
   
2. add a 'r' menu to the computer that allows you to select the type of output
   
   
3. make the computers able to be turned on/off by logic inputs. (this wont solve the problem completely but it will make the work around easier)

 

[jayman38]

I think the reason for this behavior is that it is very easy for the game to track entity entry in the background, but takes resources to track departure. I'd recommend a entity-triggered departure signal, where the entity stores the 3D coordinates of every activation/tracking field it is in, and then sends a signal to the appropriate tracking computer when the entity thinks it is outside of the detection field, which then causes the detecting entity to perform an intersection check, to see if the detected entity is truly out, and then sending an off signal on to any linked blocks.

Behavior for multiple detected entities: Only sends an off signal if all entities report an exit?

Plus maybe a periodic (10-second?) check, regardless of any signals, to check for intersections, in case the entities that exited failed to send a signal.

It would take more processing to track exits instead of just entries, but I think the improved behavior would be worth the effort.

 

[Trekkerjoe]

I would very much like for these sensors to turn on when it detects an entity, and reset when it no longer detects an entity, as described in the OP. It makes more logical sense, and you know I would exploit this for sensors left and right...

It would allow for better/simpler logic builds. Imagine the robots that would suddenly become viable due to having working sensors. How about doors that open when you get close, and close when you leave, using only a NOT, rather than the buggy/bulky timed ones. Being able to detect when an auto miner has finished up it's asteroid, rather then relying on weird storage logic would also be nice.

In the meantime, can someone link to the workarounds? Hopefully soon I will be pushing the game to it's limits with a fully programmable robotic system, and for that, I will need sensors that work like above.