helicopter transport Hermes Airlift Services Script

[Gunter Severloh 3948]

Dont really change anything, if your playing by yourself without AI subordinates then calling a heli is pointless, unless you only define yourself in the script,

then too if and when you die and only have elected side respawn then the units you switch into wont have the call heli action.

 

Call heli from radio

     What about call heli from radio, already in the script, never have tested it as an object outside my player character, but my unit already has a radio,

maybe have it where only those units with radio can call heli and if already in heli then those units without radio aren't required to be in the heli at same time to get the

"choose destination action".

 

i think the action should be made independent where if the player is by himself and has no subordinates player or AI, then when he is ready he should give the command to the pilot:

"Good to go pilot" after the destination has been chosen or if there are other players, or even if the player has AI under his command, i think there should be given more control to the player,

allowing the player decide when the pilot should take off.

 

Base

So when at base instead of you and any AI, or player having to have to be all in the chopper at once to get the choose destination action, then the action to

choose destination should be based on whomever enters the chopper, but only at base.

The after the destination is chosen, instead of immediately taking off to the chosen destination then the next action should be a check, basically the player will give

the ok for the pilot to go and proceed to chosen destination.

 

In field

When out in the field only those units with radio will be able to call for heli, player can call but he would be the one to determine

when the heli is to take off and proceed to the destination. In terms of coop you can have it where any player that enters the heli.

[Rydygier 1302]

Quote

 

Dont really change anything, if your playing by yourself without AI subordinates then calling a heli is pointless, unless you only define yourself in the script,

then too if and when you die and only have elected side respawn then the units you switch into wont have the call heli action.

 

 

Yes, it changes. Airlift will no longer stuck at waiting for all defined units to get in, when some of them can't be ordered to get in by any player.

 

Of course, whatever unit you switch into, has to be also defined as chosen for airlifting. That's up to mission designer, to ensure that. Then, the unit, you switch into, should have the call heli action.

 

Quote

i think the action should be made independent where if the player is by himself and has no subordinates player or AI, then when he is ready he should give the command to the pilot:

"Good to go pilot" after the destination has been chosen or if there are other players, or even if the player has AI under his command, i think there should be given more control to the player,

allowing the player decide when the pilot should take off.

 

  Yep. That way can be done too.

 

For the radio call - "choose destination" action may appear for each of defined for airlifting players, as soon heli is landed without any waiting for any other units to board. It will be all up to the players, when the heli will take off, heli can be ordered to take off even without any passangers in such case. 

 

For the boarding at base option - the "choose destination" action will appear for defined for airlifting players as soon any of defined units (player or AI) will board any of appointed heli (if they will board more, than one heli, the first counts as appointed). 

 

Is that OK?

 

The problem is, IIRC voice comm, when the pilot asks about the destination, assumes, all are boarded. Are we OK with that?

 

Quote

 

he after the destination is chosen, instead of immediately taking off to the chosen destination then the next action should be a check, basically the player will give

the ok for the pilot to go and proceed to chosen destination.

 

 

But what for? Seems redundant overcomplication. Destination choice can work as signal to take off IMO. 

[Rydygier 1302]

On 14.12.2018 at 7:15 PM, johnnyboy said:

Here's the animation I'm using:

[_dude, "AcinPercMstpSrasWrflDnon"] remoteExec ["switchMove", 0];

Looks pretty good:

 

 

Tried this snippet. The result:

 

 

Not the same. How do you tilt the player? setVectorUp in my tests is effectless...

 

Also tried alternative from another script:

 

 

Which is better? The second one looks more like actual fast roping, I saw on youtube, the more, in the first case unit holds the weapon in hand, which is kinda like the unit is going down using some carabiner clip? To me, both are good, except the tilt issue. 

 

