Line Of Sight Checking Script!!!

[Grendel]

So I was out of the OFPEC net this Memorial Day Holiday, But I was very busy working on a....secret project.

One of the things I needed was a way to see if a unit has LOS to another, regardless of the AI.  So I put on my thinking cap and found a solution that works!  

Does anyone know if someone has done this already? I couldn't find anything...

If not, I will post an appropriate Demo Mission ( I would have posted it on the beta page but wanted to see if it has been done...and I sort of forgot to put it on my thumb drive).  I am using it to further enhance one of my AI er...enhancing scripts, and it has many possible applications for the savy scripter.

For those that A) CARE and B) LIKE MATH here is how it works (feel free to ignore if A and B do not apply and go to the end):

The script first finds the distance between two units.  This becomes side A of a right triangle.

The script then gets the height above sea level for the two units. It uses the height difference to form the B side of the triangle.

Everything is shifted up .5 meters to keep the LOS above ground level (and is a compromise value  for OFP having no decent prone detection)

The direct LOS is the hypotneuse (side C) of the right triangle. Pretty  simple. Here comes the tricky part:

To check the LOS, the script uses a sine/cos projection from the low-unit in the direction of the high-unit in one meter incriments setposing an invisible 'H'.

The ratio of the heigt of the hypotneuse from any point along the side A, is B divided by A. The script checks the height ASL of the setpos'd 'H', and if it is higher than the point along the hypotneuse...Viola: NO LOS!

The End: It works!

-Grendel

[dmakatra]

I'm sorry, it's been done before. But it's a damn good workaround anyway. The only problem is that it doesn't work if a unit is behind a car or a house. :'(

:beat: *Gets Shot* :beat:

[Grendel]

Do you know where I can find the one done already and/or how it works?...hopefully it is a function and works better and quicker than mine (need to learn functions but...tooo...lazy)

And yeah, the building/car thing is a problem, but if you used a nearestobject function to check for these things at the invis 'H''s location maybe...

Does the other one find this stuff already?

-Grendel

[General Barron]

Lets see.... I think LCD posted a script on the forums years ago that sorta worked for finding LOS. I never checked it out myself, so I don't know how/if it worked.

Your method sounds like it would work, but only for finding if there is terrain in the way. I might suggest automatically adjusting the increments between test points depending on the distance between the two units though.

but if you used a nearestobject function to check for these things at the invis 'H''s location maybe...

This prolly would work pretty well. It would be a hassle to code, and it might make the script run pretty inefficiently, but it could work! You can take apart my find cover function here to see how to find... er, cover, with nearestobject.

Oh, and you really should learn how to do functions. They are really easy to make, and darn useful.

[Grendel]

***Long winded post alert***
You have been warned!

I might suggest automatically adjusting the increments between test points depending on the distance between the two units though

Well, I set the interval as an easy to edit variable in the script and it has comments to that effect, but actually, on my 1.5ghz it only takes about 1 second per 500m or so at 1m resolution. That is using drop particles to show the LOS hypotneuse and the terrain track (for debugging/proof of principle).  it also drops a large particle  where the offending terrain is at if LOS is blocked.

You can take apart my find cover function here to see how to find... er, cover, with nearestobject.

Thanks, will do.

Oh, and you really should learn how to do functions.

grumble, grumble..yeah. LOL!

I just thought of a new method though that might work in almost all situations: terrain, buildings, etc (Jinxed myself there):

If I config'd a new ammo class 'shell', with a damage of zero and no explosion effects, and had it setposed along the LOS hypotneuse (no longer needing the ground trace), I could just check to see if it "blew up" (! alive _shell or something) anywhere other than the target unit's location (or at a farther distance than the unit-should it be prone)!

Other than foilage (which would still need the nearest object querry) it would work on anything with collision detection...buildings, terrain, the tree trunks, cars, chickens, nuns, etc

Downside: would need to download a TINY .pbo for the new ammo.

Thoughts General Barron (or anyone)?

-Grendel

[Morglor9]

i'm looking for a script that has this, but when the player's crosshair goes over the unit it shows either red (enemy) or green (friend), using a CutRsc, to create an IFF (identify friend or foe) system. anyone know of a script that does this/care to make it?

