John Kozak

Well, if scripting commands to set forces/torques acting on object would be added, we can quite see it in ArmA 3. It's not that big of a change, and will enable to create very elaborate aerodynamics in SQF

Well, you mentioned almost all of the forces correctly; you just forgot to mention pitch and yaw rotational drag. They are also very important if one tries to build aircraft model with some fidelity. But overall, with some corrections, it is pretty accurate - essentially same as I'm describing. Hi Dr. Hladik, First of all, please don't consider what I've written above a disruptive criticism or disparagement. I reckon the flight model is either fully or partially your creation; please understand I'm only trying to give constructive feedback to help improve things for everyone. TL;DR: please don't take it as an offence. What I meant on the formula is more specific description of the function of lift as combination of mentioned factors (flaps position, altitude, ground effect, AoA (angle of attack), velocity). You said above that you can configure a curve of lift w.r.t. to speed, but did not say anything about Lift/AoA curve. With that in mind, i'd imagine the formula to be something along the lines of: Lift(velocity) = AoA * LiftCoeff(velocity) * (other coefficients); Is it actually the case? If it is, then unfortunately it won't be possible to achieve realistic behavior by tweaking parameters. Here is a picture giving a bit of an insight why: Basically, lift of an aerofoil is a complex function which is linear at some AoA range, but has complex behavior at other points. Notably, at/near the stall AoA, lift stops following linear relation with AoA and drops rapidly. In general, actual lift is proportional to V^2: L(V,AoA) = CL(AoA) * S * V^2. Trying to reproduce this in ArmA, we can perhaps try to create a quadratic curve by configuring points appropriately; however, that won't give the lift force any relation to Angle of attack - which is important, as there would be no real stall. And without stall, the only way to limit angle of attack (lacking torque/AoA curve) would be to add an artificial "draconic torque"; which would reduce agility and require other artificial forces to compensate etc. etc... If I understand correctly, disabling "draconic forces" in that scenario will lead to the aircraft pitching up when above certain speed threshold and pitching down below it. In other words, without some engine overhaul, we won't get far...

