Fixed Wing Flight Model (dev branch)

[EricJ 761]

Is it possible devs to get the pylons a hiddenselection entry in the config? I've been doing a retexture and would like to redo the pylons... as the mapping is... bad

And this is for the Wipeout as well.

Edited October 15, 2014 by EricJ

[dr. hladik 231]

As I didn't post anything for a while...

update: I still do pay attention to this thread and I plan to try to implement some improvements.

However, this is just my side-project, so please be patient.

[x3kj 1247]

Thats good to hear, thanks for the lifesign ;)

In the arma3diag force display you see a 9.81 in level flight for the Y value. Now, it may just be the force normalized to the mass. I can't know. But maybe somewhere in the force equation mass is missing? Mass (and Surfacearea) are the main components of the equation for maximum velocity you can achieve in free fall (terminal velocity). So if Mass is missing... your terminal velocity won't be very high. Provided terminal velocity even is a thing in the force equations (it's basically a result of drag force acting on the body countering gravity force).

Which leads me to another thing i'm wondering about. What exactly is draconic force doing? I can't find the term draconic force anywhere that doesnt involve some kind of dragons game... Is it intended to be "drag force" instead?

If this is the case, i would assume that draconicForceCoefficients are basically dragcoefficient (C_d) * crosssection area (A). The "draconic" (drag) force acting on the aircraft in the specific coordinate is therefore 0.5*airdensity*velocity²*dragforcecoefficient. velocity for that specific coordinate of course. Is that how it's done?

Edited October 15, 2014 by Fennek

[x3kj 1247]

Maybe a description of an independant system would help to see for you if there are errors/ important missing things/ features for improvement? If i would have to describe the forces/torques on an aircraft by myself i would always do the real phyiscal approach. It's not that difficult (especially if presented on a silver plate :P ) and provides aid if you want to config an aircraft, as you can orient on it's realworld values you find on the net.

If somebody finds anything important missing, tell me^^ i'm not an specialist in aerodynamics.

Forces: Lift, Thrust, Drag, Inertia and Gravity.

Torques: InertiaTorque, DragTorque and LiftTorque (by controll surfaces)

• Local Forces (means orientated to the local coordinate system of the plane):
  
  • [X, Y, Z]Inertia(-force), always opposed to the acceleration along the respective coordinate, only dependant on mass.
    F_x=m*a_x
    F_y=m*a_y
    F_z=m*a_z
    That's simple, we dont need config values, the mass is in the geoLOD of the model.
    
  • [Z only*] Thrust Force, dependant on velocity of coordinate.
    F = f(v)
    Only thing we need is a Thrust value and ThrustCoef (for speed envelope).
    I would define a thrust value based on Newton (or Kilo Newton) in the config. This value can be found for basically all realworld aircrafts, so configging them is easier.
    Note: For Arma the realworld thrust might prove too high (since it isnt really suited to mach 1+ speeds). However, in my opinion it's better to counter this with increased drag coefficients, because drag also causes shorter landing runway length (because smaller maps) , and accounts for acceleration during freefall as well..
    *I would pay attention so that i could later easily add it so that Thrust may be used in all coordinates. This would allow addition of full Vectorthrust in the future if the opportunity arises.
    One way to accomplish that: Define Memorypoints in aircraft and have config values thrustPos and thrustDir. The movement could be done via animations.
    
  • [Y Only] Lift Force
    Dependant on wing shape, dimension, angle of attack, coefficients, speed. The base physical equation this:
    F_L= 0.5*Rho*c_l*v²*A
    Rho - airdensity (global world variable)
    c_l - Lift coefficient. Dependant on WingProfile (constant), and on angle of attack (variable)
    A - wing surface ("shadow" from top)
    v - airspeed velocity
    Implementation:
    Not sure if implementing airdensity difference because of altitudes would have noticeable impact, propably not. Therefore i would set Rho to a constant.
    Because c_l has a constant dependancy component i would include this constant component into A (wing surface area) in the config.
    Therefore we need 2 config values for the plane:
    For ease of configging it would be usefull to assume a symmetrical wing profile. According to common info texts modern airplanes have this.
    Therefore the lift coefficient for the wingprofile for 0° angle of attack is just 0 (means no Lift generated at 0° AOA). To generate Lift in Level flight, we define a base AOA (the wing are not entirely parallel to the aircraft body)
    Therefore we need 3 config values for the plane:
    WingSurface = A = value in m²
    LiftAOACoef = f(AOA) = c_l_variable -> Array to describe curve. This curve should go from 0° to 90° (or Pi), where it's zero points are (approximately). Once either of these values is surpassed, the curve should be flipped around. Saves us from defining 360°. This means we assume a symmetrical wingprofile. A typical curve looks like this (here showed for 180°)
    AOI= value (in radians)
    
    Note: To determine how much AOI we need for the aircraft, we choose the speed at which the aircraft is supposed to fly level without input. Lift must be the same as Force of gravity for that chosen speed. So F_g=F_l , means DesiredAOI = 2 * m * g / ( v² * WingLift). We then check in our LiftAOACoef envelope how much of an angle we need (and use
    linear interpolation
    if required).

    
    To aid landing we define a coefficient that describes how much the flaps increase lift force for the entire wing because of the flaps.
    FlapLiftCoef= value
    Therefore the "game equation" would be:
    F_L = 0.5 * Rho * v² * ( AOA + AOI) * WingSurface * LiftAOACoef(AOA) * (1 + FlapLiftCoef)
    Important: v is the speedvector of the aircraft that is formed by the Z and Y velocity vector.
    AOA is the angle of that speedvector along the Y-Z plane measured from the Z axis of the aircraft.
    

  • [X, Y, Z]Dragforce
    Always opposed to the velocity of that coordinate, caused by airresistance. I'm not sure if this is physically correct, but it's necessary to simplify here as having a drag value for each flowangle is impossible to define or calculate. I would define dragforce on a component base. This means, I define the force that the Plane would generate if it is affected by an airstream from only one direction. As drag is dependant on velocity its easy to substitute the total drag force vector with 3 seperate components. base formula is very similar to Lift:
    F_Dx = 0.5*Rho*c_dx*(v_x)²*A_x
    F_Dy = 0.5*Rho*c_dy*(v_y)²*A_y
    F_Dz = 0.5*Rho*c_dz*(v_x)²*A_z
    Implementation:
    The airresistance coefficient (c_dx) for the respective coordinate can be combined with the Surface area (A_x) of the same coordinate, therefore we have in the config:
    dragCoefX= value (in m²)
    dragCoefY= ...
    dragCoefZ= ...
    Flaps increase drag in Y and Z direction (Controll surfaces in theory too, but for the sake of simplicity i would neglect that)
    Here there are 2 options - either define 2 coefficients in the config for Y and Z, or define a single Coef. that gets applied differently to Y and Z drag.
    For better usercontroll i would choose the two coefficients in the config.
    FlapDragCoefY= ... //increased wing surface area
    FlapDragCoefZ= ... //slows aircraft down in forward position
    The Gear increases drag in Z direction only (theoretically also X but i would say that this is insignificant)
    GearDragCoef= ... //slows aircraft down in forward position
    The Airbrake increases drag to slow down the aircraft in Z direction only
    AirbrakeCoef= ... //slows
    
    So in game terms:
    F_Dx = 0.5 * Rho * (v_x)² * dragCoefX
    F_Dy = 0.5 * Rho * (v_y)² * ( dragCoefY + FlapDragCoefY )
    F_Dz = 0.5 * Rho * (v_z)² * ( dragCoefZ + FlapDragCoefZ + GearDragCoef + AirbrakeCoef )
    
    
    Note: To get a physical base value for dracCoefX, -Y and -Z, aproximate your aircraft into simple shapes (main body cylinder, wing, tailsection) and use
    this
    to determine the drag coefficient of the shape, then multiply with the surface area of that shape. Do it for all shapes and add them together for your drag value. Do this for all X, Y and Y directions. Doesnt need to be that accurate...

    
    

  [*]Global Forces:

  • 
    
  • [Y only] Gravity
    F= m *g ... easy.
    

  [*]Local Torques

  • 
    
  • [X, Y, Z] Lift-Torque (Effect of Controll surfaces)
    They need to depend on square of velocity. This is required because the dragtorques that will center the airplane to it's velocity vector depend on square of velocity as well. The Torque of the controll surfaces is generated by increasing/decreasing Lift on the controll surfaces (changing AOA effectively). Therefore the equation is similar to Lift.
    Physical equation for the Lift of a single controll surface (c for controll surface is )
    F_Lc = 0.5 * Rho * v² * A_c * c_lc
    The Torque generated by the controll surface is
    T_Lc = s_c * F_Lc
    s_c is the offset (in m) of the center of lift the controll surface section in regards to the specific roll axis.
    In case of Elevator and Aileron T_Lc should be multiplied times two, because we have 2 controll surfaces
    To prevent spam of config with thousands of coefficients i would just use 1 for each controll surface and base the rest of the Torque equation on the Wing Lift components we already defined.
    ElevatorLiftCoef= value (in m³)
    AileronLiftCoef= ...
    RudderLiftCoef= ...
    These Coef's are product of the offset (s_c), the surface area (A_c). Controllsurface profile usually is Teardrop shaped and symmetrical -> 0 Lift at 0° Angle.
    Note: To determine those LiftCoef, use this Diagram [<<TODO>>]
    It's required to set the maximum angles that the controll surfaces can move in one direction. To simplify i assume that this is always symmetric (so max downwards angle= max upwards angle)
    
    ElevatorMaxAngle = value (in radians)
    AileronMaxAngle = ...
    RudderMaxAngle = ...
    The controll input values range from -1 to 1. So the Angle of the controll surface is
    Angle = MaxAngle * controllinput
    Thefore, in game terms:
    T_Ex = 1 * Rho * (v)² * (AOA + [ElevatorMaxAngle * elevatorinput]) * LiftAOACoef(AOA) * ElevatorLiftCoef
    T_Az = 1 * Rho * (v)² * (AOA + [AileronMaxAngle * aileroninput]) * LiftAOACoef(AOA) * AileronLiftCoef
    T_Ry = RudderLiftCoef * 0.5 * Rho * (v_r)² * (AOA_r + [RudderMaxAngle * rudderinput]) * LiftAOACoef(AOA)
    
    v, AOA and LiftAOACoef(AOA) where already explained in Lift Force.
    v_r is the length of Z and X velocity vector sum; AOA_r is the angle of vector v_r in X-Z Plane, measured from Z axis.
    
  • [X, Y] Aerodynamic torques that align plane with speedvector. It's dependant on the same things as Dragforce, but additionally the offset between Center of Mass and Center of Drag force. We already calculated Drag force, so we can reuse it.
    T_x = s_z * coefficient* F_Dy
    s_z - offset in meters between the centerpoint of the surface area and aircraft's center of mass (here in z direction, because we look at it from the side / Y-Z Plane )
    coefficient - coefficient how much of the drag force is applied
    F_Dy - drag force in Y direction (as defined earlier)
    T_x = s_z * CoefX* F_Dy
    T_y = s_z * CoefY* F_Dx
    Combining s_z and the coefficient
    dragTorqueCoefX= value (in m)
    dragTorqueCoefY= ...
    Therefore in gameterms:
    
    T_x =dragTorqueCoefX* F_Dy
    T_y = dragTorqueCoefY* F_Dx
    
    
  • [Z] Air resistance of rolling along aircrafts axis.
    Theoretically this should apply for all Axis. X, Y and Z. Because no matter along which axis you rotate the aircraft, the surface will always cause airfriction and therefore a countertorque to the angular velocity. I do not think that it is significant however. The 2 torques defined above should be alot higher then this effect would be. However, there is no torque that prevents infinite rolling once you stopped the Ailerons.
    <<TODO>>
    

Edited October 17, 2014 by Fennek
improved lift, added some torques

[five_seven5-7 56]

It´s better to devs answer us first then try to make a better flight model, we dont know the engine limitations.

[spanishsurfer 58]

As I didn't post anything for a while...

update: I still do pay attention to this thread and I plan to try to implement some improvements.

However, this is just my side-project, so please be patient.

Good to see you're watching, thanks! Since it's a side project I would like to suggest a list of priorities that need some looking into. (Feel free to take this list and add to it)

1. Glide Ratio - Fixed-wing aircraft need better glide ratios.

2. Loss of airspeed during turns - typically a few KTS are lost during your average turn but not as much as in Arma.

3. Stalling - Aircraft do not stall anywhere near like the real world

4. Engine Loss - Many aircraft in Arma have two or more engines. I simulate engine losses in my real world job all the time and it's not a huge deal, just requires lots of rudder and engine control. It would be great if Arma could attempt to simulate a single engine loss upon damage from the enemy.

5. ? you guys add...

[CaptainAzimuth 714]

Good to see you're watching, thanks! Since it's a side project I would like to suggest a list of priorities that need some looking into. (Feel free to take this list and add to it)

1. Glide Ratio - Fixed-wing aircraft need better glide ratios.

2. Loss of airspeed during turns - typically a few KTS are lost during your average turn but not as much as in Arma.

3. Stalling - Aircraft do not stall anywhere near like the real world

4. Engine Loss - Many aircraft in Arma have two or more engines. I simulate engine losses in my real world job all the time and it's not a huge deal, just requires lots of rudder and engine control. It would be great if Arma could attempt to simulate a single engine loss upon damage from the enemy.

5. ? you guys add...

Well, with all aircraft upon damage to a certain extent, i believe a portion of thrust is lost, making it more easy to stall out, which could result in many mistakes, such as under-shooting a runway, and not being able to pull out of a slow dive. It would be cool i suppose however, to maybe add engine loss for double engine craft... not sure about that though.

[the_demongod 31]

Good to see you're watching, thanks! Since it's a side project I would like to suggest a list of priorities that need some looking into. (Feel free to take this list and add to it)

1. Glide Ratio - Fixed-wing aircraft need better glide ratios.

2. Loss of airspeed during turns - typically a few KTS are lost during your average turn but not as much as in Arma.

3. Stalling - Aircraft do not stall anywhere near like the real world

4. Engine Loss - Many aircraft in Arma have two or more engines. I simulate engine losses in my real world job all the time and it's not a huge deal, just requires lots of rudder and engine control. It would be great if Arma could attempt to simulate a single engine loss upon damage from the enemy.

5. ? you guys add...

I do have one to add. It's not exactly related to flight model, but I think separate wheel brakes is an important thing to have. It would normally not be high priority in my opinion, but because we now have properly functioning wheelbrakes for helicopters, it should be no problem to port this functionality over to the fixed wings.

[x3kj 1247]

It´s better to devs answer us first then try to make a better flight model, we dont know the engine limitations.

??? So you suggest we wait on the devs to come to us? Wait it out and hope in silence that it gets better in some magical way? If the engine cant produce forces that have a physical basis then i wonder why we can even play the game, if it would be that bad. So the answer is: yes it is possible (flightmodel is already force based - except something is wrong somewhere).

I prefer to give constructive feedback... rather then just mumble about how bad the flightmodel is in general. The flightmodel i described is what i would do -> something for the devs to crosscheck their model if it misses something and maybe serve as Inspiration for improvements.

Edited October 23, 2014 by Fennek

[five_seven5-7 56]

Why BIS made a upgrade to the helis flight model? i can fly better now with the keyboard then with the old mechanics with joystick (remember when helis stuck to the ground in Alpha)

I`ve asked about the engine limitations to know what we can do to help them, not posting a text wall on flight mechanics. Its surprising how a model can "flight" with so little parameters.

I have the "Aircraft Design: A Conceptual Approach" book. I'm happy to assist in any way I can solve, I will not waste time on theories if we don't know if we can rely on the RV4 engine.

-Model:

Center of Gravity

Variable mass, depending on the loadout

Thrust vectoring

Roll speed

-World:

Air density altitude

crosswinds

flow separation

Can we use the RotorLib code to make something for the airplanes or its protect by intellectual property?

http://www.rtdynamics.com/v2/wp/2010/fwl-cgf/

Why BIS made a upgrade to the helis flight model? i can fly better now with the keyboard then with the old mechanics with joystick (remember when helis stuck to the ground in Alpha)

I`ve asked about the engine limitations to know what we can do to help them, not posting a text wall on flight mechanics. Its surprising how a model can "flight" with so little parameters.

I have the "Aircraft Design: A Conceptual Approach" book. I'm happy to assist in any way I can solve, I will not waste time on theories if we don't know if we can rely on the RV4 engine.

-Model:

Center of Gravity

Variable mass, depending on the loadout

Thrust vectoring

Roll speed

-World:

Air density altitude

crosswinds

flow separation

ground rolling friction

Can we use the RotorLib code to make something for the airplanes or its protect by intellectual property?

http://www.rtdynamics.com/v2/wp/2010/fwl-cgf/

https://www.youtube.com/channel/UCXdRU2pYJErCOtYqlA6yLdg

[x3kj 1247]

if we don't know if we can rely on the RV4 engine

The current model is force based... And everything in those equations i wrote down are simple force equations with some coefficients and 2 curves in total(we already have lift and thrust curve currently btw). That's it.

There are only so few coefficients because of a) simplification (in parts maybe too much) , b) other coefficients beeing hardcoded into the equations, c) maybe non-physical base equations that cause problems. And the aircrafts don't fly - at least not what i would describe as a good emulation of flying (see all the tickets and problems over the last pages here).

