Full repro (DS and multiple players required to be certain, but may also happen in P2P MP):

There's some kind of locality issue when there are multiple players in the vehicle. It seems like the railgun functionality requires the vehicle to be local, but locality isn't changing or the change isn't being detected by the railgun functionality.

The A3 default map is only a "digital" map if you have a GPS. The actual Map item is very clearly a paper map. And we now have plenty of CDLCs and such with maps that are definitely not digital, because digital maps hadn't been invented yet.

These changes haven't been introduced to the stable branch yet.

This isn't a problem with the OR operator. This is happening because the variables unit1Dead and unit2Dead aren't defined at all until you set them as true. Trigger C is attempting to reference at least one undefined variable - and silently failing - until both variables are defined as a result of their units dying. Then the trigger can actually run its check without encountering an error.

This is the same as T169494 and T126282, and a fix for that is currently on dev branch, for release in 2.14 assuming the fix works.

UI-to-texture in the procedural textures system was added in A3 2.12

This is because the onEditChanged event handler does not exist in the stable version. It's only on dev branch until the release of update 2.14, which is the next update.

The update containing the SlotItemChanged EH has not come to the main branch of the game yet. It's still on dev branch, and will be for some time. You are receiving that error because the EH does not exist in the version of the game you have installed.

I would love to see this fixed at some point. It makes it pretty much impossible to have a gamepad setup that works for both wheeled and tracked vehicles, because of the conflicting limitations of the other steering bindings. That's a real shame, because gamepad steering is a lot nicer than keyboard and mouse.

Present and correct in 2.12.

This command was added in 2.12 and is fully functional.

This has been noticed before and the answer seems to be that it is actually like this in real life. Speculatively, the wide-angle view has a large crosshair for quick acquisition, while the zoomed-in view has a fine crosshair for precise targeting without obstruction. I never did contact Bolkow to find out the real reason though.

It's not that they haven't had time, it's that most of BI's resources are now assigned to Reforger/A4/DayZ. The people on the team who would make animations are now busy making animations for other games. The few developers left on Arma 3 are mostly code and config specialists, not the developers who can make new assets like animations.

Ideally all similar magazine detail commands should get this improvement, presumably not as main syntax for back compat but as an alt syntax.

Script commands would be great too, but difficulty has historically been done through config, and I don't know whether it's practical to do mid-mission changes like that. I figured config overrides were more likely to be possible to implement.

That seems related to T166710, which was just fixed in 2.12, so it's probably worth checking again.

I think this is still a valid request for other purposes, but it turns out you can already make control groups as a built-in feature. Ctrl+<number> to create, <number> to select. It's not documented right now but it does exist.

Supporting and expanding on this.

We talked about this in Discord and I'm just summarising it here for posterity.

I had some time to kill so I tested on current main branch.
I checked with every level of Texture and Object graphics settings and observed no issues.

I haven't yet checked whether this was fixed on the original vehicle set, but I can confirm it's still a problem on the new Mi-24.

It would still be really useful to have this, as well as adding the other interesting params from the HitPart EH to HandleDamage. It would make damage adjustments and special interactions a lot easier.

Arma is reporting that Arma - and presumably also Steam - is installed directly in the desktop folder of your user profile. As in, the actual game installation is located on your desktop, not just a shortcut to it.

The notes in the previous comment still apply in CSLA 1.1.

These antennas behave more sensibly in CSLA 1.1.

In CSLA 1.1, a new retexture of the Vest was added which has a believable armour rating. However, the original Vest (now Vest (M81)) still apparently offers no armour. The other vests mentioned here still have incorrect armour ratings too.

This was fixed in CSLA 1.1.

These nonfunctional attributes are no longer present in CSLA 1.1.

In CSLA 1.1, the MAAWS and SMAAW now use an appropriate reload animation.

Since CSLA 1.1, the VG-70 no longer accepts 40mm ammo and has its own 26.5mm ammo. It did not gain magwell compatibility with GM 26.5mm ammo; I leave it to the devs to confirm whether that counts as a full fix or not.