[Chad]

This is my higher language code that i use to find the if a target can/cannot see the target. Only problem i find is that the speed at witch the calculations are done in ofp are abit slow, i am hopping if anyone of you guys can actualy see the bottleneck with my calculations?

Code: [Select]

// Author Chad Lion
// Version: 1.00
// Date: May 3, 2005
//
// This document is for demonstration purposes.
// Its to reflect a ongoing development of two current projects
// One the object orientated compiler and the next is the
// A.I. Heuristic
public class TanTarget{
   public int lastknown[];
   
   /**
    * Draws a virtual line from the object to the target
    * if the absolute height of the terriean is
    * higher than the target, then the object cant see
    * the target return
    */
   public boolean CanSee( object me, object target ){
      int mypos[] = getposasl me;
      int mytarget[] = getposasl target;
      int aheight;
      int tmpheight[];
      int tmp[];
      int adir = 0;  
      int dist = me distance target;
      int angle = atan((mytarget[2]-mypos[2])/dist);
      object camera = "logic" camcreate [0,0,0];
      boolean result = true;
      int sina;
      int cosa;
     
     
      adir = DirToObj( me, target );  
      sina = sin adir;
      cosa = cos adir;
      for( int i = 0; i < DistancePos( mypos, mytarget ); i = i + 5){  
         aheight = i * (tan angle);
         tmp = [((mypos[0]) + (sina*i)), ((mypos[1]) + (cosa*i)),0];

         camera setpos tmp;
         tmpheight = getposasl camera;
         
         // Calculate the terreian is in the way or not
         // plus 0.5 for guns position
         if( tmpheight[2] > ((mypos[2] + aheight)+0.5) ){
            lastknown = tmp;
            result = false;
            i = DistancePos( mypos, mytarget );
         }else{
            freeheap( tmp );
         }
         
         tmp = [((mypos[0]) + (sina*i)), ((mypos[1]) + (cosa*i)), (((mypos[2] + aheight)+0.5) -  (tmpheight[2])) ];
         dropSmoke( tmp );
      }  
     
      camdestroy camera;
      freeheap( mypos );
      freeheap( mytarget );
      freeheap( tmpheight );
      return result;
   }
   
   
   
   /**
    * Calculate the Degree from one object to another
    */
   public static int DirToObj( object me, object target ){
      int ai[] = getpos me;
      int thetarget[] = getpos target;
      int result = 0;

      result = (thetarget[0] - ai[0]) atan2 (thetarget[1] - ai[1]);
      if( result < 0 ){
         result = result + 360;
      }

      freeheap(ai);
      freeheap(thetarget);
      return result;
   }

   /**
    * Calculate the Degree from arraypos to another arraypos
    */
   public static int DirToArrayPos( int ai[] , int thetarget[] ){
      int result = 0;

      result = (thetarget[0] - ai[0]) atan2 (thetarget[1] - ai[1]);
      if( result <= 0 ){
         result = result + 360;
      }
     
      return result;
   }

   
   /**
    * Calculate the absolute height for object
    */
   public static int AslHeightObject( object person ){
      int pos[] = getpos person;
      int dist = 0;
      int ground = 0;
      object camera;
     
      camera = "logic" camcreate [0,0,0];
      dist = camera distance person;
     
      ground = (pos[0] ^ 2) + (pos[1] ^ 2);
      camdestroy camera;
     
      freeheap( pos );
      return sqrt((dist ^ 2) - ground);
   }

   /**
    * Calculate the absolute height for position
    */
   public static int AslHeightPosition( int pos[] ){
      int dist = 0;
      int ground = 0;
      object camera;
      object tmp;
     
      camera = "logic" camcreate [0,0,0];
      tmp =    "logic" camcreate [0,0,0];
      tmp setpos pos;
     
      dist = camera distance tmp;
      ground = (pos[0] ^ 2) + (pos[1] ^ 2);
     
      camdestroy camera;
      camdestroy tmp;
      return sqrt((dist ^ 2) - ground);
   }


