Can be closed, as it can be fixed by enabling AutoHierarchy on the RplComponent (since 1.3.0.76).

Can be closed, since EnumBitFlag attribute has been introduced in 1.3.0.x.

What is now clear, is the problem is really due to the way trucks spawn. They start in the air slightly, and are dropped and bounce, thus the handbrake is unable to arrest their movement before momentum and gravity take over.

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.