The problem is that figuring out how to adjust it changes from one model to another. If you look at the complexity of the contingencies in the functions you will see what I mean. I was thinking of adding user parameters that would adjust what the function looks for but I found that that would require about 10 to 15 parameters. Instead I made the test as general as required for standard BIS models for forests and objects. If there is some increased interest and I find that many people need it adjusted for non-BIS forests/object models, then I probably would try to come up with an instruction. More experienced scripters/function writers could probably do it on their own by examining the functions to see how the checking is done and adjust the numbers as needed. The toughest part was jumping around all the BIS islands and testing each type of tree, forest, building, fence, etc's. As you know there is no getHeight function in OFPEC, but I did find that larger objects tended to have a greater distance to their getPos positions. In other words, if you get the position, then set a game logic at that position then check the distance between the game logic and the object, there is a greater distance with tall objects than small objects. There are some anomolies and these are handled with special if-then tests. Anyway, this same thing could be done with non-BIS models to either "fit" them in to existing checks, or to add special contingencies to check for these. Also, I could maybe add and array parameter where if an object type is in that array, then it counts as dangerous to land on. One could make it an array of two dimensional arrays for the forest check, the first element being the type name of the forest and the second being the radius of that forest type. These could be optional arrays that are left off or blank if one has no special objects or forest types to check for. Yes, I think that would work! Then one would only need to find out the horizontal radius and type name for the troublesome object(s).
March 14, 2009: 7:32 PM
This idea will work for user placed objects/units for the overObst function, but forest and tree objects that are part of the map do not work with the typeOf or countType command, so knowing the type name of the forest will not help and using "forest" counType [_obj] does not work either. For this reason forests that are integral to the maps must be determined mathematically by discovering the typical "self distance" and radius size of those forest models. The "self distance" is found by placing a game logic at the getPos of the forest model and then finding the distance from the game logic to the forest. With BIS forests it will be between 6.8 and 6.9 for Nagova diciduous tree forests, between 10.9 and 12.5 for most evergreen forests and greater than 13 for evergreen forests set on steep slopes. I have begun to test some jungle forest on the Hawk Vietnam islands.