Which is precisely why i wrote the wall of text (still not complete) so devs can compare it to their internal equations. Dr Hladik (who, it seems, is in charge currently for the FM coding) said he didnt know why aircrafts turn when bank. So don't you think it's reasonable that they missed more forces, or that a simple overview of what forces apply to a flying aircraft for them to look would be usefull? I don't think they would dig through flight mechanic books in order to improve something that is not their primetask. I certainly wouldn't.

And no you can't just use RotorLib... otherwise that company wouldn't exist, because a company needs an income source. BIS would have to purchase the Lib and thats not going to happen, it has already been said. Only improvements of the current FM as a side project and no promises.

-Model:

Center of Gravity //already have that...

Variable mass, depending on the loadout //i'm certain this would work. We have setmass as script. Mass in all equations needs to be updated constantly however instead of just beeing read once on initialisation

Thrust vectoring //Super easy... because it's just one variable force vector (or multiple ones for multi engine crafts)

Roll speed //what do you mean by that?

-World:

Air density altitude //easy, just replace Rho in my equations by a table which is defined globally

crosswinds //easy, just add windspeed vector to aircraft speed vector

flow separation // thats what the AOA curve is for in my list, it's just a force coefficient based on a table

ground rolling friction //not really important for flying itself... physx seem hardcoded into aircraft configs currently

