Scripting: Advanced AI skill improvement

[Spinor]

Ok, I've tested this some, apparently it takes forever to scan an entire island (12800 x 12800), it doesn't lag while
doing it (not noticable in the test-mission) but it takes bloody ages.

This wouldn't be a good solution for our problem anyway, as you would have to store all
those thousand of objects somewhere which have to be analyzed.
The "sampe surroundings when needed" is much better. In any way, our advanced AI does not
have to kick in all the time, only at critical times, e.g. when in contact with the enemy.

A 512 x 512 area took 35 ingame seconds for me to scan (440 objects in total), so if you plan on using this you need
a good way of breaking it down.

I don't even think that 35 seconds is such a long time. You can start scanning as soon as an
enemy comes closer and when the business gets really hot, the scanning should be finished. If there
is an ambush, then bad luck, but that can also be seen as being realistic: The group leader
does not have time to make a proper plan -> bad AI.
Another idea would be to redesign the scanning algorithm so that it spreads out from the leader,
hence objects at a greater distance will be scanned later. The scanning result
can be used 'on the fly', first only containing closer objects. This also seems quite
realistic to me.

[Unnamed]

Ok, I've tested this some, apparently it takes forever to scan an entire island (12800 x 12800), it doesn't lag while doing it (not noticable in the test-mission) but it takes bloody ages.
A 512 x 512 area took 35 ingame seconds for me to scan (440 objects in total), so if you plan on using this you need a good way of breaking it down.

Out of curiosity, if you stuffed the results into an Edit dialog, and cut and paste it into a script. Could you store the entire island in an array or multiple array's that get loaded up at the start of the mission?

that it is impossible for the mission-designer to assign a specific area.

In some cases you can, when the mission designer allocates objectives and waypoints .You could map along the waypoint paths as well, if need be.

But I'm sure you could store terrain features in huge arrays populated by scripts, at the start of the mission. So pulling out the info, on the area your interested in, should be relativly quick.

[Doolittle]

And by the time THAT was done...OFP 2 would be out.  :-X

Doolittle

[Spinor]

Out of curiosity, if you stuffed the results into an Edit dialog, and cut and paste it into a script. Could you store the
entire island in an array or multiple array's that get loaded up at the start of the mission?

Using the Edit dialog would be a little difficult as, AFAIK, an Edit field (or any other string field like a hint)
can only store a very limited number of characters, otherwise OFP crashes. At CoC we are developing
a savegame reader, i.e. it would be possible to extract any variable like an array from the savegame
and reuse it somewhere else.
This is exactly the approach we are trying to do for a "global island scanner": the whole island is scanned
offline in a special scanning-mission, mission is saved, the terrain-data-array is extracted and can be used
in any mission on this specific island. We are not storing each and every object, though. This would be a little
to much I think. Instead, terrain data is stored per 128*128m grid, hence the terrain-array
is a 100*100 element matrix.

[Komuna]

If there
is an ambush, then bad luck, but that can also be seen as being realistic: The group leader
does not have time to make a proper plan -> bad AI.
Another idea would be to redesign the scanning algorithm so that it spreads out from the leader,
hence objects at a greater distance will be scanned later. The scanning result
can be used 'on the fly', first only containing closer objects. This also seems quite
realistic to me.

Yep. Realistic.

The main idea is to have independent AI units yet still inside of a group (9~12 men), so that what the leader knows is what the team mates know. It will require a clever use of "doMove", "setUnitPos", "doStop", "unitReady" and "playMove" (this last for crouching or for forcing a fast lay down).

With this, all we need is a single scanning script per group and an individual AI manager. Notice that my/Spinor's script can be ran to check 512x512 areas in whole, but can also run several times, at the same time, and check smaller areas (100x100. It will require another script, which would manage the scanned positions!), and reduce the checking time while keeping the lag low.

But after this discussion, have you tested my script with different conditions or different looping methods - for faster scanning, or am I the only one that's concerned with that? :hmm:

Surely, if u guys modify the script, you'll get faster checking and less lag...

[Spinor]

But after this discussion, have you tested my script with different conditions or different looping methods - for faster
scanning, or am I the only one that's concerned with that?

Sorry, haven't tested yet. As I mentioned, this is difficult for me right now. In a week I can start
proper scripting again, when I get home.
Anyway, although its of course to optimize the scanning, I think it's not so important right now.
I think we have proven that terrain scanning works. I guess the next step towards the AI would
be some script that actually analyses the arrays of obstacles.

[Komuna]

OK!

I have figured out why it takes so long!
It's not the condition. Its the loop. Even with an empty looping, the calculation of the coordinates takes ages...

Therefore, I've made lots of modifications to the original script... And now I have full speed functions working!

The problem is that it is killing my little baby (or "old buddy 400" as I use to call it). However, I assume that you guys have much better pc's than me, so, give it a try!

Here goes a sample - notice that I've attached a mission with lots of demo functions to be tested and analysed - :

Code: [Select]

comment {

By MorMel

Features:

Detects the nearest covering objects or roads at given positions
Detects terrain elevation per position - Not Coded Yet

};

private ["_objs","_marks","_buildings","_elevations","_roads","_covers","_trees","_forests","_i","_j","_l","_w","_x","_y","_angle","_incr" ];

_i = (_this select 0) select 0;
_j = (_this select 0) select 1;
_l = ((_this select 1) select 0) / 2;
_w = ((_this select 1) select 1) / 2;
_angle = _this select 2;
_incr = _this select 3;


