mue

Nice find. I could reproduce this bug. First I feared that all CDdc calculations (e.g. for ailerons, elevator and flaps) were bugged too. But tests showed me that they work correctly (i.e. the drag increases and the aircraft slows when these control surfaces are deflected). It seems that ReverseInput=True in the Rudder section triggers the bug (the ReverseInput option is absent in the other control surface sections).

Of course the game engine's FDM does take this into account. CGPosition= does not do what you think it does. The cog inside the FDM is fixed at 0,0,0 (in the FDM coordinate system). CGPosition= then positions the FDM in relation to the 3D Model by moving the FDM (cog) to the given position (in 3D model coordinate system). If you want to change the cog position in relation to the aerodynamic surfaces inside the FDM you have to change the x coordinates of the aerodynamic surfaces instead by altering the Xac*TableData. Since the (real) F-16 is aerodynamic unstable and requires a FBW system, and the game engine does not simulate FBW, I assume that the FDM is adapted to be more aerodynamic stable instead.

Of course does the elevators contribute to the total lift force. It's basic rigid body physics (keyword: equivalent force systems): e.g. an upward force at the elevator is equivalent to the same force applied to the cog and an additional moment around the cog with moment = force x cog-elevator-distance. Sure, the lift contribution from the elevators is nearly neglectable compared to the main wings, but it's there. But that is rolling moment due to slip angle beta Clb (of the wings) and not Cldc (of the rudder). That would be drag due to beta Cdb. Unfortunately this coefficient is indeed missing in the SF games. I tested a side slip maneuver with the F-100A: full rudder and opposite aileron to keep the wings level. And indeed the heading doesn't change. That means that either Cydc (of the rudder) is too big or (the absolute value of negative) Cyb (of the fuselage and tail) are to small, or both. Therefore you can try to decrease Cydc of the rudder (maybe until 0.0) and/or increase the abolute value of negative Cyb (of fuselage and tail).

Here you got it wrong. Cydc is the coefficient of side force due to control surface (rudder) deflection. E.g. when applying right rudder the rudder generates 'lift' at the tail in the left direction and therefore 'pushes' the aircraft to the left (the original positive Cydc is correct, but maybe too high). Since the tail is behind and above the cog additionally a rolling moment (counter clock wise) and a yawing moment (tail to the left, or front to the right) is generated. Both moments a defined by Cldc and Cndc. I think the coefficient you are looking for is side force due to slip angle beta: Cyb. Main contributors are fuselage and tail. You can try to increase this coefficient if you think the side slip force is too low.

Yes, as I wrote, (because of a bug) the other games ignore the non-default saved games folder location on drive G and put the mod folder always in the default saved game folder location, i.e. C:\Users\<your user name>\Saved Games\Thirdwire\<game name>. If you want the mod folders of the other games also in the non-default saved games folder location, you can use a workaround by modifying C:\Users\<your user name>\Saved Games\Thirdwire\<game name>\Options.ini: [Mods] Directory=G:\<path to non-default saved games folder>\Thirdwire\<game name> After running the game, a new mod folder will be created at the new location. At the old mod folder location you only need to keep Options.ini and Version.ini, all other files can be deleted here.

Is by any chance your saved games folder in a different place than the default location (c:\Users\<your username>\Saved Games)? North Atlantic will create the mod folder here, but (because of a bug?) the other games will create their mod folders in the default saved games folder location.

Always nice to see FlightGear mentioned here on this site. I'm a big fan of this open source flight simulator and I already tried to combine my love for the Thirdwire sims with my love for FlightGear: https://combatace.com/forums/topic/93840-strike-fighters-2-meets-flightgear/. I'm still working on and off on a tool that in the end should be able to automatically convert SF2 (and FE2) aircraft into FlighGear aircraft (with a JSBSim flight model).

Yes, you first have to load objects (*.obj, *.3ds or *.lod) into the TOD editor with File->Object Manager->Load Objects... . Then you can place those object with RMB -> Add or by pressing 'A' onto a TOD. As a 'workaround' to use 'stock' TOD objects you can load a TOD with 'stock' objects, select an object and save this object with RMP -> Save Object. Then you can later load that object as described above.

The info box in the corner shows KIAS. If you enable debug output with DisplayDebug=true in HUDDATA.INI, then you get a lot of additional infos, including KTAS. You can circle with ALT-D through the various display modes. I assume that TK implemented a model of the standard atmosphere that gives the air density at any given altitude and from there IAS is calculated.

You can also try to increase the Cldc coefficient (Roll moment due to control surface deflection). That coefficient is usually in the [LeftAileron] and [RightAileron] sections.

If anyone experience the same problem as Sundowner did (TODEditor freezing after opening/saving some TOD files): I uploaded a minor update (version 0.1.2) of the TODEditor. It now uses the native Windows file dialog. That should fix the freezing issue.

I haven't experienced any problems on my system yet. What graphic card do you have? Does it always happen after editing 3-4 TODs? When does the freeze happen: after loading, after saving or while editing?

I can relate to that: https://combatace.com/forums/topic/93840-strike-fighters-2-meets-flightgear/ I'm still working on and off on this project/experiment: currently working an a script that automatically converts SF2 flight models into the FlighGear (JSBSim) flight models.

I'm still not sure what do you want to achieve or what do you expect? Where do the input parameter coming from?

Your numbers are consistent regarding the drag force equation. Therefore I think one or more of your input parameters are wrong. Since you want to calculate air density I assume the other parameter are the input. What seems odd with your input parameters is a drag force of 34 kN on an area of 0.46 cm^2 (=0.000046 m^2).