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....?

You should refer to https://community.bistudio.com/wiki/Arma_3:_Server_Profile (to ensure your custom difficulty profile is set up properly) and https://community.bistudio.com/wiki/Arma_3:_Server_Config_File (to ensure the forcedDifficulty parameter is set to use your custom difficulty profile, or to use a BI preset that allows third person)

I believe this was introduced with Contact. My impression is that the cause is the physics hitbox of the wreck model being extended well below the visual model and clipping into the ground - you can also find the wrecks appearing to float in some circumstances.

This was fixed in 1.84. (With a citation of this very ticket! https://dev.arma3.com/post/spotrep-00081)

This still happens in the latest version. It's very irritating, since the screenshot command is otherwise the best way of getting screenshots at full render resolution (e.g. getting 4k screenshots by running at 200% render scale) - most other methods just capture at screen resolution.

These commands may be what you're looking for:

@Maarten er, you'll forgive me if I don't quite buy that, because both other CDLCs have animated textures for their non-sea-level water.

Okay, I spoke to one of our server wizards and this is what I got:

I can double-check (this may take a bit), but since we use Steam for updates and such it would be pretty wild if there was no connection.

It seems like they're also describing a problem where flyInHeight commands below 10 metres will prevent subsequent flyInHeight commands for higher altitudes from taking effect.

I am aware of that. However, I would still have to hunt down and test every building on the map, in-place, which I don't have time for.

I have only observed this on a Linux server, although this is not proof it doesn't happen on Windows since I only regularly play on a Linux server.

This would still be good to have. If an alternate syntax for the existing command isn't possible, it could be done as an additional command the same way as addMagazine/addMagazines, e.g. addItemsToBackpack.

We have also had this happen repeatedly over the last couple of years. We've never been able to get a reliable repro because it seems to just come and go pretty much at random, with no changes at our end. It doesn't seem to depend on a particular mission; it's server-wide when it happens, affecting all loaded missions, and we've never found any one mission that causes it to appear. Sometimes it happens to every unit in a mission, sometimes not. Sometimes it happens only to units created by script after the mission starts, sometimes not.

In T159565#2212539, @Leopard20 wrote:

It works just fine.
First of all, the command takes local args

__has_include was added in 2.02 and has been working fine since then.

Is it really not possible to have a full-body system similar to existing turrets like the vanilla raised M2s or offroad technicals?

Testing suggests this was fixed at some point.

Nothing at all! I just didn't know about it.