Everything to do with forces and vectors is possible... because if an engine cant handle vectors it wouldnt work at all in the first place. And most of what you listed would be additional features that could be added if they decide it. Not what fixes the flawed base flightmodel. All features would easily be possible because they do not require complex mechanics. Everything is just force based. You just need one who is going to put the time into it.

Edited October 23, 2014 by Fennek

[CaptainAzimuth 714]

You just need one who is going to put the time into it.

Which unfortunately, is what BIS stated they have a lack of manpower to focus on things like this on a timely basis. It does need work, and will get worked on, but I'm certain that it will get improved over the time to come. My guess would probably me somewhere around Expansion time or inbetween, they might improve the model some.

[vicx 10]

Hi fixed-wing guys. I've been playing two games lately, one called Arma and one called DCS; both these games rock and I am playing the hell out of both. Lately after playing DCS World I love playing back the action in Tacview. Watching Tacview solves a lot of those WTF just happened moments. It is a great tool and it is fun to just watch a replay of a mission. I have also been using Tacview to view my DCS: Combined Arms games and it models ground units and their actions just as well as aircraft.

Now you might see where I'm going with this. I have been testing the Rotorlib Helis in the DEV branch and lately I have been crashing them and wondering what just happened. I want to review what I did wrong and if it is my bad flying or a bug.

