helicopter transport Hermes Airlift Services Script

[Play3r 143]

https://steamcommunity.com/sharedfiles/filedetails/?id=1621671518

https://steamcommunity.com/sharedfiles/filedetails/?id=1621671285

 

I get this error when i use at BlackFish Transport on Malden.

all in module is set to YES

only Need Radio is NO

 

// Play3r

[Rydygier 1302]

As said on Steam, only vehicles of "Helicopter" kind can be used by HAS. Blackfish is of "Plane" kind. Later I can experiment, how VTOL planes would work with HAS code, but I'm pesimistic here, even the size of this vehicle itself is a problem. HAS is for choppers. 

[Play3r 143]

30 minutes ago, Rydygier said:

As said on Steam, only vehicles of "Helicopter" kind can be used by HAS. Blackfish is of "Plane" kind. Later I can experiment, how VTOL planes would work with HAS code, but I'm pesimistic here, even the size of this vehicle itself is a problem. HAS is for choppers. 

that i have missed on steam will read the description one more time :) 

Thanks for the reply.

 

Great script/mod by the way, i'm waiting for Gunter to make a video on how to use your script, so i can use that and not the mod, Gunter told me there is more you can adjust in the script then in the mod.

 

// Play3r

[Rydygier 1302]

In fact, you can adjust all the stuff in the mod too, but not all could be put into module settings. Stuff like array variables have to be defined by typing them/pasting manually in the sqf file or init fields. Meanwhile in the script version all these variables are already gathered inside userConfig.sqf file for user convenience. Main advantages of the script version are, user has more control, how to implement HAS, like when to ativate it or even manually edit the code if wanted, and also script version doesn't create mod dependency for the scenario, which is important for scenario popularity. 

[Rydygier 1302]

