This can probably be fixed easily by updating BIS_fnc_setUnitInsignia to use the new string-based selection targeting for setObjectTextureGlobal, instead of searching for and then hard-saving the current uniform's insignia index.

Confirmed fixed in 2.18

That command isn't for that type of camera locking. It's for when something's been locked with lockCameraTo, which is a different system to the aircraft camera stabilisation system.

There are reports that this can also happen when the unit does a gesture partway through a reload. (See: Arma Discord > arma3_feedback_tracker)

I think you need to read a bit more carefully.

Using getArtilleryComputerSettings makes sense for players, but I'm not sure how it'd work for AI artillery since they don't use the UI (and there can be more than one of them on a machine). I'd prefer to have a solution that can also work for AI.

I think they want the ability to use the child object's selections as the reference point. The existing selection stuff is only for the parent.

Same as T166771

Confirmed fixed in Reaction Forces 1.0.1

In T180386#2591358, cryptearth wrote:

... The base model has six spots ...
... the original Offroader ...
... The new RF variants have just replaced the middle two spots from exterior with interior - likely without touching the two rear spots at all. ...
... the RF variant ...

I think the weapon is the 20mm nose gun of the RAI-360M, and the issue is that the name text is excessively long for the display.

Update: while it's possible to sort-of use a Medical case as a substitute for its non-Medical equivalent, by removing its medical symbol texture, the Medical cases actually have attendant=1 in their config, meaning they are infinite free full health suppliers. This isn't always desirable. This makes this issue a little more annoying than I previously realised, because my intended workaround doesn't work with this.

Don't worry about that response, it's an AI-generated spambot.

No, that's correct. "Lase" is the verb. To lase something is to use a laser on it. "I'm going to lase the target", "I'm currently lasing the target", "I have lased the target".

This is being added in 2.16 for deleteVehicle. Makes sense to add it for other types too.

I'll always be in favour of making hidden texture variants into real items - especially for vests and helmets where setObjectTexture can't be used.

Likely the same as T175731. A fix for that is currently on dev and profiling. If you are on dev or profiling and are still seeing this, make sure to mention that.

Also, please don’t ignore the second part of the problem, I see no one wants to discuss this.

It's not being ignored. It's the same problem and can be fixed as part of the same change. When the Logic Entity is assigned to the correct side, the icon will simply not appear at all.

The blue icon does not belong to the character. The blue icon belongs to an invisible virtual Logic Entity. The virtual Logic Entity is created by BIS_fnc_ambientAnim for technical reasons. The function has a mistake, which causes the virtual Logic Entity to be a BLUFOR unit, instead of belonging to the Virtual side.

Further investigation:

In T174022#2522941, @BIS_fnc_KK wrote:

he can manually eject from seat to parachute

Should this be possible at all? Can you leave ejection seat in real life in flight?

It would be convenient to have this, since inGameUISetEventHandler is the best/only way to detect the use of action menu actions, and not being stackable means it's not very safe to use.

I'm not able to reproduce this - the Darter is behaving normally for me.

Probably the same as T175731, which is fixed on the experimental branches for the next update.

Just applying the callsign stuff to the existing speaker indicator, the same way it applies to text chat. (see also https://community.bistudio.com/wiki/radioChannelSetCallSign)

getPlayerChannel, currentChannel and setCurrentChannel were added in 1.42, which seems to cover everything requested in this ticket.

This was resolved by the addition of radioChannelInfo in 2.00

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.