Detecting objects (trees/bushes)

[paddy]

I have been doing some investigation into the nearestobject command with the purpose of creating a script that would make units take cover.
I made numerous attepts to get unts to move to a position fix attained by nearestobject but was unsuccessful.
I then proceeded to scour the forums for ideas, finally discovering spinors posts concerning the different use of nearestobject (the non-object specific use) that lead to general barrons attempt at a findcover script.

The script didnt fully work and I think I found out why.  Some of my more technically knowledgable friends had a look at the way bushes and trees are incorporated into the game and the way both 'getpos' and 'position' commands actually work.

Trees and bushes for anyone who has no knowledge in this area are not objects because they are not defined in any config and hence have no classnames.  They are merely positions on the map where textures are generated.  The textures have no depth or barriers (mostly) and hence need no actual object params'.

The getpos and position command when called return the position of objects.  The return is in the form of a 3 part array.  Since trees and bushes are not actually objects, the commands WILL NOT WORK.  Getpos and position can NOT return the position of textures and were never intended to do so.

Hence anyone trying to use the nearestobject command to find the positions of trees and bushes will fail because there is no way of identifying the exact position of the returned texture name (for this is all that nearestobject returns when it finds a texture).

The only way to accomplish this would be to place markers over all the trees and bushes in a map, mark their positions and tell the units to use these markers as 'cover'.  Apart from being time consuming it is also impractical in a script designed to run a mission over any decent sized area.

If anybody would like to confirm or disprove my theory I would love to hear but I can see no way round this obstacle.  Hopefully this will save other editors alot of time and energy.

[THobson]

getPos will work on objects that are already on the map.  Try putting: this setPos getPos (object XXXX) in the player's init field where XXXX is a object ID of a tree or a bush for example.

I often use nearestObject to find an object I have placed on the map by reference to where it is in relation to a pre-placed object - it saves giving them names.  I have never tried to do it the other way around which is what I think you are trying to do.  I presume you are specifying the type of object you are looking for?

[paddy]

The purpose of the script was for the AI to dtect and use cover intelligently.  The nearestcover command was used and results sorted and fed into an array.  Sorting was done by distinguishing between the height values of reutrned objects.

To use setPos getPos (object XXXX) you would have to already know the objects ID which I cant do (there is no such command to find an ID from a texture) and any function i could think of making wouldnt work.

The typeof command wont work on bushes and trees because neither have classnames.  I appreciate your use of the nearestobject command but you are using it on objects YOU have placed in the editor, these objects have classnames and getpos WILL work on them.

Try selecting a random bush, getting its ID and try and return the height value of that object through a formatted hint.  I think THAT works because ID's work in a funny way by assigning a NOID object to the bush before running any commands.  Note that NOIDs can be picked up by nearestobject and their getpos valuse can be found, hence we can assume they are true objects (but seem to have no dimensions).

Now try selecting a bush with nearestobject and use getpos on your returned object, wont work (well, didnt for me and my friends)

[h-]

nearestObject, getpos etc work just fine with trees and bushes...
Dunno how you and your friends have tried it...

And, trees and bushes ARE actual 3D models, not just positions on which textures are rendered...
If you want examples, get a program like OdolExplorer and browse through the data3D.pbo

Dunno the real reason for the bushes/trees not needing a config, but I guess as they are a solid part of the 'world' they don't need any object properties...

Anyhow, put this in a radio trigger set on repeatedly and run around to diffreent trees and bushes and it works just fine...

Code: [Select]

call {_obj=(nearestObject [(position player select 0)+4*sin(direction player),(position player select 1)+4*cos(direction player),position player select 2]); hint format ["Object: %1\nPos: %2",_obj,position _obj]}Note that when a tree or a bush is detected it returns the trees/bushes 3D model name instead of a class name..

If you compare the z axis position to the player's z axis position the trees/bushes position is not returned from the ground surface but I guess from the 'tip' of the object, or something...

[paddy]

Negative, try using that getpos value to send a unit to the tree/bush

It doesn't work.  I dont know why it works in a hint, i think it's a glitch.  I have experimented loads with this, units refuse to move to trees/bushes and when i try and add the objects to an array, nothing happens!!

Trees aren't define'd as objects I was told.  Objects can be called and defined in the config and when I tried to do this , only then could I get any units to take a position fix