   /**
    * Drop smoke at a location, used for debugging
    */
   public static void dropSmoke( int pos[] ){        
      drop ["cl_basic",
       "",
       "Billboard",
       0.01,
       40,
       [pos[0],pos[1],pos[2]],
       [0,0,0],
       0,
       1.1,
       0.861584,
       0,
       [0.5,1],
       [[0, 0, 0, 1],[0, 0, 0, 1],[0, 0, 0, 1],[0,0,0,1]],
       [0],
       0,
       0.01,
       "",
       "",
      ""];      
   }

   /**
    * Used to calculate the distance from one position to the next
    */
   public static int DistancePos( int pos[], int end[] ){
      return sqrt( (pos[0]-end[0])^2 + (pos[1]-end[1])^2 );
   }
}


[Grendel]

Chad,

It looks to be a matter of streamlining....

Mine does pretty much exactly what yours does, just with less calculations methinks?

Code: [Select]

#ut
player sidechat "Checking LOS"
_orig=u1
_targ=u2

_dist=_orig distance _targ
;player sidechat format ["_dist:%1",_dist]
_aslt=[_targ] call getASLheight
_aslo=[_orig] call getASLheight

?(_aslt>_aslo):goto "targhigh"
;orighigh
_h=(_aslo-_aslt)+.5
_lowunit=_targ
_highunit=_orig
_luh=(_aslt+.5)
goto "skiptarghigh"

#targhigh
_h=(_aslt-_aslo)+.5
_lowunit=_orig
_highunit=_targ
_luh=(_aslo+.5)

#skiptarghigh
;player sidechat format ["_lowunit:%1,_highunit:%2",_lowunit,_highunit]

lup setpos getpos _lowunit
hup setpos getpos _highunit
_dir=[lup,hup] call dirtoobj

lup setdir _dir
_lupos=getpos _lowunit
_lx=_lupos select 0
_ly=_lupos select 1

_ratio=(_h/_dist)
;player sidechat format ["_h: %1, _ratio:%2",_h,_ratio]
;;;;;;;;;LOS resolution in meters (1=check los at one meter intervals);;;;;;;;
_r=1
_di=1
#chklos
.1
_di=_di+_r
_nlx=_lx+(_di*(sin(_dir)))
_nly=_ly+(_di*(cos(_dir)))

checkheight setpos [_nlx,_nly]
drop ["cl_fire", "", "Billboard", 1,3, [0,0,0], [0, 0, 0], 0, 1.275, 1, 0, [.1,.1],[[1,1,1,1],[1,1,1,0]],[0],0,0,"","",checkheight]
_chasl=[checkheight] call getASLheight
;player sidechat format ["Checkheight ASL:%1",_chasl]

_losheight=(_luh+.5)+(_di*_ratio)
drop ["cl_fire", "", "Billboard", 1,3, [0,_di,(_di*_ratio)+.5], [0, 0, 0], 0, 1.275, 1, 0, [.1,.1],[[0,1,0,1],[0,1,0,0]],[0],0,0,"","",lup]
;player sidechat format ["LOS ASL:%1, _di:%2",_losheight,_di]
?(_chasl>_losheight):goto "nolos"
_cld=checkheight distance hup
;player sidechat format ["_cld:%1",_cld]
?(_cld>_r):goto "chklos"
player sidechat "LOS is clear"
~1
goto "ut"

#nolos
player sidechat "No clear LOS"
drop ["cl_fire", "", "Billboard", 1,30, [0,0,.5], [0, 0, 0], 0, 1.275, 1, 0, [1,1],[[1,1,1,1],[1,1,1,0]],[0],0,0,"","",checkheight]
exit
It's not commented very well (I'll fix that tonight) but there you go.

Here is a demo mission, I yanked it out without setting default units, so tou need BAS ranger/Delta (for no reason other that I was in a big hurry and forgot to clean up the mission .sqm, sorry-will fix with updated code)

-Grendel

[dmakatra]

i'm looking for a script that has this, but when the player's crosshair goes over the unit it shows either red (enemy) or green (friend), using a CutRsc, to create an IFF (identify friend or foe) system. anyone know of a script that does this/care to make it?

