Scripting: Advanced AI skill improvement

[Spinor]

I guess the script should be group-wide, representing the group leader. Otherwise, there would be
too many scripts running. Nevertheless, within the group-AI script, it will probably be necessary to
iterate through the individual units to give them orders.

The necessity to launch a scan depends on the situation. If the group is mainly static, i.e. it did not move,
there is no need to do another scan. The results of a given scan can be stored in some array to be used
whenever needed. When the group moves, a scan can be launched whenever the group moves off the
previous scanning area or when there is an enemy nearby.

What will we do with the ground-level array?

That's of course the tricky bit. We somehow need an 'analyzing' script to make use of the ground-level array.
For starters we could create some simple functions that work on the ground-level array, like
[pos, "Type"] call getNearestCover  --> to be used to determine the nearest obejct of given type to a unit.

[Komuna]

For starters we could create some simple functions that work on the ground-level array, like
[pos, "Type"] call getNearestCover  --> to be used to determine the nearest obejct of given type to a unit.

If you check the functions I've posted, there's already a demonstration of  the code we could use to get altitude values:

Store every "mark" of a scanned position - already achieved. Then store each position's altitude in an array, by calling the mark's eight according to the sea level. It should be a function based on this:

_temp_reference = "Logic" camCreate [0,0,0]

_d = _Mark distance _temp_reference

_rng = (position _mark - position _temp_reference) + some maths

_alt = that greek theorem : _d^2 = _rng^2 + _alt^2

Well, it's just a sketch, but I don't have the time to write it right now...

At least, we know how to get the altitude. My real question is: What will we do with it? How will we compare the enemy groups altitute so that we get a way of making them cover and move according to the terrain geography?

Note: the retured array is something like this: [ [position,altitude],[position,altitude],...]

Sugestion: what about getting the altitude of a position per 2500m2?

[Spinor]

Ah, sorry, when refering to ground-level array I thought you meant the array of objects
found by scanning.

BTW, there is a better way to find sea level altitude: by placing a trigger at the corresponding position. With the object "EmptyDetector" you can even camCreate one:

heightSensor = "EmptyDetector" camCreate [0,0,0]

The nice thing about them is that they are always at OFP base level (this is not exactly sea level), so the absolute height of _pos can be determined by

heightSensor setPos _pos
-((getPos heightSensor) select 2)

No need for difficult maths  
Edit: I just saw that you already included part of this into your geographical scanner as a comment.

My real question is: What will we do with it? How will we compare the enemy groups altitute so that we get a way of making them cover and move according to the terrain geography?

To be honest, I have no real idea for this right now. The difficult thing is that the problem is not local. You cannot simply compare the group height and the enemy height. A useful function will probably be something like

[_pos1, _pos2] call checkVisibility

that uses the ground-level array to determine if _pos1 and _pos2 are visible from each other. You could use this function on several possible "hiding" positions _pos1 with _pos2 the enemy pos. But even that is not all you would have to make sure that the path to the hiding pos is also hidden. Anyway that function should be doable and I try my luck with it (trying to recall the "line intersecting a plane" lessons in school  )

Sugestion: what about getting the altitude of a position per 2500m2?

That would be a 50m x 50m grid. Yup, that should be detailed enough.

[Unnamed]

I was having a quick look at the terrain scanning rountine, not sure but I think you could speed it up.

A couple of things?

Does there have to be so many calls to NearestObject. Could you not just store the result for Object and Mark in a variable then do all the tests?

But the main one was, checking for objects already detected. The more objects you store the longer it takes to check new ones. If the NearestObject command has a range of 50m then you only have to check new objects that lie within 50m of the original? In other words you dont have to check a new object against all the ones you already have, just against those that lie within 50m.

Also what about Nearestbuilding command, probably dont have to check buildings at the same resolution as bushes and trees e.t.c?

Hmm..hope that makes sense, it would mean more code and arrays but less work searching huge expanding arrays. What do you think, is it worth checking out?

[Komuna]

But the main one was, checking for objects already detected. The more objects you store the longer it takes to check new ones. If the NearestObject command has a range of 50m then you only have to check new objects that lie within 50m of the original? In other words you dont have to check a new object against all the ones you already have, just against those that lie within 50m.

Also what about Nearestbuilding command, probably dont have to check buildings at the same resolution as bushes and trees e.t.c?

EhEh! I see what you mean! Yet if you check earlier posts you'll notice that Spinor had pointed that nearestBuilding does only detect "open" (enterable) buildings. Besides that, my function checks for objects (trees, bushes, etc) each 5 meters and does not store the objects already present in the array.  In this way, it will store (almost) every objects in a 2500m2 (50x50) area, while a single nearestObject call would only pick one single object in a total of 502(pi)m2 area.

Therefore, further enhancements to these functions will require a different approach...

#Spinor

Hey! Nice hint! (the second one, after the nearesObject syntax) Really apreciated man. I like maths, but your trick is much wisier than my damn functions... EhEh! I'll see what can I do.

[SafetyCatch]

so what now?
whens this script going to be ready cant wait to get my hands on it

[Unnamed]

Besides that, my function checks for objects (trees, bushes, etc) each 5 meters and does not store the objects already present in the array.  In this way, it will store (almost) every objects in a 2500m2 (50x50) area, while a single nearestObject call would only pick one single object in a total of 502(pi)m2 area.

I'll try and knock up an example, I dont think I explain myself very well  

[Unnamed]

Not sure, but I have a hunch this might speed up the process of scanning large areas?

