The function is being called from GesturesMenu.CloseMenu publicly, instance.OnMenuRelease(); with instance being static GesturesMenu instance;. Which somehow bypasses the access modifier.

Just to be clear, my motive on replying to this thread was because I was wanting to inform its participants on better testing practices. When I had the time, I decided to go looking through the logs to find a reference that would allow me to take a look into the mod having the issue for additional advice to provide as potential a workaround or feature reduction without impacting functionality. Initially, I ignored the workshop description and took at peek into the obfuscated mod, but backtracked after certain assumptions seemed to solidify in my mind as I browsed through the files. I resorted to reviewing the workshop description primarily to see if any discussion was made about the issue on potentially a VK page or a Discord server.

@Geez given the prefix from the RPT, the mod is Forest Fortification, which the workshop version is obfuscated with a tool that provides a lot of junk and noise across the archive, scripts, rv param files, and p3d reference paths. Though the issue still resides given the logs provided were from a build that was not obfuscated.

@ArtemDozhd my comment was more targeted to @vkantik @NeoGame and @OldManvape. With less than a week from stable going live, the build that will be published has already passed review for internal QA as well as for console's review and stability testing from Microsoft and Sony. There was no time for the bug to be verified, fixed, tested, and be re-approved by primarily the console review process before the announced release date of 1.27, which is now tomorrow.

1.27 went onto experimental on 13 January, 40 days ago, waiting until a week before it goes live to test and requesting a niche issue to be fixed immediately; isn't good testing. Bohemia gives us plenty of time to test our mods and report issues between versions.

https://feedback.bistudio.com/T169112

You're asking for help from the company that you're breaking the EULA with on fixing your DRM implementation?

Thank you, I'll admit I didn't even try it, as it was not on the wiki. I'll have the wiki updated to include this launch parameter.

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