News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
 
func_door doesn't fire targets when it opens or is shot, so in this case you will likely want to set it up so that you have a thin trigger_once/multiple with 'health' '1' which is what you actually shoot... and that targets the door and a trigger_relay with a delay that targets your second door.

if you are using a func_door_secret, that will fire a target when it is shot or triggered open, but it will fire it right when it is triggered so you will likely want to target a trigger_relay with a delay in this case as well. 
I Believe That 
AD has this functionality. It could be worth using trigger_relay as scampie said. 
 
Yes. You just have to synchronize. Your door targets a trigger. This trigger waits to fire just the amount of seconds the door takes to open. Cant remember the exact properties' names, though, but that works. 
Thanks Everryone 
Sweet thanks everyone. I'll give this a go! 
It Works! 
Sweet... and I can trigger multiple things in various sequences. Epic doors opening with lighting toggling on... so fun. I wonder why this was not used more back in the day. 
I Use 
toggling on lights behind secret doors/monster closets when they open to prevent spoiling that there's something behind it before it opens. 
Door Triggered By Either Of 2 Events 
I want to create a door which will be opened by either of two events:
1. a player walks into a special trigger area (trigger_multiple?), and the door stays open as long as the player is triggering
2. a moving brush touches the door and the door will stay open as long as the brush is triggering it
The door should also stay open when both events take place at once and close (immediately) only when the events stop triggering.
Is this possible with the original Quake entities? 
Logic Gate 
Sounds like building a physical logic gate somewhere outside of the map is what you will need.

Create a button that operates when shot, set a spike shooter firing nails at it. Then place 2 doors between the spikes and button that block the spikes.

The 2 triggers inside the map should move the doors when activated, so that when both are active the two doors are moved out of the spikes flight path and the button is activated. 
 
Good lord ... that's ... awesome. 
But That's An And Gate 
He wants an or gate. 
Yep, Need OR Gate 
Yep, two doors will work as an AND gate. I need OR. But will definitely try to experiment with the spikes tonight. 
Can Use 1 Door 
Maybe I could set the triggers to open just one door? That should work as an OR gate 
 
I believe preach had a map hack for this which removes any delay in the triggers 
You Could Do The Same Spike Trap Setup As An OR Gate 
You need two spike traps firing at the trigger, and two doors. Just offset them at different angles so it works.

A NOT gate would be trickier but doable as well. Have a door block the path of the nails when triggered by the undesirable trigger. 
OR Gate 
Your idea is almost there, Shamblernaut: For that to work completely you have to do it so each door blocks the other door's path of the spikes, so it doesn't work as AND too and only as OR.

So you end up with:

Rest: 1 trigg 2nd trigg. both trigg.
� � � � � � � �
� - � - - � - �
- � - - � -
� �
T T T T T T T T 
Forgot To Preview It 
I repeat it:

Rest pos.....first trigg...2nd trigg...both trigg.
������������������������������'�������
��-����''�������-���'���-������'''���-��
-������'�������-���'���-������''�����-
t�t����''�����t�t���''���t�t����''���t�t

I am hating the fact that kerning is only applied to the posted post and not when writing. Took me a while to make the columns to stay aligned. 
Detail Brushes Considered Harmful Lol 
http://lunaran.com/files/visdetailtest.zip

(see celephais.net/board/view_thread.php?id=61207&start=184 ) 
Thanks Lun 
R.I.P. vis in natural cave type maps I guess. 
Logic Gates 
Here's the pair of articles on how to do "instant activation" logic gates:

https://tomeofpreach.wordpress.com/2013/05/13/new-logic-gate-design/

https://tomeofpreach.wordpress.com/2013/05/15/new-logic-gates-part-two/

There's some bonus content added today in the latter post: I've added the template .map files for the gates, only 32 months late! 
Lun, Kinn 
This is only if the detail brush seals the world face away. If the detail brushes are simply floating inside a world cube, this should still block vis?

Vis would see past the detail but stop once it reaches the box behind it? 
 
If it's not cutting into the structural brushes, it shouldn't be any problem at all. It's only when a detail brush completely covers and eliminates a structural poly that you run into trouble. 
 
Yeah. And that fudgy sliver space can be skip textured so you don't waste triangles and lightmap space (if that's a concern to you).

Still seems like a counterintuitive workflow, though, having to leave a gap where a gap would be totally the wrong thing to do in all other cases.

For big cave walls and such I'd prefer to have a vis table that properly treats giant func_walls as spanning multiple leaves, so there's no danger of them flickering or vanishing from the wrong vantage points. 
Cocerello 
From your description, what you're proposing is an xor gate (either, or, but not both). I think the original question mentioned that the trigger should also be activated when both conditions are satisfied. 
Lun 
thanks, that is great. Which tools did you use? I think tyrutils-ericw, original tyrutils, and rebb's txqbsp all have the same behaviour for detail.

For big cave walls and such I'd prefer to have a vis table that properly treats giant func_walls as spanning multiple leaves, so there's no danger of them flickering or vanishing from the wrong vantage points.

Yeah, that's purely up to the engine, since the table of leafs an entity is spanning is calculated and updated at runtime, in the server.
The original (problematic) behaviour was, if an entity spans more than 16 leafs, only the first 16 of those are used to compute visibility. I think most engines nowadays extend that table size and/or handle exceeding the table size by making the entity always visible (QS does this), but it is something to keep in mind. 
 
I recommend some folks check out jam6_scampie or ad_necrokeep with "r_showtris 1" and "notarget"... the way vis seems broken in this map is that certain brush entities (func_wall and func_illusionary and some func_doors) are visible at all times throughout the map. I suspect it's detail brushes which are the culprit, but I'm not exactly sure how! 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2025 John Fitzgibbons. All posts are copyright their respective authors.