Change aircraft altitude mid-flight

[mad rabbit 0]

Is there a way to alter the altititude of an aircraft mid-flight temporarily, without the altitude setting being permenant?

I am mainly working with helo and have tried using:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

_helo doMove [x,y,z+120]

however this does not seem to work.

I do not want to use 'flyInHeight' because that locks the helo into using that altititude for the rest of the game, and setPos is way too unrealistic.

[bn880 5]

play with setvelocity, you just need to script it properly

[mad rabbit 0]

Thanks for the reply bn880 CoC guys!

I've looked at this command before and to the best of my knowledge this will only alter the z-axis speed of the aircraft and not make it increase or decrease it's altitude to the desired height.

Therefore if this statement is correct, this command wouldn't work as it would make the aircraft get to the desired altitude faster or slower, as determined by the z variable in the setVelocity array, but setVelocity would still not address the problem of telling the aircraft to climb/decend to that altitude. right?!

[bn880 5]

Well it's like this:

1. flyinheight does what you want it to except it is permanent

2. there is no command to give to AI to get lower and then cancel it

therefore

3. AI is unable to help you, at least in OFP1

4. setvelocity can change the Z velocity of the aircraft to anything you want

therefore

5. you can use setvelocity however you wish to attain the desired AGL

6. it's not easy; a small physics problem

You can't squeeze anything more out of the AI without using flyInHeight, be happy flyInHeight works at all

[-STO-Badblood 0]

Is there any reason why you can't use a script or series of triggers to set the FlyInHeight command up then use FlyInHeight to set it back down again ?

I haven't tested this - just writing it on the fly (no pun intended   )

Script launched by a trigger:

Call line >> [PlaneName, TempHeight, TimeBeforeReturningToOrigninalHeight] exec "changeheight.sqs"

changeheight.sqs

;// Keep it on server (may not be needed - need a logic object called server to use this line)

?!(local Server) : exit

;// Get the passed varaibles

_plane = _this select 0

_newheight = _this select 1

_timeReturn = _this select 2

;// Get current height

_returnHeight = _plane getpos select 2

;// Make it fly in the new height

_plane FlyInHeight _newheight

;// Wait for the time to elapse

~ _timeReturn

;// Return to original height

_plane FlyInHeight _returnHeight

exit

Note: The script assumes the plane is flying at the correct height when entering the trigger

[mad rabbit 0]

I'm working on a CTI map so I've got scripts coming out of my ears!

The whole needs to be dynamic which rules triggers out (mainly due to assoc setPos problems with triggers = another thread).

I'm executing the command within a Paradrop script so the altitude needs to be low enough en route to avoid the radar system employed in the map but high enough during deployment at the DZ so the Paratroops don't die.

Now your probably thinking, why don't I just use flyInHeight at lets say 60 en route then 100 deploying then 60 during retrun to base.

The reason is:

I've been doing a lot of investigation, within the context/scope of my map, into the helo pilot and gunner AI as I've got the whole system wired in the map with a nice GUI, different options etc. This system also applies to the CAS scripts I have.

I've gone with the philosophy of working with the inherent AI (e.g. using 'doMove', 'doStop' etc) rather than trying to fight it (e.g. 'disableAI', flyInHeight). Now for the CAS scripts I've tweaked it so it all works great, or at least to my statisfaction.

The reason being is I stopped using some of the CAS scripts out there which adjust the helo altitude via flyInHeight and in my belief/experience interfere with the helo 'engagement' path. With the script I got I basically get it to go there, reveal the targets above a certain knowsAbout lvl and let it run-a-muck on 'RED' and 'COMBAT', whilst making sure the helo stays relatively within the AO.

This also pertain to the MG on the Paradrop helos as the gunner will not engage properly during an extraction script if you've messed with the helos altitude i.e. used flyInHeight. Therefore, again in my experience, during an extraction the helos gunner on a mounted MG provides better cover fire if the helo is allowed to decend on its own terms.

This is why I'm trying to avoid using flyInHeight if possible and I was also curious to the application of the doMove command as the aircraft obeys the first 2 parameters within the array you send it i.e. x and y, but ignores the z.

To quote bn880:

"...be happy flyInHeight works at all..."

Disclaimer: This is based on my testing within my map, others may have had different experiences as I have read (feel like I've read the whole forum by now!), but again I say go with what works best, looks good and realistic but fair.

[mad rabbit 0]

Just been doing some more tetsing with the scripts I've got.

It seems 'flyInHeight' interferes with the 'LAND' command issued to the helo, again at least in my experience.

I've tested the non-flyInHeight script, where the paratroopes become pancakes (helo altitude too low for ejection) vs the pro-flyInHeight script, where the helo is at the right altitude for paratrooper deployment but the landing script snnipet that worked earlier now no-longer works.

Will do some more tweaking/testing but this appears to be the case in terms of the helos landing flight path.

[-STO-Badblood 0]

Never knew flyinheight had these problems - good to know. I've only used it to get a helo or plane fly a course without combat.

Would like to read more about it - anyone have a thread link?

[mad rabbit 0]

Sorry to say mate I don't have any direct links to this behaviour as it is based on my testing. If others can confirm or discredit this that would be great as I think it needs to be looked into a bit more.

Most of the links I read up on in OFPEC and BIS Forum were in relation to the AI helos ability to engage infantry.

From the reading I did 3 main things contribute to this:

1) Infantry rating.

2) Helo combat mode, behaviour mode and skill.

3) Helo altitude.

Now for the (1) I can't alter it and don't want to as I believe the more an enemy kills your troops off the higher priority he should become. In addition I want helos to engage tanks first which they do, and I already have a knowsAbotu threshold loop within this CAS script.

For (2) is easy to set and I alter between 'RED' and 'COMBAT' for enagement and 'BLUE' and 'CARELESS' to disengage and return home.

Now (3) again from my experience is effected by flyInHeight. I tried scripting the whole patrol route within the AO using flyInHeight and positional control (doMove) but found that the helo kept trying to make it's own flight path due to the 'RED' + 'COMBAT' setting. It also was less efficient at enaging tanks and did not fire TOWs from far away on most occassions.

So as I said earlier instead of fighting the AI I let it run-a-muck i.e. got it to the area, set it to 'RED' and 'COMBAT' then let it chose it's own engagement flight path with a reveal infantry loop based on a knowsAbout threshold in the background. This seems to works best in my experience, the helo even used rockets against infantry in some cases.

Another thing I found that effected helo inf engagement was:

4) Helo weapon selection.

An Mi-26 HALO with a PK is a behemmoth of a helo but is more likely to engage and kill inf due to the fact that it's only gun is the side-mounted PK. This is contrast to the Mi-24 Hind which will fire missles etc at tanks but pretty much ignore infantry, even with the reveal loop. Funnily enough the Mi-24 Hind chooses a flight path that crosses over the inf all the time. The Mi-28AA will engage inf a lot better than the Mi-24 due to a more rotatable cannon turrent and lack of AT missles.

Funnily enough the helos that best engage inf are also the only ones which are fired upon by an MG inf !

Again further tetsing by others would be great to confirm or descredit this, but this was my experience and it makes sense at least within the context of my map.