For example if you scan a 1500m area in 150m squares you would have a grid similar to the one shown.

As NearestObject has a radius of 50m you only need to check objects that fall within that radius.

So the first square (White1) will contain all the objects within the 150m square, as each new object is detected it will be checked against the content of the white square:

If Not (Bush3 In [Bush1,Bush2]) Then  {add Bush3}

So you end up with:

White1=[Bush1,Bush2,Bush3]

Any object found with the red area will be added to another array called edge, without any checks:

Edge1=[Bush3]

Now move on to White2, the next 150m square to the immediate right.

The first object in White2 will be Bush4, as that lies within 45 meters of the left hand side of white2, it needs to be checked against Edge1:

If Not (Bush4 In [Bush3]) And Not (Bush4 In White2) Then {Add Bush4}

As Bush5 lies beyond the 45m limit it only has to be checked against the content of White2 and does not need to be added to Edge2

Once you have processed one row, the content of White1,White2....e.t.c are added to the main object list. The yellow and green squares work in a similar way except they will be stored in an array.

The dimensions were picked for convenience (a call to nearest object every 15m), but the principle remains the same for areas over 50m x 50m.

The other thing was:

Code: [Select]


         {
            IF ("House" countType [nearestObject [_x,_y,3]] == 1)
               THEN
               {
                  _buildings = _buildings + [nearestObject [_x,_y,3]]
               };
         };


Here your calling [nearestObject [_x,_y,3] twice to return the same object. Why not just call it once and store the result?

[SafetyCatch]

any progress made on this one?
I really cant wait, this will add a whole new feel to OFP

[cornhelium]

Hi,

It's great that you folks are trying to expand the AI.

 Could these object/elevation matrices also be useful for things like BAS's Blackhawk Insertion/Extraction scripts or the Medevac script that was discussed recently? Eg. If you call for extraction in the middle of Tatu city the inbound Blackhawk would scan your surrounding area and choose the nearest clear, level spot of, say, 50mx50m and land safely there. Similiarly, choppers could dynamically identify suitable LZs in woodland/jungle areas.

...Maybe they could even judge whether to use a straight-in approach (ie. no objects with a Z value above 3 in the last 100m between the chopper and the center of its chosen LZ, so it can come straight in on a steady descent), or to slow to a hover 25m above and then come straight down vertically.

Anyway, great work so far - tks  ;D

[Spinor]

Using it for chopper insertions is an excellent idea, especially as the chopper AI simply does not evade any objects. Maybe it could be even possible to safely use choppers within cities.

[BadAssSuntchezz]

Hey Komuna, hope you're still on it. i just stepped over this very exiting topic. As to your point with the AI operating in smaller groups have a look at General Barrons custom formations. Maybe that'll help on with that?

[Komuna]

Using it for chopper insertions is an excellent idea, especially as the chopper AI simply does not evade any objects. Maybe it could be even possible to safely use choppers within cities.

If you check the "Acceleration" topic, here in advanced editing you'll see a chopper landing script which I made to fulfil the need of having precision on landings.

I'm sorry, but since the down of OFPEC and due to my computer limitations I lost the excitment of improving OFP's AI.

The good news are that I have a new computer and I'm preparing myself to restablish my work while caring about my studies which are going bad and do a nice paralell work. I don't promise that I'll be here for long, but soner or later I'll manage to release a full set of AI scripts (Stealth [AI improvement], ChopperLanding, single player wide-group Management).

[cornhelium]

Hey Komuna - that's one precise script for the helo landings - thanks! I found I could position the Invisible H/Waypoint/Triggger group anywhere and the blackhawk would land beautifully (setting the height in the
Trigger OnActivation field). Not even putting 2 enemy machine gunners and a BMP2 on the landing pad would stop her landing right where I asked her to (this is a good thing!).

Great work so far - good luck with your coursework  

[Komuna]

[...]

Code: [Select]


         {
            IF ("House" countType [nearestObject [_x,_y,3]] == 1)
               THEN
               {
                  _buildings = _buildings + [nearestObject [_x,_y,3]]
               };
         };


Here your calling [nearestObject [_x,_y,3] twice to return the same object. Why not just call it once and store the result?

I had explained that before: due to OFP bugs, the stored result will be considered "null" (using our debug method of hint format, it will return the known and strange string - "0xdede......" or something like this. Besides, it will spare OFP's memory management as you don't have to store variables. Just check a few posts before and you'll understand me.

Now, about your method: have you tested it? Will the area calculation be easier than Spinor's method? Such is important as the game will lag due to excessive calculation.

Let me explain my [remind it is Spinor's idea] method: checking for objects every 5 meters will alow you find more than one single object per 502pi m2 - nearestobject does a 50 meter radius scan to find the nearest object since the check position; the other objects won't be detected. In this way, every object that distance from each other more than 5m will be detected. Those which are too close, only one will be stored. BUT if the check postion is once near to the first one and then near to the second one - even if they're 1m close! - both will be stored.

I hope you understood. I'd explain better in portuguese but... you know


@cornhelium

Thanks mate! I see you found my landing script. Indeed it forces any chopper to land as the pilot has no control except on the altitude decrement. I'm also thinking about improving it and force chopper to raise in the same way, for faster take-off's - and even appear behind buildings, for cut-scenes!

But I'm not the only one who has landing scripts. 'deaddog' [I haven't seen that guy :'(] has a version of such script very close to mine and he helped me to achive the last result - I forgot to give him credit . When available, check the editor's depot for 'snypir''s landing script - which engine I haven't checked, but i believe that is a little different from my de-acceleration method.