Sensor + area triggers

[therimmer96]

We all know area triggers suck ass for things like automatic doors. Most people want them to activate when something is in it, and deactivate when empty.

The perfect block for this behaviour is a sensor.

pls schine <3

 

[rariisan]

Thinking about it, and I'm not sure that would simplify trigger doors. Right now the simplest way of making a trigger door is having two trigger detectors, one for each side of the door. Each trigger detector would then have some delay blocks and shut itself down in a few seconds.

Now I think how I would make a trigger door with your described sensors. First of all I couldn't connect both sides of the door to the same sensor, since when a player passes he would first open the door by passing through one side of the door and then close it by passing through the other side. But that's not fail proof. If a player were to activate the door from one side and just not cross the door, the next time he wanted to pass through that door it would shut on his face. So I would need again two different sensors for each side of the door, being at the same situation I am with the current state of the game.

Lemme know if I got something wrong, but my conclusion is that it would basically be the same, no?

 

[Spindizzy]

Agreed, area trigger controllers suck.

I have no idea why they are designed to look like a logic block and why they're are able to linked to directly and turned on and off, seems to be a redundant feature, as far as I can tell and according to a generally unhelpful wiki they only work with an activation block placed next to them, maybe there were supposed to not need an activation block but they were never finished.

As you say, sensors would be better as you can link a clock to them and look for updates in the status of something blocking a doorway before you start triggering stuff. Would be better than a double door trigger or a delay as it would actually be an intelligent system that only shuts once something gets out of the way.

 

[Malacodor]

Thinking about it, and I'm not sure that would simplify trigger doors. Right now the simplest way of making a trigger door is having two trigger detectors, one for each side of the door. Each trigger detector would then have some delay blocks and shut itself down in a few seconds.

Now I think how I would make a trigger door with your described sensors. First of all I couldn't connect both sides of the door to the same sensor, since when a player passes he would first open the door by passing through one side of the door and then close it by passing through the other side. But that's not fail proof. If a player were to activate the door from one side and just not cross the door, the next time he wanted to pass through that door it would shut on his face. So I would need again two different sensors for each side of the door, being at the same situation I am with the current state of the game.

Lemme know if I got something wrong, but my conclusion is that it would basically be the same, no?

You can use four trigger areas like this:
12D34 (D=door)
1 and 4 close the door, 2 and 3 open it.

1. Link 1 and 4 to trigger controller A and 2 and 3 to controller B
2. Place activators A and B next to each controller
   
3. Link Activator A <-> Button A, same for B; the buttons will reset the activators
   
4. Link Button A -> AND gate -> Flip Flop -> NOT gate -> back to same AND gate as before
   
5. Link Button B -> AND gate <-> Flip Flop (same as above)

This way, going back after the door opened will still close it.

 

[jayman38]

I disagree with this suggestion, but only because it's a bandaid fix for a broken game mechanic that needs to be fixed at the root of the problem. Area triggers need to use periodic sampling (example: once every second, but only if there is an intersection between two or more entities) instead of a one-time flip-flop trigger.

 

[Spindizzy]

Area triggers need to use periodic sampling (example: once every second, but only if there is an intersection between two or more entities) instead of a one-time flip-flop trigger.

Yeah, periodic sampling such as every second, which is basically what sensors do when you link a clock to them.

 

[Malacodor]

I disagree with this suggestion, but only because it's a bandaid fix for a broken game mechanic that needs to be fixed at the root of the problem. Area triggers need to use periodic sampling (example: once every second, but only if there is an intersection between two or more entities) instead of a one-time flip-flop trigger.

This way I could run through a lot of trigger areas undetected.

 

[Space Shaman]

Yeah. I would see them activate on contact act as they do now and use either a clock or their own periodic sampling to turn off when a player leaves. Perhaps then you could configure them with linked activation modules to require a certain number of entities to activate. Then instead of activating on contact they would sample on contact and periodically/with a clock.

This way I could run through a lot of trigger areas undetected.

I must say, once every second would be rather slow.
[doublepost=1476050728,1476050577][/doublepost]

You can use four trigger areas like this:
12D34 (D=door)
1 and 4 close the door, 2 and 3 open it.

1. Link 1 and 4 to trigger controller A and 2 and 3 to controller B
2. Place activators A and B next to each controller
   
3. Link Activator A <-> Button A, same for B; the buttons will reset the activators
   
4. Link Button A -> AND gate -> Flip Flop -> NOT gate -> back to same AND gate as before
   
5. Link Button B -> AND gate <-> Flip Flop (same as above)

This way, going back after the door opened will still close it.

I'd say that's unreasonable for one door and thus warrants a change.

 

[Space Shaman]

Thinking about it, and I'm not sure that would simplify trigger doors. Right now the simplest way of making a trigger door is having two trigger detectors, one for each side of the door. Each trigger detector would then have some delay blocks and shut itself down in a few seconds.

Now I think how I would make a trigger door with your described sensors. First of all I couldn't connect both sides of the door to the same sensor, since when a player passes he would first open the door by passing through one side of the door and then close it by passing through the other side. But that's not fail proof. If a player were to activate the door from one side and just not cross the door, the next time he wanted to pass through that door it would shut on his face. So I would need again two different sensors for each side of the door, being at the same situation I am with the current state of the game.