I did some test with said VTOL in 1.3 scripted, where Blackfish simply pretends to be a helo. And it kinda worked. I mean, this beast requires lots of room to maneuver or land, but successfully picked up and delivered my team in demo mission (but doesn't work well with slingload, seems unable to hook the box, only circling around). I still affraid, the code is not prepared for the vehicle of this size, mostly as for searching for safe LZ (too low flat&empty space radius), thus it will stay officially not supported in 1.3, but I just added small change in our next release, so also module will accept VTOLs (planes of "VTOL_Base_F" kind) as helis. Use on own risk. 

[LBMartin_Boh 3]

Hi Rydygier.

 

I was digging in the saved arsenal loadout issue with Liberation. There is nothing wrong with your 1.2 version added to Libertation. The problem was that three loadouts I was testing doesn't have backpack!!! so the script was not loaded because of that. It is working perfect mixing both scripts.

 

Best regards.

[Gunter Severloh 3948]

Update

 

Version 1.3 released!

 

Changelog:

• Improved MP compatibility (client side players/dedicated server)
• Optional usage of 0-8 supports menu instead of most of mouse actions, except for destination choice actions
•  0-8 variant includes manual choice of the heli to use for the call (always, via submenu);
• Task prioritization for the helis in the mouse actions variant. Two variables: "RYD_HAS_TransportPriority" and "RYD_HAS_SupplyPriority". To determine, which heli should be used for given task in the first place, regardless of the distance, and also which heli shouldn't be used for given task at all. The higher value, the higher priority of usage, negative value excluded from the task completely. Application for example via heli's init field: this setVariable ["RYD_HAS_TransportPriority",1];//the heli gets priority 1 for troops transport (will be used before any heli of 0 priority)
• Predefined boxes to be delivered before spawned boxes. Script version - boxes/objects added into: RYD_HAS_SupplyDrop_Prepared = [box1,box2];//holds optional prepared boxes as supply to be dropped, that will be used before default, spawned boxes. Module version - same method or synced with module objects of "ReammoBox_F" kind or any synced with module object tagged for example via init field: this setVariable ["RYD_HAS_ThisIsBox",true];
• Alternative landing (experimental, will enforce autodisembark at destination, if not RTB or fast roping, faster descent). Variable: RYD_HAS_AlternativeLanding = true;//scripted solution instead of vanilla getin/getout landings at pickup and disembark spots;
• Respawn compatibility (player should get back HAS actions after respawn)
• RYD_HAS_IgnoreAbilityCheck = true;//if true, in mouse actions variant there will be no check, if heli is able to lift given container before accepting the task. 
• Workaround for not unreliable slingload unhook issue on dedi
• Several code fixes.
• New Video added to the OP ---> https://www.youtube.com/watch?v=VlUE1hWYBbs&t=1s
• New PDF Manual created and added to the OP ----> https://www.dropbox.com/s/txetwb5t6xug5ud/HAS_Manual.pdf?dl=0

 

Thank you Rydygier for all your work!, and to those who has given any feedback to help create this new 1.3 version!

Cheers!

 

[nomadd 66]

Been playing around with the script version and mod version of this. It is a wonderful addition to the community and very much appreciated. Thanks for all your hard work.

 

Few things I have noticed in multiplayer.

using RYD_HAS_STT = []; in multiplayer is a problem. Say you have 10 playableunits named s1-s10 and all 10 are in game no problem, but if only 5 slots have players and you disable the AI in the lobby. Your script throws errors looking for units that are not there. The mod version does not have this problem ( I know they are two different threads so will try and keep anything about the mod out of this one.)

 

if you only name one unit in RYD_HAS_STT = []; So only one person can control the helo. Fastroping will eject the unit named in RYD_HAS_STT = []; but not any other units in the cargo. Same with landing. Even if you turn off the auto-disembark feature. If the unit(player) that is named in RYD_HAS_STT = []; gets out of the helo. The helo will immediately take off even if other units are still in the cargo area. 

Not sure how to work around this. I tired different ways to check for alive or !isnull units and add them to the [newUnit1,newUnit2,newUnit3] call RYD_HAS_NewUnits; but with no success. Also need a way to grab JIP and add them unless your can change the way the RYD_HAS_STT = []; array works. Maybe name the group  that is being transported or possible add a variable to each unit to be transported.

 

Couple of quality of life features, not necessary but just suggestions

-ability to cancel an order while you are flying. Ex: you pick a destination but half way there you decide to change it

-ability to tell the pilot either landing (insertion) or fast-rope (insertion) when you choose a destination. Right now is it hard coded in the userconfig to one or the other 

-ability to set up more that one helo for fast roping, this way can have different helos to choose from and the rope attachments points will be correct even if they are different helos. 

RYD_HAS_RopeAttachPoints =

    [
    //[-1,0,0],
    //[1,0,0]
    ];

maybe something like
RYD_HAS_RopeAttachPoints =
   [
		["CUP_Uh60_Base",[1.47,1.93,-0.47],[-1.47,1.93,-0.47]],
 or even the name of the helo
		[Helo1,[1.47,1.93,-0.47],[-1.47,1.93,-0.47]],
	];

-option in the config to lock out not just the pilot seat, which i believe is done but also the gunner seats if there are any. The reason is playing with other humans, they love to get in the gunner seats during flight but once the AI is out of the gunner seat and switches to a cargo seat the AI will never get back in the gunners seat. So you get dropped off do your mission call helo for a extraction while taking fire and helo comes in sans gunners because the AI gunners are still sitting in the cargo area.

[Rydygier 1302]

Thanks for the feedback!

 

Quote

but if only 5 slots have players and you disable the AI in the lobby. Your script throws errors looking for units that are not there. 

 

I see the problem, not familiar, how blocking AI affects the disabled units (deletes them?), will test that to check, what's exactly is going on in such case. 

 

PS general request: if you want to tell me about any erros - include RPT logs of this error, please, knowledge, there are some errors may be not sufficient. Often isn't. 

 

EDIT: tested. Disabled units are just gone. And the first error because of that appear already at userConfig's RYD_HAS_STT definitioin. I could catch nil variables later, but one rule: user simply can't add into RYD_HAS_STT variables, that he plans to make nil before HAS init. Not sure, how it could work otherwise. There's no error for the mod, as he reads synced units after some of them was deleted, so no problem here. 

 

Quote

 The mod version does not have this problem

 

Interesting. Feel free to mention any differences between both version in any thread, it may be helpful. 

 

Quote

if you only name one unit in RYD_HAS_STT = []; 

 

Then only one unit is supposed to use HAS features. That's how it works by design and the problems, you described, are expected in such case. 

If you wish only one be able to call, but several to be transported, add an assigned item class restriction and give the item to only one unit. GPS perhaps? Or just radio, most logical? Hm. Perhaps I'll add setVariable to optional disable calls for one of HAS-enabled units without any items juggling. 

 

Quote

Also need a way to grab JIP and add them

 

Don't know much about JIP. Doesn't they just fill playable characters already defined and added to the STT? If so, it should work as is? Sadly, I've no means for testing HAS with more, than one player, the more on-the-fly, as I code, so I can work only blindly here, and only collecting feedback after release. 

 

Quote

Maybe name the group  that is being transported or possible add a variable to each unit to be transported.

 

Both rather no, I'm affraid. First may work for some, but become an issue for the others, if they want only some units of the group to be HAS-enabled. Second means, the code each time need to go through every single unit on the map to check, which at the moment has this variable. 

 

Quote

Couple of quality of life features, not necessary but just suggestions

 

Some may be doable, some not, I'll think about them, thanks for the suggestions. 

 

Quote

option in the config to lock out not just the pilot seat, which i believe is done

 

HAS doesn't lock anything. Not touching that seats at all. 

 

[Rydygier 1302]

10 hours ago, nomadd said:

 but if only 5 slots have players and you disable the AI in the lobby. Your script throws errors looking for units that are not there.

 

Tested. Disabled units are just not present. And the first error because of that appear already at userConfig's RYD_HAS_STT definition. I could catch nil variables later, but one rule: user simply can't add into RYD_HAS_STT variables, that he plans to make nil before HAS init. Not sure, how it could work otherwise. There's no error for the mod, as it reads synced units after some of them was deleted, so no problem here. 

 

Hm... An idea then. We have Base game logic there. What if to give up manual definig this array, same as choppers etc. entirely (or rather, will stay undefined by default, but may be defined manually and only then will be used), and by default use same way, as in module version also here? By syncing with Base object? Promising. Simplier for the user. I'll do that. Yep. 

[Rydygier 1302]

Seems, above works and solves the issue BTW. 

 

Quote

and add them to the [newUnit1,newUnit2,newUnit3] call RYD_HAS_NewUnits; but with no success.

 

Tested such code: 

 

[unit1] call RYD_HAS_NewUnits; (where unit1 is me, the player)

 

In the singleplayer and on dedi, run server side only, for both variants - mouse actions and 0-8 supports and in all cases it worked for me - my unit, initially excluded from HAS actions, got that actions when added via NewUnits, and could properly use them. 

[Rydygier 1302]

Quote

 Perhaps I'll add setVariable to optional disable calls for one of HAS-enabled units without any items juggling. 

 

Added, works. :) In case, someone want to test newest changes, here are:

 

