Door Trouble

HeistHeist 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.


  • HeistHeist Join Date: 2002-11-09 Member: 7922Members
    Well lol.. I belive I fixed the second problem. I just thought of as I hit Post. I will just add some no build enities around the doors.
    But the first question still remains.
  • MendaspMendasp I touch maps in inappropriate places Valencia, Spain Join Date: 2002-07-05 Member: 884Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Gold, NS2 Map Tester, Reinforced - Shadow, WC 2013 - Shadow, Retired Community Developer
    edited April 2003
    Put damage on your doors, noone will want to exploit that...

    "Damage inflicted when blocked"
  • OlljOllj our themepark-stalking nightmare Fade Join Date: 2002-12-12 Member: 10696Members
    To die for:
    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.
  • HeistHeist Join Date: 2002-11-09 Member: 7922Members
    OK.. Currently I have the two doors named the same thing and operated by a switch. Problem is, if you flick the switch and block door 1 from closing, door 2 closes, and if u flick the switch again while the door is still blocked then they get out of sync.
    Perhaps I can just make it do dmg.
  • watch_me_diewatch_me_die Join Date: 2002-11-10 Member: 8107Members
    <!--QuoteBegin--Heist+Apr 10 2003, 03:38 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Heist @ Apr 10 2003, 03:38 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> OK.. Currently I have the two doors named the same thing and operated by a switch. Problem is, if you flick the switch and block door 1 from closing, door 2 closes, and if u flick the switch again while the door is still blocked then they get out of sync.
    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.
  • YamazakiYamazaki Join Date: 2002-01-24 Member: 21Members, NS1 Playtester, Contributor
    func_train is your friend!

    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.
  • BlackPantherBlackPanther Join Date: 2002-02-11 Member: 197Members
    func_doors with mortal damage is easier and it's fun to watch aliens get squashed <!--emo&:p--><img src='' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
  • Green_MeatGreen_Meat Join Date: 2002-11-06 Member: 7331Members
    I set the damage on my doors to 2000. That did the trick. If it is blocked by anything, it is instantly killed and the doors don't reverse.

    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.


    Yamazaki, are the func_trains triggerable by the comm? If not, that may be solution I'm looking for.
  • coilcoil Amateur pirate. Professional monkey. All pance. Join Date: 2002-04-12 Member: 424Members, NS1 Playtester, Contributor
    You can use a trigger_presence to force a marine or alien to be standing in front of the button.
  • HeistHeist Join Date: 2002-11-09 Member: 7922Members
    Thanks for your help.. guys...
    Always appreciated.
  • ConfusedConfused Wait. What? Join Date: 2003-01-28 Member: 12904Members, Constellation, NS2 Playtester, Squad Five Blue, Subnautica Playtester
    it has something to do with having a name .. i think a comm can only trigger a named button but i may be wrong
  • Green_MeatGreen_Meat Join Date: 2002-11-06 Member: 7331Members
    I see what your saying Coil, thats a really good idea, but...

    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='' 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,
Sign In or Register to comment.