mue

How much disk space is required?

Do you know, how the blending works?

If you could find more information how exactly stall is modelled in SF2, I would be *very* grateful! How the normal flight envelope is modelled I understand quite well: sf2_fdm_notes.pdf. But the stall regime is still rather unknown to me. BTW, the key 'Qr — Downwash/relief factor used in aero build (vs α)' is also unknown to me. And I couldn't find it in any stock aircraft data inis. What exactly is this downwash/relief factor?

The LODViewer should work with either encoding: ANSI or UTF-16LE (unicode).

Why do you have a problem with posting your mods on other sites? Why does it matter where and how the mods are shared, as long as the license terms (containing readmes, etc. ...) are fulfilled? Genuine question. I was under the assumption, that creating and publishing (free) mods is about sharing them. And the more they get shared, even on other sites, the better.

No, if one has to pay money to get the mods, that makes them effectively payware. And It doesn't matter who receives the money, the mod author, the website operator or any other person. It' not about that all mods must be free (as I wrote, you can of course choose your license as you like). It's about mods, that were published by its authors as freeware under the CA freeware license, are now effectively payware by putting them behind a paywall. That's where I see a problem.

I thought you wrote about "CA files" in general. And since (I think) most mods (CA files) here are published under the CA freeware license, I only wanted to point out my understanding of this license, that it's perfectly fine to share mods that were published under this license, even off-site. Of course every mod author is free to choose it's own license, e.g. make the mod CA exclusive. No problem. But my understanding is, as already written in my previous post, that CA exclusiveness means the mod is practically payware now and therefore must not be based or contain any mods published under the CA freeware license (without permission of the mod authors).

Why? According to the CA Freeware License it's not forbidden to share the mods/files as long as they remain "free": From the CA Freeware License: "The work may not be used in payware projects or in projects that will not be freely distributed under these same terms". On the contrary I could argue that putting the mods/files behind a paywall and simultanously forbid sharing them (off-site) makes them practically payware and that is against this very license. I would think that most modders here want to share their work for free so what all (including those who can not or don't want to pay any money) can enjoy them. Yes, I know Erik has to pay bills, and I myself have a subscription to support this site although I haven't downloaded much in the last years. But personally I had hoped there would be a donation based solution or similar be found.

Good luck and keep fighting the big C!

Damn, sorry to hear that. I wish you a full and speedy recovery!

As Nyghtfall already wrote: blender 2.78/2.79 does allow for angled pivot points. If you rotate an object it actually does rotate the pivot point (and its attached mesh). To see the rotated pivot points you have to set the Transform Orientation option to Local, e.g. through the Transfrom Orientation Selector in the 3D view header or with Alt-Space. The problem with blender 2.78/2.79 is, that you can not directly rotate the pivot point without rotating the attached mesh. But you can use this workaround: - First rotate the object (pivot point and mesh) in the opposite direction. - Then apply the rotation to the mesh with Ctrl-A Rotation. That resets the rotated pivot point to the global axes but keeps the mesh rotated. - Afterwards rotate the object back in the wanted direction. That rotates the pivot point in the wanted direction while the mesh is back in its original orientation.

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.

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?