Am I right to understand the issue here is more about wheels keep turning after keyboard input started and player opens map? So would making wheels start turning towards center be enough? Mouse/analog steering doesn't have this problem in my tests, wheels stay where you left them, only keyboard turning seems to continue to extreme.

In T158681#2268256, @dedmen wrote:

the DS does not have the contact (platform) folder:

"contact" is not "Contact (Platform)"
"Contact (Platform)" is "enoch" folder.

Everyone has Enoch, but if the server uses content from it, it will tell you that you need it (like with other DLCs, place helicopter DLC helicopter in mission file, server will tell you that you need helicopter DLC).

The question here is rather if the server somehow wrongly thinks Enoch content is in use, while in reality it isn't.

No you are correct, WorkDrive is missing Tanks.

Hello, Sorry for the delay.

"Our FOVs are customized which could possibly be the reason for this issue.

I asked a programmer and they say i might be your custom FOV, We don't officially support changed FOV.
Due to the current phase of Live Ops development in Arma 3, it's unlikely that we will be able to fix it if this is the case.

also tested on vn server with 0 mission files. just now
says i require contact

I have a vietnam server, 6 missionfiles o enoch in them , says i require contact. it will also do this on other servers with no enoch in the missionfile
there is also how every other server requires it in the launcher.
there are however at least 3 places where it will "guide " you to the buy your "missing dlc" page. looks like marketing to me.

https://community.bistudio.com/wiki/set

https://community.bistudio.com/wiki/getPiPViewDistance
https://community.bistudio.com/wiki/setPiPViewDistance

I just tested on my own server. It displays I'm missing Contact Platform, and TacOps and Tanks.
When I look into the mission file its currently running, it has "A3_Weapons_F_Enoch" and "A3_Weapons_F_Tank" so that explains two of them... TacOps is indeed weird now :D
So for your case of it saying Enoch is required. Check the mission.sqm of the mission running on the server, search for "Enoch" in it, if you find stuff, then that mission requires/uses Contact Platform content and the Launcher correctly displays that to you.

the DS does not have the contact (platform) folder:

Test script

_hm = createHashMap;
_hm set ["a", 1];
_hm set ["a", 2];
_hm get "a"

expected result is 1

Whoops, the recursion check didn't clean up after itself.
This happens everytime the same hashmap is referenced more than once in a hashmap.

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

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

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.

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

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

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.

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

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

Hello thank you for reporting the issue.
I could confirm it on our internal build.

Hello thank you for reporting the issue.
I was able to confirm the problem on our internal build, following your repro.
We will see what we can do.

Have you tried verifying your game files though steam?

Duplicate of T162475

Did verifying resolve the issue?

wait this seems a duplicate of T162471, closing this one as that ticket has a little bit more info

Have you tried verifying the game files through steam?

Did some additional testing, M3 Carbine also has the same issue

For a more clear comparison, I took screenshots of the issue.
Rifle grenade version (not bugged): https://ibb.co/FDqYG9N
Normal version (bugged): https://ibb.co/Zhb4NfZ

Rev 148609 alt syntax https://community.bistudio.com/wiki/reload

Ah yes. So not a bug then.
I'll add it as a note to the wiki.

does RPT say something like "Invalid path (only relative paths supported):.... ?

Should be fixed in 148607

Oh that's a much better idea! Thank you!

not yet?

@Tenshi I would be glad to sit in a discord call with you and try to narrow down to issue, if thats a possibility. Though im pretty convinced it should be an easy thing to reproduce. I could be wrong

Another observation : EPEContact event handlers are properly triggered, even beyond 100 meters, and as far as I know, there's no range limit on the simulation of physX objects; so the issue likely comes from some sort of limitation on infantry units themselves.

@BIS_fnc_KK :
That's a limit from the engine.

is the limit hardcoded in the function or the engine?

So should I report this to STEAM instead? If so, do you know which team to direct it to?

Should be fixed in rev. 148606

Thank you @BIS_fnc_KK! I ask about this because I dreamed of such a function for 8 years.

Can confirm backpack and headgear is never affected, only Uniform and Vest.

in new year for sure

Ok, now firemode also persists on weapon swap (Revision: 148605) please test thoroughly

Ok, now firemode also persists on weapon swap (Revision: 148605) please test thoroughly

The first link being all low graphic settings

Even with pixelated video trunk of the tree became visible at 0:11
at 0:12 branches became visible.
at 0:13 it is fully rendered.

could be due to buggy graphics driver, have you upgraded recently?

The fix has been applied internaly thank you for reporting

should be fixed in 148604

Rev 148603, customCenter param https://community.bistudio.com/wiki/setVelocityTransformation