Proper landingzone

[Garcia]

Is there some way to actually get a chopper to choose a proper landingzone without defining it yourself in the editor? What I want is having a unit placed anywhere on a island, then create a chopper to pick the unit up and then drop him off somewhere else on the island. I've got everything sorted out except the landingzones. I don't want to place different LZs on the map in the editor so the chopper only lands at one of them. I want the chopper to land as close as possible to the unit, but not at a crappy LZ where it ends up crashing.

I've tried placing empty helipads at the position of the unit, but of course it didn't turn out well. The chopper didn't land in forest if the helipad was placed there, but it did land on trees if the helipad was placed close enough to a area where it could land or if it was placed in a area far from a forest but with shitloads of trees. I tried using only the land "get in" command, but that made the chopper sometimes land a few km from the unit, even though there were several places where it could pick him up, and the chopper still crashed in trees. Another problem is that the chopper got problems when trying to pick up a unit in a hill. The chopper won't find a flat area, and keeps bumping into the ground or hovering too high.

Anyway, I remeber the BAS MH47 having some sort of script that worked quite well. So I tried to find it, and I think I did. Problem is, it doesn't seem to actually be a solution, and it didn't work well when I tried it on a chopper in the editor, so I don't know why it keep working perfect when I use the MH47.

So, anybody got any ideas on how to make a chopper find a flat area to land and manage to keep away from trees? Of course, it also have to be able to land at a hilly area, just as long as the hill isn't too steep.

[Baddo]