That cannot be done.

@ Barron: LCD made such a script yes. But in that you needed to define every object in the mission area. Kinda sucks if the mission is spanning across the island.

:beat: *Gets Shot* :beat:

[Morglor9]

ok, i didn't think it would be possible, but now i know for sure. thanks.

[Grendel]

Chad after further review  of your script, I think I know where the 'bottleneck" is..

It appears that you are using your script to calculate the absolute height....

There is a function that does this made by TakeOffTim (found in the Ed Depot funcitons section here at OFPEC), and functoins ALWAYS run much quicker than scripts as they are preloaded into RAM at the begining of the mission.

I am working on the new script that uses a setpos'd shell along the virtual LOS, to check for any oject or terrain. This should be both more effective in finding the true LOS and be quicker.

-Grendel

[Chad]

Grendal do you have msn or icq i would like to talk to you about acouple of things. Do you use team speak?

I will post my code when i get home later on tonight for you to have a look at.

My contact details are
icq: 20758380
msn: doodo477@hotmail.com

[Fragorl]

Taking a bit of a stint from ofpec on account of exam season at the moment, but this thread reminds me....

I made a function a couple months ago now, which is pretty much the same as Chad/grendel's two versions except it uses vectors & no trig... the function (in the demo mission) is here[/url].

There is no bottleneck, the only problem with it is that there's no way of knowing the dimensions of any of the objects.... and I still don't think there is a solution to this.

My next attempt to do a los check was with a physical object..... a bullet.

Eventually, after much agonising and optimising, I came up with a decent script (not function) which could get the position of a colliding object along a line AB to within one metre. Being a script not a function, it is quite difficult to implement as it does not *instantaneously* return a value.

The lmitations:

The tracing object is subject to gravity - any traces over ~100 metres are too inaccurate
The script takes time to return a value
If multiple instances of the trace script are running, the trace position gets more and more inaccurate.

I haven't released this script yet, but if anyone wants it...

[Chad]

Well its nice compairing a hand writen version of a script to my compilers emited code. Though I am re-designing the emited instructions. The reason for this is mostly because i ran both your script and mine side by side, and yours came out so far ahead its not funny. So i am just revisiting the code emmited by the compiler.

Chad.

[Fragorl]

I'm eagerly awaiting this compiler of yours...

A couple of things. Firstly, I lied about there not being any trig There doesn't need to be, but there actually is in that version. I use trig for checking if the projection vector is > 90* from the vector to the target, when I could just use the dot product. I wrote that series of functions, oh, nearly a year ago now, and looking at them I can see a whole bunch of ways of improving them. I will do so in the near future. They can also be made way more accessible / understandable to the layscripter ;D. One of the problems with my code has always been that it's not too easy to follow. Well, I'm mending my ways.

The advantage of doing a pure projection is that it works in 3 dimensions, in any direction, be it up, down, or side to side, there's no need to worry about angles or anything. Just the projection distance and the distance to an interfering object.

Secondly, about the bottleneck. I can't say for sure where it's coming from, but if you're constantly creating or positioning objects at regular intervals in your function, then this will constribute far more to the load than your code's structure itself. Structure-wise, you can have a whole heap of stuff, much more than you have now, before even the slightest lag shows up. I refer to mathematical calculations etc. I think the criteria for loops is way into the tens of thousands of iterations before you experience the slightest lag. Of course, with functions in ofp it's a little less . It more depends on what you're doing per loop.

EDIT: i see the max attachment size has gone up. Hurrah!

[Chad]

Cc i am holding off abit on the compiler side of thing because posting code it emits is asking for all the guys here to jump onto it like a pack of starving dogs.

In regards i actualy coverted the above scripts to see the performance gain or decrease in the compiler. From my observation Grendel's code actualy ran faster in the compiler than my original version that i did about a week ago. So congrats to grendel for his help there. I have mainly underlined the bottleneck with the system, its in regards how the compiler treats variables. I will do some higher language examples here and some code that is emited from the compiler that you can see how things are done.