As for door animations/rope attachement points issue decided, attachement points will be chosen procedurally (hopefully with sane results), but doors will be not animated (I see no way to ensure, right one are opened, in my tests with Huron appeared, that procedural choice of doors to be opened is not sufficient, pilot's door are used, result is silly, while that heli has anyway a hatch in the floor or something), but user will have an option to define by hand for each heli animation sources, that should be animated.

[Gunter Severloh 3948]

8 minutes ago, Rydygier said:

For the radio call - "choose destination" action may appear for each of defined for airlifting players, as soon heli is landed without any waiting for any other units to board. It will be all up to the players, when the heli will take off, heli can be ordered to take off even without any passangers in such case. 

 

For the boarding at base option - the "choose destination" action will appear for defined for airlifting players as soon any of defined units (player or AI) will board any of appointed heli (if they will board more, than one heli, the first counts as appointed). 

 

Is that OK?

That can work.

16 minutes ago, Rydygier said:

The problem is, IIRC voice comm, when the pilot asks about the destination, assumes, all are boarded. Are we OK with that?

Ya about all you can do unless theres more lines there, but basically player will have to wait til all are aboard, player/AI to set destination.

 

9 minutes ago, Rydygier said:

But what for? Seems redundant overcomplication. Destination choice can work as signal to take off IMO. 

Agree, but the idea was to add more immersion, dont want to make things to quick and easy, leave it as is.

 

[Rydygier 1302]

Quote

Agree, but the idea was to add more immersion, dont want to make things to quick and easy, leave it as is.

 

Well, if ppl say, they want such thing, we always can make it optional...

[ayoung 29]

Thanks for looking into the fast roping. Here is a link to SHK's fast rope script. http://www.armaholic.com/page.php?id=30242    This might be helpfull. Thanks again for the hard work

Edited December 17, 2018 by ayoung
grammar

[lordfrith 401]

is it just me or does your helo not shoot hundreds of meters into the air when braking towards an LZ? i was looking through the script and possibly "RYD_HAS_AscentCounter" might be responsible for this?

[Rydygier 1302]

Quote

is it just me or does your helo not shoot hundreds of meters

 

Frankly didn't even know, they tend to do that... :) Nothing, I've done consciously. 

 

RYD_HAS_AscentCounter is optional function, that may help in very specific (rare) issue, which I saw once at disembarking under fire - when the heli goes up too early, before all are out. It is disabled by default though, as this is kinda brutal "club" code, that fights with heli's native behavioral code. If turned on, it activates only for the last stage of landing. 

 

[Rydygier 1302]

BTW encountered an issue with fastrope disembark. It is about heli positioning over destination spot. Horizontally and vertically. Simply - as always in case of vehicles, aerial especially, sending the heli towards given position is highly inaccurate (wide tolerance of completion radius). It is so due to limited AI maneuverability. Meanwhile precision is crucial here, otherwise units may end on the top of some object/building without a way to go down, to the ground level or be exposed to harmful collisions with objects beneath. Also when player marks one position, while heli unload troops at another position makes whole fast roping idea futile. 

 

I'm thinking, workaround may be as brutal, as RYD_HAS_AscentCounter, to force (literally) the heli to move to the pointed spot before fastroping. Or perhaps it will start with invisible helipad landing (which makes positioning very precise), but interrupted befor the heli start to descent. If possible. 

 

Another thing - vertical positioning. Not sure yet, but wanted to use FlyInHeight, and from what I saw, it may not work too well, need to test more.  

[Jnr4817 215]

Speaking of FlyInHeight, can we have the ability to define a flying height enroute to the landing area? For example, pick your destination then pick the flying height, with the ability to change as needed.

 

Dudas rappel script is pretty awesome for fast roping.

 

 

Thanks,

Reed

[LarsAspra 13]

C2 - Command & Control by Mad_Cheese has a feature similar to what you're going for with Duda's aforementioned script/mod as a dependency which also detects if the waypoint is on a building, might want to check it out to see how he does it, if you haven't yet.

[Rydygier 1302]

Quote

Speaking of FlyInHeight, can we have the ability to define a flying height enroute to the landing area? 

 

Tested this yesterday. There will be such option, but only in user config, not at each call (I could, but frankly, I hardy see a point to implement such possibility, what for?). Anyway, FlyInHeight is ignored for altitudes considered as too low by the engine apparently. You can set, say, 200 meters, and it works, but if you set 20 - will be ignored, and, I guess, for a reason (collisions with tall objects). 

 

When solving the issue of precision of fast rope drop I've made a function, that applies calculated 3D velocity vectors, like 10 times per second, to bring helicopter to the chosen spot with few meters accuracy at chosen by the user config altitude (+ possible some meters, if needed to avoid collisions with nearby buildings). It works for small, precise amandements, but it's too rigid for constant use, so this is no go as for flyInHeight replacement during whole flight. Also, since usually heli considers a waypoint completed/stops around 80 meters before reaching it, I've made, so actual waypoint position is moved 80 meters beyond drop position, assuming straight A-to-B flight path, which is quite helpful too, and even before any amandements heli is positioned quite close. 

 

Mentioned temporary, interrupted landing on invisible helipad way of precise positioning was kinda working too, but not reliable, sometimes heli no matter what was insisting to nearly touch the ground before fly away, even if landing interrupted, and helipad deleted. I'll not reveal a big secret if I say, AI routines are flawed. 

 

Quote

 which also detects if the waypoint is on a building, might want to check it out to see how he does it, if you haven't yet.

 

I think, I got this my way. There will be an option to set custom search radius for building objects at the drop spot. If set to, say, 15 meters, it will ensure, final spot will be free from buildings (except those of >15 meters radius). But if user want, may set it to 0. Then fast roping will be conducted as close to the clicked pos, as possible for the heli, which may be used for rooftop fast roping. Rooftops are considered as for rope length etc. Of course, despite some small safe code, I adwise against it as for AI groups, as they tend to jump down from the rooftop to stay in formation. AI on the rooftop usually equals troubles as soon they try to move, still, there will be such option. 

 

My next "to do" before 1.1: ammo drops. I'm thinking, should I do it via slingload, via parachute or some combination of both?

[Rydygier 1302]

Regarding slingload, tested "HOOK" waypoint. It's semi-broken in a way - heli (Huron) was at first postion itself properly, but no rope was created, then it was randomly circling long time over the supply box area, then finally tried again and hooked the box properly. Weird. I wonder, if good enough... At the second try it was same, but this time Huron made second attempt much faster. At third Huron started from afar, and this time it worked at first approach. An issue with maneuverability when target too close from initial position perhaps. I think, I'll make it optional, if the box should be slingloaded, or dropped via parachute. 

[lordfrith 401]

5 hours ago, Rydygier said:

Regarding slingload, tested "HOOK" waypoint. It's semi-broken in a way

 

slingloading seems to work pretty consistently with the technique in the snippet below. Embarrassingly i hadn't yet noticed there was such a thing as a "HOOK" waypoint so i did this:

 

Spoiler

				_lndPos = getPos _RANSupply;//selects supply crate to collect
				_tempPad = "Land_HelipadEmpty_F" createVehicle _lndPos;// creates invisible helipad at crate position
				_heloRun =[_helo, _lndPos, 100, false] spawn LF_fnc_heloMove;//function, heli flies to pad on "MOVE" waypoint
				waitUntil {scriptDone _heloRun};
				_helo land "GET IN";//make heli hover a low altitude
				waitUntil {(getpos _helo select 2 < 7)  or (!alive _helo)};
				_helo setSlingLoad _RANSupply;//once heli is low eough attach crate
				_helo land "NONE";//make heli return to flyInHeight
				deleteVehicle _tempPad;//clean up temp helipad

 

 

this seems to work fine everytime, i guess if there are many helipads close together it could get confused

 

:D

[johnnyboy 3741]

On 12/17/2018 at 3:27 AM, Rydygier said:

Not the same. How do you tilt the player? setVectorUp in my tests is effectless...

Sorry for late reply...just saw this.  Within an EachFrame eventhandler, I move the unit down with this setVelocityTransformation code.  The vectorUp and vectorDown is hardcoded in that statement below.

        _pos1 = missionNameSpace getVariable "jboyClimbPos1";
        _pos2 = missionNameSpace getVariable "jboyClimbPos2";
        _dude setVelocityTransformation 
        [
            _pos1, 
            _pos2, 
            [0,0,-.0001], // from velocity
            [0,0,-.0001], // to velocity
            [0,1,.7],     // from VectorDir
            [0,1,.7],     // to VectorDir
            [0,0,1],      // from VectorUp
            [0,0,1],      // to VectorUp
            moveTime _dude
        ];
        //_pos2 = missionNameSpace getVariable "jboyClimbPos2";
        _pos1 = _pos2; 
        _pos2 = _pos2 vectorAdd [0,0,-0.125];
        missionNameSpace setVariable ["jboyClimbPos1", _pos1, true];
        missionNameSpace setVariable ["jboyClimbPos2", _pos2, true];

Your other animation is fine, and may be more realistic (but mine has fun factor of weapon in hand).

[Rydygier 1302]

Quote

Embarrassingly i hadn't yet noticed there was such a thing as a "HOOK" waypoint

 

I still may decide to use method similar to yours, but as for "HOOK"/"UNHOOK" wp, it seems to be gone from BIKI description, or rather replaced by "Lift Cargo" and "Drop Cargo", same I found in EDEN waypoint types, still seems, script-wise it' still the old name, as this code:

 

_wp = group h1 addWaypoint [(position _box), 0];	
_wp setWaypointType "HOOK";
_wp waypointAttachObject _box;

 

Does, what I described. If a box is 50 meters or more roughly ahead of landed Huron, the more if the heli is of smaller and more nimble kind, it seems to be enough space for maneuver to lift the box without described issues. 

 

Quote

I move the unit down with this setVelocityTransformation code.

 

So far never tried setVelocityTransformation. I definitellly want to test this, thanks.  

 

[lordfrith 401]

 

3 hours ago, Rydygier said:

method similar to yours,

 

i was noticing some glitches on hooking cargo so i think i'm going to abandon that method i posted in favour of the waypoints now ;) like you say as long as the heli has enough room to maneuver into position first waypoints work fine.

 

anyways, slingloading or paradrop, i'm  looking forward to the ammo drops :D

[Gunter Severloh 3948]

Wanted to let you guys know if it helps any the mission KP Liberation has a slingload component in it you could look at, idk where the script is or what code is used.

[Jnr4817 215]

On ‎12‎/‎20‎/‎2018 at 2:25 AM, Rydygier said:

 

Tested this yesterday. There will be such option, but only in user config, not at each call (I could, but frankly, I hardy see a point to implement such possibility, what for?). Anyway, FlyInHeight is ignored for altitudes considered as too low by the engine apparently. You can set, say, 200 meters, and it works, but if you set 20 - will be ignored, and, I guess, for a reason (collisions with tall objects). 

 

When solving the issue of precision of fast rope drop I've made a function, that applies calculated 3D velocity vectors, like 10 times per second, to bring helicopter to the chosen spot with few meters accuracy at chosen by the user config altitude (+ possible some meters, if needed to avoid collisions with nearby buildings). It works for small, precise amandements, but it's too rigid for constant use, so this is no go as for flyInHeight replacement during whole flight. Also, since usually heli considers a waypoint completed/stops around 80 meters before reaching it, I've made, so actual waypoint position is moved 80 meters beyond drop position, assuming straight A-to-B flight path, which is quite helpful too, and even before any amandements heli is positioned quite close. 

 

Mentioned temporary, interrupted landing on invisible helipad way of precise positioning was kinda working too, but not reliable, sometimes heli no matter what was insisting to nearly touch the ground before fly away, even if landing interrupted, and helipad deleted. I'll not reveal a big secret if I say, AI routines are flawed. 

 

 

I think, I got this my way. There will be an option to set custom search radius for building objects at the drop spot. If set to, say, 15 meters, it will ensure, final spot will be free from buildings (except those of >15 meters radius). But if user want, may set it to 0. Then fast roping will be conducted as close to the clicked pos, as possible for the heli, which may be used for rooftop fast roping. Rooftops are considered as for rope length etc. Of course, despite some small safe code, I adwise against it as for AI groups, as they tend to jump down from the rooftop to stay in formation. AI on the rooftop usually equals troubles as soon they try to move, still, there will be such option. 

 

My next "to do" before 1.1: ammo drops. I'm thinking, should I do it via slingload, via parachute or some combination of both?

I disagree.

 

The ability to set flyinheight to your destination is key depending on the type of insertion you are doing (fast-rope, rappelling, paradrops, etc.). It would be nice to have the option low 200, medium 400, high 1000. Also, depending on the enemy your going to encounter.

 

Just my humble opinion.

 

Thanks,

[Rydygier 1302]

Well, if you don't mind few more mouse actions, then no problem, apart from user config variable, I can make it possible to change flyInHeight also on-the-fly. At any time even, at least during pending troops transport call. I feel, in the future some small piece of GUI would be in order to control these things, but for now may be too little time for such luxuries.  

 

BTW core code of supply drop mission is mainly ready, not sure, if I manage to complete 1.1 before Christmas though, would be nice, but it depends... 

[Gunter Severloh 3948]

Update v1.1

After few days delay (real life stuff, and video demonstration), Rydygier has implemented several new functions and features

into the script thanks to your guy's ideas and feedback.

 

The following is the new additions and changes:

• Added Fast-roping
• Added Supply drop - (you can have the heli sling-load or para-drop the ammo crate)
• Changed Destination choice action now appears, when heli is landed at pick up pos (no waiting for all to board, radio call)
• Added Four new action to change flight ceiling on-the-fly
• Rearranged the code (subfolder, all user config in the separate file for better clarity)

We want to thank the following members for their

ideas and feedback:

• ayoung           -  (Fastrope idea)
• johnnyboy      -  (Fastrope animation, elevation)
• lordfrith          -   (Slingloading idea/code)
• Jnr4817         -   (Heli Elevation idea)

Dropbox link has been updated to the v1.1

Armaholic is pending with the v1.1 update.

 

New Demonstration video recorded to demonstrate the new

v1.1 features and functions, video also added to the OP.

 

On a last note watch to the end of the video i added a few words ;)

Thanks to Rydygier and his amazing work on this project without your skill,

dedication and know how this script would not be possible!

[ayoung 29]

Thank you for  the script. I hope you and Rydygier had a great X-mas.  

[Gunter Severloh 3948]

Now updated on Armaholic

http://www.armaholic.com/page.php?id=34661

Thank you Foxhound!

 

Note

Spoke with Rydygier about it, but we may go to Steam Workshop too with the script, but are going to wait a couple

of days until we get enough feedback, and any bug reports on the script, so let us know how it plays for you.

 

Lastly

i had asked Rydygier about something that i was wondering if it was a bug, and that is if you called a heli to a location for either transport,

or a supply drop, and called again to the same area or position, the pilot will remember the location and not ask for a signal. Cheers!

 

[Gunter Severloh 3948]

Hey guys, another update pending,

a small fix, but you'll have to wait til i get back home in the morning after work, if anyone finds any bugs, or issues

then please report it so Rydygier can take a look and see whats going on, be back with the update. Cheers!

[Jnr4817 215]

Awesome job.

 

Anyway to easily add Arsenal to the supply drop as an option?

 

Thanks for the hard work.