Just saying I'd love it if Arma exported ACMI logs for Tacview. It would be awesome.

[x3kj 1247]

Which unfortunately, is what BIS stated they have a lack of manpower to focus on things like this on a timely basis.

yes, that's what i intended to say but didnt phrase properly i guess - the additional features he meantioned would be certainly nice to have but are not essential in correcting the plane behaviour itself. Fixing base behaviour requires a basic understanding of the forces, to be able come up with a valid way to simulate them. And that's what i try to give in that post (along with one possible solution).

Edited October 24, 2014 by Fennek

[EricJ 761]

Hi fixed-wing guys. I've been playing two games lately, one called Arma and one called DCS; both these games rock and I am playing the hell out of both. Lately after playing DCS World I love playing back the action in Tacview. Watching Tacview solves a lot of those WTF just happened moments. It is a great tool and it is fun to just watch a replay of a mission. I have also been using Tacview to view my DCS: Combined Arms games and it models ground units and their actions just as well as aircraft.

Now you might see where I'm going with this. I have been testing the Rotorlib Helis in the DEV branch and lately I have been crashing them and wondering what just happened. I want to review what I did wrong and if it is my bad flying or a bug.

Just saying I'd love it if Arma exported ACMI logs for Tacview. It would be awesome.

Barring the ACMI issue I got a new Thrustmaster Hotas X and I flew DCS, Strike Fighers 2, managed to trap my jet and land my jet in DCS with little to no problem. However the jacked up throttle in A3 needs to be tuned so it offers a full range of thrust, as I was coming in for a landing and borked two approaches, putting my jets in the fence on the small runway on the southeast "A" airfield on Altis. The problem with RotorLib was that it's TKOH, and I well... thought it was WAAAAAY too sensitive, so its not you, it's the fact that RotorLib isn't matured and quite frankly while the Rotary-Wing system isn't say... DCS quality, it is good to pick up and with the tweaks so far it's pretty fun. So yeah... devs... throttle settings for jets should be 1-100% and not 50-100% like it is now, as I've gotta re learn how to do my approaches again with a good stick now. But if I can land first time in DCS easy with a real throttle setting A3 should be a piece of cake.

