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.

I believe the Old Man modules are already available in the editor, so it's already possible for people to do this (with some work).

Yeah, it's super annoying trying to place minefields without being able to see the area covered, you have to turn on markers for it and then jump back and forth from the scenario preview to tune the dimensions.

Turns out it is actually a separate keybind under Weapons called "Gun Elevation Up"/"Down", which I happened to have bound to the same as the zeroing keys for reasons which remain unclear.

Testing in VR (nice straight lines for reference) reveals that all US light vehicles seem to be affected by the direction changing issue to varying degrees. My impression is that there are two problems at play:

1. Vehicles undergo a single direction shift when changing up gears
2. Vehicles undergo a continuous drag to one side when decelerating from top speed (i.e. you go from holding shift+W to only holding W)

On your last point, just like vanilla artillery, the gun can be manually elevated and depressed by using the zeroing up/down keys (pageup/pagedown by default, I think). I'm pretty sure this is just how vehicles with artillery config work and there isn't a way to change it.

This might be wrong, it seems like other vehicles do have this sound....sometimes. When I initially tested it, only the CUCV (Radio) had this sound, but now others do. Weird, may not actually be a bug.