_objs=[];

_marks=[];

_buildings=[];

_roads=[];
_covers=[];
_trees=[];
_forest=[];

_x = _i - _l;

While "_x <= _i + _l" Do
{
   _y = _j - _w;

   While "_y <= _j + _w" Do
   {
      IF ({(isNull _x)||(_x in _objs)||(_x in _buildings)} count [nearestObject [_x,_y,3]] == 0)
      THEN
      {
         IF (format["%1",typeOf _x] == "")
         THEN
         {
            _objs = _objs + [nearestObject [_x,_y,3]]
         };
         ELSE
         {
            IF ("House" countType [nearestObject [_x,_y,3]] == 1)
               THEN
               {
                  _buildings = _buildings + [nearestObject [_x,_y,3]]
               };
         };
      };

      IF ((isNull _x)||(_x in _marks)} count [nearestObject [[_x,_y,0],"Mark"] == 0)
      THEN
      {
         _marks = _marks + [nearestObject [[_x,_y,0],"Mark"]]
      };

      _y = _y + _incr;
   };

   _x = _x + _incr;
};


{
   IF (position _x select 2 < 0.2)
   THEN
   {
      _roads=_roads+[_x]
   }
   ELSE
   {
      IF (position _x select 2 < 6.5)
      THEN
      {
         _covers=_covers+[_x];
      }
      ELSE
      {
         IF ((position _x select 2 > 15)&&((getdir _x)in[0,270,90,180]))
         THEN
         {
            _forest=_forest+[_x]
         }
         ELSE
         {
            _trees=_trees+[_x]
         }
      }
   }
} forEach _objs;


comment {

_temp_ref = "EmptyDetector" CamCreate [0,0,0]

{
   _elevations = _elevations + [_x,[_temp_ref,_x call loadfile "Altitude.sqf"]

} forEach _marks;

end comment};

hint format ["total: %1\nroads: %2\nrocks&bushes: %3\ntrees: %4\nforests: %5",count _objs, count _roads,count _covers, count _trees, count _forest];
Don't forget the attachment!

#Edit

I just forgot to say:

Most of the functions included in the attachment are just for reference... Only the "MMK_GeoScanner.sqs" script, the "MMK_GeographicalChecker.sqf" and "MMK_GeographicalScanner_FullLag2.sqf" functions are currently being used for the testing the mission.

[Komuna]

Hello? :-\

[General Barron]

Sorry man, I've been meaning to check this out, but I've been pretty busy with school and the like recently.

Maybe later...  

[Killswitch]

Hello? :-\

Hey Komuna... I've been meaning to post here for a while but never got around to it. I've tested your terrain feature detector and I am experimenting with it, detecting small bushes near roads. This is intended to be used in a mission that needs to detect bushes for randomly placed (and well hidden) mines and/or claymores. Initial tests are very promising.

This is of course but one of the many possibilities for the GeoScanner scripts.

Don't suppose you have dabbled further with it since the last version posted?  

Just chiming in to tell you I'm following this and other "tactical/strategic AI" threads with great interest.

[Komuna]

Don't suppose you have dabbled further with it since the last version posted?  

Errrr...

No, I haven't. My "Old Buddy" (400MHz) won't handle all this scripting and, therefore, I expect that your machines could show me the results...
And I've been occupied with a new model of a grenade (MKII) for ECP, if they accept, of course. It's a stupid grenade, high resolution and complex model (for a grenade?? Geez...) that took me the time (3 days) I should have spent on studying or developing this topic... ;D I understand you Barron

Besides, the scanning scripting is basically finished. Now, I need your sugestions of how I should use it to improve the AI. Take a close look at the first post from mine and you'll understand the objective.

[junkie-xL]

1 - Use a single waypoint for the whole path, which position can be updated with setWPPos. The waypoint's type should satisfy the combat conditions. Therefore, it's type shall be changed using the triggerSwitch method.

I'm sorry to interrupt, but could you please elaborate on the triggerSwitch method/command or give an example? I have been looking for ways to define waypoints in script, but the command you mention is not (yet?) in the command ref.

[Komuna]

Hmm... Well, this is not the right topic for your Q, but I'll have the whole pleasure to answer you:

triggerSwitch is not a command yet a method that we use to switch a waypoint. All you must do is place a trigger on the editor, set its type to "Switch" and then synchronise it with a waypoint. Once the trigger's condition is satisfied, the current waypoint will be switched with the synchronised one. If the sync one is the current, then it will switch to the next one and etc etc... It's very usefull with the static ones (HOLD, GUARD, S&D, SENTRY, etc)

[Spinor]

Hi Komuna,
finally found some time yesterday to quickly check your scanning mission. Unfortunately, using the
full lag scanner from the radio menu freezed my comp  .

In any case, I'm not sure if wrapping up the scanner within a function is such a good idea. It may be the
fastest solution (and the most easy to use), but it will cause a hickup if the scanning area is too large.

My suggestion is to 'functionalize' only one scanning point and make the loops via scripts.

[Komuna]

OK. I was aware of the "freezing" prob, but still had some hope it was due to my comp speed.

Then, how should the script set be used to improve the AI? What will we do with the ground-level array? We must think about an effective way of having the scripts managing the AI: should it be individual? group-wide? scan and organise each X seconds?