Lemme know if I got something wrong, but my conclusion is that it would basically be the same, no?

You just described current area triggers.

 

[rariisan]

You just described current area triggers.

...Which is precisely the conclusion I put in the end and beginning of the text. And if my conclusion is true, which I invite everyone to refute, this suggestion doesn't simplify automatic doors.

 

[Space Shaman]

...Which is precisely the conclusion I put in the end and beginning of the text. And if my conclusion is true, which I invite everyone to refute, this suggestion doesn't simplify automatic doors.

No, you see the door would simply close on you, since by stepping through the auto door, you'd leave the trigger that was behind you. But that's only if you're using vanishing doors and if you aren't smart enough to use them differently than the current triggers. With this change, you can make a door system that works the same as the old one, and them improve upon it by detecting the absence of a player after 1 delay block to determine whether or not the door should close. Vanishing doors are NOT what this change in triggers would help with (the sensor is).

Rail doors are a different story. One of these area triggers would make would make a rail door run smoothly, as it would open as it triggered the same as current triggers would, but the same trigger area can be all through the door. This means means the signal would stay on until you leave, when which it would close unlike current triggers.

This also applies to things like broadside trigger systems. they would stop firing the moment the offending ship left the fire zone.

 

[rariisan]

No, you see the door would simply close on you, since by stepping through the auto door, you'd leave the trigger that was behind you.

What door are you talking about now? If you're talking about the simplest possible trigger door I gave as an example, no it would not close on you, because leaving the trigger that is behind you is what causes the opening signal in the first place. The closing would happen once a delay shuts it down.

With this change, you can make a door system that works the same as the old one, and them improve upon it by detecting the absence of a player after 1 delay block to determine whether or not the door should close.

You completely lost me here.

Rail doors are a different story. One of these area triggers would make would make a rail door run smoothly, as it would open as it triggered the same as current triggers would, but the same trigger area can be all through the door. This means means the signal would stay on until you leave, when which it would close unlike current triggers.

Technically not, since when you're inside the door there can't be any area triggers, and that would close it for a second (if they are block doors that's bad news).

 

[Space Shaman]

My point was that with the changed triggers you could build a consistent and bug-free trigger door (non rails) with only slightly more blocks than the common buggy area trigger door with the current triggers.

Technically not, since when you're inside the door there can't be any area triggers, and that would close it for a second (if they are block doors that's bad news).

I was referring to rail doors here. The area triggers can take up the same space as the door.

 

[rariisan]

I was referring to rail doors here. The area triggers can take up the same space as the door.

Yes they can, but since it would output true when there's someonthing inside the area, it would always stay open, since a door is an entity that triggers areas. :P

 

[Space Shaman]

Yes they can, but since it would output true when there's someonthing inside the area, it would always stay open, since a door is an entity that triggers areas. :p

Docked entities don't affect trigger areas.

 

[rariisan]

Docked entities don't affect trigger areas.

Last time I checked it did, but that was some patches ago. did it get patched?

 

[Space Shaman]

Last time I checked it did, but that was some patches ago. did it get patched?

Only one way to find out!
[doublepost=1476174977,1476173687][/doublepost]Nope! they don't!
[doublepost=1476175273][/doublepost]As you can see here, it does not trigger. And yes that is another docked entity with a trigger in the same spot just to see if that works. (it don't)

 

[Malacodor]

Docked entities don't affect trigger areas.

That's a bug.

 

[Spindizzy]

...Which is precisely the conclusion I put in the end and beginning of the text. And if my conclusion is true, which I invite everyone to refute, this suggestion doesn't simplify automatic doors.

Wouldn't really simplify no, but it wouldn't make more complicated either, it'd be about the same, only;

1. We can bin the Trigger Area Controller block and free up a Block ID.
2. No other existing fixed logic system in the game rail or otherwise is capable of doing what this could do, which is to be able to correctly trigger and handle objects of any size.

I'll give an example to get the point across.

You've built an internal docking bay with 8 docking bays and a rail system that guides docking ships to their dock points, hangar doors open and close behind them and they're guided by rails to a free space.

You've built your trigger door, with trigger areas on both sides of the door, where it opens from one side and closes on the other. Only you've built this place for visitors and have no idea how large the ship that docks is going to be. (Let's say for arguments sake they're smaller than the maximum and fit inside though)

Using the tools you currently have, you'd just have to guess how long to delay a door and how far apart to space the trigger areas. Or to avoid problems, you'd have to measure your docking bay and see what length the biggest possible docked ship would be, figure out the correct maximum delay timer of how long it'd take an object of that size to pass through the door based on rail speed and you'll likely have to figure this out through trial and error. Or you could just use an activator under when the ship finally finished docking to close the door.

Where with a sensor that detects a presence you just have your triggers on both sides of the door, link it up and forget about it. So in that sense it is simpler. You'll never have to space out trigger areas ever again for certain tasks, they can always be just on both sides of a door.

 

[Space Shaman]

That's a bug.

I needs to be a feature. You can detect docked ships using the rails themselves. It's more functional for it to not detect it's sibling/child docked ships.