There is some spilling because of the effect described in this ticket https://feedback.bistudio.com/T120542 under b) that gets magnified when bullet damage is too large. When bullet damage is reduced however it can be mitigated. Both issues should be fixed imo.

Not necessarily true. The wiki could have been right, but some change in development resulted in the handledamage beeing changed (possibly unintentionally) to the state it is now.

For an equivalent usability this replacement needs one more feature - the damagestates themself need to be usable as animation sources in model.cfg, like the Hitpoints currently are.

Alternative (more workintensive) to untangle this issue: define damage states independantly, that way we can get rid of Hitpoint dependency entirely. https://feedback.bistudio.com/T121856

Dr. Muerrte, this damage system works the same for everything. Infantry and Vehicles.
This has nothing to do with bloody tactics and stuff - it is a large issue for reliable damage modelling (which has plagued combat in A3 a great deal), especially when trying to improve the damage models by making firegeometry and hitpoints more detailed - which is what i'm doing for a total conversion, otherwise i would have never bothered to investigate deeply how the damage actually works.

suggestion: Put a delay in the AI's retargeting procedure, so it keeps its crosshair on the target until a burst is complete. While this does not solve the "issue" (which comes due to the fact that AI bursts are implemented as long mechanical burst, which means all rounds will complete no matter what), it solves the issue of AI shooting unintentionally at friendlies or into the environment, after their target has been killed.

another issue that relates to "invulnerable" infantry / inconsistent damage to infantry comes from the way the dependencies in the hitpoint systems are defined. https://feedback.bistudio.com/T120765

Then decouple the updating from setHit and give us a script command that enforces an update to the hitpoints, so the hitpoints we read with getHit match the internal values, and also trigger hardcoded game functionality (death, handshaking, limping, vehicle engine damage, etc) in case a child hitpoint was damaged enough to trigger the parent.

It might be arkward, but it is alot less arkward, than setting damage 1 to the Neck of a soldier and have nothing happen. One look at the Hitpoint configs will tell you what hitpoints you should damage and which ones not.

It's very irritating.

it would also make artillery more realistic. Right now, without cover, the 155 covers a huge radius where everyone just dies or gets seriously injured from one hit, making artillery and other explosives way too strong against infantry.

mismatched decimal symbols - doesnt that depend on system/user settings?

FIRSTLY steeringwheel animation source for TankX and throttle Animationsource for PlaneX needs to be fixed! They don't work but are very important. Particulary for TankX vehicles that are not enclosed. Throttle animation is also important for animating the engine on the plane properly. Related http://feedback.arma3.com/view.php?id=25207

rpm source also need fixing for PlaneX simulation (ticket #17020)

Scratch the engine and oil temperature thing and exchange it for a direct link to the bodyheat, the one which is used for FLIR (vehicles and humans alike)- it is already simulated (basic but still), so why not utilize it directly?

A usefull thing would be acceleration animation sources (time derivative of velocity) for all sorts of stuff. Preferably for all 3 translational directions (in model/object space) if available, but at least for forward acceleration. PlaneX have all the 3D data, it would be nice to be able to use it.

it would also be really usefull to allow integer division for animation sources, so that the floating point gets deprecated.
Say, if you want to make a digital clock you have to write a complex script and do constant updates, when all you want is to display digital values

For the 1minute digit you want the floating point value as integer, for the 10 minute digit you want the floating point value/10 as integer. Especially for animationsources that are 100% floatingpoint like ammo count for ammo counter displays and such things.

For weapons we could really need an animation source for having the weapon holstered or not. It would be very usefull for weapons with folding stocks or other collapsable stuff (e.g. LAW AT Launcher).

Rotation of the model in the world around all 3 axis in modelspace would also be very usefull to have for every simulation class, not just planes& helicopters

This is a different matter.
If you set hideProxyInCombat=0, you disable the option to turn in/out for the entire vehicle and every passenger will be forced to turn out, not just the driver. For some vehicles this may be usable (single person vehicles), but for others this is no good.

It doesnt fix the problem that you can't kill a driver by penetrating shots when he is turned in in a normal tank, because this command is unusable for a normal tank.

i support this, my custom weapon uses the old sound because it was very fitting. The new sound doesnt really fit to the weapon

I dont get motionsickness from it, but it's unrealistic.
If you feel acceleration there is no wild shaking. Shaking only occurs if you have turbulences, and acceleration in random directions in short order.

Or does your entire body shake if you accelerate in a car? No it doesnt! Same with an airplane or helicopter. Remove it. Replace it by blackout/redout viewlimitations if you must.

A flag is a very simple object. Clothing, Truckcovers etc are not so simple.
I'm against it. Attention to detail is better invested elsewhere.

Instead of a fixed cone, a config value for radar cone angle would be very usefull

They should instead just overhaul the goddamn action menu. This thing you propose will not fix anything. You trade one inconvenience for another (accidentally placing explosives vs. no space in vest to put explosive in it).

Instead they should make explosives deployable from the gear menu and remove them from action menu. Placing explosives isnt something you need urgently all the time, like firing a weapon or throwing a grenade is.

i had a look at the physx source code in the hopes to maybe find something valuable, but the solver and all that is fine. It's, like i assumed earlier, the clutch that is the sole problem.
I would have hoped to offer a simple solution but adding new controll inputs into the physx framework is beyond my limited programming abilities.

BIS needs to implement a way to modify the clutch strength depending on drive situations, because i dont see Nvidia pulling their finger regarding this.

Especially not now since the code is accessable with permission to modify to nvidia partners.

I guess i was wrong to say the operation of the clutch is properly simulated with physx. I did more reasearch on this topic and started a topic on the nvidia physx forum.

It seems to me as if the characteristics of the physx clutch system are responsible for this problem. In case you stand still and give thrust the resistance produced by the clutch can be so high that any acceleration of the engine is prevented.
Here is the topic https://devtalk.nvidia.com/default/topic/764824/physx-and-physics-modeling/clutch-strength-question/

I compiled the whole thread in the physx forum as image (4MB) as i can't figure out how to make it viewable to public and have gotten no reply from the forum guys
http://abload.de/img/compiledeqsy5.jpg

Vehicle turbo does nothing but to change throttle to 1.0 (or to whatever value it is set in the config). If you do not push "turbo" you don't drive at maximum throttle. It's an illusion, the turbo is not a turbo, it's standard throttle. The regular accelerator is a retarder instead, not applying full throttle.

To have a kick down effect give you any use it requires a proper working clutch in the first place. And kickdown doesnt solve 0-speed torque. It can only improve the acceleration once you are in motion, depending how efficient the autogearbox operates. Right now all of them operate very efficient so this wouldn't have a big influence.

i think i found the underlying problem in the physx implementation of the clutch.
Let's hope Nvidia will implement a solution in a timely manner so it can be fed back into Arma 3

https://devtalk.nvidia.com/default/topic/764824/physx-and-physics-modeling/clutch-strength-question/?offset=7#4277592

Edit: for some reason my posts are hidden, will try to unhide them so you can see the discussion

no it isn't related. Faster tanks (e.g. Moira) also have this issue. With the slow acceleration it takes longer to get out of the banana-mode to higher speed however, so it makes it feel worse.

just noticed that there is a similar request
http://feedback.arma3.com/view.php?id=18434