Default values are not evaluated, this has been an issue for as long as I can remember. It's not entirely useful for me, but I'll follow the ticket.

Would you be able to have one of the team members provide a brief technical summary of the issue and its resolution? Out of all the bugs I've seen in enforce script, this is by far one of the most peculiar, inconsistent one to date.

Bumping this with the expected changes.

Expected output should be a string, can even be the same format as what's used in Workbench.

This is the final fully working solution. which is still not pretty.

modded class BuildingBase
{
	private int ConvertComponent(int srcComponentIdx, string srcGeometry, string dstGeometry)
	{
		string selection = GetActionComponentName(srcComponentIdx, srcGeometry);

Nevermind this solution doesn't always work, due to some twin doors not following the naming scheme and order in CfgDoors.

This was the most "efficient" solution I could come up with to solve this problem. Not sure if this would support all modded buildings I'm unsure if they'll follow the same naming scheme as vanilla. Was an annoying issue to solve since component name and damage zones from the parameters never seemed to be consistent across the following:

• CfgVehicles {Type} Doors
• DamageSystem.GetComponentNamesFromDamageZone
• Object::GetActionComponentName(componentIndex, LOD.NAME_FIRE)

I know buildings are not supported via the official object spawner, but was using it as a test bed. I'm only using vanilla types and models. But it seems like any P3D not using autocenter 0 seems to have an offset when spawning with CreateStaticObjectUsingP3D. I've created a simple test to prove the difference. Attached is code an the local watched variables for the object transformations. The typed object stays true to the original position, while the P3D only one does not. It also seems like you're unable to move the P3D static object after it's been created either through SetTransform or SetPosition.

@LBmaster this issue fell out of bound of the development cycle due to how late we reported it. In fact this issue existed in the first experimental build of 1.21 but no one tested or reported the issue until it was too late. By the time we reported it, the final experimental update was already approved and was prepped for publishing, and the fix for this was still in internal testing through QA. The timing of this doesn't fall on Bohemia but us for failing to utilize experimental to test our mods.

Changed: Reverted clothing mid classes change as it was breaking vanilla clothing balancing mods

This change shouldn't be reverted, the claim it breaks 99% of the clothing mods on the workshop is preposterous, as mods that add their own clothing already define their own inventory slots. Keep this change for 1.21, as this is something I've been wanting done since 1.0. Mods that are affected are mods that redefine existing types and overwrite things like cargo size and defined repair kits.

Of course just about anything is available through modding
https://www.youtube.com/watch?v=TNcsZAJ-DG8

I've been using a work around with POST request and setting custom headers, but this only works for POST request, as by default SetHeader only sets Content-Type headers, using this work around with GET requests fails, because GET request by standard does not have a request body, which is why SetHeader is ignored.

In T151046#2146091, @Geez wrote:

Hello LBmaster.
Can you please check the vanilla scripts? As we are using this for barrels, stashes or vehicles.
Regards,
Geez

Alternative solution, which is incorrect and a workaround, is to lock inventory from script on child items, which is unnecessary.

Merged into duplicate ticket above. Can close this feedback as duplicate.

Clothing attached to 'CoatRack' still show the cargo when attached.

I don't know what I didn't think of this. Completely forgot about the Param data type, and honestly got it confused as a Tuple, because of how long you can make them. This should actually suffice, I feel quite stupid now.

I agree it would be nice, but that could be a lot of unnecessary network traffic if you have a bunch of entities that store string data to be synced to the client when within network range.

This is the original action script, I haven't changed it. But UseMainItem and MainItemAlwaysInHands is part of 1.07, I've yet to test the changes to actions there, but I'll check to see if it makes any difference.

I know this is subtle, but it's something that bothers me too.

This would be extremely helpful for those who want to make configuration files that are easy to read for humans and computers!

Here's a video for example: https://streamable.com/zugig