TRIGGERS: Show/Hide versus Triggerable/Nottriggerable

[Slyk]

What I'm working on is a progressive spawn system that forces each team to maintain a continuous line of communication. I.e., they can't run ahead and get OBJ#2 until they secure OBJ#1... I have 3 OBJ switches, each set up in TOW mode (this actually going to be used in TOW & TDM play) that function perfectly. BUT, I want to be able to 'disable' the switches until the one before or after them is tripped. Bascially, OBJ#3 is in the middle, and if the AXIS control it, OBJ#1, 4 & 5 should be inactive, but #2 should be open... if ALLIES control #3, then #1, 2 & 5 should be inactive, with #4 now open to their advance.

Make sense?? I have four progressive spawn regions tied to the switches, making a really good flow to the map. Here's a sample using the SHOW/HIDE that I can easily use on normal brushes, but would the TRIGGERABLE/NOTTRIGGERABLE commands work better? OR have to be used?? Any ideas?

//--------------------------------------------------------------
// Move the switch handle - OBJ3
//--------------------------------------------------------------
moveobj3:
$obj3_switch_trigger nottriggerable
$obj3_switch bind $obj3_switch_origin
if( level.obj3_switch_up == 1 )
{
$obj3_switch_origin speed 1.0
$obj3_switch_origin rotatezdownto 180
$obj3_switch_origin waitmove
$obj3_switch_origin playsound switchbox
level.obj3_switch_up = 2

$spawn_allied3 enablespawn
$spawn_allied2 disablespawn
$spawn_axis2 disablespawn
$spawn_axis3 enablespawn

$obj4_switch_trigger show
$obj2_switch_trigger hide

}
else
{
$obj3_switch_origin speed 1.0
$obj3_switch_origin rotatezupto 0
$obj3_switch_origin waitmove
$obj3_switch_origin playsound switchbox
level.obj3_switch_up = 1

$spawn_allied2 enablespawn
$spawn_allied3 disablespawn
$spawn_axis3 disablespawn
$spawn_axis2 enablespawn

$obj2_switch_trigger show
$obj4_switch_trigger hide

}
$obj3_switch_trigger triggerable
end

[jv_map]

(not)triggerable seems most logical to me.

[nuggets]

wouldn't it be easier to make an array of switches?

then have

main:
$obj_switch[1].on = 0
$obj_switch[2].on = 0
$obj_switch[3].on = 0
$obj_switch[4].on = 0
$obj_switch[5].on = 0

$obj_switch[1] triggerable
$obj_switch[2] triggerable
$obj_switch[3] triggerable
$obj_switch[4] triggerable
$obj_switch[5] triggerable
end

if ($obj_switch.on[1] == 1)
{$obj_switch[2] triggerable}
end

etc...

using an array though, if you add a property to the entity like #slyk to the triggers and the relevant number, could have

if ($obj_switch.on[self.slyk] == 1)
{$obj_switch[self.slyk++] triggerable}
end

[Slyk]

Thanks nuggets for the array info. But OMG, am I glad the simple 'nottriggerable'/'triggerable' commands work like a charm. They tested fine for me, but alas, I have only one machine to run it on and I can only do the Allied side because of how the TOW structure is set up, but it works as far as I can tell. The array never entered my mind... mainly because I don't understand that stuff more than, say,...... 1.2% But I appreciate it. And actually I'll probably look at it and try to get it to work because it looks easier to implement in more convoluted situations......... which I'm sure to dream up sooner or later.

[nuggets]

not a problem always here to help

with arrays everything has the same name but has a number that floows it in the [] brackets to define it from the others

i don't know whether that would work for your exact needs, but it's easier to use rather than typing
if 1 then do 2
if 2 then do 3
if 3 then do 4

that kind of stuff

it'd just use a number stored as whatever you like so something.thenumber then attach it to what you need so
trigger[something.thenumber]

then that'd work for every line of code, rather than implementing it for each possibility, or put

trigger[something.thenumber++]
to use targeted name 1 greater than the trigger, so 2 would trigger 3 etc...

if you want more info, i'll offer it on here, BJARNE has a scripting topic going, don't know the http address but i've heard from several good sources that it's good (even though one of those sources is BJARNE )

anyway, for now good luck, and welcome to the world of scripting