For ACE All in One, we just override a config without making any actual changes to it.

Also crashes when replacing

//------------------------------------------------------------------------------------------------
class ConcreteContainer : IContainer<ConcreteElement>
{
}

with

//------------------------------------------------------------------------------------------------
class Client : Managed
{
	protected ref IContainer<ConcreteElement> m_pInstance;
}

so subclassing the container is not even necessary for producing a crash.

There are some indirect approaches via character command handler to force weapon fire:

//------------------------------------------------------------------------------------------------
modded class SCR_CharacterCommandHandlerComponent : CharacterCommandHandlerComponent
{
	protected bool m_bACE_ForceWeaponFire = false;
	
	//------------------------------------------------------------------------------------------------
	override bool HandleWeaponFire(CharacterInputContext pInputCtx, float pDt, int pCurrentCommandID)
	{
		if (m_bACE_ForceWeaponFire)
		{
			if (pInputCtx.WeaponIsRaised())
				pInputCtx.SetWeaponPullTrigger(true);
				
			m_bACE_ForceWeaponFire = false;
		}
		
		return HandleWeaponFireDefault(pInputCtx, pDt, pCurrentCommandID);
	}
	
	//------------------------------------------------------------------------------------------------
	void ACE_SetCanHandleWeaponFire(bool canHandle)
	{
		m_bACE_CanHandleWeaponFire = canHandle;
	}
	
	//------------------------------------------------------------------------------------------------
	void ACE_ForceWeaponFire()
	{
		m_bACE_ForceWeaponFire = true;
	}
}

However, this approach does not work when the weapon is lowered, so it's not good for features like weapon cook-off.

Turns out there is already a ticket for it: T166418

Also still a thing in Reforger, but typedef can be used as a workaround:

ProvokeTypenameIssue(TIntArray) //no problem

I just realized that there is technically already a syntax for it the code base:

class SCR_Sorting<Class T, SCR_SortCompare TCompare>
{
...

but it doesn't seem to be enforced, as the example below still compiles:

class WrongClass
{
	static int Compare(Managed left, Managed right);
}

Thanks for the reply. Looks promising!

Changes were made so that type in JSON is basically cast into script variables if possible.

Does this mean that parsing for other types that defvalue supports will also work?
Like "VETERAN" for EAISkill or "0 1 0" for vector or "0 1 0 1" for Color?

modded also doesn't work:

class test_base<Class T> {};
modded class test_base<Class T> {}; // Throws error

Fair enough. I stick to your suggestion then, thanks!

I thought the point is to pave the way for the future, so backward compatibility should be secondary. Also to consider is that the "default" generators sampling floats from 0 to 1 in modern programming languages are also execluding 1: random.random() in Python, Math.random() in Java, Random.NextDouble() in C#, etc.

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.0", desc: "My mission header float variable")]
	float m_fMHT_myFloatVariable;
	
	[Attribute(defvalue: "false", desc: "My mission header boolean variable")]
	bool m_bMHT_myBooleanVariable;
}

Nice, thanks for the update!

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