Remember its an OOC it not a precedual language. I have thought about it long and hard, and any such tasks that i find that require a large amout of proccessing i can actualy convert into libaray files eg.. the compiler enables you to also write in higher language to built your function files, such i have tended to mostly keep the whole compiler in the script language department to test performance hit it would cause.

I am finding out con-currently the performance hit i am getting using the techniquie i do in the compiler is "lets just say, a hit in the nutts when doing jobs that require down to the micro second to execute".

Anyway onto some examples.

<!-- Last chance to turn back -->

Code: [Select]

/**
 * Author Chad Lion
 * Version: 1.00
 * Date: Thursday, June 02, 2005
 *
 * This document is for demonstration purposes.
 * Its to reflect a ongoing development of two current projects
 * One the object orientated compiler and the next is the
 * A.I. Heuristic
 */
 
/**
 * Okay lets start with the basics and move up from there
 * this is a class type, a class is a blue print to building
 * an object. What is an object, well an object is a instance
 * of a class. With a copy of all its variables and methods
 * such try not to confuse a ofp game object with higher
 * language object.
 */
public class Example{
   
   /**
    * This is the location that ofp will jump to when the file
    * is executed. But for this demostration its to show how
    * methods and variables are handeled within the compiler
    */
   public static void main(){
      /**
       * We want to declare some variables for some calculations
       * you have the following types
       * boolean   <- Boolean
       * int       <- Number
       * string    <- String
       * unitside  <- side
       * mygroup   <- group
       * object    <- game object
       * The above are all your primitive data types.
       *
       * Higher language data types
       * Class     <- Blue print for a object
       * array     <- Can be any of the primitive data types and also class data type
       */            
       int a1 = 2;
       int a2 = 3;
       int a3 = 4;
       int a4 = 5;
       
       a1 = (a1 * a2)/2*a4-a3;
       
       print( a1 );
   }
 
}

This is the emited code

Code: [Select]

MA=0
heapsearch = preprocessFile "heapsearch.sqf"
_heap=[]
_stack=[]
_reg2=0
_stack = _stack + [0]
_stack = _stack + [0]
goto "5"
#5
_stack set [ (count _stack), _reg2]
_reg2 = (count _stack)
_stack set [ (count _stack), [0,0,0,0]] [b]REFERNCE ONE[/b]
_reg1 = (_stack select _reg2)
_reg4=2.0
_reg1 set [0,_reg4] [b]REFERNCE TWO[/b]
_reg4=3.0
_reg1 set [1,_reg4] [b]REFERNCE THREE[/b]
_reg4=4.0
_reg1 set [2,_reg4] [b]REFERNCE FOUR[/b]
_reg4=5.0
_reg1 set [3,_reg4] [b]REFERNCE FIVE[/b]
_reg4= (_reg1 select 0)
_reg5= (_reg1 select 1)
_reg4=_reg4*_reg5
_reg5=2.0
_reg6=_reg4/_reg5
_reg4= (_reg1 select 3)
_reg6=_reg6*_reg4
_reg4= (_reg1 select 2)
_reg5=_reg6-_reg4
_reg1 set [0,_reg5]
_reg4= (_reg1 select 0)
hint format[ "%1",_reg4]

exit

Okay lets start from the top down what the compiler does. Because ofp has no actualy memory address range that you will have within a normal machine language for example x86. This has to be emulated some how, this emulation is done via an array, using it as a stack to allocate and de-allocate memory on the fly via the programs execution.

In reference 1 you will see that the compiler via its second pass will count all the variables within the higher language. Then will create a make frame ( Make Frame being memory space for the method to store its local variables ). This is the memory space that the variables are stored in, so each time you assign a = b. b is retreaved from the stack yes, each time. And then assigned to the array at position a.

Though this is mostly the bottleneck within the system. That because of variables not actualy being stored in an memory address range, they have to be stored within an array that holds those locations.

You will see the same keep occuring in reference to 2,3,4 in the emited code from the compiler.

But!

Not all is lost, because of the nature and how i have designed the system. It emits assembly instructions out into an interface that converts those assembly instructions into ofp game script language code. Such the result is what you see above.

