helicopter unload

[inferno7312 0]

I built a mission created a helicopter carryed a group of soldiers and unload them on unload point.

But the helicopter the altitude was so high that some of soldiers was wounded when they got out of the chopper.

is there a way to low the Helicopter when it unload the soldier?

I do remember I read a post about this question. But I can not find it again.

[Serclaes 0]

This will help

click me!

But if you just let the "GET OUT" in the waypoint options it should usually work Oo

[-SPA-LynxEye 0]

I don't know if this is the place for this, my question.

How to cancel the command 'FlyInHeight' ?

It means... If never we are using that command... dunno if we can manage/control the height of a vehicle in another way... but...

If we are using that command in a script for the very 1st time (in the script) attached to a certain vehicle/vehicles...

It seems like we are 'attaching' the control of the altitude of the vehicle with that command (flyinheight)...

Then i think 'flyinheight' is the owner of the altitude of the chopper (maybe near the 80% or 90% of most cases).

If this last is not wrong (or wrong at all)... as 'flyinheight' can't move an airvehicle below '20 meters altitude' (ASL? Normal?)....

HOW TO CANCEL THIS COMMAND WHEN WE STARTED TO USE IT TO CONTROL A VEHICLE?

This is my question. Sry the caps, i'm not shouting.

The questions means:

If we 'start' to use the command 'flyinheight' with a vehicle, how can we 'dettach-cancel-abort' that command, to 'give-the-freedom' again to the vehicle?

So.. maybe we can control the altitude of an air vehicle, but only during a 'trip' (flight?, route?)... then, once the air vehicle reached some coordinates (or waypoint... trigger... etc) we can 'cancel' that FlyinHeight and now we can start to 'handle' that chopper in another way to make landings or whatever we want.

Sry the long post. I have to say the same in more than 1 way to ensure you understanding me... my lack of English...

[inferno7312 0]

I try to use "FlyinHeight 0", but it just crashed after unload.

[-SPA-LynxEye 0]

Not always "0" altitude means the ground.

Because ArmA is more 'real' than a integer value of altitude.

I noticed sometimes, real altitude of objects-in-ground with reference to the 'real ground' is not >= 0. Sometimes is negative altitude.

Why?, i think, ArmA, not always is 'glueing' boundaries of surfaces,elevation... sometimes i think that i'm seeing some 'points' out of control, but only for a few 0.XXXXXXX meters, even 0.00000XX meters of difference.

I suppose ArmA is translating with not 100% accurate maths a 'rounded-Earth' to 'flat-Earth'.

And i am understanding why... maybe if BIS making perfect this maths... then this is not a playable game... it will be a 'science-based' game.

And then... we need a NASA computer to play this. And ArmA will cost thousand dollars... you know what i mean. Yeah, i think the price of this game is so cheap, compared with the 'power' that is showing us all. Just a comment.

Thx to the competitive-market.

I prefer a not 100% perfect maths-based game.

Sometimes humans need errors to enjoy the life. If nobody is falling into ground in a comic way... not the Earth, not humans inside. You know what i mean.

If you never seeing in ArmA... a flying tank... or certain issues... lol... ArmA has a very good balanced reallistic-playable ratio. It's my think. (thought?)

This last showing you that altitude is not a perfect concept in ArmA. But is not 100% wrong.

Solution:

Just check

http://community.bistudio.com/wiki/getPos

So: to solve your problem you have first to experiment this: (i think)

1st. What is the altitude (not only as integer value, like 34.26782 meters, you know what i mean) with the command getPos. The 'position 2' of the array returned by getPos is the 'Z', the ArmA-altitude respect the nearest object (surface) below the chopper (below in a vertical metered coordinates from the center of main helix in UH60, as example, just like a vertical laser from center of helix to nearest vertical (100% vertical, as the gravity concept) object-surface.

OK, you now know all the time the 'real' altitude (normal one, not ASL) between 'ground' and 'your chopper'.

If you putting FlyInHeight to "1", probably you will be keeping safe the chopper near 99% of times... because...

a) You are 'absorbing' that ArmA-error (maybe not an error ) referring ground as 1 meter, not 0.

b) at 1.000000  meters over the 'nearest ground/surface'... the unload is 100% safe.

