AIWorld.GetRoadNetworkManager looks already promising. Currently returns null, but I guess it will be functional once AI driving is added.

This issue is no longer observed on experimental.

It still happens for me on stable, but it looks like it has been resolved on experimental.

Since this hasn't been tested yet, I'll take the liberty to provide a more detailed repro. I created and published a test mod with the ID 5EAC510A8E6EC623, which contains the following code and in essence defines a new variable for the mission header and its value is written in the chat for all clients:

//------------------------------------------------------------------------------------------------
modded class SCR_MissionHeader : MissionHeader
{
	[Attribute(defvalue: "11", desc: "My mission header variable")]
	int m_iMHT_myVariable;
};

Nice, thanks for the update!

I think this ticket can be marked as resolved. The server name has been fixed in the recent update.

In T171445#2427817, @Andrew_Bones wrote:

A notorious spot is the one here (red circle)

When US has base on the coast (somewhere around the blue cross), it does often end up in a pile of trucks stuck in the forest right at the start, because one guy does not know the handbrake trick.

There is probably more but I play Soviets more often, and Urals do not have this problem...

One can always argue whether it is a feature or an abuse. I am more on the abuse side, since a lot of causal folks don't know the mechanic too well and don't know how to deal with it.

This type of abuse is really rampant on the official servers, however simply hiding the delete action behind a rank would be problematic at the beginning of a match, since no one would be able to remove misplaced objects.

Yes, the A2S_INFO is all over the place...

• dedicatedServerId instead of server name
• the map is reported as stringtable ID of the mission instead of Everon
• Game is reported as "Arma Reforger", which in Arma 3 was used to report the name of the mission
• Steam app ID is 0, which is why you can't connect

I'm sorry for the confusion I created. We were trying to get rid of ACE optionals for ZEN by using __has_include, but still have issues with file patching.
At this point it's more likely an issue on our end, since I take your word that it was fixed. Hence, consider it as resolved.

That fix actually is the root of this issue. Yes, __has_include matches unpacked mods now when file patching is enabled. Problem is that it does so regardless whether the mod is actually loaded or not.

Still, the cache is also here an issue. https://feedback.bistudio.com/T123355 would imply that the caching is done independent of whether you pass code or string.

But why don't I observe a memory leak in this case?
Nvm, bad example.

uiNamespace setVariable ["display", displayNull];
terminateOnEachFrame = false;
onEachFrame
{
	_display = uiNamespace getVariable ["display", displayNull];
	if (isNull _display) then
	{
		if (terminateOnEachFrame) exitWith {onEachFrame {}};
		terminateOnEachFrame = true;
		_parentDisplay = findDisplay 49;
		_parentDisplay createDisplay "RscDisplayEmpty";
		_display = findDisplay -1;
		uiNamespace setVariable ["display", _display];
		_arr = [];
		_arr set [500000,random 1215235345];
		_display displayAddEventHandler ["unload", {_arr = []; _arr set [500000,random 1215235345]; str _arr}];
	}
	else
	{
		terminateOnEachFrame = false;
		_display closeDisplay 1;
	};
};

Not really surprising, but passing a string instead of code to an event handler seems to have the same effect, e.g. for a display like in this test case

uiNamespace setVariable ["display", displayNull];
terminateOnEachFrame = false;
onEachFrame
{
	_display = uiNamespace getVariable ["display", displayNull];
	if (isNull _display) then
	{
		if (terminateOnEachFrame) exitWith {onEachFrame {}};
		terminateOnEachFrame = true;
		_parentDisplay = findDisplay 49;
		_parentDisplay createDisplay "RscDisplayEmpty";
		_display = findDisplay -1;
		uiNamespace setVariable ["display", _display];
		_arr = [];
		_arr set [500000,random 1215235345];
		_display displayAddEventHandler ["unload", str str _arr];
	}
	else
	{
		terminateOnEachFrame = false;
		_display closeDisplay 1;
	};
};

OMG, thx! Setting BIS_fnc_initModules_disableAutoActivation to false does the trick!

Nvm, logging revealed you are completely right. It's "attributesChanged3DEN" that gets triggered, "registeredToWorld3DEN" is for redos in the history instead. You may want to add "registeredToWorld3DEN" to ZEI to handle redos in history, since in that case "attributesChanged3DEN" does not get triggered.

Ok, that's curious, since our effect modules in Achilles, which follow the syntax used in the smoke module, still work fine when placed in Eden and we are using "registeredToWorld3DEN" for Eden and "init" for Zeus/mission start. Gonna have a look if I got time. Unfortunately, got some other issues with spawning modules on the fly with scripts, but that is unrelated to this issue...

I suspect the culprit is sectorA = (createGroup sideLogic) createUnit ["ModuleSector_F",_pos,[],0,"NONE"];. The module function of ModuleSector_F does not get called, and thus "finalized" will never set to be true. The update likely broke something in the createUnit command.

I'm pretty sure it's intentional. For instance, have a look how BIS_fnc_moduleGrenade is implemented, which is the module function for the smoke grenade module. "registeredToWorld3DEN" is the one that should be triggered in Eden, not "init".

Well, this issue has been resolved by now and can be closed.

The name attribute for the music class is not properly localized. Hence, it is not restricted to Zeus. It can also be observed in Eden.

A concrete examples may help. You can use the Ares/Achilles source code as a template.

+1 Essentially the last two commands that are missing for creating an EH that handles the enter key as a line break.

I can confirm this issue.
The "Game Master" module "Default Addons" combo box seems to be broken for certain resolutions atm (at least for x64 version).

Thank you for the fix!

Thx for fixing the issue!

@nomisum
I wouldn't say that the issue makes fog completely useless. You just have to avoid the critical region atm.

No, it can be closed.

Hello Alwin,
thank you for your answer.
I wasn't sure how hard such a feature would be to implement.

I tried to reproduce the issue by executing

Possible duplicate of T123262. Although this ticket is older, the other has higher priority, since it got assigned.

@Alwin
Thx for reviewing the topic.

I can confirm this issue. As a result, the artillery fire module does not work properly for mortars in Ares Mod - Achilles Expansion (see Github).
Note that the current category "Firing from Vehicles" is not appropriate and should be changed.
In addition, the title is also misleading as the command just does not work properly for multiple rounds.

Hi BISWizard,
thank you for the reply. Also an interesting aspect is that all folders contain the files of the most recent update, even if the folder name is refering to an far older version.

I can confirm that this issue is fixed by now. The topic can be closed.

This issue is not general for Zeus. In fact I only observed it in the official Zeus Game Master missions since update 1.62. For whatever reason compositions and most empty objects are no longer available for curators there, which is a severe issue!

Update: I probably found the error.
BIS_fnc_configPath cannot convert strings such as "bin\config.bin/cfgWaypoints/A3/Land" to type config.
(RscAttributeWaypointType.sqf, line 40)

Thank you for the notification.