Objects and other things are handeled ore or less in regards the same way, but with key differences that i wont go into in this dicussion. But, what i am thinking lately is actualy creating a faster emited code by simply declaring the whole stack within functions that would greatly speed up the proccessing time of the script lagnuage completly abstracted from the higher language.

So, even though at this point in time. I have found issues arrising within the system. Its not the end of the world. I can simply re-modifiy the emited game script language to take into account doing things differently.

But right now i have to head off to sleep, its getting late and i need the rest for a full days work tommoro.

[Grendel]

@Chad,

Grendal do you have msn or icq i would like to talk to you about acouple of things. Do you use team speak?

Unfortunately I have never set up any of these yet...feel free to e-mail or pm me untill I do get one of those up and running...

Another unfortunate thing is how little I understand about compilers and higher language coding...That last post might as well be in that african 'clicking' language for as much as I understood!

I'm just a self taught/trial and error scripter with a big imagination and too much ambition for my own good I guess LOL.  

@Fragorl,

I would be quite interested in checking out your script using the bullet, since if it does what the one I'm working on will do, then I can spare everyone the redundancy.

-GrendEl  

[DBR_ONIX]

The easiest way I can think of is getting the height of the two units above sea height
Getting the angle from one to the other (both up/down and 0-360).
Then, using this data, use the drop command on an object with a geo lod.
if the droped thing comes withing < 0.5m of the second person, it's almost certainly got LOS with the other person
If the drop partical colides with something, it's killed.

If the drop partical fails, you can use the exact same idea, with a bullet, but this requires a config/pbo

I'm not too good with trig and stuff like that in OFP, so someone else could try this if the other methods are unreliable.
- Ben

[Grendel]

@Ben

If the drop partical fails, you can use the exact same idea, with a bullet, but this requires a config/pbo

This is pretty much the method I am working right now, if you (or anyone) could please explain the geo lod drop particle, I would appreciate it! This sounds very promising.

The only drop particles I've worked with are the basic, fire, and fired ones.  So what do I put in the drop array to use a geo lod and do they otherwise obey the same properties of particles such as staying put?

-Grendel

[DBR_ONIX]

That idea came from manticore (for a different project, though). I think it is just a spaceobject thing you drop, as these can be objects, which can have lods.
I think a good starting point for "different" drop stuff would be the script in editors depot (Or was it beta testing?) that could drop a partical with a JPG picture on it.
I'll ask manticore next time I talk to her about the droping objects with GeoLods

Just a random guess, try changing the cl_fire thing to an object classname? it works in dialouge drop with the crater classname, seems logical enough

This could make a leap in OFP AI, nomore AI seeing you though everything! ;D
- Ben

[Fragorl]

@DBR_Onix

Then, using this data, use the drop command on an object with a geo lod.

In my experience, you can walk right through spaceObjects, even for example a 'dropped' m113? If not, I don't think that it will work. As always, I could be wrong.

if the droped thing comes withing < 0.5m of the second person, it's almost certainly got LOS with the other person

I disagree - for example the walls of a house are << 0.5 metres thick. Also types of concealment that could be used, e.g. cars, trucks, barrels etc fall within the error range of this function. It's one of the problems I ran into. Also, the more traces going on at once, the less accurate each individual one becomes. This is, of course, for physical ammo.

If the drop partical colides with something, it's killed.

I've never heard of a way of killing/deleting a drop particle? That's not to say there isn't a way. I've just never had any success affecting a drop particle in any way before, be it setting its position, velocity, or deleting it.

If the drop partical fails, you can use the exact same idea, with a bullet, but this requires a config/pbo

Actually, I forgot to say, I ended up using a smokeshell not a bullet, because it doesn't disappear when killed, it stays so there's no problem getting it's position once it's collided. Also it doesn't deal any damage. Also, if the trace is fast enough it doesnt put out any smoke. So, no configging is actually necessary.

