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