I don't know, but as far as I see there is no good reason. You could just as easily have all the select overloads, such as _string # [1,2]. Same way you could have _string + [1,2] (I know, it's not a valid syntax)
And - is a unary command, so _arr#-_index is not gonna be confusing either.

In T163762#2343019, @BIS_fnc_KK wrote:

in 2.10
"a3\data_f\snowflake4_ca.paa" -4 frames for low texture video setting
"a3\data_f\snowflake8_ca.paa" -8 frames for medium texture video setting
"a3\data_f\snowflake16_ca.paa" -16 frames for high texture video setting

Why does it not have all the overloads select has?

Any particular reason why? I mean # is used more often than select nowadays...
And I can't think of any limitations either 🤔

no

# is not supported?

Thank you for reporting the issue, i was able to confirm it using the repro mission.

Okay, thanks for confirming that. In terms of feedback on the original ticket, the previously selected side is correctly restored as expected now.

I see, well the order of side tabs in curator is blufor = 0, opfor = 1, independent = 2 etc. RscDisplayCurator_sections was meant to follow this order and the fix made it so, so yes this new order is the correct order

Issue is no longer present, please close this ticket.

ZEN uses RscDisplayCurator_sections to get the currently active CREATE tree control (refences: IDC defines, getActiveTree function). As an example, the getActiveTree function is used by the tree expand/collapse all buttons to affect the currently active tree control (reference).

Could you give short summary what is not working as expected after the change?

Hello could you try the steps in the link below and see if it resolves your issue?
https://community.bistudio.com/wiki/Arma_3:_Unusual_process_exit#0xC0000005_-_ACCESS_VIOLATION

The fix changed how RscDisplayCurator_sections is interpreted. That is, the side value was 0 for OPFOR and 1 for BLUFOR` (like side entry in CfgVehicles configs). In 2.10 (dev), the side value is now 0 for BLUFOR and 1 for OPFOR. We can update mods like ZEN that rely on RscDisplayCurator_sections to determine the state of the Zeus trees in preparation for the 2.10 update but I wanted to confirm that this change was intentional and will remain as it is on current dev-branch.

Access Violation 0xc0000005

rev 149734 negative index is supported by select and set

in 2.10
"a3\data_f\snowflake4_ca.paa" -4 frames for low texture video setting
"a3\data_f\snowflake8_ca.paa" -8 frames for medium texture video setting
"a3\data_f\snowflake16_ca.paa" -16 frames for high texture video setting

Good to hear

Hello, It seems that your crashdump got corrupted somehow.
Could you try to play again and if you happen to crash again, add a new crashdump?

Happy to hear it worked out for you.

Hello, we checked your crashlog seems the crash is happening in combination with XAudio2_7!LEAPCORE, what ever that might be.
Are you using a USB (Wireless) headset?
If so could you try playing the game without headset plugged in or with a wired headset to see if thats the cause?

i change the game language in Steam to English. but it dosen't work. crash report sitll show Culture: zh-CN UI Culture: zh-CN.
so as this method : %localappdata%\Bohemia_Interactive Delete all folders that begin with arma3launcher.
i think this launcher is hopeless

Ok I got it.. I can see where its crashing, but not why.
It doesn't make sense.

These are good captures
Sadly the first 4 are still stable branch, looks like its all the same as the last one I checked. But cannot really see whats going on.
And the new ones.. ugh.. you renamed arma3serverprofiling_x64.exe to arma3server_x64.exe, That just turned this from easy to really annoying

More crashes recently

I'm talking about however it tracks ammo could be used to modify the fouled-up way that magazine weight is calculated.

Thank you for your investigation and giving the solution.

Ah I thought you said it crashed when you wanted to start the game.
Well try this then:
press Win + R and type this and press Ok:

%localappdata%\Bohemia_Interactive

Delete all folders that begin with arma3launcher.

The load value of inventory things is not the weight of the item it is like volumetric weight, so it is not as simple as dividing max value and value remaining.

steam always star ARMA3 form launcher. but launcher crash before it show up

but i can't even make it to the luncher

Culture: zh-CN
UI Culture: zh-CN

thanks for the reply
unfortumately, it didn't work

Can't be replicated.

Both M60s are firing but due to a engine limitation it's not possible to have duplex tracers on a machinegun turret on a helicopter (UNLESS we make them as gunpods, which means no gas fx and no shellejection fx which are more important for these guns than say the external swivelmount m134s).

We switched to profiling branch and it wasn't crashing for a couple of days, but today it did again

There is a script that sets simple object params from vehicle config, you can compare that. AFAIK the data was gathered manually by one of the designers

Can you post new crashlogs with the USB headset removed?
If the issue isnt related to the headset we might be able to see something new

Found a solution: After digging online installing Microsoft Visual C++ 2008, 2015-2022 seemed to be the fix. I’m unsure which one was the actual fix but I installed them all.

Did all the steps from https://community.bistudio.com/wiki/Arma_3:_Unusual_process_exit#0xC0000135_-_STATUS_DLL_NOT_FOUND. I even tried going to back to a restore point on windows from 3 days ago. Nothing.

The solution is presented on the following StackOverflow question:
https://stackoverflow.com/questions/50970449/error-800700c1-in-instantiating-an-object-for-microsoft-office-interop-excel-a
Deleting the file "C:\Program" fixes the issue.

The modified gas block on SOG:PF M14A1 is solely to have the sling appear attached to the proper swivel - real-life M14A1 uses same gas block as the regular M14, and the different part on the SOG model is in fact the clamp mechanism of M2 bipod, which fits both variants of M14 rifle. Solution number two (separate bipod entity for M14) would be preferred.

Since patch 1.2 added M14A1 rifle, it might be interesting idea to allow it to use same optics as the M14/M21. That's because M14A1 was also used in a sniper guise in Vietnam. Used in very limited numbers by LRP company of 4th Infantry Division these rifles ditched the heavy M2 bipod (replacing it with a M16 clamp-on bipod), and (as evidenced by one surviving example) had the front-grip assembly removed, with a more traditional sling swivel appearing in it's place. They still had the pistol-gripped stocks and characteristic muzzle devices.

Verifying ArmA in Steam, reinstalling DirectX/Visual C++ and running the File Check Tool did nothing. However, I ran the 64 and 32 bit version of Microsoft Dependency Walker and got a ton of errors for several hundred DLLs for the ArmA EXEs. Same results for ArmA 3 Tools and the Publisher EXEs.