But yes, if a reliable raytrace method (that's not resource-intensive) is developed, then it will open new doors for ai. Just believe me when I say I have been working on this for a (relatively) long time now.

@Grendel

I will try to get that script for you as soon as possible, however upon looking at my old version, I saw numerous ways of improving on it's clarity and effectiveness- I couldn't help but tidy it up a little bit, seeming as other people will now be using looing at it ;D

[Fragorl]

Here is the script, within a demo mission. There are still one or two minor improvements to be made, and i need to write an explanation of how to use the trace script within another script, but the general idea is there.

Feel free to muck around with the demo mission, substitute a tank for another object, etc. Note the script can be quite accurate sometimes, and out by quite a lot others.

[UNN]

I have an addon based LOS idea, that allows you to detect if one map positions is visible from another. It takes about three seconds to return a result, but that should be constant. It will work with anything that blocks the AI's line of sight in the game.

I'ts a pain being addon based, but in conjunction with your scripts it would cover all the bases. Either way it would be great if you do come up with a script based solution, I can think of a few uses off hand. Mainly a far more flexible alternative to the Laser Designator.

P.S I also did something similar with Vektorbosons Height Above Sea Level function, to get a cross section of the terrain for an approach path. If your looking at different methods it might be worth checking it out.

[Fragorl]

Just having a look at some old topics and I came across this... I never saw your post UNN, which is a shame. I'm very interested in this method of yours; can you tell me about it?

[Blanco]

Have you tried Mapfact SKY AI addon? Very very good.
It's a bunch of AI scripts (no addons) and there's a LOS script included for the body discovering part.  (much better then snypir's isbodyhidden script)
In fact, it's not a 100% LOSscript but it's effective most of the time, actually I never saw it fail.
There's also a very good tutorial mission where they show you the FOV, it even works on vehicles
You really have to try it, it's awesome stuff.
 

[Fragorl]

cheers blanco I'll definitely have a look at that.

Still interested in yor method, UNN

[Fragorl]

I've taken a look at that addon thing blanco. I ran the tutorial mission (The scripting is done in german, but the english instructions are very clear and concise, so i was able to find my way around easy enough).

After taking a look at the scripts, I think I'd have to conclude that there is no line of sight checking being run, lathough the AI scripting in itself is something special. The picture you posted (and the one they use on the website) is just an outline of the unit's field of view, with drop particles dropped depending on the unit's direction, and are dropped at ground level. The relevant lines from the script (for the tutorial, anyway) are:

Code: [Select]

[(_Units select 0),Sichtfeld,Sichtweite] exec "KI_Addon1.8\blick.sqs"
(_Units select 0) move getpos (_Units select 1)
@ (_Units select 0) distance (_Units select 1) < 6 or not alive (_Units select 0) or Alert
Units select 0 is the guy who finds the body, and units select 1 is the body. 'blick.sqs' is just the script that outlines the FOV in dopr particles. There is no LOS check there (you can tell by how quickly the drops go that nothing very intensive is happening ). Obviously there is a distance trigger, although this is a minimum cutoff point.

The tute states something like 'hills and rises will affect the unit's view', but they say 'the script relies on the knowsabout value of the unit with respedct to the body'. So i think what they do is use the game engine to judge line of sight for itself, knowing that the LOS will be taken into account in the knowsabout value.

[Blanco]

Yeah, I know it's not a real LOS script, it just simulates it.
But I've used it in a few missions and it never let me down so far, even in dense areas like bases.

But I'm always open for other methods offcourse.

[Fragorl]

Yes, i entirely agree. In this case, not only is it not broke, it works very well indeed. Certianly doesn't need fixing I'm all for using the engine to its full before other methods are explored. Certainly, in my experience, the best a scripted alternative can be is almost as good.

[Triggerhappy]

Mainly a far more flexible alternative to the Laser Designator.

not quite
we can't tell if the persion is looking or not, only if they could see if they happen to be looking the right way

[UNN]

Still interested in yor method, UNN

It was such a long time ado, I can't find my original addons and test mission. But I started again, and it seems to be working as I remember. In fact better, it works at the distances available to human players. Always one of the things that annoyed me about the myopic AI. It sounds like it's not to dissimilar to the Mapfact scripts, I even did the same experiments with FOV.

I will post it up once I add the scripting commands to get the results, although it will probably need more work. But at least you can try it out.

 

[Fragorl]

Sweet. look forward to it.