N.B. Try the same thing with trees/bushes added by kegteys editor addon, that will work cause the trees/bushes now have classnames and hence are classed as objects, otherwise it wont work.

P.S. I'm asking for a second opinion from my tech guys @ work.  They think it's something to do with the hint command that you were getting a return from hint format ["%1", getpos _tree select 2]

[h-]

And works just fine... ??

Of course the unit won't go to the tree or bush if you use the position straight off because for example a tree will return an z axis of 8 meters so the unit can't get there...
(like I said earlier.. about the z axis, that is...)

Try this in your radio trigger, and place another unit (man) on the map called dude:

Code: [Select]

call {_obj=(nearestObject [(position player select 0)+4*sin(direction player),(position player select 1)+4*cos(direction player),position player select 2]); hint format ["Object: %1\nPos: %2",_obj,position _obj]; dude doMove [position _obj select 0,position _obj select 1,0]};

[paddy]

Tried it and it failed.  Dude, I got this checked out.  Getpos WONT RETURN A VALUE IN A CORRECT FORM TO ANOTHER COMMAND OFF A P3D FILENAME!!

The tech guys think the value returnd by the hint format is something to do with the p3d file itself, and not the object

[h-]

Works in my OFP as we speak....
With setPos, doMove........

I attached an example mission..

EDIT:
Or maybe my sleep deprivation makes me misunderstand you all the time ...

[paddy]

Have no time (or energy) to test but will get bac 2 u asap.

[Terox]

you cannot return a "Typeof" for an object placed on an island during the islands's construction

thats where the problem lies

Try debugging this by using a nearestobject command and trying to return a typeof variable in a hint format, it returns ""

You can do it for an object placed there by a missionmaker


The only way to work around this, is to create a "vegetation" array of object id's, which would be a very big array and take hours to do

The problem with that is, you need an array for each island and also, if that island is updated, the object ID numbers change



so unfortunately, this is another OFP limitation....

mmm just had a thought

when you try to return a typeof,  on an object ID, it doesnt return an error, it simply returns ""

so perhaps what you could do is

tx_bush1 = typeof (object xxxx)
tx_bush2 = typeof (object xxxy)
tx_bushes = [tx_bush1,tx_bush2.... etc etc]

and then, it may be possible to use nearestobject and query if that object is in tx_bushes
... perhaps (but that would only work for the 1 island)

[Planck]

I can confirm that bushes and trees are definitely objects as they are P3d files.

As they don't have an entry in the game config they have no classnames.
But they are still objects nevertheless.

Any object properties for these objects are derived from the P3d file itself instead of a config.
After all, they are static objects that are only required to fall down or get crushed by tanks and such.......in most cases.

Every bush and tree on an island has an object number, which can be used to reference any individual tree or bush.
This requires you to know what the object number of any particular tree or bush is beforehand.

The object number for any particular tree or bush can be used to get its position, which will never change unless you edit the island and move it, however once you do that and save the island, all the object numbers on the island will then be re-done and may very well not be the same as they once were.


Planck

[THobson]

you cannot return a "Typeof" for an object placed on an island during the islands's construction

Hmmm.  Now I am stuck in a hotel room with no access to my system so this is from memory: I do remember, what feels like a lifetime ago but was probably 9 or 10 months I was looking for a way to find all the streetlights on an island and Blanco came up with a script that looped through all the object IDs checking the typeOf of the object and reporting on those that were of a specified type.  So typeOf does work, but maybe not for all types of objects.    Blanco do I remember correctly?

EDIT:

There you go:
http://www.ofpec.com/yabbse/index.php?board=8;action=display;threadid=20204;start=0

[Planck]

Streetlights have classnames, so it should work for them.

All derived from class "StreetLamp"

"StreetLampWood"
"StreetLampMetal"
"StreetLampPanel"
"StreetLampPanelAmpl"
"StreetLampYellow"
"StreetLampCut"


Planck

[THobson]

Ahh, so not all the objects on the map are created equal.  I suspected something like this when reporting on typeOf while looking for lamps and fuel stations.  Some typeOf results seemed strange and some were non-existant.

[Planck]

It can be argued that streetlamps are not completely static because they actually do something....whilst not moving
The same can be said for most buildings

Trees, bushes and other minor objects on the other hand just fall over or get crushed.


Planck

[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??