[Imperator[TFD] 444]

Map both Axis of throttle to thrust to achieve 100%?

Works for me (X-52)

[EricJ 761]

All axes are mapped correctly but the engines (that and my old Logitech stick) would activate at 50% or so. I checked the dead zone (there is none set) and still get that issue. Coule be a stick thing but I'll mess with it later on or so.

[the_demongod 31]

All axes are mapped correctly but the engines (that and my old Logitech stick) would activate at 50% or so. I checked the dead zone (there is none set) and still get that issue. Coule be a stick thing but I'll mess with it later on or so.

The issue is actually worse than you might think.

What you're "supposed" to do is map the throttle-up axis to "Thrust (analog)" and the throttle-down to "Brake (analog)". It expects the throttle, when lowered to 0%, to be used to trigger the brakes and slow the aircraft down.

It's really messed up, it means that the aircraft essentially cannot truly glide or idle which is insanely annoying. To be perfectly honest, it's no better than Battlefield's jets. I hate to say that, but there's no denying it. I really really hope we eventually see FixedWingLib get added, even if it's long after the expansion pack (hopefully we'll see more DLCs after that).

[Brisse 78]

I really really hope we eventually see FixedWingLib get added, even if it's long after the expansion pack (hopefully we'll see more DLCs after that).

I'm not sure the maps in Arma3 are big enough for realistic fixed wing flight dynamics, but otherwise I fully agree with the annoying throttle problem.

