Door Trouble
Heist
Join Date: 2002-11-09 Member: 7922Members
Join Date: 2002-11-09 Member: 7922Members
<div class="IPBDescription">2 Problems</div> OK.. I just need two questions answered.
First - Double Doors - If you have played Caged or Trane you know the doors I am talking about. These doors can be manipulated so that one will close as the other opens. Is there anyway to stop this from be exploited?
Second - Blocking Doors - On one of the doors in Trane, when you block it with defense chambers it emits a loud looping noise that overflows clients. It is very similar to the shound made by the garage door on cs_office. Anyone know what causes this?
Thanks for any help.
First - Double Doors - If you have played Caged or Trane you know the doors I am talking about. These doors can be manipulated so that one will close as the other opens. Is there anyway to stop this from be exploited?
Second - Blocking Doors - On one of the doors in Trane, when you block it with defense chambers it emits a loud looping noise that overflows clients. It is very similar to the shound made by the garage door on cs_office. Anyone know what causes this?
Thanks for any help.
Comments
But the first question still remains.
"Damage inflicted when blocked"
You can make doors causing damage on getting blocked too.
This will still desyncronize the doors but do you really want to die for this?
Unblockable closed:
I think a door (or was this an elevator) with the "toggle" flag will move back when it gots blocked once while a non-toggle elevator does not stop moving. (so use an elevator as door, wich needs +2 entities)
Could be that the "-1" value on doors determines this behaviour for doors.
keep open:
One simple solution can be giving both doors the same name.
-> theese doors behave like clones, if one gets blocked both move back.
Another is making both doors one door entity.
-> theese doors behave like siamesian twins.
(this solutions will open and close both doors at the same time)
Other solitions need a lot of trigger_relays, trigger_state, good timing...
-> When one door was blocked it "calls" the other door to open IF this door closed.
Perhaps I can just make it do dmg.
Perhaps I can just make it do dmg. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Make the doors inflict mortal damage and they should keep going.
Block func_train at your peril, for it will not stop moving. It moves from path_corner to path_corner, and anything in its path takes crushing damage until dead, then it continues moving to its destination. Func_doors just reverse direction, which is undesirable behaviour.
I use func_trains for all my large doors, as they're usually tied to events which would be messed up if the door didn't close.
For extra control, use the fire on pass field for a path_corner to set up entities that are triggered when the door opens or closes, this way your sequence will only occur when the doors are properly closed. A good example is a pair of env_globals that state whether a door is open or not, and multisources that use these env_globals to store the open/closed state of the door. You can have the fireonpass trigger a multimanager which turns one on, and one off, to ensure that some things will not work until a particular door is closed.
I have one for you guys:
Do you know of any way to stop a comm from triggering a door?
The doors I'm working on are 'special':
They are made to be one-way doors until welded open from the locked side. I have fixed the buttons by burying the func_button brush slightly in the wall. That prevents the comm from being able to activate the switches, but the problem that I'm running into is that if the comm clicks directly on the door, it opens. I've tried using the func_seethroughdoor and setting the comm's alpha to 0, but even though he can't see it, he can still activate it.
thanks,
GSH
Yamazaki, are the func_trains triggerable by the comm? If not, that may be solution I'm looking for.
Always appreciated.
I would have to have a trigger_presence on both sides of the door, one for each button. I would assume that the trigger_presence would activate a multisource which acts as a master to the door. The door therefore can't be activated unless someone is in the trigger_presence. Unfortunatly, that still leaves open the possibility of having the comm direct a marine to stand at the switch while he clicks the door, negating the need to weld it open.....
Unless of course the trigger_presence is under the control of the master which activates the button.
To clarify:
Currently the door is a standard door with a name like "door1". On one side of the door is a working button, it's simple a func_button that targets "door1". On the locked side of the door, the button is made of a func_weldable, a func_walltoggle, a func_button, a multimanager, and a multisource. The func_button is disabled by the multisouce at game start, the func_weldable (looks like the button, but is the 'sealed' version) triggers the multimanager. When welded, the func_weldable shatters and disappears and triggers the multimanager. The multimanager then toggles the func_wall toggle to be on (showing a working button), and toggles the multisource which then allows the func_button to work. In theory then, I could make the trigger_presence have the same master as the button, so that when the button comes on, so does the trigger presence. The trigger_presence then points at a second multisouce that allows the door to operate.
The question is: Will stepping out of the trigger_presence toggle the multisource back to the off position, or will it only toggle it on when a player step through it, and toggle if off only when a player steps through it again?
OK, this is really good stuff, and I will likely end up using this to fix my problem (if it works like I hope). At the same time though, this is too much to implement through-out my map (only for the one-way doors, not the rest), and I wonder if there might be any chance that a "comm can't use" flag could still be coded in ( to NS-V2 <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> ). I am also worried about the comm being able to kill enemies "with his bare hands" by closing doors on them.
Thanks Coil,
GSH