Line of sight

[Blanco]

Hi, is there a way to check a unit's line of sight?
I'm improving my searchlight script with some new features:
- Don't run though the light or you will be detected. (if closer then 200m) The player can avoid detection when he goes prone and stay completely still. (if farther than 50m)
- When detected the searchlight will follow you whereever you are. (if closer then 200m)

It all work fine now but I'm running into a mayor problem: they still can spot and follow you when you're behind a building that breaks the line of sight of the searchlight operator.

How can I fix this? 
Knowsabout is not a reliable command for this.
 

[Mr.Peanut]

No guarantees, but my binotarget script los calculation might work. It sends a straight line out from the weaponDir until it either goes beyond a certain range, or intersects the ground. Since height of buildings is detected as zero, it may also stop when it intersects a building. Easy test I suppose would be to run my test mission, stand near and facing a building and see whats happens when targeting the wall. One sec and I will test.

Edit: crapola. Didn't work. My idea was as follows. A unit on top of a building still has a near zero height, so compare the asl height with a gl set to ground level, and you can tell if a buildiong is in that position or not. However, I cannot get a gl to automatically end up on the top of a building, so no go.

[johnnyboy]

Maybe BoundingBox command would help:

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

If peanut's code detects the objects in line of sight to target, then you could test the height of the objects using BoundingBox to see if they would hide the target.  Just an idea...

[Mr.Peanut]

Nope, all my script does is find where line of sight intersects ground

[johnnyboy]

A brute force method might be to do a nearestObject search at every 3 meter interval point between searchlight and target.  Limit the nearest object search to a couple meter radius.  For each object found, check its bounding box to see if its large enough to obscure the target.  Then check the next point 6 meters out, then 9, etc.

[Mr.Peanut]

Is the model bounding box defined by world coordinate dimensions?

[h-]

Afaik bounding box is in model scope so you need to modelToWorld it..

[Blanco]

A brute force method might be to do a nearestObject search at every 3 meter interval point between searchlight and target.  Limit the nearest object search to a couple meter radius.  For each object found, check its bounding box to see if its large enough to obscure the target.  Then check the next point 6 meters out, then 9, etc.

Thx, sounds like a reliable solution.
I had contact with Mandoble yesterday and he suggested me to it via the same way.

[johnnyboy]

I wrote a simple script to display the values returned from boundingBox (see attached).

BoundingBox values for a car object:

minX= -1.62568
minY= -2.64179
minZ= -1.75382
maxX= 1.62568
maxY= 2.64179
maxZ= 1.75382

BoundingBox values for Barracks object:

minX= -8.28908
minY= -3.8812
minZ= -2.78802
maxX= 8.28908
maxY= 3.8812
maxZ= 2.78802

It appears the positive max values are the simple dimensions of object (i.e, the car is 1.6 meters wide, 2.6 meters long, and 1.7 meters high).

For the Searchlight LOS script, it is reasonable to assume that all objects are set at ground level.  You can then check the height (maxZ) value of each object that is in the LOS path from searchlight to target.  If the object height is > X, then the searchlight loses the target.

That would be a good start, but not perfect.  As it would not solve:
- How far is the object's center from the LOS line?  If center is too far too left or right, and the object is not wide/long enough, then target might be visible, but script based on height alone would not know it.
- What dir is object facing?  Target is more likely to be obscured if behind long side of car (length), rather than short side (width).

But it seems possible to dial all that in with further math and logic.

A final hassle would be dips in terrain, but I remember reading somewhere that somebody was handling that somehow, or at least discussing it.

Edit:  Good luck Blanco.  This is a worthwhile script.  Having a searchlight behave smartly will be awesome for immersion.  Adding voice files for detection, evasion, etc. would be fun too:  "Target spotted!", "Lost him behind the building!", "Check around those bushes!", "Behind the wreck!", etc.

After spotting target, then losing him, a behaviour to scan the immediate area where target was last known, getting slowly wider and wider would be cool (before switching to default search pattern).

[Blanco]

Having a searchlight behave smartly will be awesome for immersion.  Adding voice files for detection, evasion, etc. would be fun too:  "Target spotted!", "Lost him behind the building!", "Check around those bushes!", "Behind the wreck!", etc.

After spotting target, then losing him, a behaviour to scan the immediate area where target was last known, getting slowly wider and wider would be cool (before switching to default search pattern).

You're reading my mind 
These things can be done when I have a LOS script/function.
You can even make the searchlight spot friendly bodies, a synced sniper from an other tower,...

[Mr.Peanut]

With objects that are native to the map, do the getPos and getDir commands still work?

@Blanco, how did you detect if a unit was prone or not?

[Mandoble]

I have a question, are the ArmA searchlights cosmetic or not? So, if you put a soldier in AWARE mode as gunner of a searchlight and iluminating clearly an enemy unit 100m away, does the gunner detect and engange the enemy by its own or not? Or, does the knowsabout of the gunner increases at least a bit or not?

[Blanco]

@Blanco, how did you detect if a unit was prone or not?

Getpos function by Mandoble does the trick.
http://www.ofpec.com/forum/index.php?topic=29174.0

@Mandoble
No he doesn't engage targets by himself, only when you are really close and making a lot of noise.

Here are some tests: (searchlight operator has NVgoggles)

When I use _unit dowatch (getpos player) when the player is in the lightcone:

-KA increases when I'm about 50m away and moving
-KA increases  when I'm about 100m away, moving and firing upon the searchlight. Making a lot of noise actually :p

When I use _unit dotarget player when the player is in the lightcone:

-KA increases to 0.3 iimmediately whereever I'am, even when I'm hiding in a bush or behind a tree. Seems that reveal does the same.

Dowatch is too passive, dotarget is too harsh

I also tried to target the player's position instead of the player itself, but it seems you can't target a position.

Then I created a gamelogic and placed it somewhere around the player and made him target the logic. KA stays 0.3 and dropped to 0 after 90 sec.
Then I deleted the gamelogic a sec after creation, same result.
Also tried dotarget objnull and dowatch objnull, all with the same results.   

I don't think we can rely on knowsabout values...

[Mr.Peanut]

Have no fear Blanco, I am close to have a proof of concept demo for one aspect of the LOS problem. Now, if I could just find where my code is causing my computer to crash. 

Edit: Crap. Seems the best that can be done is buildings and vehicles. Walls, trees and native vehicle wrecks seem to be unavailable to the nearestObject command and its variants. It is the walls that are the real piss off. Would it still be useful if it only worked for buildings and vehicles?

[Blanco]

It's better than nothing 

I was thinking about another approach...it's just an idea, I dunno sh*t about the drop command but...
...do particles collide with buildings and stuff and is it possible to detect the exact position of that collision?
Is so, you could "shoot" a transparant particle and see where it hits something... somthing like a laser
If not, an invisible harmless bullet might work, but I think we need the modding tools for that.