Wait, RL missile developers try hard to achieve it and you consider it an issue? :P (Joking, don't take too seriously)

You took the formula for constant deceleration, while, as you written above: I.e. deceleration is proportional to v^2

As far as I know, it's because ArmA 2 does not detect devices on-the-go (mid-mission) EDIT: Or perhaps it just uses less virtual memory

It looks like we're down to 3 options: BI makes a workaround - adds a command-line switch instructing game to not detect devices on opening options BI removes the feature for re-detecting devices on opening options Microsoft fixes the bug in DirectInput devices enumeration I don't know which one is more likely to happen, but it's most probably not 3 :)

Because for vast majority of cases it's truth ;) Of course, if you buy it, you don't see it as propaganda. But for anyone with just a bit of understanding of how things work, it's obvious.

You see, I have no problems with that. But I don't get along well with people trying to publicly degrade me. Yes, being an asshole to someone always beats rational arguments. Totally. Now yes, end of discussion :)

http://feedback.arma3.com/view.php?id=23955 - Can this be rechecked, please? I've updated the (initially insufficient) repro notes.

Really? It's a freaking definition. => range between the quietest sound (grass/wind) and loudest (gunshot). You asked for dynamic range - here it is. See, you didn't even read my post. As for your initial statement, gunshots are f***ing crazy loud in real life, compared to grass noise and footsteps - 150db vs 40db, which is 90db => 1'000'000'000 times difference in sound pressure, and shots do damage hearing. You can't ask for realistic sounds and ask for shots to not be painful in one sentence. There are bound to be compromises. One is DRC I mentioned above, other is reducing overall sounds range - i.e. making footsteps almost as loud as shots. But both options are bad in something.

Among the offtop, finally found the post which relates to the discussion :P Disclaimer: I am not an aircraft engineer, however, I had a chance to work on aerodynamics of Rise of Flight simulator and have (unfortunately abandoned) physics education. So, I do have some experience to be able to discuss that area; whether to believe anything you read on the internet is as always on you :) Looking at the above, I can say that there are 2 components that must not be there. 1."Draconic forces". There's no such thing in aerodynamics. All the (major) forces acting on an airframe can be divided into one of 4 categories: - Lift - Gravity - Thrust - Drag (subdivided into parasitic drag, induced drag and wave drag). There's no force keeping the plane from changing its vector; rather, in statically stable aircraft there is a torque which keeps the orientation along the velocity vector, plus "damping" (rotational drag) which damps oscillations 2."Draconic torque". Generally, there is no torque returning the aircraft to flight direction vector. It is indeed the case for most aircraft, because they are explicitly designed that way (otherwise they would be not controllable), but it's not true in cases of: - Intentionally statically unstable aircraft (F-16, Su-47) - Unstable flight modes - stall/spin mode. In general, that torque is described as Mza = f(AoA) (moment of force over Z axis as a function of angle of attack). Rather than a specific force coefficients, flight model of it is most accurately described by following functions: L(AoA) - Lift D(AoA) - Drag M(AoA) All of these are coefficients - i.e. you need to multiply them by 0.5*rho*V^2 to get actual drag. Why V^2? Because the dynamic pressure of the "incoming" airflow (assuming aircraft is stationary - like in aerodynamic tunnel) is proportional to square of velocity times density. So, basically to get a believable flight model (no need for total fidelity), we need to: 1.Get rid of "draconic forces" 2.Make sure the equations are followed (aerodynamic forces are quadratic to velocity) 3.Tweak the coefficients by trial-and-error I'm not sure regarding p2. Perhaps Dr. Hladik can clarify - what is the actual formula for, say, computing lift? P.S. And I finally got my hands on oukej's Wipeout test configuration, let's see how it goes... ---------- Post added at 16:21 ---------- Previous post was at 15:50 ---------- Here's a small video recorded in DCS World FC3, to illustrate the following idea: the direction in which the airframe flies is not necessarily same as where it is pointing. Here, I pull the stick to end in a level flight (only pitch input, no roll) What happens next is: 1.The frame of the aircraft starts pitching up, which starts to produce more lift. 2.This starts to increase vertical airspeed (note: vertical airspeed is not increased instantly) - but the aircraft is still basically flying level 3.Meanwhile, due to high angle of attack elevators start to stall. This looks as if the plane is suddenly "jerked" back down 4.Due to high angle of attack, one of the wings stalls. This is just to show how complex behavior can appear just out of few small formulas (parameters to which are tweaked a lot, however). And also to highlight one thing I personally miss the most - the feeling that the aircraft is a thing which flies and responds to inputs. With default ArmA 3's Wipeout, there's a feeling it behaves like a camera in plastiline - point it, and it stays in that direction.

"There are two kind of opinions: mine and wrong", yeah yeah.

Works for me - what is the issue you are experiencing?

Have you tried releasing shift? If you're talking about 'combat pace', not sprint - make sure left mouse button is assigned to 'Combat pace - 3 seconds'.

Mikero's Dos tools

1.Open the mission in editor 2.Add ACE medical module onto it 3.Put the module settings to the wanted realism level 4.Save the mission 5.Play

You are confusing range with volume.

Lol, you don't have any idea what a discussion is. If you think you can make your point simply by trying to appear smartass, you can't be more wrong here. Your post does not contain any sense by any stretch of imagination. See what I did here? Now, please tell me how extending sounds' volume range does not add to dynamic range.

Well, I disagree that this is broken. High dynamic range of audio is something that was desired by quite a lot of people here; now that it's here, of course, someone is bound to be unhappy :P Personally when external noise is an issue I just use "dynamic range" feature in my soundcard, so that it adjusts the volume to hear wind and footsteps when it's quiet and tones it all down when shots are fired - just the way it's actually supposed to be.

You can take them prisoner (requires cable ties) which makes them civilian from trigger point of view. Some missions may hard code success on death of specific units, but then it's that mission's fault.

Razer Carcharias. While it's definitely not an audiophile's choice, it is sturdier than anything - it lived through 5 years, numerous strong cable tugs (one actually ripped off front panel of computer case!), many many falls and 2 kids. Still alive & kicking. Started to respect Razer after that.

Slovaks would disagree with you: http://btvt.narod.ru/4/t72m2.htm

I take your offense as an offense

Hi Franck, Thank you for confirming - now I can be sure that the test works correctly. I'll forward your results to the BIS dev I've been in contact with. I can't right away come up with a scenario how that might happen... But since there seems to be a fairly low-level bug, anything is possible. I'll try to reproduce this effect. Thank you very much for helping to check this, much appreciated

Removed - sorry, forgot about "no discussion" rule.