In CSLA 1.1, flares were added for UH-60s, but not the Mi-17.
After close inspection, I believe the Mi-17's flare launcher is a small module located on the port rear door. Since the rear doors can open, moving the flare launcher, I suppose there may be engine limitations preventing this from being made functional...

This critical issue was resolved in CSLA 1.1.

This was fixed by CSLA 1.1.

Confirmed fixed in CSLA 1.1.

Verified fixed in CSLA 1.1.

This would be the UAV (IED) added in the Western Sahara 1.1 update.

Atm_01 at [3777.37,13517.8]
Atm_02 at [3281.66,12963.2]

"rev 149887" is a revision number, a change number. There have been 149,886 logged changes to the Arma 3 code before this one - see how this other fix, committed right before this one, is 149886. The current dev branch contains revisions up to 149863, so 149887 will probably be included in the next dev branch update (this week?). It will probably come to stable in the next release, but it's not guaranteed - the next stable release is likely to be the thermals hotfix, and it's possible that's already locked down for QA, which would push this change out to 2.12.

unitAimPosition is for finding the point on a unit's model that AI will aim at. This request is for finding the point in space a vehicle's FCS is currently trying to aim at. There's a little overlap in the 0 and 2 cases, but the other cases are well outside what unitAimPosition can provide - it's coming at it from the opposite angle.

The Launcher category refers to the Arma 3 Launcher software, not to missile launchers in the game.

It's missing from the 2.10 patch notes, but the files added do exist in the 2.10 release. Can be closed.

Verified fixed in 2.10.

The fix as described by KK appears to be working in the release version of 2.10.

Testing in 2.10 indicates Hatchbacks no longer have supermassive parking brakes. Can be closed.

Verified fixed in 2.10. Can be closed.

Previous report of the same issue: T139070

If it's decided to let the command accept a number value rather than just on/off, it would be useful to also allow a "whatever the config value is" number in addition to the specific modes, e.g. -1. This would make it easy to let type-agnostic scripts switch between config and override values without needing to know the config value for every potential turret.

I've got a feeling this is related: T162734

If such a system were to be implemented it would make more sense for the object deletion flag to be opt-in, rather than opt-out. This would avoid issues with backwards compatibility.

Some static objects, such as sandbag walls, don't have physics simulation at all - they're always fixed in place. You could place one in midair to begin with and it would stay there. The only possible solution for these objects would be to delete them when the building is destroyed, and it wouldn't be safe for the engine to do that automatically (it could accidentally delete something the missionmaker doesn't want it to). The best way to handle those is for the missionmaker to use an event handler or trigger to delete them when the building is destroyed.

In the instance in your screenshot, it's because the command is spelled wrong.

This is being added in 2.10: https://discord.com/channels/105462288051380224/105465701543723008/976129544425713774 (Arma Discord - community_wiki channel - 17/5/2022)

This would be very useful.

As a missionmaker, you can use the disableRandomization parameter in description.ext to disable this feature as desired: https://community.bistudio.com/wiki/Description.ext#disableRandomization

Spot lights are perfectly functional lights (source: used one yesterday). As with any scripted light source, they need to be set up with the proper commands.

It's not caused by being the last item in the list overall, it's caused by being the item right at the very bottom of the panel. You don't actually need to scroll down to see it, you just need a long enough inventory list to make sure there's an item right at the bottom of the panel.

Perhaps a more convenient(?) solution would be to allow custom CfgMarkers definitions in description.ext? Then the engine would still get its config class, and missionmakers would be able to define whatever markers they like without using a mod.

This seems like it would be pretty useful.

setUnloadInCombat might cover your usage until (if) locked behaviour is changed.

Now that we have related features such as enableDirectionStabilization, it would be nice to add some of these commands to go along with that. disableRangefinder in particular would be very cool to have; now that the Tanks DLC improvements are in, it could also be subdivided into disabling just the rangefinder readout and disabling the full FCS auto-zeroing/auto-leading functions.

The mission includes some comments with testing instructions. I guess I'll write them out here as well....?