Thank you for reporting the issue.
We will see what we can do to resolve the problem.

Thanks for reporting. After some investigation, the elevationOffset feature seems to affect the altitude figures displayed on the map, and nothing else. It is unfortunate that Livonia is using it, because the altitude figures on the map do not correspond to the true altitude in game. Therefore we created a script command setElevationOffset https://community.bistudio.com/wiki/setElevationOffset that you could use to reset this offset to 0, available with rev. 148610

Imho this is not a good solution. Let me elaborate:

First of all there are maps which use way more extreme elevation offsets. See Takistan for example, which uses (iirc) something around 2k. This makes absolute sense, because those mountains should be around 2k ASL high. Using elevation offset and not having those high elevation directly baked into the elevation model has two advantages:

• Scripts and mods do not have to work with huge numbers.
• You can have water on the map (on Takistan, this is a small lake in the north) which always has to be a elevation 0 in the elevation model (this is an engine limitation iirc)

In my opinion the height values used by scripts should not matter. The elevation offset is only for displaying a pretty (and theoretically correct) value to the user.

Take the following theoretical example:
I’m making a Himalaya map so it makes perfect sense that I want the elevation, which is shown to the user, to be thousands of meters ASL without compromising scripters and having the ability to add water features.

In conclusion there is to say, that elevationOffset has valid use cases. Just ignoring it is not the right solution. I think everything user facing (which has nothing to do with scripting, Mission making etc.) should be changed to reflect the elevation offset, because this was the intention of the terrain creator.

As I tried to explain to you, and as stated on the scripting page, current map elevation offset shows fake altitude for mountain peaks, that’s all. When in 3den mode the altitude delivered by cursor is real altitude, artillery computer shows real altitude, HUD elements show real altitude. elevationOffset is half baked feature that only brings inconsistency to the map visualisation and the actual values. There is no good solution but a complete revamp of altitude system to take elevation offset into account across the engine. Unfortunately at this stage of Arma 3 development this might not be possible.

Just to clarify, the real issue is that cursor value displayed on the map is real altitude and not fake altitude and you want cursor to display fake altitude as well, is this all what this ticket is about? Because this could be tweaked, but only this

In T160606#2267700, @BIS_fnc_KK wrote:

Just to clarify, the real issue is that cursor value displayed on the map is real altitude and not fake altitude and you want cursor to display fake altitude as well, is this all what this ticket is about? Because this could be tweaked, but only this

I totally get the issue and yes, technically all I wanted to achieve with this ticket was the latter, but it's a little more complicated:

You are suggesting that elevationOffset does not have a use-case and therefore is implemented only partially. That’s at least what I’m getting from here and the description of the new setElevationCommand-command.
I (personally) disagree with the first part of that statement. As I explained in my post above, I can see use-cases where having a „fake“ elevation is something the terrain creator wants to have. Either to make sure the map is as realistic as possible or to avoid engine limitations.
I would never suggest a full revamp of the elevation system. This would be far from proportionate and imho not even a good solution. (apart from that it would also break almost every script)

It is my opinion that in a perfect world every elevation, which is user-facing (shown to the player) in mission, should include the elevation offset.
This includes:

• everything shown on the map
• any ASL elevation in the (in mission) HUD

but this excludes:

• Generally anything that is not in mission (e.g. EDEN)
• Any AGL-values

I don’t have a full list of places this would need to be corrected, but I’m quite sure that this includes only a fairly limited amount. If I’m not forgetting about something major, most values within the HUD and UIs are AGL anyway. The map cursor and the artillery computer may be one of the few cases where it would actually make a difference.

I think it is also acceptable to just change the cases we can think about now and delay changing anything missed to when it comes up again. I mean that's all this ticket was supposed to be: a "Hey you missed to include the elevation offset here". Basically scrapping elevationOffset completely (by suggesting to always run setElevationOffset 0;) is imho not a well thought-out solution. There are many mods, (like ACE) which use elevationOffset in various places and imho elevationOffset is not a "bug", but a feature (which may have been a bit neglected tbh).

I'm sorry, I understand where you are coming from, but the reality of the situation is, I can relatively safely change that cursor elevation. The rest will require thorough investigation and risk assessment, and we do not have resources for that. So it is either cursor change only or leave it as it was for years.

I mean that choice is fairly simple. If it's fixing the map cursor or nothing. Of course I'd prefer the prior :)

OK, the changes should be active with the next dev or one after next

rev 148671 changes reverted to the original state. After careful consideration, the issue is now a "won't fix"