Deleting Triggers

[Dirt]

Is there a way to have a trigger in a mission that only allows on player to see a message. The reason for the question is I have a mp mission that I would like each aircraft to have its own trigger to report when it enters an area. The problem is when it enters the area every plane gets the message, so within a few minutes you get like 10 message on a/c information. Just on each a/c to get its own info.

 

Also is there a way to have a trigger delete itself after tripping. Such as once it trips have it activate another trigger that notes it condition as tripped and deletes it.

 

I won't even bring up "Dead is Dead" yet....lol

 

:helpsmilie:

[nomdeplume]

Nope, the most granular you can get the messages is to send them to a particular country. If the aircraft you're using are available for multiple countries you might be able to at least reduce the message spam that way.

 

Triggers that are set to "once" delete themselves, but there's no other in-editor way of deleting a trigger. The best you can do is use a flag as a guard condition and ensure it's set to false when you no longer want that trigger to be able to fire.

[nomdeplume]

Re "Dead is dead", there was a thread recently about trying to prevent people using particular aircraft until certain conditions were meant. The result seemed to be that you can't stop people from spawning aircraft, but you can de-activate aircraft in order to remove them from the game.

 

So you might want to experiment with setting a flag when the plane is destroyed and using that to deactivate aircraft if people try to re-use them.

[Dirt]

Thanks...I will start the test mission for deactivating aircraft. I would be nice if we had a forum for mission makers. It would make searching for answers a lot faster and a place for mission makers to pass on there findings.

[Dirt]

Ran a test on deactivating aircraft. Well you can do it, but all the player has to do is drop out to the lobby and select the aircraft again and bam he is back with the same aircraft. Kills the immersion in the game. You speed hours building it so the team has to work together to complete a mission or not. Not so a pilot can jump back for forth killing all the enemy aircraft one on one to complete it. The games needs a option for Dead is Dead. Such as a selectable option for the mission or a Dead is Dead trigger.

 

Just my 2 cents worth.

[nomdeplume]

You can put a repeating trigger to determine if the aircraft is present within a location (i.e. the area where it spawns), and deactivate it if the "no aircraft allowed" flag is set. i.e. they can still join the mission, but will be immediately booted back to the lobby. I think it's the best solution available atm.

[104th_Crunch]

You can put a repeating trigger to determine if the aircraft is present within a location (i.e. the area where it spawns), and deactivate it if the "no aircraft allowed" flag is set. i.e. they can still join the mission, but will be immediately booted back to the lobby. I think it's the best solution available atm.

 

"no aircraft allowed" trigger? Is there really a trigger with that name? I recall that one.

 

You can deactivate any aircraft after an event with a trigger. Including one that spawns. You just can't make a deactivated client activate after an event. It is broken.

[nomdeplume]

I said -- "no aircraft allowed" flag -- as in, whatever flag number you are using to indicate whether the aircraft is allowed to be active or not.

 

If deactivating a client aircraft pushes that client back to the pool, then I don't see how you could "activate" a client aircraft from the mission. Who would fly the plane? So it seems logical to me: a group with an aircraft set to "client" is 'activated' when a multiplayer client selects that aircraft and presses fly. They can be deactivated at any time by the mission triggers.

 

The missing functionality I suppose is 'permanently' deactivating a client slot, i.e. removing it from the list; and its reciprocal function of adding a 'permanently' deactivated slot back to the list. I suspect its omission is because it would be difficult to implement a variable number of client slots into the current code. Or perhaps because it just wasn't considered, or the effort/reward ratio is too low to warrant the development time.