"detected by" trigger Resloved

[D007]

We have been trying to use a trigger set to
"blufor detected by opfor"
Every time we use it. The "first time" and only that time, the opfor detects the blufor unit, and the trigger goes off..
The opfor unit is named base1
If that unit detects blufor, bad things happen etc etc.

That unit needs to follow waypoints we have him set to, even after he respawns.
So he needs to keep his name.
It's a splinter cell kinda thing.. set up so people can try to creep around inside a base and steal stuff.
Unless of course they mess up and get seen by the opfor unit patrolling the area.

we have it set to repeatedly, but still, only goes off once.
we have even tried killing the unit after the area clears and recreating the unit. (same name)
Thinking maybe his attitudes would reset when he was killed or something..
We set his damage to 1 after the area was clear of blufor.

Tried grouping an individual man (blufor player) to the trigger as well.
same result.. one activation, no more.

It activates repeatedly just fine on "blufor present".
but not repeatedly on "detetcted by".

Just can't get this trigger to work and have been trying to get it right for a couple days now..
Any help would be very much appreciated. Thanks a bunch all. .

[Mr.Peanut]

How long have you waited between "detected" events? If ArmA is anything like OFP, it took some time for AI to forget they had seen something i.e. KnowsAbout value below a certain threshold.

[D007]

Not very long.. a minute or so...
so not even killing the unit would reset his detection status?

was trying to make it so that when the blufor players in the list, leave the trigger area.
The enemy units' attitude resets..
is there a command maybe to reset that status im missing?
I tried setting him back to careless and setcombat mode green etc.
he seemed more relaxed but he didn't seem to forget he saw something..

Thanks again Peanut..
Hate to bug yas so much lately but man...
this new mission got us in over our heads and we don't want to let anyone down ya know..
we haven't like slept proper in weeks..lol..

I did find this line though.. which might help me

{if ((_unit knowsabout _x) > 0.105) then {_return = _return + [_x]}} foreach _list;

maybe I can tweek it a bit for this trigger purpose or arrange it into a trigger to reduce the unitknowsabout level when they leave the area.. or set the knowsabout to false.. idk.. more things tot ry I guess.. XD

[Spooner]

Sadly, the only way to affect knowsAbout values is to use reveal. Can't make anyone forget...

[D007]

ahh well ty for the answers.. At least I know not to pursue my current train of thought.

[Mr.Peanut]

The knowsabout values will eventually reset. There was research for OFP on how long this took. If you search the forums you will find it.

Your solution would be a script that monitors the contents of list yourTriggerName. Have the script launch when the trigger is activated and exit the script when {alive _x} count list myTriggerName == 0. Better yet pass thisList into the script as a parameter and then your condition would be {alive _x} count _MyTriggerList == 0.

So onActivation

Code: [Select]

nul = thisList execVM "myscript.sqf";myscript.sqf

Code: [Select]

_list = _this;
// either one big loop
while {{alive_x} count _list > 0} do
{
};
// or a periodic check somewhere in your script
if ({alive_x} count _list == 0) exitWith{nil};The beauty is that _list will remain updated with all the detected units.

I am not entirely certain what will happen when _list is empty. Hopefully the script will still exit gracefully.

[D007]

Ahh theres something to work with..
I'll see what we can do with that and hope it exits gracefully..lol.

that doesnt reset their knowsabout value though then I'm assuming.
looking at it, It seems to me to read how many player are in the area..
If there are none I assume the script ends?
but it doesn't reset the detected by status of the trigger?

I'm no veteran scripter so I'm likely just confused..
looks to me like it accomplishes the same thing as.

Code: [Select]

(({isPlayer _x} count thisList) < 1)
or

Code: [Select]

(({isPlayer _x} count thisList) > 0)

We use that in the triggers as a safety net.. in case the detected by value hasn't reset.
At least we know a player is there then.
also if the opfor unit doing the detecting is killed, it goes off.

Odds are by the time they return to the trigger.
the detected by status would have reset anyway.
It's pretty far from main base and anyone who goes there, won't have much of a reason to hang around.
Nothing valuable will respawn until they leave anyway.

So at least most of the time, the detected by will work.
and having multiple officers to cycle through might help too.
possibly cycling through different officer would help speed up this process.

Maybe you could let one do the initial detected, but after he does that detection and that trigger area is no longer active..
perhaps by a blufor not present trigger etc.. or player this list trigger..
you could teleport that officer to an island until his status resets.
Or create a new one and delete the old one..
the new one might come in with new status.

something ill try I guess. XD..




Thanks ..

[Mr.Peanut]

Yes, your use of isPlayer is a better implementation. The more I think about it, however, it seems extraneous. I would presume this type of trigger cycles though each enemy inside to see if they knowsAbout any of the players inside. When a dead player eventually changes to side civilian, I would think the trigger resets.

I think it is important to know what exactly this trigger does. Does it call a script? If so what does the script do and what are the arguments passed to the script?

There are ways you can deal with this, if you need to. Place one slightly larger trigger(east present?) about the area. It will be used to get a list of all the enemy units. Call it trigGetEast. Place another smaller trigger inside replacing your detected trigger. Leave it as type none and in the condition put:

Code: [Select]

{_y = _x ; {(_y knowsAbout _x) > 0.7} count myPlayerList > 0} count list trigGetEast > 0 where myPlayerList is a list of all your possible(or living) player units. You might want to check if this condition is a resource hog or not. If it is your best bet would be to change the inner trigger to type (West?) present named trigGetWest and have a looping (server only?) monitor script that checks the condition:

Code: [Select]

{_y = _x ; {(_y knowsAbout _x) > 0.7} count list trigGetWest > 0} count list trigGetEast > 0

[D007]

Thanks a ton for all the help all.
sorry it took me a bit to respond but have been knee deep in fixing things.. XD..
I will definitely look into all of this information ASAP.

Edit: The trigger does call a script..
the script simply executes an array of attackers to move into the area.
as long as those attackers aren't already present on the map.


Things are working acceptably now.
just took the information on hand and decided to put a small "civilian not present" trigger inside a house.
the house has a repair script on it, so it can't be permanently disabled.
That would leave an area for cars etc to park in, which would disable the trigger.

The knows about level will reduce over time and that seems acceptable to me.
when combined to triggers, which are set to activate the same script,
in case any of the units inside die.
so no one can kill them without triggering the event.

generally not many could get in with the detected by trigger.
seeing as that may appear to be based on the individual the enemy sees and not the whole group.
IE: sgt slaughter goes in and gets detected
then Mr.popacap gets in not long after. he seems to be detected anyway because he is not the same person
who was previously detected?

Or maybe that was just due to having more than one guard.
That definitely seems to allow for more activations of the detected by trigger.
Regardless I'm going to try to put those script lines you wrote to work for something ..

thanks a bunch all.. much appreciate it.