Creating an Alert System with Detected By

[IndeedPete 1038]

Hello,

I'm currently working out an alert system based on detection by hostile units within a trigger area (using detected-by). Goal is to give the player some chance to kill the detector before he can call in reinforcements / set off the alarm. But since the timeout in detected by triggers does not work properly I have to try a script-based approach.

My problem is how to get the detector. My hope was that it is somehow passed via "this" in the triggers OnAct field but that was a dead-end. So now I have no idea how to identify who exactly detected the player to check whether this unit survives long enough to make the call. I've bypassed this problem in earlier apporaches by just having one group/unit within the trigger area that is capable of setting off this arlarm but unfortunately I have a huge camp-site with many patrols as designated trigger area now. Any ideas? I can only think of using knowsAbout on all hostiles upon activation and then "guessing" by the highest value who could have detected me. But that seems bumpy and inefficent.

Help is -as always- much appreciated.

[bangabob 42]

You could pass each AI group into a script which waits until the they are in a hostile combat mode.

Something like

_group=(_this select 0);

waituntil {((combatMode _group)=="RED") OR ((combatMode _group)=="YELLOW")};

//YOUR CODE HERE

http://community.bistudio.com/wiki/combatMode

[IndeedPete 1038]

Thanks, but sadly that didn't work as the units don't seem to change their combatModes. Checking for yellow fires all the time and for red fires never, even when the patrols in question detect me and open fire.

My next thought was somehow resetting the knowsAbout value as the detected-by trigger probably relies on that but I can't find a script command that actually does this.

Anyway, my next idea involves experimenting with fired EHs, maybe I can somehow make up an (imprecise) system based on gunfire by the patrols...

Help is still welcome!

---------- Post added at 07:12 PM ---------- Previous post was at 06:37 PM ----------

Just checked the discussion below the ticket and that seems to work for me. So now I have a trigger similiar to killzone_kid's solution:

Timeout : 10, 10 ,10
Type: NONE
Activation : independent
activation: once
Present
condition: {_x knowsAbout player > 0} count thisList > 0
on act: hint "you failed"

[barbolani 198]

The way I do it is adding a FIRED eventHandler to simulate this. If the AI spots you but does not have time enough to fire to you, then the alarm is not fired.

[giallustio 770]

You could use nearTargets

[IndeedPete 1038]

Thanks for ideas guys but I think I will keep the knowsabout trigger. A fired EH also came to my mind and would be my fallback strategy.

[f2k sel 164]

I would say it is a kind of a bug or at least not obvious.

It says in the Wiki "Timeout - The trigger's conditions must be satisfied for the entirety of specified amount of time for the trigger to activate. For example, if a soldier walks into a <side> Present type trigger but leaves the area before the timeout is complete, the trigger will not activate."

So you would expect that if you kill the detecting unit it shouldn't fire as the condition has changed but it only checks to see if you are still in the trigger.

It doesn't check to see if you are still being detected.

It all comes down to how you want to read it I guess.

Also the detecting unit doesn't have to see you, hearing you is enough and they don't need to be in the trigger area only you do.

[k0rd 3]

does the timeout work if you delete the bodies after they die?

[IndeedPete 1038]

I would say it is a kind of a bug or at least not obvious.

It says in the Wiki "Timeout - The trigger's conditions must be satisfied for the entirety of specified amount of time for the trigger to activate. For example, if a soldier walks into a <side> Present type trigger but leaves the area before the timeout is complete, the trigger will not activate."

So you would expect that if you kill the detecting unit it shouldn't fire as the condition has changed but it only checks to see if you are still in the trigger.

It doesn't check to see if you are still being detected.

It all comes down to how you want to read it I guess.

Also the detecting unit doesn't have to see you, hearing you is enough and they don't need to be in the trigger area only you do.

Yup, as I already wrote under the ticket there's basically no difference whether you use timeout or countdown in this particular case. It's just a redundancy and easy to misunderstand.

does the timeout work if you delete the bodies after they die?

Hm, I don't know; haven't tried it. But I think I'm satisfied with the workaround for now.

[f2k sel 164]

No deleting them doesn't work neither does resetting their knowsabout value back to zero.

The work around is the only way.

[IndeedPete 1038]

Just wondering, how would you reset the knowsAbout value? I've been looking for such command but I wasn't able to find it.

[f2k sel 164]

I haven't seen it either but I did stumble across a work around the other day when trying to find a fix for something else.

It works best for single units, groups take a little scripting.

All you need to do is use

[unitname] join grpnull

it will clear the knows about value instantly but if they are still looking at you it will reset to whatever they can currently see.

It seem to also clear the target array of AI units.

[IndeedPete 1038]

Interesting. "Unitname" is the unit which you want to reset or is it the unit that gets detected?

[giallustio 770]

Setting the reveal value to 0? Can't test atm.

[f2k sel 164]

Unless reveal has be changed it won't work, we have asked for this many times but never get a response from BIS.

you can set the value after wiping

[unitname] join grpnull ;unitname reveal [player,2]

could be used to lower the value from say 4 to 2 or whatever you want.

unitname would be the unit who's memory your wiping.

Obviously it's limited as it wipes all knowledge of all units including waypoints.

A function could be written to preserve these values.

Edited February 9, 2014 by F2k Sel