HAS 1.4 script wip1

 

- now defining units, helis and prepared boxes (if any) same way, as in module: via syncing them with RYD_HAS_Base Game Logic. This should fix script errors when unused AI slots disabled in the lobby. 

- [unit1] call RYD_HAS_NewUnits; run server side works for me in this version. 

- if set on server: 

 

unit1 setVariable ["RYD_HAS_canCall",false]; 

 

unit1 losts access to HAS calls. Use:

 

unit1 setVariable ["RYD_HAS_canCall",true]; 

 

To give actions back. Can be switched back and forth any time. 

 

Other stuff next time. 

[nomadd 66]

Thanks for the quick update. I will test this out as soon as I can. 

[Rydygier 1302]

Quote

ability to set up more that one helo for fast roping, this way can have different helos to choose from and the rope attachments points will be correct even if they are different helos. 

 

After some tests - no problem. Most troublesome seems changing destination en route - not compatible with script's logic architecture, I've some idea, but chance is slim. Choosing method of insertion possibly easier, I'll look into it. 

[Rydygier 1302]

New wip for tests:

 

HAS 1.4 script wip2

 

- now custom rope attachement points defined per each heli separatelly (helis have to be named in EDEN for that). 

- at destination choice two variants for choosing target location: touchdown, for traditional landing, and fast rope. Usage of the fast rope switch in userConfig removed. 

- added RYD_HAS_SafetyMargin = 10; user config variable. Value set here is added to the heli size when calculated radius for flat and empty area search at landing zone (where fast rope or RTB not used). 10 is reasonable minimum. The higher - the safer LZ as for collisions with map objects. The lesser - bigger collision risk, but also bigger landing accuracy (closer to the spot chosen by user). If 0 - only heli diagonal model radius will be used as search radius. If set with negative number like -100, final search radius is 0, thus collision checks ignored, but landing most accurate. Especially with RYD_HAS_AlternativeLanding = true; may produce hardcore landing accuracy experience indeed, but beware, where you mark the spot :). Without alternative landing in such case if there's object colliding at LZ, it may produce a bug of premature heli lift up. So, use with caution, decrease below default on own risk. 

[nomadd 66]

Wow Rydygier you are a machine making changes that fast. I was able to test (not fully)  the HAS 1.4 wip1  and looks like you fixed the errors with naming the units. 

The variable is an excellent idea you had. That way as a mission designer I can basically turn HAS on and off during the mission. 

I really haven't found anything major, ie script errors in the .rpt.

One thing I did notice. One test was just with AI, I ordered them on the helo. I was probably standing(in game)  15-20 meters away from the helo and got the action for "Transport to another location".

Maybe need a check in the addaction to make sure unit(caller)  is in the helo before they can get the "Transport to another location".

[Rydygier 1302]

Thanks. Good, the erros are gone. 

 

Quote

One thing I did notice.

 

This way is by design, on Gunter's request. The goal is, to make able the caller to decide, when to send the heli towards the destination. Be it all aboard, only some got in or even no one in the heli. Before code was waiting, till all STT units was in. "More control for the player" approach. 

[nomadd 66]

Quote

