OFPEC Forum
Editors Depot - Mission Editing and Scripting => OFP - Editing/Scripting General => Topic started by: Komuna on 30 Oct 2003, 14:38:28
-
Exactly. I want them accurate, clean, smart and deadly.
I'm sick of seeing the AI acting like dummies, eventhough I play in "Veteran - SuperAI" mode.
So, I'm asking your OFP brains to sugest ways of making the AI smarter, by posting code and editing methods in this thread.
Note: You don't need to read the whole post, just a few lines to understand the main parameters.
Main objectives:
#Edit
I'll be adding new objectives as they come up. Last modifications: 10th and 11th objectives
#Edit
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 unsing the triggerSwitch method.
2 - In combat, the AI units shall engage at will without getting more than 60 meters away from their leader. If the leader orders one grunt to engage, he should be compeled to fall back into formation if he gets too far. Knowing if he's being ordered to engage can be achieved through unitReady.
3 - In combat, the AI's behaviour should be set according the proximity of the enemy, the terrain level and obstacles, the weapons in use, etc.
4 - In combat, the machine gunner stays close to the leader, usualy behind an obstacle and laid down. He's covered by a crouched grenadier, unless the situation compels him to lay down.
5 - Behind terrain elevations, while moving, the AI should low his head (by laying down) if he knows about the enemy presence. Besides, such thing will happen everytime there's a direct contact and there are some hidings nearby. Otherwise, the Ai shall keep on his foot and move quicly, or I'll kill him easily 8).
6 - There should be designated cover position (Forests, Rocks, Bushes), so that in combat eminence, the AI moves stealthily along those concealments - in order to increase realism.
7 - When facing tanks and APC's, the AI runs away to a safer point (special designated cover positions - Forests and between rocks) and the AntiAromor weapon specialist gets in position to engage the enemy. If there's no AA specialist, then run away and join a stronger force should be the solution.
8 - When contacting snipers, the AI shall move quicly to a safe point, get covered, deny engagement and proceed with a clever trap for the sniper by moving stealthily towards him, if they know his position. The snipers never stay at the same position.
9 - The AI shall be able to form small teams (two by two) within the group and keep close in urban combats.
10 - When disembarking from an APC (Exempli Gratia: BTR80), the AI should do it from the oposite side to the enemy, to guarantee safety, and move away from the APC, towards a safe position, to avoid being catched by its probable destruction.
11 - The AI shall not cross in front of their mates, while they're firing, to avoid stupid killings (added from macguba's post).
Surely I'm missing lots of parameters for the AI's better behaviour; that's why I'm asking you for help. But don't forget the code! ;)
Some hints on editing:
I've noticed that the AI behaves cleverer when they have to follow "Guard" and "Sentry" waypoints in Stealth/Combat mode and engaging at will. They hide, take better ways to engage the enemy and act more realisticly (not moving along into a perfectly simetric formation ;D).
However, they still fail most of the times. For example, in real life a leader would never order a single soldier to engage the enemy 200m away, unless he was nuts. They would do it in teams and would take the safest path, not the shortest one.
I'll be waiting for your sugestions. Once I've gathered the main code procedures, I'll make an AI improvement script.
-
Well beyond my knowledge to help, but if an improved AI script comes to pass - and I hope it does - then one little gem would be to prevent friendly loons from crossing in front of me when I'm firing.
-
i started workin on som AI improvin script ;D
got somin like AI coverin while da oders move (nd in teams :o) nd things like dat
but i gave up after i noticed dat wen deytried 2 flank enemy wat dey realy did was 2 draw fire while da leader nd his MG took all da enemies down (so all team members dead xept da leader nd MGunner ::)) ;D
but deres 1 hard thing here :-X interactin w/ obstacles nd things like dat is haaard - no good way 2 detect it unless its somin da player puts dere :-\
LCD OUT
-
Such a AI skill improvement script (or probably set of scripts) would be extremely useful.
The main problem of writing it would not only be to create a proper AI (always difficult),
but also to get the necessary information from OFP, namely the enemies positions
and the terrain features (location of trees, height information).
Another problem is the interference from the standard OFP AI. In general one should exploit
standard OFP AI wherever possible and only interfere where necessary.
Lacking some further ideas, I'll try to comment on the points you made (and no, no code yet ;D):
2 - In combat, the AI units shall engage at will without getting more than 60 meters away from their leader. If the
leader orders one grunt to engage, he should be compeled to fall back into formation if he gets too far. Knowing if
he's being ordered to engage can be achieved through unitReady.
That should be fairly easy to achieve. One simply has to continually check the distance
to the leader. One should avoid too clear cut and "obviously scripted" behaviour, though, e.g.
that a unit immediately returns to the leader when reaching 60 meters. At first it could only
stop and seek cover and then return after some time .
3 - In combat, the AI's behaviour should be set according the proximity of the enemy, the terrain level and obstacles,
the weapons in use, etc.
One nice thing here could be different types of movements, i.e. bounding overwatch etc.
4 - In combat, the machine gunner stays close to the leader, usualy behind an obstacle and laid down. He's covered
by a crouched grenadier, unless the situation compels him to lay down.
Again, this shouldn't be too difficult either at it is easily definable. The biggest problem would be
to select position (behind obstacle? or terrain elevation? which one?).
7 - When facing tanks and APC's, the AI runs away to a safer point (special designated cover positions - Forests
and between rocks) and the AntiAromor weapon specialist gets in position to engage the enemy. If there's no AA
specialist, then run away and join a stronger force should be the solution.
It would be great (but even more challenging) if the AI script could handle different group types, e.g.
infantry squads, armor platoons, etc. To handle all the different situations, one could assign
different threat values to the groups according to their type. Threat values could be:
[AntiPersonnel, AntiArmor, AntiAir]
For example, an inf squad without AT or AA capability could have:
[5,0,0]
whereas an M1 tank platoon might have:
[10,20,5]
The decision to engage/hold/run away could then be based on comparing ones
own threat values with the one of the enemy (much like oldfashioned strategy games)
9 - The AI shall be able to form small teams (two by two) within the group and keep close in urban combats.
Could be achieved by using the follow command properly, and maybe in conjuction with the
formLeader command. AFAIK, it should be possible to have subformations within a group already.
Having such teams would even ease the task to write the AI (or at least reduce the CPU strain), as
one does not have to take into account all units but only the teams:
-Teams are controlled by improved AI
-Units within teams by standard OFP AI
A general programming scheme for an improved AI could be to introduce basic urges for a unit,
which have to be fulfilled concurrently. For example, a unit might have the "Stay close to leader"
and the "Stay close to cover" urge. Both urges get greater the larger the distance is (either
to the leader or the nearest cover). The mathematical task would then be to move the unit such the
sum of all urges is minimized.
The advantage of such scheme would be that it is fairly easy to create the basic urges,
but when combining them one could get very interesting behaviour (although I can't give you
a guarantee for that ;D)
-
It would be good to bring all the AI scripts together.
I'm interested in how you envisage combining all the different elements and delivering them to the mission designer? Things like are you looking to track all the units in the game or just those for specific tasks e.t.c
Cant help thinking the Nueral Net code used by the COC artillery could be useful for this kind of thing.
-
A few scattered replies:
6 - There should be designated cover position (Forests, Rocks, Bushes), so that in combat eminence, the AI moves stealthily along those concealments - in order to increase realism.
Here is an easy way to do this: this setbehaviour "COMBAT" or this setbehaviour "STEALTH". Those commands make the AI stick to covered positions, such as trees and bushes.
Unfortunately, (AFAIK) there is no way to find rocks, bushes, trees, et. al with the "nearestobject" command. That is what has stopped me from doing some various AI scripts. The only form of cover that I could refer to was stuff that the editor placed. If somebody knows a way to get around this, I would love to hear it, because it sure would open up some doors.
7 - When facing tanks and APC's, the AI runs away to a safer point (special designated cover positions - Forests and between rocks) and the AntiAromor weapon specialist gets in position to engage the enemy. If there's no AA specialist, then run away and join a stronger force should be the solution.
I believe there are some scripts out there already that will do this, such as Toadlife's group link script or Bremmer's AI script.
8 - When contacting snipers, the AI shall move quicly to a safe point, get covered, deny engagement and proceed with a clever trap for the sniper by moving stealthily towards him, if they know his position. The snipers never stay at the same position.
Now this is something that a lot of missions could use. Way too often when playing a mission I can just sit back and take out a whole base with my m21 without anyone going after me. This problem can, of course, be fixed if the mission maker would just take some time to put a few triggers and waypoints down, but unfortunately most do not.
Another problem is the interference from the standard OFP AI. In general one should exploit standard OFP AI wherever possible and only interfere where necessary.
Actually you can get rid of most of the AI with this command: this disableAI "TARGET". This basically eliminates the AI's programmed response to enemy fire. If you use this command, instead of running out and engaging the enemy, the AI will stay where they are, unless otherwise ordered to move (with a domove command).
got somin like AI coverin while da oders move (nd in teams ) nd things like dat
but i gave up after i noticed dat wen deytried 2 flank enemy wat dey realy did was 2 draw fire while da leader nd his MG took all da enemies down (so all team members dead xept da leader nd MGunner )
The biggest problem with OFP (and the biggest thing keeping it from becoming realistic) is the lack of micro-terrain. By this I mean the small little dips and bumps in the ground, and the little bushes or tall grass, and so on. Basically, the terrain is too flat and barren. I know OFP does a good job handling lots of bushes and trees at once, and the terrain often looks pretty well vegitated. But take a look outside and you will see all sorts of little places to lay down and hide in here and there.
Basically, the reason why "covering fire" is of very limited use in OFP is because there is so very little cover. There is no way for a unit who is prone in OFP's land to get any more covered and protected. In real life, however, unless you are in the most flat and barren of landscapes, you can always lay down a little lower, or move a short distance first, and take better cover. But in OFP, since there is nowhere to take cover, there is no reason to take cover. And if no one takes cover, there can be no such thing as "covering fire" (bullets which are meant to get the enemy to hunker down, not to kill him): it's the same thing as shooting to kill.
Of course there can be exceptions to this, but usually that only will occur when a mission designer specifically places units in defensive positions. That calls for it's own script, IMHO.
It would be good to bring all the AI scripts together.
Okay, now my main reply:
There seems to be this desire to create a "one-size fits all" AI script. I guess the goal is to make one script that can be implemented in only a couple lines that will completely overhaul the AI, and will work in every situation for every mission. I don't see this as the way to go. It should be up to the mission maker to tailor the enemy's "AI" to suit his specific mission.
For example, in a 'Nam mission I am currently making, I wanted to improve the enemy AI, so I thought I would use Bremmer's AI script. It is an impressive script, but I found many problems that made it unsuitable for my mission. First off, it makes the enemies "talk" to each other using the ingame voices, which are russian, and my baddies are Vietnamese. That doesn't sound right, and so I proceeded to try to edit out that part of the script. Okay, no big deal though. Next, I didn't want most of my enemy's calling for support groups to come help them, since I didn't think that my Vietcong guerillas really would have the ability to call backup to their position like that. And even for times they could, the only American group anyone would encouter was going to be the player squad, so I could just as easily use a simple "detected" trigger and have a support group move to the player's location.
I really wanted the enemies to call artillery on the player's group, like Bremmer's script does. However, I didn't like the specifics of his artillery barrage (shell type, impact area, amount of shells, etc), so I found myself editing that part of the script to suit my needs. But there were so many things I wanted to change, it ended up being easier to write my own script.
I also liked how the enemies will try to retreat with Bremmer's script, but I also wanted them to surrender at times instead of retreating. Again, it ended up being easier to write my own script for this.
Instead of trying to make the script that always works for everybody, we should focus on making AI scripts that fulfill one specific function, such as a script to call for backup, one to engage enemy snipers, etc. Then it should be up to the mission designer to "plug in" which script(s) fit best within his mission, and to toggle the parameters of the script to suit his needs. The main thing to watch out for in this model, though, is to make sure multiple scripts don't interfere with each other. I think a sort of open-ended AI script standard would be nice. Basically, scripters could create small AI "snippets" to fulfull one specific need, and the standards would make sure that nobody's AI script interferes with the operation of another persons AI script.
Whew! Sorry, that was longer than expected. Anyway, I hope you get my gist. I like AI scripts, but I think it should be up to the mission designer to get the "best fit" for his mission, not the scripter.
-
Cant help thinking the Nueral Net code used by the COC artillery could be useful for this kind of thing.
Quite right, at CoC we are looking into this ;D. At CoC, we are actually more concerned
with inter-group-AI (how different groups work together to achieve a goal) than intra-group-AI,
but the same rules apply.
Denoir created a completely general Neural Net Module that can be used for all AI
tasks (and even non-AI tasks like the artillery).
Unfortunately, (AFAIK) there is no way to find rocks, bushes, trees, et. al with the "nearestobject" command. That is
what has stopped me from doing some various AI scripts. The only form of cover that I could refer to was stuff that
the editor placed. If somebody knows a way to get around this, I would love to hear it, because it sure would open up
some doors.
There is way, but a very nasty one. Essentially, you have to use nearestObject on a very fine grid,
say 2-5 meters in x- and y-direction. With this you can capture most objects (you'll miss those that
are closer placed than your search grid).
The main problem is only that bushes/trees/forests/roads do not have a object class. The only way to
differentiate them is to take their z-value:
roads: z = approx 0
bushes: z = approx 2
trees: z = approx 12
forests: z = approx 20
Using this approach I wrote an terrain sampler for CoC that creates a matrix array (100x100 elements,
one element corresponds to one terrain grid) containing data about the terrain. It works quite well, giving
a faithful representation of the terrain features like vegetation, roughness, etc.
For an improved group AI it won't be necessary to do it for the whole map but only in some
proximity of the group.
Actually you can get rid of most of the AI with this command: this disableAI "TARGET". This basically eliminates the
AI's programmed response to enemy fire. If you use this command, instead of running out and engaging the enemy,
the AI will stay where they are, unless otherwise ordered to move (with a domove command).
Doesn't this mean, though, that we would have to do our own "Target-AI"? Unfortunately, the AI
can't be enabled once disabled, so we are stuck with it.
-
@Spinor & General Barron
Well, thanks alot for your posts! Keep improving the main idea!
Note: just avoid explaining how to do the scripts concerning my posts, as most of my objectives I already know how to code. ;)
@Community
Hmm... Don't think I'm gonna make a single and easy-to-use script! It will be for advanced users only!
Notice that most the AI settings, according the several scripts we'll put at dispose, will have to be configured by the editor him-self! For example, the safe positions and random safe paths - these last shall be "choosed" by the AI regarding the enemy's position.
Oh! And... Excuse my ignorance. ::) What does "AFAIK" mean?
#Edit
1:
The most important of these scripts will be the one concerning the AI's behaviour according the terrain!
Several times I've seen AI enemies coming after me from very bad positions and through the shortest path, being an easy target. So, I want them clever and deceiving!
I've made one similar script, once, which fulfils the need of getting the terrain elevation, etc. However, it causes too much lag, and besides, Spinor mentioned a terrain monitor script (right?) which I don't know and that might be very usefull.
2:
Answering Spinor, the enemy position monitoring is easy. Lets see: If you don't know the enemy's position, yet a small reference, then you take the theoricaly most safe path. Yet if you know were the enemy is (countEnemy and knowsAbout association, 'forEach' leader), then you behave differently. It's a question of realism.
In conclusion, the enemy position checker and terrain checker are theoricaly solved - now, we need scripts. However, one of the most difficult to solve will be the obtacle checker (very important for concealment/covering).
In my opinion, if such objective gets too hard to achieve, then there should be designated safe locations (as I've already mentioned) and study the best behaviour conjuctions (waypoint type, combat behaviour, engagement setting, speed) we might combine, so that the AI covers and positionates strategicaly at those locations.
-
As Far As I Know
-
Oh! And... Excuse my ignorance. What does "AFAIK" mean?
AFAIK, as far as I know ;)
I've made one similar script, once, which fulfils the need of getting the terrain elevation, etc. However, it causes too
much lag, and besides, Spinor mentioned a terrain monitor script (right?) which I don't know and that might be very
usefull.
I have to say though, that it also lags as a lot of nearestObject calls have to be done
to get a reasonable faithful terrain representation. I don't think this is really a problem
because we don't have to actually "monitor" the terrain all the time as it is mastly static.
One can make once in a while a sample of the terrain surrounding our group, store the
result, and access it from memory.
Answering Spinor, the enemy position monitoring is easy. Lets see: If you don't know the enemy's position, yet a
small reference, then you take the theoricaly most safe path. Yet if you know were the enemy is (countEnemy and
knowsAbout association, 'forEach' leader), then you behave differently. It's a question of realism.
In principle, monitoring the enemy is not too difficult, but it can also put some nosty strain on the CPU, because
unlike to terrain sampling it must be done regularly. Also, we not only need the positions
but also the strength/type/ability.
In conclusion, the enemy position checker and terrain checker are theoricaly solved - now, we need scripts. However,
one of the most difficult to solve will be the obtacle checker (very important for concealment/covering).
I would say that the obstacle checker is also solved theoretically. It should best be combined with the
elevation checker to give a terrain sampler.
-
Quite right, at CoC we are looking into this . At CoC, we are actually more concerned
with inter-group-AI (how different groups work together to achieve a goal) than intra-group-AI,
but the same rules apply.
Yeah, different nets for the different layers.
Denoir created a completely general Neural Net Module that can be used for all AI
tasks (and even non-AI tasks like the artillery).
I will have to prise it out of the Artillery scripts, as the zip file in the COC downloads section is empty :(
In principle, monitoring the enemy is not too difficult, but it can also put some nosty strain on the CPU, because
unlike to terrain sampling it must be done regularly. Also, we not only need the positions
but also the strength/type/ability.
If only have to monitor what group leaders are present, anything else could be picked up at the start or after contact has been made. It just requires lots of detect triggers, for those groups who can report.
-
I will have to prise it out of the Artillery scripts, as the zip file in the COC downloads section is empty
I wasn't aware of that, I'll check with denoir if he can put it back.
-
Ooooh and AI thread! ;D You AI nuts might wanna check this (http://www.ofpec.com/editors/funcref.php?filter_func=41), this (http://www.ofpec.com/editors/comref.php?letter=K#knowsAbout), and this (http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=3d618136eb4242ee42e34af7e25b4bdf;act=ST;f=7;t=33915) out.
-
The main problem is only that bushes/trees/forests/roads do not have a object class. The only way to
differentiate them is to take their z-value:
roads: z = approx 0
bushes: z = approx 2
trees: z = approx 12
forests: z = approx 20
Using this approach I wrote an terrain sampler for CoC that creates a matrix array (100x100 elements,
one element corresponds to one terrain grid) containing data about the terrain. It works quite well, giving
a faithful representation of the terrain features like vegetation, roughness, etc
Spinor, could you please post this script?! This is EXACTLY what I have been wanting to be able to do for so long! I'd love to see this! I can think of so much to do with this!
*Salivates heavily*
-
If you don't mind, have a look into this thread:
http://www.ofpec.com/yabbse/index.php?board=6;action=display;threadid=13884
Waypoint SCRIPTED seems to fit perfect into your idea,
as you can have a mix of waypoints and scripts.
With a lil bit of tuning, you'll be able to easily switch thru
let's say: a sentry wapoint, or a guard and the scripted one ;)
~S~ CD
-
I have to say though, that it also lags as a lot of nearestObject calls have to be done
to get a reasonable faithful terrain representation. I don't think this is really a problem
because we don't have to actually "monitor" the terrain all the time as it is mastly static.
One can make once in a while a sample of the terrain surrounding our group, store the
result, and access it from memory.In principle, monitoring the enemy is not too difficult, but it can also put some nosty strain on the CPU, because
unlike to terrain sampling it must be done regularly. Also, we not only need the positions
but also the strength/type/ability.I would say that the obstacle checker is also solved theoretically. It should best be combined with the
elevation checker to give a terrain sampler.
Checking terrain obstacles with nearestObject?!?! WOW! :wow: Such script must be a jewel! Didn't think it was possible... :hmm:
This weekend I had been testing a few Waypoint types. Indeed, "SCRIPTED" type WP allows you to call scripts with several usefull arguments; however, it would be too complicated in what concerns to behaviour randomness. So, I'll still defend my "safe-positions" theory, which allows the AI to cover and move through safe paths, "chosen" by themselves... (As "Choice" is something we can't apply to AI, I had it in quotes ;)).
For my surprise, this weekend I've seen the AI acting stealthily!!! They organized two groups each; one covered the right side of the base (Machine Gunner laid behind a bush; GL crouched next the base walls and 2 meters away from the MG; RFLman crouched behind a tree) and the other covered the entrance. I was :wow:. And it happened with no scripting, just a "Guard" waypoint and "stealth" behaviour - this last is the one that forces the AI to get covered.
Unfoutunately, at the next attempt (retry), they started again acting like fools; again and again.
So, as you can see, there's alot (maybe too much) randomness in the AI's behaviour. Scripting the AI would 'kill' such randomness; besides, if dependent on WP's, the AI would always cross the same path or maybe two different paths, being too predictable.
Now, the solutions surely dwells on the terrain/obstacles script, which - if it works with bushes and trees - will allow the AI to cover at the nearest "obstacle".
-
Spinor, could you please post this script?! This is EXACTLY what I have been wanting to be able to do for so long!
I'd love to see this! I can think of so much to do with this!
Checking terrain obstacles with nearestObject?!?! WOW! Such script must be a jewel! Didn't think it was
possible...
Mind you, it is a bad workaround so its far from perfect and as I mentioned it puts
quite some workload on the CPU. As I don't have internet at home at the moment, it's
a little difficult to put the script up. In any case, my script is not originally intended to
determine each single object but to determine the general category of a map grid.
Anyway, here's a snippet (untested) to scan an area of size _dx * _dy around
the position [_x0,_y0]. All objects found are stored in the arrays _objs (containing all
proper objects belonging to an actual object class, e.g. buildings), _roads, _bushes
(probably also containing rocks) , _trees and _forests
;---------------------------
;center of scan area
_x0 = 5000
_y0 = 5000
;scan area size
_dx = 200
_dy = 200
;step size for nearestObject calls
_incr = 5
_objs=[]
_roads=[]
_bushes= []
_trees=[]
_forests[]
_x = _x0 - _dx/2
_y = _y0 - _dy/2
#LoopX
?!(_x < _x0 + _dx/2): goto "EndLoopX"
#LoopY
?!(_y < _y0 + _dy/2): goto "EndLoopY"
_object = nearestObject[_x,_y,0]
;object analysis----------------
;if object is of known class type (== of class "All"), it is not a road/bush/tree/forest
?("All" countType [_object] == 1): _objs = _objs + [_object]; goto "EndAnalysis"
_z = (getPos _object) select 2
?_z < 0.2: _roads = _roads + [_object]; goto "EndAnalysis"
?_z < 3: _bushes = _bushes + [_object]; goto "EndAnalysis"
?_z < 12: _trees = _trees + [_object]; goto "EndAnalysis"
_forests = _forests + [_object]
;---------------------------
#EndAnalysis
_y = _y + _incr
goto "LoopY"
#EndLoopY
_x = _x + _incr
goto "LoopX"
#EndLoopX
;--------------------------------
If the snippet works as expected it should put all the objects, bushes, etc. into their
respective arrays. Armed with these you should be able to do all kinds of stunts,
e.g. determine the closest cover for a given unit, an analysis of good cover areas, etc.
The method is not foolproof and is bound to give some false results sometimes, e.g.
misinterpreting a tree for a bush, etc. The z-values used (0.2,3,12) are not perfect,
a little finetuning maybe required.
With the numbers given, the snippet will have to perform (200/5) * (200/5) = 1600 nearestObject
calls to scan an area of 200m * 200m.
The object analysis can be extended to determine the type of buildings, etc. through the
use of typeOf,countType. Another neat command is buildingPos. If used properly
one can determine whether a building is enterable and if yes, how many building
positions it has.
-
Hmm... That script uses the nearestObject command in a different way, and if you're right, Spinor, then our AI problem is solved... Thing will be alot easier...
WOW! Thanks alot mate!
-
Yeah but don't forget the part about having to run it 1,600 times.
What about telling AI to be Stealthy, like you said...but then keep telling them that every 5 seconds or so. Maybe each time you give the command they run for cover...but then come out after they find cover. This might keep them in cover.
Doolittle
-
_object = nearestObject[_x,_y,0]
A couple Q's here. First, why are you passing 3 parameters to nearestObject. Doesn't it only take 2? And second, what is the "0"? Is that what I think it is? Does that make it return the nearestobject of any type?!?! How come I never knew this?!
?("All" countType [_object] == 1): _objs = _objs + [_object]; goto "EndAnalysis"
Could you explain this line? How could the object not fall under the "any" class? Doesn't everything fall under the any class?
-
Yeah but don't forget the part about having to run it 1,600 times.
You dont have to, just run it for area's of interest or when something happens.
First, why are you passing 3 parameters to nearestObject. Doesn't it only take 2?
You only need to pass the XYZ coordinates of the position you want to search from, if no type class is provided I it gets any of them.
How could the object not fall under the "any" class? Doesn't everything fall under the any class?
If you use the typeof command. Roads,bushes,trees and forests do not return a type. So I guess "ALL" is all CfgVehicle types or something like?
-
You only need to pass the XYZ coordinates of the position you want to search from, if no type class is provided I it gets any of them.
Wow! News to me. And good news at that! Excuse me now; I have to go play.....
-
Incredible... :wow: nearestObject's main syntax requires two arguments:
nearestObject [[x,y,z],"Type"]
or
nearestObject [object, "Type"]
However, and that's really amasing to me, nearestObject works by giving a position and ignore the type:
nearestObject [x,y,z]
So, you can detect anything and everything...!
Now, that's the problem... We don't want to detect either roads or marks... So, we'll have to do a few tricks.
Roads, like most of the buildings are at level 0m according to the groud level. But they don't return any class name; besides, nearestBuilding solves us the building detection problem, and so, every objects between level 1 and -1 shall be ignored.
Marks (a strange invisible thing I've detected in the islands, usualy called "stopa_l" or "stopa_p" - not sure, though) are at the same level of buildings (between 1 and -1). Therefore, they can easily be ignored, by calling their z-value.
Bushes, rocks and trees have usualy a z-value higher than 2m. These are easy to define (mainly trees, which are 8~20m tall - while bushes and rocks have the same level :().
In conclusion:
wood/desert land combat - nearestObject (ignore <1 z-values)
urban combat - nearestBuilding
Storing the buildings settings into an array, regarding each type - [width, length, number of inner positions] - is a good way of making the AI to walk along them and explore them.
-
Yeah but don't forget the part about having to run it 1,600 times.
What about telling AI to be Stealthy, like you said...but then keep telling them that every 5 seconds or so. Maybe each
time you give the command they run for cover...but then come out after they find cover. This might keep them in
cover.
Like unnamed said, its not necessary to do it continually. An even better solution
is to run this "terrain scanning" in the background with a low priority (put large
waiting times within the loops).
Anyway, for simple things like "Take cover" I would also try your suggestion of using
"Stealth" mode first. If we want to write our own AI that is able to "intelligently" use
terrain features, a proper analysis of the terrain is necessary, though.
If you use the typeof command. Roads,bushes,trees and forests do not return a type. So I guess "ALL" is all
CfgVehicle types or something like?
Yes, "All" covers all vehicle classes, but roads/bushes/trees/forests do not belong to any class.
Now, that's the problem... We don't want to detect either roads or marks... So, we'll have to do a few tricks.
Roads, like most of the buildings are at level 0m according to the groud level. But they don't return any class name;
besides, nearestBuilding solves us the building detection problem, and so, every objects between level 1 and -1 shall
be ignored.
Marks (a strange invisible thing I've detected in the islands, usualy called "stopa_l" or "stopa_p" - not sure, though)
are at the same level of buildings (between 1 and -1). Therefore, they can easily be ignored, by calling their z-value.
Bushes, rocks and trees have usualy a z-value higher than 2m. These are easy to define (mainly trees, which are 8~20m
tall - while bushes and rocks have the same level ).
I haven't noticed the marks yet. Any idea what they are for?
One clarification about buildings. nearestBuilding only returns enterable buildings.
To capture "fake" buildings you need to check for the "Buildings" class of a given
object. If needed, with countType and typeOf you can determine subclasses
or the exact type of building.
I found that forests objects (i.e. not single trees, but a section of a forest patch) have the
highest z-value of about 22 meters.
Another trick to differentiate between types is to use getDir. E.g. roads mostly have a
non-zero direction (naturally), whereas trees and bushes have zero direction. I'm not sure
about rocks.
-
I've finished editing the first version of Spinor's script. It looks really nice, but I'll have to implement a few more features. It detects 65% to 100% of the objects in a given area. It ignores classed objects - AI units, buildings and other structures - and stores every detected object in a proper array:
roads for unclassed objects with less than 0.2m. Note: stopa_@ usualy have the same height of roads, but they're class-named as "Marks". I can't figure out what they are.
rock_bush for bushes and rocks. I can't distinguish them through scripting.
trees for trees with more than 6.5m and less than 12.5m.
forest for forest sections with more than 12.5m. There are a few trees with 25m (!!!) and which will be considered forest. There's nothing we can do... yet.
I've fully tested this first version. Kedgety's/Gunslinger's editor update doesn't cause any conflicts with the script. The script doesn't cause any lag in my old Buddy (400MHz), though it takes 20 seconds to finish looping in an area of 500x500m2. Scanning an area of 100x100m2 is basically instantaneous - my old buddy takes 0.5~1 seconds to finish scanning.
The mission sample contains a trigger with the size of the area to be scanned; therefore, every objects within that area shall be detected, except when they're too close of each other - in this case, only a few will be detected. It also contains a JPEG with a sample of the monitoring grid (made with flag poles).
In a further version I'll implement an area angle setting, which allows the script to work exactly like a trigger. Besides, the conditions I use (which are quite large) will be writen in a function which will be called by the script everytime it is required.
Note: Looks like I'm having problems in attaching the zip-file. I'll be able to do it in a few hours (about 1:30pm GMT). See ya!
#Edit
I've just forgot the following:
This script looks like solved. It shall be used only in open area combat. For the urban combats, we shall make a new script which consists in:
Detect buildings included in an array of classes (which can be modified by the editor through a variable!). The class names array should consist in a group of arrays (arrays within array) containing the settings of each building type: ["Class Name", length, width, number of positions (for open build')]. With such array we'll be able, as I've said, to have an AI unit to explore it and positionate at it's corners.
Then, after the "urban combat terrain monitor", we must make a script returning the terrain elevation gradient between the enemies and the surrounding area. With such script, tha AI will be able to decide which position is better for attacking the enemy.
Unlike the medieval ages, where whoever had the mountains, would have advantage; with powder, the highest positions are the best targets! A depresion is an excellent positon for hiding from the enemy, while a hill is the best position for guarding an area.
After that script, then, we'll start to make the great "AI units interaction script", consisting on the unit's behaviour according the terrain settings and the enemy. And after that we'll have to make the "Inter-Group interaction script" - which I believe there are already some good samples - and the "Intra-group interaction script".
Awaiting for the mission sample... (1:30pm GMT)
#Edit2
EhEh! Geometry writen test went bad... ::) :-\ So, I got out later... It's now 1:40pm
Here's the sample (not big deal, though, Spinor...)
;Original script by Spinor
;Improvements and modifications by MorMel (Komuna at OFPEC)
;[position - array[x,y], scanning area - array[length,width], angle - integer, step - integer] exec "TerrainChecker.sqs"
;center of scan area
_i = (_this select 0) select 0
_j = (_this select 0) select 1
;scan area (divided by two)
_l = ((_this select 1) select 0) / 2
_w = ((_this select 1) select 1) / 2
;angle of the area shape
;Note: this feature hasn't been coded, yet.
_ang = _this select 2
;step size
_incr = _this select 3
_objs=[]
_x = _i - _l
#X
_y = _j - _w
#Y
IF (({(format["%1",typeOf _x] != "")||(isNull _x)||(_x in _objs)} count [nearestObject [_x,_y,3]]) == 0) THEN {_objs = _objs + [nearestObject [_x,_y,3]]}
_y = _y + _incr
? _y <= _j + _w : Goto "Y"
_x = _x + _incr
? _x <= _i + _l : Goto "X"
_roads=[]
_rock_bush=[]
_trees=[]
_forest=[]
{IF (position _x select 2 < 0.2) THEN {_roads=_roads+[_x]} ELSE {IF (position _x select 2 < 6.5) THEN {_rock_bush=_rock_bush+[_x]} ELSE {IF (position _x select 2 < 15) THEN {_trees=_trees+[_x]} ELSE {_forest=_forest+[_x]}}}} forEach _objs
hint format ["total: %1\nroads: %2\nrocks&bushes: %3\ntrees: %4\nforests: %5",count _objs, count _roads, count _rock_bush, count _trees, count _forest]
exit
-
Sounds excellent, Komuna :)
rock_bush for bushes and rocks. I can't distinguish them through scripting.
Have you tried getDir yet? I could imagine most rocks are rotated somehow.
orest for forest sections with more than 12.5m. There are a few trees with 25m (!!!) and which will be considered
forest. There's nothing we can do... yet.
One way to distinguish between them is to check for nearby forests. Forests always come in patches
and a typical patch consists of about 20 forest objects or so, which are placed very regularly.
So, if you have an assumed forest object, check if another one is close by (30-40m). If yes,
make it a forest, if no, a tree.
The mission sample contains a trigger with the size of the area to be scanned;
One Q here: Why do you need a trigger? The trigger does not catch map objects, only vehicles/units.
The obstacle monitor should work fine without a trigger.
It shall be used only in open area combat. For the urban combats, we shall make a new
script
In the end, I would suggest a single script, that unifies both. Otherwise, you have to
externally check if a map section is urban or open area. Mixed terrain even complicates
this.
-
One Q here: Why do you need a trigger? The trigger does not catch map objects, only vehicles/units.
EhEh! I use the trigger just for reference! It only activates the script and gives the editor an idea of the area to be scanned... Nothing special, indeed.
In the end, I would suggest a single script, that unifies both. Otherwise, you have to
externally check if a map section is urban or open area. Mixed terrain even complicates
this.
Mix them? Might be a solution, but I was thinking that each script type would be configured by the editor according to the area's nature - urban or open.
But that's not a problem. First we make all the required script's. Then we mix them, create some extra scripts and delete the one's we don't need.
#Edit
IF (({(format["%1",typeOf _x] != "")||(isNull _x)||(_x in _objs)} count [nearestObject [_x,_y,3]]) == 0) THEN {_objs = _objs + [nearestObject [_x,_y,3]]}
You might be wondering why I use such a complex condition (instead of calling nearestObject everytime I need to check a cond).
The answer is simple: calling nearestObject several times will increase the game lag (Wo! Imagine in my 400MHz) and, due to OFP bugs, it might also detect a diferent obj each time use call it...
Note: the "Angle" feature ahsn't been coded yet. Maybe tomorrow I'll have that finished, as long with the building detector.
-
Mix them? Might be a solution, but I was thinking that each script type would be configured by the editor according
to the area's nature - urban or open.
Yup, that should work nicely. Sorry, I have to admit that I view most of this stuff in combination
with the Command Engine and in that case everything is so dynamic (when AI is included, even
more) that it is impossible for the mission-designer to assign a specific area.
-
Perhaps we should use this tread as a development place for this?
I.E post updates on scripts and such, so that we can all work to create one bad-ass system.
Because I'm very willing to help out :)
edit
Or in other words:
Post your bloody scripts so I can help out ;D
edit 2
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.
I suppose one could just scan a smaller area around each AI group leader, 256 x 256 gives the AI enough room to manouver in, and doesn't take that long to scan.
-
I suppose one could just scan a smaller area around each AI group leader, 256 x 256 gives the AI enough room to manouver in, and doesn't take that long to scan.
Indeed.
The "Advanced AI skill improvement" is far from being finished. This script I've edited is just a very small part of a big scripting process. So, finding a solution for reducing the scanning time is not reliable, yet.
In this way, we shall wait for the other scripts and only then find a solution according to the whole scripts-set conditions.
P.S.: I've been a little lazy and, yesterday, instead of studing physics or coding the scripts - as I had promissed - I prefered to shoot down a few thunderbolts with the SU25BM... Sorry! :o ;D
#Edit
You might be wondering why I use such a complex condition (instead of calling nearestObject everytime I need to check a cond).
Well. Why didn't I store the nearest object into a variable, then?
That's what I forgot to explain: everytime I stored the nearest object into a variable, the stored value was a bug: the well known "fdeeee :sdbsgh - something I can't remember". This value doesn't mean anything, it works like a null value. So, storing it into the objects array would be usefull... I could try storing the initial value into an array for testing the condition (_temp = [nearestObject [_x,_y,3]]), but I though such thing wasn't needed, so... I made that condition.
-
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.
-
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.
-
And by the time THAT was done...OFP 2 would be out. :-X
Doolittle
-
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.
-
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...
-
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.
-
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 - :
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.
-
Hello? :-\
-
Sorry man, I've been meaning to check this out, but I've been pretty busy with school and the like recently.
Maybe later... :(
-
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.
-
Don't suppose you have dabbled further with it since the last version posted? ;)
Errrr... :-[ :P
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.
-
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.
-
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)
-
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 :o.
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.
-
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?
-
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.
-
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?
-
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.
-
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?
-
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.
-
so what now?
whens this script going to be ready cant wait to get my hands on it :D
-
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 :(
-
(http://homepages.nildram.co.uk/~gunfight/NearestObject.jpg)
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:
{
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?
-
any progress made on this one?
I really cant wait, this will add a whole new feel to OFP
:D
-
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
-
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.
-
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?
-
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).
-
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 :-[
-
[...]
         {
            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.
-
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.
Never heard about the null bug before? You mean a variable given the address of an object by the nearestobject, command will/can be set to null by mistake?
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.
No testing yet, I do need a terrain scanner for my observer, although for different requirements, so I will give my idea a try.
To be honest it depends on lots of factors, like the relative overheads of using nearestobject, the in command on larger arrays and multiple if statements. It may not even be so bad, having duplicate objects in the final arrays, if it speeds up the initial processing.
hope you understood. I'd explain better in portuguese but... you know
Nope, still none the wiser. But it's no big deal, and my portuguese is a little rusty :)
-
I haven't read the thread(I think you understand why, its soooo long)but I have a suggestion.
When AI is low on ammo it should decide which weapon to take from a dead body, the closest or the best? And automaticly take the one it finds best suited without any stupid orders from the player leader. Should be fairly easy to make.
:beat: *Gets Shot* :beat:
-
I agree, that would be a great feature (more so for the AI squads than the player squads, since the AI squads have no way of doing that now). I've thought about doing a script like that in the past, however, it wouldn't be as easy to make as you seem to think. But if you have a good idea on how to do it, please post a script showing it, and perhaps we can work on ways to improve it. :-X
-
Oh, no, no, no, no, you guys are the gurus. I can make easy scripts, I'm absolutley no AI-improver. :P
Don't you have to put each gun that's, say 50 meters from the AI in an array and then let the script have a lot of math and crap about which would be the best to pick up(for example: the AI should rather pick up a M21 10 meters away from him than a Kozlice 8 meters from him).
:beat: *Gets Shot* :beat:
-
hmm - there's just one thing, you should never forget here:
soldiers and their rifles are married
I don't think it's very realistic, if ai goes for changing the
rifle just because they ran out of ammo, even though there's
the right ammo for their guns laying around.
Also think about the fact that some soldiers will even not hit
a hangar door with the rifle of a stranger due to their own
configuration and training on their very own rifle.
SF's may be an exception as i believe those are also trained
to use a whole lotta more different weapons (even enemy's
ones).
Another point is:
what is the best weapon in the near?
Is it a machinegun, is it the grenadelauncher rifle, an AK, or
the shotgun?
This will in many ways depend on the combat situation, so
i think the implemention of this could lead in some cases
into a very unlucky direction.
~S~ CD
-
i actualy made a script 4 picking up ammo (toadlife uses edited ver of it in his kool mision - da 1 dat u need 2 rescue som captive from a prision - got som randmo location damn cant remember da name) was made 4 NPD2 ;D
not makin soldier change his weapon tho - dis shud b kept 2 da commander so he decides wich weapons he needs in da mision (silenced ? MGs ? mebe he wants somin else ?)
LCD OUT
-
I don't think it's very realistic, if ai goes for changing the
rifle just because they ran out of ammo, even though there's
the right ammo for their guns laying around.
Agreed, of course the AI should pick up ammo for their gun first, if available. However, if I were outta ammo for my m16, and there was none around, I'd gladly throw it away and grab an AK (assuming I was in immediate danger).
Also think about the fact that some soldiers will even not hit
a hangar door with the rifle of a stranger due to their own
configuration and training on their very own rifle.
Yes, each rifle is BZO'd (battle-sight zeroed) for each individual shooter; however, even if a weapon isn't zeroed for you, it is still fairly accurate at close ranges (100-200 meteres), and you could always just adjust it on the fly. Also, not all weapons have adjustable sights like the m16.
-
OK then, what about picking up AT if the squad has none and it's laying around and there's tanks in the area? I'm tired of AI that just lay themself down if an abram rumbles in.
:beat: *Gets Shot* :beat:
-
The current topic subject will be developed by the ECP team.
The first results of our work will be available in a few weeks.
If you want to contribute, join us.
Until the first reliable results have been achieved, this topic will be locked.