Detecting objects (trees/bushes)

[paddy]

The point of an object reference, whether classname or ID is to allow code to identify the object.
Classnames are a much better form of reference because they allow use of the nearestobject command and sorting of the returns
Object ID's are very fiddly, cannot be used in adaptive advanced scripting (because of their inflexible nature) and are useless excepft for in very limited cases.

My aim initially was to create an advanced AI script that would let AI use cover more effectivly, classify the cover and choose the most appropriate accordingly.  This is impossible with the current command engine and as BIS had (i think) stated in one of their press releases about ArA that the command engine wil be largely the same I cannot see that changing, even in the new game.

Hopefully it will be introduced in OFP2 though so that we can have some really kick ass AI.  Saying that maybe BIS have developed a whole new AI interface for ArA that will render this discussion obsolete? ... we really can't say.

However any solution to this problem is beyond the realms of my knowledge and patience.  I will still release a version of my advanced AI although I believe it wont look half as good as it would have if my attemp at a new 'findcover' script had worked.

If anyone would like to have a look at the remnants of my research into this issue please email me but it'd be a waste of your time basically.

- Paddy

[h-]

So you tested that missionette I posted?

Of course typeOf returns no usable info when used on objects that have no class names...
The only way you could make the AI to know what kind of object a tree/bush/rock would be is to make a huge reference of the heights of the objects (as returned with the nearestObject method, which works) and then math up some border values and when a certain height value is exceeded a certain type of object would be selected...
Not at all perfect way...
There was a discussion about this ages ago here in these very forums, was in 2004 or 2003...

Or, make a reference of those .p3d filenames (.p3d=OFP 3D model) of the bushes/trees/rocks and compare the p3d model name returned by the nearestObject to those and tell the AI what object it is based on that..
Dunno how much less or more work that would include than the height method...

Why tress/bushes crumble is just because it's hardcoded stuff in OFP destruction engine etc...
Which on other configgable objecst/vehicles/etc can be manipulated by giving the hardcoded stuff values which BIS have allowed OFP 'hardcode' to read from external configuration (me guesses.. )...
Why this is done like it is I have no speculation to offer ..
(sorry for any erroneous terminology)

[Mikero]

compare the p3d model name returned by the nearestObject

not knowing too much, would looking at icon= solve the probem? Or does this only apply to genuine addons, where 'bushes' eg will mostly have a generic icon for the editor.

[Spinor]

Paddy, as you mentioned my terrain scanner, I can say that using getPos on static objects (either refering to them by the object ID or as a result from nearestObject) works fine for me.
In fact, I was using the z-value to classify an object because it roughly corresponds to the object height, e.g.
Roads: z ~ 0.0, mostly negative, as a further filter, most roads will have getDir != 0
Bushes/Rocks: z ~ 0.5 - 2
Single Trees: z ~ 5 -10
Forests: z ~> 12

As HateR_Kint pointed out this is not perfectly exact, but it should not matter to much in practice. The AI might run towards a tree instead of hiding behind a bush once every 10 cases. My original intention was to create a terrain scanner for the whole island to classify map grids (open, wooded, etc.), so some false recognitions did not matter.

All I wanted to say is that using nearestObject to analyze the terrain can be done and a rough object classification is possible. If you like I can dig up my original script and pimp it a little.

[paddy]

Did that, pimped it.

@Hater
I remember that post well, it was where I got alot of ideas for the script.  I had the idea from our mod leader smiley who basically set me the task (slave-driver)   and I got spinors oroginal script idea and adapted it.

@Spinor
It doesn't work for my, then again neither did general barrons script.  Classifying cover for the whole island is far too taxing on the PC, remember every time you increase the dimensio0ns of the search box, the number of nearestobject calls increases EXPODENTIALLY hence you get a very high CPU drain.  My script only did 5 or 6 calls, but they were well spaced out and seemed to return a piece of cover quite frequently.  However the problem arose when I tried to use the array of cover created to move to cover.  I basically had a setup like this (randomint is a function by general barron that will return a random integer between 2 given values)

Code: [Select]

_resultsofcalls = [call1obj, call2obj, call3obj etc .....]

_i = [0, ((count _resultsofcalls)-1)] call randomint

_unit setpos [getpos (_resultsofcalls select _i) select 0, getpos (_resultsofcalls select _i) select 1, 0]