[five_seven5-7 56]

We can assume the throttle settings are correct, if we generalize:

. A10 - General Electric TF34 (turbofan)

http://www.grc.nasa.gov/WWW/k-12/airplane/ngnsim.html

In NASA EngineSIM: the turbofan only starts to produce thrust after the 50%, turbojet 35%

In the next url, there are formulas for earth's atmosphere, for a better flight model.

http://www.grc.nasa.gov/WWW/k-12/airplane/Images/atmosmet.gif

Edited October 29, 2014 by Five_Seven5-7

[b00ce 160]

We can assume the throttle settings are correct, if we generalize:

. A10 - General Electric TF34 (turbofan)

http://www.grc.nasa.gov/WWW/k-12/airplane/ngnsim.html

In NASA EngineSIM: the turbofan only starts to produce thrust after the 50%, turbojet 35%

~50% is probably idle.

[oukej 2911]

What you're "supposed" to do is map the throttle-up axis to "Thrust (analog)" and the throttle-down to "Brake (analog)". It expects the throttle, when lowered to 0%, to be used to trigger the brakes and slow the aircraft down.

Wrong ;) I know it's damn unintuitive, but you have to map BOTH X Axis + and X Axis - to "Thrust (Analogue)" to have the full extent of one axis.

Like:

(Similarly you can map both halves of one axis to "Brake (Analogue)" to have airbrakes' input stretch over the full axis. The consequence of mapping + and - also defines if the axis is going to be inverted.).

You can also check http://feedback.arma3.com/view.php?id=6888

Recently a new programmer started looking into some of the long-lasting controller issues. (you may have noticed that e.g. the painful 16-button limit has already been fixed in the dev branch)

Edited October 29, 2014 by oukej

[five_seven5-7 56]

yeah, it is not necessary to be exact percentage, you get the point

[Brisse 78]

Thanks for clearing that up oukej.

[Guest]

Damn, one of the Arma univers mystery is solved :eek:

---------- Post added at 16:40 ---------- Previous post was at 16:36 ----------

But is it possible to bind two buttons of a joystick to make an action ? (such as button 6 + 5 to remove brake)