Yabbididuu, hmm. Once upon a time I had a thought about this very same issue. I never got into making a solution (didn't need it actually) but I will tell you what I had in mind. I was thinking of writing a script which places invisible objects at ground level on an area big enough for the chopper to land, and then check the height of the objects relative to sea level. That way we could get a elevation "matrice" from the area and figure out from it if it is suitable for the chopper to land on.

Have you checked that silola's Dynamic AI Creator doesn't include a function/script to do such checking? I recall it has some sort of checking routines for checking where to place waypoints but I don't remember right now if there is one suitable for this situation.

Also the script should check for objects to not be in the landing area or too close to it. I think this can get CPU heavy  (like DAC)

I think that controlling the chopper precisely into the suitable landing area would require a setPos loop to force the chopper go into the correct spot. That should be avoided though, if possible.

[Mandoble]

May be this helps:

Code: [Select]

;helidescend.sqs by Mandoble
;Quick landing of helicopters
;Emergency climb if something is hit during descend
;then choose alternative descending point
;
;Arguments:
;helicopter
;Below this altitude the helicopter cannot do emergency climbs (landed or almost)
;Altitude to reach in emergency climb before moving to another landing point
;script to be executed when landed. This script receives the helipcopter as argument.
;
;Example:
;Heli1 will descend quickly to 0m
;If climb rate in descension is positive above 2m, heli1 will climb quickly to 50m and move to
;a different nearby location before trying to land again.
;[heli1,2,50,""]exec"helidescend.sqs"

_heli         = _this select 0
_safetyminalt = _this select 1
_safetymaxalt = _this select 2
_script       = _this select 3
#descender
_dmg = damage _heli
~1
@(unitReady driver _heli)|| (damage _heli > 0.9)
?damage _heli > 0.9:exit
;Lo bajamos a nivel de suelo sobre su posición actual
driver _heli sideChat "Descending";
_heli flyInHeight 0
driver _heli doMove getPos _heli
~1
#verificarrebote
_vel = velocity _heli
_pos = getPos _heli
;Comprobación de choque contra algo (rebote)
;No desciende por un momento, pero está a más de 1m del suelo, luego choca
? ((_vel select 2 >= 0) && (_pos select 2 > _safetyminalt))||(damage _heli > _dmg): goto "elevarseymoverse"
?damage _heli > 0.9:exit
? getPos _heli select 2 < _safetyminalt: goto "landed"
~0.01
goto "verificarrebote"

#elevarseymoverse
;Por seguridad, le paramos donde está
driver _heli sideChat "We hit something, trying again";
doStop driver _heli
_heli flyInHeight _safetymaxalt
driver _heli doMove getPos _heli
~1
@(unitReady driver _heli) || (damage _heli > 0.9)
?damage _heli > 0.9:exit
_ang = random 360
_pos = [(_pos select 0)+101*sin(_ang),(_pos select 1)+101*cos(_ang),_pos select 2]
driver _heli doMove _pos
~1
@unitReady driver _heli
goto "descender"

#landed
driver _heli sideChat "landed";
_heli action ["engine off"]
? _script != "":[_heli]exec _script
exit

I use it for quick descends over forests or cities without helipads.
The choper will descend quickly, ensuring that its climb rate (descending) is always negative, at least, above indicated alt. If the climb rate goes 0 or positive before, something has been hit (a tree or whatever), then the choper stops, climbs to safety alt, moves 100m away and retries the descend. You may provide also a script to be executed when choper is correctly landed.

What this script does not check is how flat is the terrain below the choper.

[Garcia]

Hmm, well, I've been thinking about the same way to detect if there is a too steep hill. I started working on a script now to check if there is a forest or not where the LZ is. Found a way to place a object in the center of a square (the square is as big as a square of forest) so I can place a game logic at the position where the forest would be if it's there. Only problem is, I didn't think of the fact that forests ain't defined in a config.cpp, so they got no classnames, and therefor I can't use nearestObject command to check for forest parts :-\

Anyone got a idea how I can check for forest in any other way? Or do anyone know how to get the nearestObject command to work without classname?

[Baddo]

Check silola's DAC. It's not the most easiest code to read (not much comments IIRC) but there should be such a system somewhere in DAC to detect forests because that's what he was claiming in some introductory pdf IIRC that waypoints are not placed into forest for vehicles.

[Planck]

hmmmmmmmmmm...........forest models do indeed have classnames defined in the config.bin.

Model name                                      ClassName            Description
---------------                                       --------------           --------------

les ctverec pruchozi_T1                    "Forest001T1"        Forest Square
les ctverec pruchozi_T2                    "Forest001T2"        Forest Square
les trojuhelnik pruchozi                    "Forest002"            Forest Triangle
O\Tree\les_nw_ctver_pruhozi          "ForestRes01"        Forest Square
O\Tree\les_nw_ctver_pruhozi_T1    "ForestRes01T1"     Forest Square
O\Tree\les_nw_ctver_pruhozi_T2    "ForestRes01T2"     Forest Square
O\Tree\les_nw_jehl_T1                    "ForestRes02T1"     Forest Triangle
O\Tree\les_nw_jehl_T2                    "ForestRes02T2"     Forest Triangle
O\Tree\les_nw_jehl_trojuhelnik       "ForestRes03"         Forest Triangle
O\Tree\les_nw_trojuhelnik               "ForestRes02"         Forest Triangle
les_su_ctver_pruhozi                       "Forest003"             Forest Square
les_su_ctver_pruhozi_T1                 "Forest003T1"          Forest Square
les_su_ctver_pruhozi_T2                 "Forest003T2"          Forest Square
les_su_trojuhelnik                            "Forest004"             Forest Triangle

Planck

[Garcia]

hmm, problem is I'm not gonna use this script in a mission on a official island, and the guy who made the unofficial island I'm using said the forests he is using doesn't have classnames :-\ Though now I can test if the script will work at all, so thanks

And I've looked into DAC, and I think it will take me ages to figure out something from that script

[Baddo]

And I've looked into DAC, and I think it will take me ages to figure out something from that script

Yes DAC files are obscure. A couple of comments here and there could do wonders... maybe the developer decided to remove comments from the release version. For example a header comment for every file to explain what exact functionalities the file has would be good for these kinds of massive script packs 

[Garcia]

bah...I've had a look at the DAC scripts that's placing the waypoints, and I think I found the coding that's supposed to detect a forest, though it doesn't work TBH I have no idea wtf the guy has been scripting...way to advanced...

anyway, I've been messing around, and I just noticed something. If I use the nearestobject command to check a position (_obj = nearestobject [x,y,z]), and set the z-value to a bit over ground (like 5 or something, since it seems the z-value of a forest is more than 0), I do get the classname...but I also get the damn ID number...

So, if anybody got an idea how to use this information, then please post your suggestions

If I could just get only the classname, then it would have been perfect, cause then I could run it against the classnames of the forests and then it should have worked...

gonna go have a look in the comref to see if there's something I may use from there

[Mandoble]

To check how flat is a terrain you may use the following concept:
a grid of moving particles is created, a group moving W->E and a second group moving N->S, covering the selected area.
At fixed intervals, the particles triggers a script with their positions, so it is quite easy to calculate maximum and minimum height over terrain for horizontally moving and vertically moving particles. Note that particles, once moving, will not change their altitude over sea level.

The good point is that particles may be transparent, so you check flatness of terrain without any visible object/effect.

Code: [Select]

;checkflat by Mandoble
;Arguments:
; Center of the landing area
; Lengh to the square to check
; How may checks per square side
; Marks transparent true/false
;
;Example:
; 100m^2 area-check in squares of 10 by 10
; [getPos logic1, 100, 10, false]exec"checkflat.sqs"
;
_center = _this select 0
_lengh  = _this select 1
_cells  = _this select 2
_transp = _this select 3

_tr = 1
?_transp:_tr = 0
;Adjust max time to increase accuracy
_maxtime = 5.0
_d = _lengh / (_cells - 1)
_delay = 1.0 / (_cells * 2)

_time = _maxtime / _cells
zinith = true
zinitv = true
maxzhelilandh = 0.0
minzhelilandh = 0.0
maxzhelilandv = 0.0
minzhelilandv = 0.0

_i = 0
_xh = (_center select 0) - _lengh / 2.0
_yh = (_center select 1) + _lengh / 2.0
_xv = (_center select 0) - _lengh / 2.0
_yv = (_center select 1) + _lengh / 2.0
_velh = [_lengh /_maxtime, 0, 0]
_velv = [0, -_lengh /_maxtime,0]
#detectors
_pos = [_xh,_yh,0]
drop["cl_basic","","Billboard",_time,_maxtime,_pos,_velh,0,25.50,20,0,[1],[[1,1,1,_tr]],[1],0,0,"dropposh.sqs","dropposh.sqs",""]
_pos = [_xv,_yv,0]
drop["cl_basic","","Billboard",_time,_maxtime,_pos,_velv,0,25.50,20,0,[1],[[1,1,1,_tr]],[1],0,0,"dropposv.sqs","dropposv.sqs",""]
~_delay
_yh = _yh - _d
_xv = _xv + _d
_i = _i + 1
?_i < _cells:goto "detectors"
~_maxtime
~1
hint format["Max vertical dev W/E:%1, Max vertical dev N/S:%2", abs(maxzhelilandh - minzhelilandh), abs(maxzhelilandv - minzhelilandv)]
exit


Code: [Select]

;dropposv.sqs
_z = _this select 2
?zinitv:maxzhelilandv=_z;minzhelilandv=_z;zinitv=false;exit
?maxzhelilandv < _z:maxzhelilandv=_z
?minzhelilandv > _z:minzhelilandv=_z
exit


Code: [Select]

;dropposh.sqs
_z = _this select 2
?zinith:maxzhelilandh=_z;minzhelilandh=_z;zinith=false;exit
?maxzhelilandh < _z:maxzhelilandh=_z
?minzhelilandh > _z:minzhelilandh=_z
exit

EDIT:
added position check script also at end of life of particles.

[Garcia]

Thanks mate, works like a charm. Now I just gotta figure out a way to detect that damn forest :-\

Think I'm gonna send a mail to the DAC guy. Anyway, since the damn editors depot is gone, anyone got that array to string or string to array (or both if there is both ) function? I could have some use of it.

[Mandoble]

Well, probably you should be concerned about any solid obstable group higher than 2 or 3 meters, not only forests. Groups of large rocks, buildings, etc would be as dangerous as forests.

Just an idea. If you set a small object moving diagonally through a square NW->SE and keeping its velocity vector updated every second while checking its speed, existance and damage you may easily detect forests (large area obstacles). More than probably, the moving object will hit an obstacle and decelerate or get damaged.

Code: [Select]

_ulcorner = _this select 0
_speed = _this select 1
_flighttime = 3
_strnull == format["%1",objNull]
_vel = [_speed*sin(135),_speed*cos(135), 9]
_object = "BulletSingleW" camCreate [_ulcorner select 0,_ulcorner select 1, 3]
_object setDir 135
;_object switchCamera "EXTERNAL"
_timeini = time
_timeold = time
_object setVelocity _vel
~1
#check
?(_time - _timeold) > 1.0:_timeold = time;_object setVelocity _vel
?(time-_timeini)>_flighttime:goto "endcheckok"
?(speed _object) < ((_speed*3.6)/2.0):goto "endchecknook"
?(damage _object > 0.0)||(format["%1",_object] == _strnull):goto "endchecknook"
~0.1
goto "check"

#endcheckok
hint "SAFE AREA"
exit

#endchecknook
hint "LOOK FOR A BETTER AREA"
exit


[Garcia]

Thanks mate, it works quite well. Only problem may be that the bullet hits the ground if it checks a sloped area, but I figure if you run the check twice with the second bullet starting from the other corner and going the other way (so if one bullet hits something, but not the other, then it got to be a hill, since the second should have hit the same object.)

[Mandoble]

Hitting sloped area is an advantage, the bullet object will be null after the hit and before end of flighttime which means you hit something bad for the landing zone (a tree, a rock, a hause, a sloped terrain with a terrain elevation higher than 3 meters, etc). I used a bullet for the script example, which has a limitation: bullet object is automatically erased by OFP engine 3 seconds more of less after the object is created. This is the flighttime maximum limit.

[Garcia]

Well, 3 seconds is more than enough, cause if I'm to give it a velocity that's low enough to not check a too large area in the 3 seconds, it falls to the ground it seems (at least it didn't work), so I had to turn the flighttime down to less than 1 second Gonna mess around a bit with the script to get it as close to perfection as possible.

[Mandoble]

Well, you need to compensate the gravity during flighttime and before the object is automatically erased. In a similar way as do the prototype script, try to update the vertical velocity component periodically. While testing, I would use "Shell73" instead of the bullet object, so you have more flight time available and uncomment the switchCamera line to follow the round while moving.

[Raptorsaurus]

Just before OFPEC went down I started on a script (suite of scripts and functions) to do this.  I've been waiting for OFPEC to be back to submit this.  The scripts and functions have descriptive headers, but if you have any questions just let me know and I will be glad to help you implement it. Here is what it can do:

Finds an LZ of a size you specify, in a search area you specify, with a slope that you specify.  It also makes sure the area is not in forest, not over water and not over other obstacles (buildings, trees, etc.).

To use it just put the Find_LZ folder in you mission folder, then in your init.sqs put this line:

[] exec "Find_LZ\find_LZ_init.sqs"

Once the Editor Depot is up and running I will submit a more formal version with a test mission and all.

Also, I made a script called fastland.sqs that forces a chopper to land where you want.  So you can use the above to find the LZ , then use fastland to make the chopper actually land there. It is not in this folder and I cannot find it now.  I will search for that tomorrow and add that as well.

See post below for newer version of find_LZ

[Garcia]

Thanks mate, but I did read your topic, and if you still define if a unit is in a forest or not from how high the object is above ground (difference in height from object to a another object that is placed there) I'm afraid it won't work. I also noticed the difference in height, so I ran a random loop to see how high certain objects are over ground (did this on a none-offical island). It showed that the forest parts used was from 0.4 m to 40-50 m above ground, while other objects were from 0.1 m to 18 m above ground :-\ On the island I most likely will need this it won't work too well. Though, I will try the script and see how well it works later on...too tired ATM

[Raptorsaurus]

I found a new way to determine if a unit is in a forest.

The find forest function does not use altitude to determine a forest.  Rather it uses the distance to a gamelogic placement.  It so happens that when the game logic is place at the location of the forest, the distance is always in the range 6.8 to 6.9 for the small tree forests and in the range 11.9 to 12.5 for the large tree forests. I am attaching the find_LZ folder, this version now has a demo mission. Also, it include the fastland.sqs script which will make a chopper land precisely where you want (even in a bad area if that is what you want).

What island are you using?  If it has new forest models, then I can modify the find forest function to work with those models as well.

[attachment deleted by admin]

[Garcia]

Using A Shau by Hawkins, but it's not released yet :-\ I'll give it a shot today and see how it works. Thanks mate

[Garcia]

I've just tested it, and it won't work. I edited the overforest function to give back _cdis and put it in a hint. First of all the difference it gives back is usually 4.2 or 19.2, but it's sometimes 3.3, 0.3, 0, 11 etc. It changes too much to really be able to find a good spot. I tried putting new numbers into the function and check. It worked good in hilly areas, but it doesn't work at all on flat areas. There it gives back forest as a proper LZ because _cdis is either 0 or 11. If it was just 11 it wouldn't be a problem, but when it's 0 too, it won't work, cause then the script will think flat areas are forest too (or that forest is a good landingzone).

[Raptorsaurus]

Sorry to hear that it does not work with that island.   I tested it on all the BIS islands and it works fine.  Maybe there might still be a way to make it work.  I wonder why the values vary so greatly?  Maybe examining the actual forest models would help.  Do you know what forest models are used? I would like to have a look those and the island as well. I designed the overforest function by examining the BIS forest models.  That is why for instance the _z value is 18 in the nearestobject check, and why 36 is added to the user entered _rad (to make sure even areas near the edge of the forest would still be counted as overforest).  If the forest models used on the island are smaller or larger, then the search algorithm may have to be adjusted accordingly.  I would make the current function a check for BIS_forests and the new function a check for A_Shau_Forests.

[Garcia]

I'll send you a message (if I remember) when he releases the island. I think all the forest parts he's using is custom made and not yet released. So you'll have to wait for the island :-\ One solution to why the z value vary so much may be because he's placed these grassfields at the same spot at the forest some places. The forest I checked and got 0 back had grassfields in it (I think).

The forest parts are 50*50 m. I changed the _rad a bit to make it set the LZ outside forests in the areas it did work.

[Raptorsaurus]

The grass in the forest should not bother the function.  That is why I do a nearestobject at 18 m above ground, that way, the forest is always closer than stuff on the ground.  But if the grass and forest models have their origins the same distance from the ground, then that could be causing problems.  There is another completed A Shau Valley island at OFPNAM.com that has very high user ratings. Just for kicks I am going to test that island. If it works on that island, maybe you can use that one instead of Hawkins?

[Mandoble]

Raptorsaurus, independently of the result (working or not) of the script, the idea itself is EXCELENT.

[Garcia]

hmm...I dunno wtf was up yesterday when I tested only the overforest function...it seems to be working ok now. I changed the value in the function to be in a forest if _cdis was higher than 10...seems to work fine now. Though I have to find a proper _rad now. Not 100% happy. It seems to ignore good LZs because they're too close to the forest. So gonna fiddle around with that value. Though I got 1 problem. Since this is a vietnam island, there's shitloads of forests here. So when I search for a LZ in the middle of the jungle, it doesn't find a good LZ (thank god ), but after some time it stops searching and "finds" a LZ somewhere long away from where I wanted the LZ, and sometimes in the middle of a forest. So what I need is to know where I can tell the script to actually search until it finds a good LZ, so it doesn't timeout and just find a LZ on a random spot on the map

[Raptorsaurus]

I am glad it is working a little bit better.

The default search radius is 300 m in the AIland.sqs in the demo mission.  The way it currently works is; if no LZ is found in the original 300 m rad, then it searches in the next 300 m radius area centered at the choppers current circling position (the chopper circles the area while searching for an LZ. It repeats this until an LZ is found.  The best thing to do is find out what the worst case radius is (for the largest forest area) and then use that value (+ a little extra) for the search radius.  Also, with the Black Hawk chopper, you can get away with 15 m radius LZs so it has a better chance of finding LZs between non-forest trees and ground obstacles.  This will also help it accept areas close to the edge of the forest.

Last line of AIland.sqs:

Code: [Select]

[_craft, _pos, _LZrad, 8, 300, _mk, _code0, _cond, _code1, 3, _code2, 0, [_leaders, _units] ] exec "Find_LZ\find_LZ.sqs"
change 300 to 500 or whatever you find necessary:

[_craft, _pos, _LZrad, 8, 500, _mk, _code0, _cond, _code1, 3, _code2, 0, [_leaders, _units] ] exec "Find_LZ\find_LZ.sqs"

In the search_LZ_map_click.sqs change the last line:

[chopper, _pos, 20, [player], _mode, "RPT_LZ"] exec "AILand.sqs"

to:

[chopper, _pos, 15, [player], _mode, "RPT_LZ"] exec "AILand.sqs"

Also, in the overforest function, you might want to change the value that is added to _rad (at the begining of the code body) I add 36 to whatever value _rad has.  I did this to prevent the chopper from landing on the corrner of the square bis forests (the worst case corner to center in BIS forests is 36 m).  If the Nam forests have more rounded edges, then you might be able to change this value to 25 (for 50 m diameter round forests that should work fine, but play arround with the value).

Change this line in overForest.sqf:

_rad = (_this select 1) + 36;

to:

_rad = (_this select 1) + 25;