Trigger_relay Addition
MightyMooquack
Join Date: 2003-01-16 Member: 12356Members
Join Date: 2003-01-16 Member: 12356Members
<div class="IPBDescription">Suggestion for a new flag</div>I had originally posted this in the Suggestions and Ideas Forum, but it was suggested I post it here. So here you go:
Here's a very simple little addition, which may or may not be feasible. If at first it doesn't seem useful, well, I've thought of at least one use for it. Anyway, here goes: a NOT gate.
It could be implemented as a flag for trigger_relay. Basically, it would cause the trigger_relay to fire so long as it is not being triggered. Your first reaction (at least, my first reaction, if I weren't the one with the idea) is probably that anything that would require this trigger could probably be implemented in another way which doesn't actually require it after all. Like I mentioned earlier, I've thought of a single, specific use for such a thing, and it goes like this:
Take a hallway, lit with spotlights on the ceiling, pointed down. Actually, make those spotlights turned off. The effect we want to produce is one where a light will turn on when someone is under it and turn back off when no one is under it. This effect, if we want to do it in the context of NS, must ALSO work in a multiplayer setting, where any number of people could be running around, coming and going, under these lights. If this were a single-player setting, one could easily set up triggers in such a way that a single player would produce this effect by triggering them in order, but such an approach wouldn't work well with more than one person.
With multiple people, the easiest approach would be to have a trigger_multiple under each light. This would target a trigger_relay with the triggerstate set to "on", and this still-theoretical NOT gate, which in turn would target another trigger_relay with the triggerstate set to "off". Both of these trigger_relays ("on" and "off") would target the spotlight. Thus, when the trigger_multiple is fired (by one or more players walking under it) the NOT gate shuts off (shutting off the "off" relay) and the "on" relay switches on, turning on the light. When no one is in the trigger_multiple, the "on" relay switches off, and the NOT gate turns on the "off" relay, turning off the light. (Of course, another option for a new flag is a "hold on" option for the light itself, which would allow one to target the light directly from trigger_multiple, but a NOT gate seems more multipurpose.)
If I'm missing something obvious in the creation of this effect (i.e. a simpler way to do it), don't hesitiate to let me know. If you think the example effect is useless, well, it's not the only use for a NOT gate, I'm sure. It seems like a simple thing to code in, and I see nothing against giving mappers such an option.
Here's a very simple little addition, which may or may not be feasible. If at first it doesn't seem useful, well, I've thought of at least one use for it. Anyway, here goes: a NOT gate.
It could be implemented as a flag for trigger_relay. Basically, it would cause the trigger_relay to fire so long as it is not being triggered. Your first reaction (at least, my first reaction, if I weren't the one with the idea) is probably that anything that would require this trigger could probably be implemented in another way which doesn't actually require it after all. Like I mentioned earlier, I've thought of a single, specific use for such a thing, and it goes like this:
Take a hallway, lit with spotlights on the ceiling, pointed down. Actually, make those spotlights turned off. The effect we want to produce is one where a light will turn on when someone is under it and turn back off when no one is under it. This effect, if we want to do it in the context of NS, must ALSO work in a multiplayer setting, where any number of people could be running around, coming and going, under these lights. If this were a single-player setting, one could easily set up triggers in such a way that a single player would produce this effect by triggering them in order, but such an approach wouldn't work well with more than one person.
With multiple people, the easiest approach would be to have a trigger_multiple under each light. This would target a trigger_relay with the triggerstate set to "on", and this still-theoretical NOT gate, which in turn would target another trigger_relay with the triggerstate set to "off". Both of these trigger_relays ("on" and "off") would target the spotlight. Thus, when the trigger_multiple is fired (by one or more players walking under it) the NOT gate shuts off (shutting off the "off" relay) and the "on" relay switches on, turning on the light. When no one is in the trigger_multiple, the "on" relay switches off, and the NOT gate turns on the "off" relay, turning off the light. (Of course, another option for a new flag is a "hold on" option for the light itself, which would allow one to target the light directly from trigger_multiple, but a NOT gate seems more multipurpose.)
If I'm missing something obvious in the creation of this effect (i.e. a simpler way to do it), don't hesitiate to let me know. If you think the example effect is useless, well, it's not the only use for a NOT gate, I'm sure. It seems like a simple thing to code in, and I see nothing against giving mappers such an option.
Comments
it fires A when its empty and someone joins that brush, and B if the last person leafes it.
its perfect for everything that gets triggered in 0-time or that activates a trigger once..
Triggering doors multiple times with trigger_presence is tricky because it gets out of sync with the door with high speed or teleport (when its done the simple way).
the light effect is already used in nc_chilrais. you just dont see it good because the map is too bright even with that lights off.
a "trigger_nonpresence" is still missing.
trigger_nonpresence should act like a big trigger presence that is all over the map but just not at one place.
But it's more entities, which (as you should all know by now), brings you a step closer to poor server performance. The fewer entities, the better. Within reason, that is.