Please let me know what info you need (I see status was changed to "need more info").

this issue is resolved no crash this time

In MP. I haven't tried in SP.

The status of this ticket is incorrect because I already provided more informations

I don't see how to do that (please give an example).
Do you mean I should use variables instead of #define? If yes then I will still have to use 2 files colors.ext (with #define, used in dialogs) and color.sqf (with variables used in sqf scripts).
Also my point was to use #define for all variables that are static.

I was thinking about something like I am already using:

• I define functions in some files
• I include all these files in the init.sqf (with #include)
• Before the inclusion of function files, I include all definition files (eg the ones containing #define blabla or even other #include)

This way I don't care where the definition file is located since it is included in the init.sqf and all file paths are visible at this level.

So I am asking whether this can be achieved with CfgFunctions.

One example is that I have a list of colors as #define in a file ([root]\colors.ext and I want to use this in [root]\functions\fn_myfunc.sqf and also other scripts that i don't want to place in same folder as fn_myfunc.sqf but sth like [root]\mygreatscript\toto.sqf. At the moment I'm forced to cpy the colors.ext file in [root]\mygreatscript\ and [root]\functions\.

I am using kbTell in my mission because it allows me to use some audio files from the game (so I don't need add more to the mission).
I am using these radio messages when a player teamhits a friendly player.
The problem is the following script will display the "cease fire" message in the language of the target for both target and shooter (so if shooter is polish and the target is french then polish shooter will see message in french and will not understand what he's doing):

MYTARGET kbAddtopic ["SENTENCES", "bikb\sentences.bikb"];
MYTARGET kbTell
[

		MYSHOOTER,
		"SENTENCES",
		["CEASE_FIRE_1", "CEASE_FIRE_2", "CEASE_FIRE_3", "CEASE_FIRE_4"] select floor random 4,
		[
			"MESSAGE",
			{},
			format ["%1! %2", name MYSHOOTER, localize "STR_A3_CEASE_FIRE"],
			[]
		],
		if (group MYTARGET == group MYSHOOTER) then {"GROUP"} else {"SIDE"}

];

I am using kbTell in my mission because it allows me to use some audio files from the game (so I don't need add more to the mission).
I am using these radio messages when a player teamhits a friendly player.
The problem is the following script will display the "cease fire" message in the language of the target for both target and shooter (so if shooter is polish and the target is french then polish shooter will see message in french and will not understand what he's doing):

MYTARGET kbAddtopic ["SENTENCES", "bikb\sentences.bikb"];
MYTARGET kbTell
[

		MYSHOOTER,
		"SENTENCES",
		["CEASE_FIRE_1", "CEASE_FIRE_2", "CEASE_FIRE_3", "CEASE_FIRE_4"] select floor random 4,
		[
			"MESSAGE",
			{},
			format ["%1! %2", name MYSHOOTER, localize "STR_A3_CEASE_FIRE"],
			[]
		],
		if (group MYTARGET == group MYSHOOTER) then {"GROUP"} else {"SIDE"}

];

the issue is not solved in 1.42, the pictures are still black in arsenal

It also happens with vehicle icons (configfile >> "CfgVehicles" >> _type >> "picture"). I attached screenshot. before the patch these icons were white.

I confirm the issue, however it only happens if you use mortar optics and not artillery computer. After shooting the 4 mags with the mortar optics I got killed.

Just retested today and issue is still there in v1.44

I tried what you suggest Kid but it didn't work. I was on dedicated server with another player. I went in driver seat of Scorcher. He went in gunner seat. I executed the command on my computer and on his computer without any effect (I don't remember executing on server side but I don't think that would have worked either). The only way it works is when both turret and vehicle are local, so it will never work when the locality of turret and vehicle is different.

I just checked and the issue is still there (b_mortar_f and o_mbt_02_arty_f).

Same problem with Strider and the laser designator in commander seat.

Even if shadows have huge impact, server admins still should have control over them (forced value or free for all) and players notified of server's settings.

As another suggestion difficulty settings & mission settings should be combined in one view for more easy access to information and control:

• in server list
• in game lobby under parameters button (or 2 buttons: generic, aka difficulty, settings and mission settings)
• in game briefing under log sectio.

Difficulty settings should be editable by game admin in the same way mission settings are.

Server admins should have the last word over mission settings made available by mission makers. Players should be explicitly informed when difficulty and mission settings are different from the default values (modified by game admin) by highlighting modified values in red and default values in green.

Many times the game/server admin chooses the wrong difficulty profile and only notices it at mission start (eg: 3rd view and weapon crosshair enabled) because the individual difficulty settings are not visible to anyone and not editable in game lobby after mission is selected.

Another suggestion is easy creation/modification of profiles for difficulty and mission settings in the game lobby by logged in admin

Some players can't see the HUD at the top of the screen because they increased the "interface size". I didn't find any way so far to check whether the "interface size" is over "normal" and alert the player.

I also didn't find a way to make sure the HUD stays at the top of the screen (not beyond the top limit) and at same time adapt its size to the bigger "interface size" value (as it is the case for ArmA standard menus).

i added repro_mission.zip with the mission folder and the output I have in log file and the empty dump file that is generated when I shoot the OPFOR officer.

this issue is fixed (by the way I get an "Access Denied" page when I try to set the issue to "fixed" myself).

Thanks for answer.
But I forgot to mention that I also want to disable the default action bound to that key combo. So if a player wants to autolock a target he will see a hint with a message instead of the target lock square/diamond.
Wouldn't it be easier/more performant to make KeyDown event handler detect the key combo like inputAction does?
Is inputAction working reliably inside the KeyDown EH code? I will have to test it (maybe it will work like 50% of the time).

I finally fixed this problem by doing the following:

description.ext
respawnTemplates[] = {};

init.sqf
player addEventHandler
[
"Respawn",
{

		_new_unit = _this select 0;
		_dead_body = _this select 1;

		if (not (_dead_body getVariable ["zcm_isrevived", false])) then
		{
			[_new_unit, nil, nil, 10] spawn BIS_FNC_RESPAWNMENUPOSITION;
		};

}
];

With the above I can call [player, nil, nil, 10] spawn BIS_FNC_RESPAWNMENUPOSITION and it will work as expected.

I haven't experienced errors reported by caliban although I am using side type of target (_respid = [playerSide, player call ZCM_F_POS, localize "STR_ZCM_ITEM_MHQ"] call MBIS_FNC_ADDRESPAWNPOSITION;).

So from my point of view this ticket can be closed.

The flickering is indeed fixed (this wasn't really the issue but it looked more like the cause).
The fact that player doesn't respawn on the location he chose is not fixed. This was the issue I wanted to report but maybe I chose bad ticket title.

If anyone is editing the code of the respawn menu ([player] spawn BIS_FNC_RESPAWNMENUPOSITION) please share your fix before BIS solves this.

I should maybe mention that I am using respawn markers (respawn_west_xxx, respawn_east_xx) with script added positions, maybe this is causing the trouble.

I removed the "respawn_west/east_xxx" markers and tried calling BIS_FNC8ADDRESPAWNPOSITION with both objects and position arrays. The result is the same I respawn on the position where I died.
respawn = "BASE";
respawnDelay = 10;
respawnDialog = 0;

Tried with and without respawnTemplates[] = {"Base"};

Maybe the problem comes from the fact I'm calling "[player] spawn BIS_FNC_RESPAWNMENUPOSITION" from script and haven't defined any respawn templates (respawnTemplates[] = {"MenuPosition"}). It seems that [player] spawn BIS_FNC_RESPAWNMENUPOSITION must be also called at player respawn. Adding [player] spawn BIS_FNC_RESPAWNMENUPOSITION to onPlayerRespawn.sqf file seems to fix the issue (I respawn where I select).

Thanks TakeHomeTheCup, I switched PiP Quality to Ultra in Video settings and I immediately have a good quality (no distance fog) but when drone turret is at 1000m from target the PiP view starts to have more distance fog than the drone turret. It looks like there is still a difference between the viewdistance of drone turret and the viewdistance of PiP camera (at least around 1000m).

So can these 2 viewdistances be made the same for drone turret and PiP view?

I added file with last version of my modifications to the bis_fnc_arsenal function (search for FIX keyword). Each original modified section is left in comments to quickly spot the differences.

I added 2 screenshots to illustrate point 7)

I added 2 fixes in the second attached file:

• I excluded "throw" and "put" magazines from the magazine list (these were added in my previous fix)
• the green color was not removed from throw/put/misc mags when switching between uniform/vest/backpack (it only worked for rifle mag list)

Calling ["Open", [objNull, _soldier]] call BIS_FNC_ARSENAL; (where soldier is AI) didn't work for me. Then I noticed that the indexes were wrong:

BIS_fnc_arsenal_cargo = [_this,1,objnull,[objnull]] call bis_fnc_param;
BIS_fnc_arsenal_center = [_this,2,player,[player]] call bis_fnc_param;

instead of

BIS_fnc_arsenal_cargo = [_this,0,objnull,[objnull]] call bis_fnc_param;
BIS_fnc_arsenal_center = [_this,1,player,[player]] call bis_fnc_param;

Anything new about this issue? Is there an easy way to make the group persistent?

That's what I did, I added a game logic, but it makes some problems sometimes (the game logic becomes leader, etc). So I would prefer completely remove the game logic (and scripts that fix the game logic issues) and have only to set a variable that contains the list of persistent groups BIS_persistentGroupList = [grp1, grp2].

this issue was fixed some time ago it can be closed

duplicate ticket http://feedback.arma3.com/view.php?id=15990

it can be a nice feature for mission briefings:
you click on a briefing topic and see an integrated video from the Internet.

Or at least a hyperlink in the briefing that would open the Internet browser with a given URL (but maybe a security problem?).

At the moment I am using this trick in my briefings:

blabla
<br/>
<execute expression="copyToClipboard 'http://forums.bistudio.com/showthread.php?176567-ZDROB-Team-Missions'">ZDROB Missions (click to copy weblink)</execute>

After reviewing GLTLegislator's addon I understood a more simple solution is possible and tested it.

The function responsible for this mess is BIS_fnc_initRespawn. So all you need to do is change it like this:

1. add this in description.ext

allowFunctionsRecompile = 1;

2. add this to the init field of any unit/object you have in the mission

BIS_fnc_initRespawn = {true}

Please vote this up so devs will fix it sooner

The cursorTarget command can be used only if players disassemble the static weapon (missions with AI disabled). In a mission with AIs I can cheat by ordering an AI to disassemble the weapon since cursorTarget applies to player unit and will return objNull.

if (not isDedicated) then
{
waitUntil {not isNil "ZCM_PLAYER_IS_DEFINED"};

...

// track backpacks when disassembling static weapons
player addEventHandler
[

		"WeaponDisassembled",
		{
			(_this select 1) setVariable ["zgp_vehicle_group", cursorTarget getVariable ["zgp_vehicle_group", grpNull], true];
		}

];
};

This will update the weapon backpack object by adding a variable to it that tells the group of the player who disassembled it.

I tested the idea with the nearestObject command but it returned objNull. I bet the cursorTarget command will return the same (haven't tested). From this I deduce that the event handler triggers after the weapon is disassembled (after the weapon object is removed and replaced with backpacks).

issue still present in v1.44

related to http://feedback.arma3.com/view.php?id=18090
and this http://feedback.arma3.com/view.php?id=18330

The solutions suggested here are OK if you want to enable/disable the action for everyone based on some generic conditions.

But these solutions are not OK if I want to decide whether weapon disassembly/assembly is decided on the fly when a player/AI tries to disassemble the static weapon or assemble the backpacks (eg: allow/prevent player action depending on the group he belongs to at that specific moment).

A more generic solution would be better (although more complex), since it will allow more fine control over what happens in the mission. And I think the more generic solution is to improve the already existing WeaponDisassembled/WeaponAssembled:

WeaponAssembled => the return boolean determines whether the weapon is assembled or not

WeaponDisassembled => add reference to the weapon object (so I don't need to use cursorTarget workaround which is limited to human player and cannot work with AI soldier)

WeaponDisassembled => the return boolean determines whether the weapon is disassembled or not

I installed a dedicated server (Branch: Stable Version: 1.18.124200) on my PC and was unable to reproduce the issue. So apparently this is working now.

However I noticed this problem (setvariable with global broadcast not working) is still occurring randomly. Yesterday, I noticed the issue on a dedicated server. The setvariable command didn't work on "b_supplycrate_f" for one player only (we were 4 players in total). I asked the player to reconnect and after he did the server broadcasted the variable correctly (I didn't reexecute the setvariable command before or after he reconnected).

I tested the issue with "b_supplycrate_f" again too and I couldn't reproduce it either. It looks like something random.

It also happens with command menu. When you open command menu a white circle appears and any enemy/friendly unit inside has its tag displayed.

This is mainly a problem in PvP missions. Players who know the trick of the menus have an advantage over those who don't.

I couldn't reproduce this issue so this looks fixed. You may close the ticket.
Test info:
productVersion result on my PC: ["Arma 3","Arma3",128,126958,"Stable"]
productVersion result on dedicated server: ["Arma 3","Arma3",128,126958,"Stable"]

I installed the ArmA 3 dedicated server but I can't connect to it from a DEV version. I ran the steamcmd with 233780 -beta development parameters to set the dedicated server in dev mode but it didn't work.
We will see if it is fixed in stable version.

related to http://feedback.arma3.com/view.php?id=12984

I've read that guide and there is nothing said about reporting one issue/request per ticket only.

Anyways I consider this to be the case here since I am describing only one issue: there is no general 'switch' to turn off TI on all game elements (vehicles, optics, weapons, etc).

Thanks for optic_NVS idea. When I checked this (during daytime) I had a completely white screen and thought was bugged.

I don't see the point of creating 2 additional tickets since for me there is only one problem with multiple causes. I think putting it all together makes the problem clearer.