Players/AI, ejecting at 1.000000 meters... never being wounded (nor adding damage to his actual damage value).

Still i don't know if the value 'altitude' in FlyInHeight is referred to ASL, normal (like getPos) or its just the 3rd altitude reference of ArmA, as i never tried to script with AI inside a mission.

So:

Case altitude is ASL:

- Obviously you are understanding now (if my theory is not wrong), why a chopper is 'crashing' to 0 meters. Because the chopper is trying to 'land' at 0 meters sea level... trying to land 'THROUGH' the ground, not AT the ground. So, as ArmA is detecting that 'CRASH' of boundary coordinates being 'mixed', ArmA will 'crash' your chopper. As you all the time trying to move the chopper 'under' the ground, ArmA, soon or lately, will 'damage' your chopper.

Case altitude is normal:

- behaviour so close to previous one. As i explained (from my theory, not from facts) sometimes the 'viewable' altitude at 'ground' level is not "0" meters. Maybe is not always a 'negative' value... Maybe is more than "0". As example: "0.243765" meters. Then, mathematically, with "FlyInHeight 0" , you are trying to put the chopper inside the 'ground'... because "0" meters is 'appearing' to be < than those "0.243765" meters. Then, again, ArmA will damage (probably till death, your crash) your chopper. Because, in both cases, you will be mathematically trying to 'crash' in the ground, just like a normal crash between a car and a wall, but changing his axis.

Car-Wall mostly of times is horizontal axis, and choppers-Ground... is vertical axis. No matter which axis or group of axis... a crash is always a crash in ArmA.

In the Car-Wall crash test... if you not trying again to crash the car... the damage will be a stable value... but now... translated to the Chopper-Ground crash test... the command 'FlyInHeight' will be the only one 'driver/pilot' that will try (as a no-head-guy) to 'move' to that 'altitude'.

This means, more or less:

- The chopper will crash because (really, under your script) you ordered it. Blame it on 'FlyInHeight' command, such a 'fatal' order.

Less blah blah blah from me, and more solutions (i hope useful):

- Never try to use "FlyInHeight 0", just try upper value. Try 0.5... it depends in your tests over your surfaces-as-Landing-Point in your mission/missions.

With 0.5 as altitude, probably, never you will be adding damage to chopper.

If not 0.5... try upper ... i think limit is near 2.5 meters (soldiers ejecting, starting to be wounded from near 2.5 meters altitude, like a too high jump).

So, you need first to test your 'magic number' of altitude, to make a perfect "FlyInHeight" landing.

As example, altitude over sea (but really only when vehicle is over the sea), is not an stable value... blame it on the 'tides'.

Maybe altitude referred to ASL style, when vehicle is over the real water, is not a stable value, and maybe, when the vehicle is over 'ground', ASL altitude is stable value. Dunno.

Maybe ASL altitude of a vehicle in ground, is still 'dancing' , because... maybe, there isn't a stable value of "0 meters" in the sea. Maybe "ModeltoWorld" has the true light. I suspect that the origin of the altitude in ArmA, can be found under the sea... maybe in the real center of the ArmA-Earth. Dunno, i'm not interested to research some 'truths' of ArmA. At least, not at this level.

In 'ground' surfaces, there is not the 'tides'... but the altitude of the chopper is not an stable and perfect value... so... now... the chopper altitude is like 'tides'. Check the altitude of a chopper when chopper is hovering... never stable value, just moving with certain 'undulation-wave motion-wave' (auto-extinguishing loop from minimum value to max value, just like 'tides', maybe not always extinguished at all... maybe never altitude can be a 'frozen' value.)

Because of the 'air' behaviour of vehicles... i think you can't use 100% of times... FlyInHeight 0.

If ArmA is not perfect, add/remove its 'error/s' to your maths, to make your script, PERFECT... and then... you will see... a perfect ArmA. Simply a "Perfect-ArmA version inferno7312".

Another note to normal altitude (such shown under getPos).

Example:

