Detect if object/unit is over/in forest?

[Raptorsaurus]

I am working on a helo evac script that need to detect the type of terrain over which the chopper must work.  I can detect steep slopes, I can detect if it is over water uing a function I wrote for detecting that, but I am at a loss as to how to detect if the chopper is over a forest area.  I was hoping to use the nearestobject command, but I am not having much luck with that, partly because forests are very large objects, and partly because there are too many different forest object types.  Any help is appreciated.

[Terox]

i imagine you need to know this so that the chopper doesnt try to land in trees,

so, what if you count all objects within the target area over a certain height
for both objects and buildings


good luck on getting it to land exactly where you want it though

[XCess]

check nearestObject in comref.

[TKC_Hubertus]

check nearestObject in comref.

He already tried nearestobject, but as he said, its too complicated to detect weather the player is in a forrest or not.
The best solution is to create triggers above each forrest. You can then use this command to check the players position:
?player in list forresttrigger1 || player in list forresttrigger2: player sidechat "I am in a forrest!"

[Raptorsaurus]

More precisely, what I am am trying to do is determine the mode of evacuation.  If the ground is level, land and pick up troops, if it is steeply sloped, hover low or lower a rope ladder (an addon I am working on), if over water, (to pick up suba divers) lower a ladder.  If it is a forrest, hover above the trees and lower a rope ladder.  I have the first three situations working quite well, but the forest condition is proving to be more difficult.

The idea of triggers is fine for making a particular mission, but since I am trying to make a general script that anyone can use on any island, the trigger method is not very practical.

[Planck]

I would have thought nearestobject would work provided the chopper was at 50 metres or lower.

Every forest model class is derived from class "Forest", so checking if the nearest object is of class "Forest" might work.


Planck

[THobson]

I haven't checked (I am in the office!) but I think the distance limitation on nearestObject will prevent it from being an effective way of detecting forests because of their size.  

Time passes

But the more I think about it the more I think Winston Churchill's comment about democracy applies here.  It really is not a good system, but it is better than any alternative.

To do this generally I would look at doing the following:
1. Find all the different types of forest objects.
2. For each forest type - find its dimensions
3. Put all the above information in an array, or arrays.
Then to do the check in mission:
Move a GL at ground level to various places (a 40 by 40 grid possibly?)around the location of the chopper and see if nearestObject detects one of the forest types.  If it does then using the known dimesions of that forest type work out whether the chopper is over it.

Actually that is quite do able - but a bit of a pain to create, especially since nearestObject only detects object that are quite close.

[Planck]

I don't think there are any "Forest" objects that are bigger than 50 metres in size.

I think the maximum size of the largest forest objects are 50 square metres.

As any forested area is composed of many forest models placed close together, you will at any given time be closer than 50 metres to at least 1 forest object........maybe  ;D


Planck

[THobson]

Well that would make it easier, you would just need to be careful to ensure the check is done at ground level to allow for the chopper to be flying at any height.

[Planck]

Hmmmm.....I think not...........If the chopper is higher than 50 metres, wouldn't nearestobject fail?

After all, I think it is the chopper performing the check.


Planck

[THobson]

you would just need to be careful to ensure the check is done at ground level

 by putting a gamelogic there and using nearestObject on the GL not the chopper

[456820]

why not make some triggers set to repeatedly activated when the chopper is present. Then
On activation : Chopperoverforest = true
On deactivation : Chopperoverforest = false

That way in a script you just need to check if the variable is true if it is you can move onto a nother part of the script if its not exit or wheatever you want

[THobson]

456:  I think he wants a general script that will work with any map.  So triggers just won't do it.

[Raptorsaurus]

I've been playing around with nearestobject using a test script that finds the nearestObject to a map click.  In so doing I have discoverd something interesting!

If I place a game logic right at the location of the nearestobject, then do a distance check from the game logic to the object I do not get zero distance (only a road object yeilds zero distance)!  If the object is a tree (fatal to a chopper) the distance is in the range of 1.5 to 7 meters (1.5 for small trees and 7 or large trees).  If it is a forest, the distance is between 11.9 to 12.3 m.  If it is a structure it is 2 to 3 m (except for one type of building that is about .4 m).  If it is a bush (harmless) the distance is about 1.123 m.  So basically, if the nearestobject is <NULL-object> (bareground) I can then test for the ground slope to determine of landing is OK.  If it is not <NULL-object> I just have to check the distance to a gamelogic placed at the object's location.  If the distance is 0 then it is a road and landing is OK (if the slope is minimal), if the distance is > 1.4 then the object is a tree or forest or building and so landing is not permited, if the distance is > .3 && < .5 then the object is that one building type (AAA550) so again no landing.  Using this method I can determine if any harmful objects are within the potential landing zone without sorting out all the possible object types.  Thanks for all your suggestion, if not for the suggestions I would not have done the experiments that lead to this "distance vs. object type" discovery.  Problem solved!

[THobson]

You say problem solved just after raising a point that may well be worthy of discussion in the Advanced forum, namely that if you move a gamelogic to the location of an object and then check the distance from the object to the gamelogic you get a non zero result.  So I hope you don't mind I briefly unsolved this thread to make this post.

This is an interesting ‘feature' of OFP.  If you place an object on the map (it is particularly evident with a ‘wire' object but it applies to many other objects as well).  Call the object obj then the instruction:

Code: [Select]

obj setPos getPos objwill result in the object moving a non-trivial distance.  A wire object will move about half its own length sideways.  I am grateful to Macguba for pointing this out to me.  Set up a repeating radio trigger to test this.  It is amazing.

Also if you create a weapon holder, carefully get it to where you want it and then change the direction it is facing it will move sideways as well as changing direction.  

My mental model for understanding all this is to think of an envelope with a stamp on it.  The envelope is the object you place on the map and the centre of the envelope is at the location you specified, but the stamp is what you see in the mission and the location of the stamp is what you get when you do a getPos.  For some objects the stamp is placed near the centre of the envelope and for others it is not.

[Raptorsaurus]

I certainly do not mind! I have also observed the phenomenon you are describing.  However, I think in this case there may be another explaination (or it could be a combination of both what you say and another factor).  I have noticed that some models do not have their "origin" at ground level, so the distance from the game logic to the "origin" of the model may be the value I am seeing.  But, I have also observed that repeated runnings of the script on the same object will yeild varrying distance results (up the thousandths decimal place and occasionally even to the hundredths).  This may be due to the phenomenon you are describing.  I am giong to examine the models for trees, bushes and houses to see if the distance value I see is equal to the offset between the ground contact and "origin" in those models.  I will PM you what I find.