Toggle trigger_ff_clip?

[ian.de]

I want to make it so my flag can't be grabbed through lasers while security is up.

I looked at phantom_r's .vmf in hammer and it uses a func_brush.

But I can't figure out how to make the func_brush solid without blocking a demoman's pipes.

When I use a trigger_ff_clip I can make it block a specific team, and let a demoman's pipes in, but I can't enable/disable it with the security toggles.

So how do I make a security controlled clip brush that still lets a demoman's pipes through?

[squeek.]

A perfect security solution using trigger_ff_clip is definitely possible (non-exploitable by the offense and doesn't get the defense stuck in it), but no map has done it yet. I'll see what I can do when I get home.

[ian.de]

Originally Posted by squeek.

A perfect security solution using trigger_ff_clip is definitely possible (non-exploitable by the offense and doesn't get the defense stuck in it), but no map has done it yet. I'll see what I can do when I get home.

Yes, using the "aardvarkdoorhack" security door relay, I tried every I/O modifier I could think to use on the trigger_ff_clip brush.

Example: I tried to "Disable" the clip brush on open and "Enable" the clip brush on close.

Or "TurnOff" the clip brush on open and "TurnOn" the clip brush on close.

But these I/O commands don't seem to register with trigger_ff_clip entities.

Thanks for taking a look squeek, I thought phantom already had implemented something similar but I was mistaken.

[squeek.]

Alright, here's a working example. It's not very clean, but it functions properly.

http://www.fortress-forever.com/publ...v_security.zip

It uses a trigger_ff_clip to block players, a non-solid func_brush for the visuals, and a trigger_hurt 1 unit inside the trigger_ff_clip to kill any offense that is inside the security when it goes up (so they don't get stuck inside). This also means that offense doesn't get killed if they touch the lasers from the outside when security is up; if you don't like that, just extend the trigger_hurt to overlap with the trigger_ff_clip.

The Lua code is somewhat complex, but you should be able to use it without modifying much (put any custom OutputEvent()'s or anything like that in the ClipSec_Event_SecurityOn/ClipSec_Event_SecurityOff functions at the bottom).

The func_button approach I used I'm not very fond of (I've never made a security map, but I think it's ill-advised to have the func_button reset delay dictate how long security goes down for as that should be controlled by Lua ideally). That is something that can really be improved.

I'll look into adding a Disable and Enable input for trigger_ff_clips, as that would make this whole thing immensely cleaner, easier, and more intuitive.

[ian.de]

Thanks for your hard work Squeek!

[ian.de]

Squeek I hate to drudge this topic back up but I can't for the life of me get this LUA to work with the aardvark_doorhack style Security system. When I load up the map in FF I can choose out of four teams (instead of two) and when I select a team all of the classes are greyed out (so the LUA is breaking the map).

My current security system (the same used in sd2 and destroy, etc.):

A trigger_ff_script (red_aardvarksec) opens a func_door (red_aardvarkdoorhack) that handles all the outputs. Can we make it so the func_door (red_aardvarkdoorhack) toggles the trigger_ff_clip, instead of a button doing the toggles like it does in your previous solution?

I tried to mess with your code to achieve the desired effect but I ended up breaking something.

[squeek.]

Originally Posted by ian.de

Squeek I hate to drudge this topic back up but I can't for the life of me get this LUA to work with the aardvark_doorhack style Security system. When I load up the map in FF I can choose out of four teams (instead of two) and when I select a team all of the classes are greyed out (so the LUA is breaking the map).

When this happens, it means there will be an error logged in the console. Load the map and look in the console for [SCRIPT] error lines.

To use any other system, just call the ClipSec_Event_SecurityOn and ClipSec_Event_SecurityOff functions for each team in the correct place. For ff_aardvark, that'd be ClipSec_Event_SecurityOn in blue_aardvarksec:ontouch( touch_entity ) and red_aardvarksec:ontouch( touch_entity ) and ClipSec_Event_SecurityOff in aardvarksecupred() and aardvarksecupblue().

Aardvark's system is weird for sure though. The door is not necessary when using Lua (all Hammer outputs that get sent through the door can be called through Lua, and it's more foolproof that way [things won't get stuck on/off on restartround/prematch ending]).

[ian.de]

Yeah I'll bite the bullet and just learn LUA scripting, there's no reason I've waited this long, thanks man

[squeek.]

Originally Posted by ian.de

Yeah I'll bite the bullet and just learn LUA scripting, there's no reason I've waited this long, thanks man

I take it the main thing you want from aardvark's sec is using a trigger instead of a button for getting security down? If so, I can add an example of that in ff_dev_security.

[ian.de]

Originally Posted by squeek.

I take it the main thing you want from aardvark's sec is using a trigger instead of a button for getting security down? If so, I can add an example of that in ff_dev_security.

That would be most gracious of you

[squeek.]

Alright, here's a working version with triggers (same link as last time, I overwrote the file):

http://www.fortress-forever.com/publ...v_security.zip

Name the triggers: red_security_trigger and blue_security_trigger. You can also use either func_buttons or triggers with this Lua; they will both work.

Definitely re-download to get the new Lua, because I changed up the layout a bit to try to make it clear what should be edited and what shouldn't. Just FYI, though, here's what I added to make the triggers work:

Show Spoiler:

SECURITY_LENGTH = 5

-- security triggers
base_security_trigger = team_only_trigger:new({ button = "" })

function base_security_trigger:ontrigger( player )
	-- only take sec down if its up currently
	local button = _G[self.button]
	if button and button.sec_up then
		self:onsecuritydown( player )
	end
end

function base_security_trigger:onsecuritydown( player )
	-- call the button's onin directly
	local button = _G[self.button]
	button.onin( button )
	AddSchedule( self.button.."_security", SECURITY_LENGTH, function() self:onsecurityup() end )
end
function base_security_trigger:onsecurityup()
	-- call the button's onout directly
	local button = _G[self.button]
	button.onout( button )
end

red_security_trigger = base_security_trigger:new( { team = Team.kRed, button = "button_red", allow=false } )
blue_security_trigger = base_security_trigger:new( { team = Team.kBlue, button = "button_blue", allow=false } )

It's somewhat complicated, but, basically, I'm re-using the button onin and onout functions from base_shutdown for the trigger being touched/security going back up. This makes it so that any changes to base_shutdown will not be overwritten (like if we add/change something on the HUD). Note: there do not need to be func_button entities in the map for this to work.