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).