Chopper over the roof of a 'yellow' gas station (banner 'Schnell', german joke: Shell is English, Schnell is 'fast-quickly-go go go' (correct me if i'm wrong, german scripters)).

That gas station is a "building object".

If the chopper is over 5 meters above that roof (roof? top side-place of the gas station), as the 'height' of that gas station is near 7 meters (who cares in this example), maybe you are thinking that "'getPos' select 2" (altitude) will show you 12 meters... nope... it will show you 5 meters.

Because 5 meters is the altitude to the nearest 'ground/surface' point.

In that case, the nearest 'ground/surface' is the 'top' point of the roof, 100% perpendiculary metered to the 'origin-coordinates' of the chopper.

So... not always "FlyInHeight 0" means land at ground... just open the eyes of the AI pilot with a little bit more maths hhehehe... if not... AI will be not AI, just another Blind/Stupid-NotHuman-Soldier.

As AI has no eyes... your maths will be his eyes... perfect maths... perfect eyes... 50% perfect eyes... AI will have 'no glasses' in his eyes. Just like a human 'driver/pilot' controlling a vehicle without eyes and ears... create his 'senses' with your "easy maths".

Another tip:

Quote[/b] ]Dr_Eyeball

getPosASL obj select 2

might sometimes return the vertical position above sea level, but over land for stacked objects, it returns the vertical position above the object beneath it or at least affected by this offset. The same problem exists for getPos. There was a discussion thread in the BIS forums which suggested the use of the command modelToWorld instead to get around this issue where an absolute vertical position is required. ArmA Ver 1.02.

Check this in Wiki: getPosASL

Dunno if this last was checked in 1.05.

Research time...

Still i'm thinking that the use of 'FlyInHeight' can't help others taking mistakes of concept.

But... if BIS don't giving us more options to control the altitude of certain vehicles... 'scripters' have to make more 'work' to control perfectly a landing, in all cases, all surfaces, all terrains, all altitudes...(maybe you can control the altitude of a parachute (as object, don't think parachute as player or AI) with FlyInHeight... because 'parachute' is "Air" class 'vehicle'.  

I also forgot one FACT:

If we are thinking that the altitude ASL or normal in the side of a vehicle... is metered from its lowest point... maybe yes... maybe not... maybe some commands is referring 'altitude' from a center point (real origin of coordinates) or just only from the lowest point.

http://community.bistudio.com/wiki/boundingBox

Maybe this last command can SOLVE ALL of our altitude issues...

We can 'remove' (opposite calc of 'add'?) ASL Z from boundingBox minZ and maxZ...

This concept:

_test1 = (vehicle ASL Z) - (vehicle maxZ)...

if _test1 < 0 ... the ASL reference of altitude is not taking into account the maxZ...

if _test1 = 0 ... the ASL reference of altitude is exactly taking into account maxZ as the origin of coordinates of the vehicle.

if _test1 > 0 ... the ASL reference of altitude is... simply... strange   . Well, if ASL reference is greater than maxZ, then the origin of coordinates that ArmA is referring with ASL altitude... is over the vehicle, not inside it Bounding box. Just over it.

If we test _test1 but changing MinZ by MaxZ... if (ASL - minZ) <

Now we can repeat the test, but changing maxZ by minZ.

And when this test is finished, repeat this first 2 tests with normal Z, not ASL commands.

Then... probably... we will be able to write in Wiki or here, the forums... the truth of the altitudes in ArmA... needing to be checked in tests more or less like these... with ALL the commands that is handling info about Z axis (altitude, height,depth...)

I know i'm mixing ASL coordinates with ModelToWorld coordinates/references... but people who want to make tests... sometimes having to make some hard work.

Maybe ASL is so difficult to be tested... only with 'floatable' vehicles... boats... but APC's can bring us some interesting info about in this tests. Or cars/trucks/motorcycles... keeping all the time the damage of the vehicle to '0'.

Probably its easier to use this tests, changing ASL by normal Altitude... and testing it with the lower-height possible vehicles.

IN THIS TESTS, ALL VEHICLES BEING TESTED MUSt TO BE LANDED.

In another words... if we can 'reach' the "origin point of coordinates" of all vehicles... we can test the 'quality' of the commands using info about axis X,Y and Z.

So we can 'correct' some issues if we can 'handle' some easy maths to add/remove a little from some 'real' values... This last is... 'tunning' the scripts to the 'reallistic' ArmA behaviour.

Closer we can... more perfect (and less headaches) we will do.