But for some reason the getposcouldn't be called from the object in the array.  That lead me to investigate whether u could call getpos off an object w/o a classname.
The ONLY command that would give me any feedback was 'hint format' .. e.g.

Code: [Select]

_resultsofcalls = [call1obj, call2obj, call3obj etc .....]

_i = [0, ((count _resultsofcalls)-1)] call randomint

hint format ["%1 %2", _resultsofcalls select _i, getpos (_resultsofcalls select _i) select 2]

This would return a height value, and yes, your script in theory should work.  What really threw me was when I tried to use this value with the setpos command, No matter what I did the game engine wouldn't take the fix.  I tried putting brackets everywhere, I even put the result into a string and then used the call command to try and get a numerical value returned.  Nothing seemed to work.

Now, when I said that trees/bushes aren't objects, that wasn't my research but as I've already said some of the guys in work pointed that out to me (and they're smart so I took their word for it).

However you say they are objects, i find that hard to believe, they are part of the map, not the mission so they aren't actually objects.  However since the defenition of object is a bit vague we might be talking about slightly different things.  Like, you could argue the thle island is an object ... which in essence it is, just a very bit one, but calling getpos off the island wont work!!

[h-]

Ok, of course you can say that the trees/etc are part of the terrain, but they are physical objects as they have a 3D model; trees/bushes/rocks are modelled the same way as any other 3D object used in the game, and so on...
They are not 'molded' like the terrain is but modelled in a separate software and inserted on the molded terrain...

But in any case this does not change the fact that nearestObject finds such objects and you can getPos them and use that position to move your men/vehicles to, etc..

[paddy]

It wont work for me, I dont think this topic is going anywhere so unless i find a solution, i'll leave it open one more day and then close it

[h-]

What OFP version you use?
The only reason that I can think of for it not to work (or GB's script, as you mention) is that you have a 'wrong' version of OFP...  :'(  :-\

Annoyingly puzzling situation...  

[Spinor]

Paddy, do not give up   ... believe us, it works. Either there is something wrong with your OFP version or you have some nasty and hard-to-find bug in your code. Maybe its some stupid thing like _unit is not defined.

I can not believe that getPos in your case only works in a hint. Commands do not care what they are used for. If the hint works, everything else should also. Could you post a mission or send it to Spinor25@aol.com ?

Classifying cover for the whole island is far too taxing on the PC, remember every time you increase the dimensio0ns of the search box, the number of nearestobject calls increases EXPODENTIALLY hence you get a very high CPU drain.

Quite right, but the scan is done only once for a given island, and takes about an hour or so. The result of that scan is written into an 100*100 array (one element for each grid) and can be extracted from a save game. In an actual mission, you only have to read in that array, not perform a scan every time.

[paddy]

Ohh, inspiring

Fair enuf then. However my time is short and mostly needed for sleep and work at the moment, so this may take a while lol

[paddy]

Well, I had a brainwave overnight and it just warranted re-opening this post for, what about a find object ID script?

Okay, so object id's are only useful atm if you know them beforehand, well what about a script that will loop through ALL possible values for an object id, e.g. 12345 is an object id so the lowest possible id theoretically would be 00000 and the highest possible would be 99999.

for example

Code: [Select]

_id=00001
objects=[]
objectsnoclass=[]
private ["_id"]
publicvariable "objects"
publicvariable "objectsnoclass"
~0

#loop
@ true
? _id > 99999 : exit
? isnull (object _id) : _id=_id+1; goto "loop"
? All != (object _id) : objectsnoclass=objectsnoclass+[object _id]; objects=objects+[object _id]; _id=_id+1; goto "loop"
_objects=_objects+[object _id]
_id=_id+1
goto "loop"totally untested code!!!

As you can see if you read thru this code, it would create 2 super useful arrays called "objects" and "objectsnoclass".  These name are pretty self explanatory.

Now of course this would create a LOT of lag and drain on the cpu, but it would only ever have to be done once, at the start of each mission, have a sort of 'initialising' screen before mission start and hey presto you have an array of objects 'suitable' to be used as cover.  

I dont know how feasable this would be, would we have to sort the objects by height again like spinor suggested to remove ground textures and 'NOID's.  You could even rationalise the script and only add objects to the array that were a certain distance from the player, even divide the map into 'sectors' and scan only the sectors containing units.

and ideas??