Here is a movie:
https://youtu.be/pVOK08AnR-M
Here are config files:
https://drive.google.com/file/d/1S9d2TI3GdKxXFjRNHT9jQNbCspDwmvGV/view?usp=sharing

Additionaly I can say that fadeDistanceSpan seems to be really about 10 meters.
But fadeDistanceStart as I wrote earlier is about 100 meters and I can see tags through objects (even on the distance 100 meters).

Hello Wulf.

And still nothing changed.

Should be closed.
It is dobled by this one:
https://feedback.bistudio.com/T117044

And hardcoded, and hardcoded, and hardcoded...
What is the point to give to the player ability of camera movement configuration if significant part of basic keybord can't be used?
Or maybe I don't know how to configure this?

After last patch: all key bindings in Eden are still hardcoded.
Question: why you give to the user choice of settting camera movement if you don't respect it? This is simply speaking stupid. Remove this section in key configuration (Editor camera) or make it usable.

Keyboard is still hardcoded to some Eden elements.
Now it seems also F is hardcoded to switching to next unit or center on currently selected one (i don't remember).

Still not work. I've check it also on other PC with clear installation and new player's profile.

After Apex nothing changed.
Still E and R are hardcoded.

It may be connected with those messages from log:

Well... if this is intended, please close this ticket.
Honestly i am not sure why it is done this way (especialy slowing down over the rocks and during passing line of water) also what are usabilities of those features but i belive you know what you are doing.
Regards

I have also this problem. I confirm it happen after last update.

I am not sure you understand a problem.

It generally should works like it works with exception if LShift+some_key is detected as pressed combination, "hold breath" (or other action - no matter) shouldn't be made if it's binded under LShift. What can i tell more?

Possible fix is to add some timer in function which detects keypressings to avoid of making double actions. I mean, there are possible combinations some_key+other_key. It means they must be somehow detected. This detection should be just more precise.
I suppose this can be reproduced also with other "alternation" keys.

To lean i use toggle mode. It means when i hold breath i use just "hold breath" key (one at the time).
I just claim keybinding execution is not so good as it seems to be.

Do you really consider it as not a bug? This isn't critical one of course (other side this is communication interace...) but i suppose it can be easily fixed.
I can add another one in this scope: "hold breath" doesn't work with combination 2x some_key.

Because of character of the game i have binded about 80% keys from keyboard and mouse (i don't mention about alternations) and OFTEN i use more than 50% from this. I have big problem with usefull binding of all activities. This is a real problem.
But not in this topic.

This is really simple matter (in fact i am suprised nobody discovered it earlier).

Here is detailed procedure with my expectations:
LShift = hold breath
LShift + W = lean left (toggle !!!)

I want ONLY to turn on lean left mode by single pressing LShift+W (after release, character should stay in this mode).
Nowadays: When I press LShift - I start hold breath, when I press W - I go into lean left mode. After release LShift+W I stay leaned and I stop hold breath.
Expectations: When I press LShift+W - I start lean mode. When I release LShift+W - nothing happen.

Problem is that additional activity is made (in this case it is holding breath, but it can be also in worst case trhowing a grenade).

Key word in this case is TOGGLE. I am absolutely agreed when it is not a toggle, then everything is OK. But I have TOGGLE in mind from the very beginning. I will undersore it in first post.

I am not sure what do you mean but in my opinion making of LShift+W doesn't disable separate LShift or W.

I hope now everything is clear.

Add. Bug 1:
After update to 1.55.133446 this bug doesn't exist.

Add. Bug 3:
I figured this out. Car with MG i had added was emtpy FIA car.
I had to move it to OPFOR group first (on Entity layer) and then move crew to this car.
However this isn't too intuitive. Shouldn't be empty car always added as aneutral object?

Add. Bug 4:
I've just notice, this happen during turning back from mission testing to eden editor.
This is part of the log from this period of time:
14:57:10 EPE manager release (42|174|0)
14:57:10 Number of actors in scene after release: 42
14:57:10 EPE manager release (0|42|0)
14:57:12 Attempt to override final function - bis_functions_list
14:57:12 Attempt to override final function - bis_functions_listpreinit
14:57:12 Attempt to override final function - bis_functions_listpostinit
14:57:12 Attempt to override final function - bis_functions_listrecompile
14:57:12 Attempt to override final function - bis_fnc_missiontaskslocal
14:57:12 Attempt to override final function - bis_fnc_missionconversationslocal
14:57:12 Attempt to override final function - bis_fnc_missionflow
14:57:12 Attempt to override final function - rhs_fnc_findangle
14:57:12 Attempt to override final function - rhs_fnc_calcbalistic

My apologies. I was wrong. Please remove this ticket.

I knew something is wrong in the woods!
Do you have any info the same situation occurs with the bushes and tree top?

I am also curious if you really use more than first "page" of this menu (i don't mention some actions are placed on the last one...) and if yes how you figure out what is what?

Well...
Don't be so sure. Most of my tickets are "new" :)
However recently i've noticed something very interesting.
I've made this ticked:
http://feedback.arma3.com/view.php?id=25444 which is "only" acknowledged and in 1.53 i've noticed AI which uses FirstAid!
Back to the topic.
I think this menu will not be fixed as a separate task.
Whole menu system should be replaced and probably somwhere in the future it will happen. But i am not sure if this is near or far future.

And you see how many emotions on dev side... Maybe it is worth to silence all those malcontents like me with solving this issue at last?
Your voting against this report may be understood like voting against the problem.
Besides i suppose this is ENG forum.

I see you forgot about such simple physic mechanism like tilting which should solve this situation.

TheMasterofBlubb your intention was to write "would be to hard" or "wouldn't be to hard"?
Because if like in original sentence i suppose you are joking.
The simplest way to implement it will be to replace obstacle which has a contact with a much heavier object with debris. Yes it wouldn't be elegant but it would work and effect would be much more playable than lack of such mechanism.
Other way is to segment obstacles (Bohemia prooved that they can do such "sofisticated" things).
Then my statement is such mechanism is at most moderate to introduce for proffesional team. Much more work is with segmentation of object (however it should be rather simple ant-work).

Well, this is strict academic discussion.
Engine of Arma3 is about litlle bit less than 15 years old and currently this is quiet funny there is no such things like obstacle destruction.
If you mention that Bohemia has a reason to not introduce small obstacle destroying, then as a programmer i can say that something is screwed up in the engine (if it is). I don't see any other reasonable cause.
You ask me about size of the team... well i don't know, depends how many seniors :). Often i really don't understand some decisions of BI: eg. they develop some not necessary islands instead of improovement and polishing physics (yea! money!).
Anyway tank movement is bugged and those are at least moderate bugs.
Regards.

ad. 1: i realy can't reproduce it - forget.
ad. 2: look at this film
https://www.youtube.com/watch?v=qaXKh0A04gw
ad. 3: look at this film
https://www.youtube.com/watch?v=6B4yy5iKlb8

Additionaly, this is quiet funny behaviour:
https://www.youtube.com/watch?v=vxyMJ1b1I44

TheMasterofBlubb, i can't agree that tracks have no friction. At least front part of them have. Besides i have strange impression that until i go forward on vertical part of T, trackss act like they have contact with groung and after stop they act like they have not. And additionally tank was, i don't know how to say it, "snapped" to problematic position.

Sorry for big delay.
To the point, here is video:
https://youtu.be/3BLKUBrlhk8

I tried drive best i can (i made some excercises).

Please notice especially two fragments:
0:32 - i try to pass soft curve. As you see car is oversteering (it is proper in rear-wheel drive) however i have big troubles to counter with a steering wheel (mouse) to compensate those force. Mouse is just to responsive.
1:30 - I little bit forced a slip and then tried to back to the road. Of course tree finished it quickly, however once again my swings probably would be bigger and bigger and would cause finally 180 degree turn.

In both cases moves of the mouse on the table were around 2-4 milimeters (i have not too sensitive mouse).
I tried to figure out how fast i have to be and i noticed this problem escalates near 180-190 km/h (my top speed in SUV was about 225 km/h). Below this spped steering response is fast but able to control.

What i am trying to say is that counter with a mouse influence the direction too much.

I can't reproduce moose test. Forget about it.
And one additional remark: i'am not specialist, but shouldn't front crash with 200 km/h end with instant dead?

My mouse settings:

revMouse=0;
mouseSmoothing=3;
mouseAcceleration=0;
mouseSensitivityX=0.86363655;
mouseSensitivityY=1.0438869;

Used mods: none.

Well, probably this is quiet subjective, however i have real problem with steering with high speeds using a mouse. BMW-like car overreact on even small movement of mouse. Because of this there is hard to make a wide smooth turn. I will try to make a video with this.

Additionaly this BMW-like car often fall on the side when i make a "Moose test" (i think i can do it easily with the speed about 80-100 km/h). This is quiet funny.

I really don't understand you.
I don't need any commands. I just want to smoothly iterate over soldiers in equipement view without unnecessary and time consumable actions.
OFP has this feature and there were no problems at all.
Thats all.

3 times multiplied by number of soldiers...
Don't count it as a simple clicking. Yes it is hard and time consumable and can be simply improved.
First of all A3 is a game, after that is a sim.

Read with understanding.
In real world i have this info much quicker just by asking soldiers how many magazines they have.

Thank you for info - link has been fixed.

Here is video with this phenomenon:
https://www.youtube.com/watch?v=K_udocV634I

It doesn't work in this way since OFP. Rather since some patch in A2.
Simply lets try to change speed with command from fast to normal (with one key press).
AFAIK pressing twice slow does not result with normal. But i have to check it.

Simply speaking - inspired.
Freelok, veh steering, aim zooming... Wow if i would have such options it would be splendid.