The Slammer tank, as you guessed already, can't be sling loaded by a heli.

Either use the canSlingLoad https://community.bistudio.com/wiki/canSlingLoad command to check if sling loading is possible, or check in the config viewer if a sling load memory point exist for the vehicle to be sling loaded.

A setPosATL (or setPosASL) with a postion outside the vehicle object should work for removing dead units from a vehicle.

A call BIS_fnc_addRespawnPosition used with the target parameter type SIDE, will result in a long list of errors and respawn is not possible. Parameter type GROUP works, as do the marker respawns (did not test for namespace, objects).

https://community.bistudio.com/wiki/BIS_fnc_addRespawnPosition

Error log excerpt:
Error in expression <ist lbsetdata [_lbAdd,_xStr];
_ctrlList lbsetpicture [_lbAdd,_picture];
if (_xSt>

Error position: <lbsetpicture [_lbAdd,_picture];

if (_xSt>

Error Type Any, expected String

File A3\functions_f\respawn\fn_respawnMenuPosition.sqf, line 297
Error in expression <ist lbsetdata [_lbAdd,_xStr];
_ctrlList lbsetpicture [_lbAdd,_picture];
if (_xSt>

Error position: <lbsetpicture [_lbAdd,_picture];

if (_xSt>

Error Type Any, expected String

File A3\functions_f\respawn\fn_respawnMenuPosition.sqf, line 297

and so on...

Addition/correction to my note from above.

The respawn menu is working correctly, with Side/Namespace target parameters. The problem was, that BIS_fnc_addRespawnPosition expects the position in an [x, y, z] format, providing only [x, y] coordinates will result in the error described above. The client menu respawn dialog will not show the correct markers then and the respawn not work.

Maybe this can be added in the description for the function.

Summary:
_CreatedRespawnPositionArray = [WEST, [1, 1], "Respawn menu string"] call BIS_fnc_addRespawnPosition; -> will NOT work.

_CreatedRespawnPositionArray = [WEST, [1, 1, 0], "Respawn menu string"] call BIS_fnc_addRespawnPosition; -> works as intended.

Thank you Karel!

Will test it when it is integrated into the stable branch.

Yes, confirmed.

Also noticed this behavior. It started happening with the changes along with the ZEUS update and the reworking of the respawn menu, especially respawnTemplates[] = {"MenuPosition"}; . Before, the respawns were working correctly at the selected positions.

Thank you Karel, it is working now with the command:

["AmmoboxInit",[this,true,{true}]] call BIS_fnc_arsenal;

I still receive the following, non-critical, message though (happened already before, but as I said, not critical):

[BIS_fnc_baseWeapon] Class '%ALL' not found in CfgWeapons

Oops, where was my mind here... my bad.
Should be:

if (!(isServer)) then
{
showHUD false;
};

You can simply create the init.sqf and place it in your mission's folder, it's a text file.

Honestly? I don't think that there is much use for this option to make availabe on general basis. If a mission author wants it, he can implement it.

Small code mistake above: showHUD false; should be the correct syntax.

if (isClient) then
{
showHUD false;
};

As Killzone Kid pointed out, this command is used for scripting. If you put in your description.ext, your mission will crash (tested it, CTD as expected). The weapon pack does not matter...

Workaround for you:
In your init.sqf add the following code:

if (isClient) then
{
showHUD false;
};

This will have the desired effect on clients in a multiplayer enviroment.

There is already a command for this: inRangeOfArtillery

https://community.bistudio.com/wiki/inRangeOfArtillery

The high or low trajectory don't really matter as long as the artillery is able to hit the target. The flighttime can be retrieved with the getArtilleryETA command.

If you want to get exact values, the mathematics behind ballistic paths are not that complex.

Interesting, did not know that before. I will have to try it. If it works, there should be no need for the additional commands.

Thank you Killzone_Kid, nice one.

Ticket closed.

The WeaponHolders can be accessed without any problems with either the nearestObject, nearestObjects or allMissionObjects commands. Problematic is only the performance, when used with a larger radius.

Dedicated means the use of a dedicated server, which can either be Internet, LAN, or neither of those.

As far as I know, this is still not working and especially with the standard BIS High Commander module, which use the military symbol module, results in a not desired behavior.

For me it's not relevant anymore, as I wrote a custom integration for displaying groups/intel data for my mission, but other users might still rely on this.

It would be nice, if this issue would be at least reviewd or even assigned. The wrong BLUFOR icon color on a dedicated server leads to some quite annoying issues, when clients believe that they are hit by friendly fire.

The module was working correctly in Arma 2.

Yes, japapatramtara, you can close this ticket as successfully resolved. Thank you!

Thank you japapatramtara.

I am not using the DEV build, so I can't test this, maybe someone else can help out with this. I will check it, when it is released into the stable branch.

Cannot create entity with abstract type ParachuteEast (scope = private?)

Still present in version 1.14 stable; happens when an AI crewed To-199 Neophren is shot down and the AI crew is trying to bail out and deploying a prachute.

Upvoted.

I would also like to see the option to individually mute/disable a specific VON channel available ingame.

If there are several players talking all at the same time, it is very hard (impossible) to understand what is going on in your group or vehicle channel - and sometimes those are the channels that are important in some situations. It is a bit distracting hearing talk about the weather in the side channel and I would actually prefer to play the game instead of muting/unmuting players.

As a visual reference, it would also help to display a speaker icon for muted/unmuted with matching channel colours somewhere in the upper right/lower right corner of the screen.

Thank you!