Can be closed. Issue was that the server executable wasn't up to date yet...

Add -forceUpdate to launch params

I have not found a vehicle that would spawn without the hand brake on. Or has anyone followed a car that rolled away and went in to driver seat to check and then found that hand brake was off.

I double checked it in the workbench and you're correct that they do spawn with the handbrake on. I would argue that the issue is in fact how the handbrake behaves on neutral gear. When I use GM to drag a car to a slope with the handbrake on, it will not slide down when I put it on 1st gear, but it will when I put it on neutral. Ofc cars spawn in neutral, which leads to OP's issue. The ticket's title and description should be updated accordingly.

The video above shows the old spawning system, but the newer building mode has the same issue. In fact any editor mode has this issue, hence also GM.

It also doesn't seem to get removed when someone falls unconscious while bandaging. For instance, you can shoot an AI in the leg and then keep shooting until they fall unconscious while they try to bandage it. You won't be able to bandage it, but you can verify in GM that they are still bleeding. This can even be reproduced without peer clients.

Thanks for the update. Tbf. the AI has gone through many revisions in the meantime and I don't think I've seen the problem pop up in practice recently. It might still be reproducible with the setup above, but it was a ridiculous setup to begin with just to make it reproducible.

Should be closed, since duplicate of T184289

Can be closed as resolved.

I get a new error now with the very same set-up as described in the repro:

07:43:28.112 BACKEND   (E): [RestApi] ID:[3] TYPE:[EBREQ_WORKSHOP_GetDownloadListS2S] Error Code:503 - Service Unavailable, apiCode="", uid="", message=""
07:43:28.211 BACKEND   (E): Failed to fetch addon details from workshop API! Repeat later or try different mods.
07:43:28.410 ENGINE    (E): Unable to initialize the game
07:43:28.430 ENGINE       : Game destroyed.

Was just a temporary thing. It falls back to the old error again.

Correction, the repro still produces crashes when done with a peer client. I updated the repro accordingly. Latest crash ID: d1fe2423-714a-4d00-bd30-43ed8f2fbc1a.

In T181447#2631970, @veteran29 wrote:

The crash is caused by doors in doors info list perhaps the game could handle this more gracefully or at least report something to logs.

Thanks to NiiRoZz for the information.

Can be marked as resolved, since it was added in the meantime.

RoadNetworkManager has been implemeted on experimental. It's now possible to query roads and get their width and points.

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.