This way is by design, on Gunter's request. The goal is, to make able the caller to decide, when to send the heli towards the destination. Be it all aboard, only some got in or even no one in the heli. Before code was waiting, till all STT units was in. "More control for the player" approach. 

 

Gotcha, makes sense.

[Gunter Severloh 3948]

Otherwise all units would have to be in the heli just for you to go anywhere, now you can get in yourself without your squad and go where you want.

 

Green Smoker was the original name for the script in 2014 btw, lol was an idea i had and Rydygier made it a reality but back then it was primitive compared to its functions now,

but the main concept behind the script was to be able to call a heli by throwing smoke, basically signal the heli your position kinda of like real life, the heli would come, wait til everyone

was aboard and then take off and return you back to base which was the position of the gamelogic in the editor.

 

So you can see just from that how much more added functions, and features there are, and now alot more advanced with options you can turn on and off,

you got to give major props to Rydygier for knowing his code, im sure with the current work hes doing for the MP aspect hes learned how to do some new things with code,

if i had the patience, and the interest i'd learn how to code, but you can see what my role in all this is so it works anyways.

 

Sounds like v1.4 is coming along, something to release for the coming weekend Rydygier?

[Rydygier 1302]

Quote

Sounds like v1.4 is coming along, something to release for the coming weekend Rydygier?

 

Quite possible, unless I'll be flooded by new bug reports. :)

 

Apart from that, I have just one or two more features to try, if possible to implement. We'll see. 

 

PS Indeed, initial code was 35 lines long, current is about 4000. 

[Rydygier 1302]

Last portion of 1.4 features to test:

 

HAS 1.4 wip3

 

- fixed a bug with no destination choice actions appearing, if task was triggered by the unit entering the chopper at base, while player unit wasn't the first in the array (with current, syncing method order in the array AFAIK is same, as order of unit placement in EDEN - first placed unit will be the first etc.);

 

- minor code improvements;

 

- caller can now redirect the chopper during the transport if initially was't chosen "RTB" option (because adding such ability also for RTB task would require extensive rewriting of core logic structure). Method: if not RTB, action to choose "another location" will be not removed after initial choice and can be re-used to point new location during the fly again and again as long the heli reach current destination and enter landing pattern - at this point actions are removed. To cancel choosing, click on some invalid position - water or out of the map boundaries (hint about cancelling should appear). If you don't, new destination choice will be auto-cancelled just before landing stage at current destination.

 

Initial choice of "RTB" is final, actions are removed immediately. 

 

I'll wait around 24 hours from now on, then, if no bug reports appear, I'll push forward to Gunter package for 1.4 release. 

 

[ayoung 29]

Thank you soooo much for all your hard work.

[nomadd 66]

Will try it out this weekend

 

Thanks again for making this. It is extremely useful 

[Gunter Severloh 3948]

Update

 

Version 1.4 released!

 

Changelog

• Defining units, helis and prepared boxes (if any) in the script version by default similar way, as in module: via syncing them with RYD_HAS_Base Game Logic (old way still possible too if proper variables defined by the user);

• If set on server: unit1 setVariable ["RYD_HAS_canCall",false]; unit1 losts access to HAS calls. Use: unit1 setVariable ["RYD_HAS_canCall",true]; To give actions back. Can be switched back and forth any time;

• From now on custom rope attachment points defined per each heli separately (helis have to be named in EDEN for that, see the manual or userConfig.sqf for details);

• At destination choice two variants for choosing target location: touchdown, for traditional landing, and fast rope. Fast rope switch in userConfig removed;

• Added RYD_HAS_SafetyMargin = 10; user config variable. Value set here is added to the heli size when calculated radius for flat and empty area search at landing zone (where fast rope or RTB not used). 10 is reasonable minimum. The higher - the safer LZ as for collisions with map objects. The lesser - bigger collision risk, but also bigger landing accuracy (closer to the spot chosen by user). If 0 - only heli diagonal model radius will be used as search radius. If set with negative number like -100, final search radius is 0, thus collision checks ignored, but landing most accurate;

• Fixed a bug with no destination choice actions appearing, if task was triggered by the unit entering the chopper at base, while player unit wasn't the first in the array (with current, syncing method order in the array AFAIK is same, as order of unit placement in EDEN - first placed unit will be the first etc.);

• Caller can now redirect the chopper during the transport if initially was't chosen "RTB" option via re-using destination choice actions;

• Minor code improvements;

• Manual updated accordingly.

[Gunter Severloh 3948]

All download links including Armaholic is now at v1.4

You have the option on steam workshop page too to download from dropbox or armaholic for either script or module as well as subscribing to the module.

 

If anyone is able to give some feedback on this latest version on how it works for you on a dedicated, as well as overall using the various features,

Rydygier spent alot of time coding this and implementing this into script and module to make it versatile as possible,

let us know fellas, we'd really appreaciate it.

Cheers!