mue

I didn't want to sound too negative. Anyway, I contributed some $. Maybe it helps...

In principle I like the idea of crowdfunding. But in this case I wonder... 1.)...why TW started a "Keep It All" campaign instead of a "All or Nothing" campaign, since the goal of $25K was already stated? 2.)...why the Windows 10 update is so expensive? I thought the games (unsupported) run already on Windows 10. Is the update to DirectX 12 really necessary? I think Windows 10 supports DirectX10 quite well. 3.)...why the campaign is only two weeks long? I really doubt, that the $25K can be reached in this time.

Version 0.6.3 was uploaded. Changelog: Version 0.6.3 -bugfix: selection of nodes without material crashed the program

Thank you baffmeister for your infos, explanations and tests. I still wonder when exactly the stall tables "kick in". When alpha > AlphaMax or alpha > AlphaDepart? My guess is the latter (alpha > AlphaDepart). I also wonder how is the Drag handled between the end of the CDLAlpha table and when the stall table kicks in (AlphaMax or AlphaDepart) in cases were AlphaMax and/or AlphaDepart are greater then the end of the CDLAlpha table. Maybe the CDLAlpha table is then extrapolated (linear or constant)? Regarding the abscissa of the stall tables: First I thought it's alpha. But maybe it's delta alpha, i.e. the difference to AlphaMax (or AlphaDepart). Because the tables have (modifier) values of 1.0 (or near 1.0) at angle = 0 degrees. I assume the modifiers are factors for the lift and drag values at AlphaMax (or AlphaDepart). If the abscissa would be alpha (and not delta alpha) were would be a "step" in the resulting lift and drag graphs when the stall occurs, because the (modifier) values then (at AlphaMax or AlphaDepart) are quite different to 1.0.

No, those free download links are all illegal. Please buy the strike fighters games from the official thirdwire store!

Bug confirmed!

The original values you can find in the original <aircraft>_cockpit.ini files. Note: Not all <aircraft>_cockpit.ini files contain those data. I think most stock SF2 aircraft do not, but most (all) FE2 aircraft do. If the data are missing I _think_ the game uses 0.0 as limit, that means no lateral head movement. The values describe the allowed minimum/maximum lateral head movement in meters. Unfortunatelly IMHO the trackir implementation of the lateral head movement in the game is not fully correct. Because if you change those values, besides changing the movement limits it also changes the movement scale. IMHO the movement scale, i.e. how much real head movement translates into virtual head movement, should only be defined by the trackir profile and not by the game.

To allow larger lateral head movements the following entries in the [CockpitSeat001] section in the <aircraft>_cockpit.ini can be changed: MinMovementX=-0.1 MaxMovementX=0.1 MinMovementZ=-0.1 MaxMovementZ=0.1

With a little trick you can view ALL lods contained in the cats: Create a fakeaircraft.ini that contains the following lines: [LOD001] Filename=Meteor8_pit.lod <--- insert lod file name here By opening this fake aircraft ini the LODViewer shows the referenced lod. The meteor clock node name is "face_clock":

Fantastic pics! ... Now I have to watch "The Bridges at Toko-Ri" and "The Hunters" ... And then maybe I'm motivated enough to start a long, long, long, long-time project of a Korean Air War flight simulator game using the FlightGear engine and maybe SF2/KAW mod assets...

Maybe it helps to switch to orthographic projection by switching off the perspective projection. Have you tried the side (left/right) views. And then to pan the view either with mouse (shift + left mouse) or keybord (shift + arrow keys)? You can also set the view control "sensitivity" in Extras->Settings->Control.

Setting Options->Gameplay->Fuel Usage to "Easy" gives you unlimited fuel.

I think if the Stall* tables are missing the default ones from AIRCRAFTOBJECT.INI are used. Because I want to reverse engineer the TW flight model to (re)implement it with JSBSim for use in FlightGear I have to use a more "academic" approach: I bought a copy of Modern Combat Aircraft Design and Aircraft Control And Simulation to learn the needed know how about aerodynamics and flight model simulation. Together with the TW forum archive and this forum I then try to reverse engineer all needed formulas. I think the *Speed= entries under [FlightControl] are only relevant for the AI.

Ok. For Drag you can extend the CDLAlphaTable. But how do you define Lift at post stall condition (alpha > AlphaDepart)?

Question for the FM experts: What does the chord value in the wing sections of the aircraft_data.ini mean? How is it used in the FM?

Thanks for the link. Unfortunately "Chord=" is not described there. I already searched my TW forum archives, but didn't found anything.

I know the definition of chord. I wanted to know what the chord values in the aircraft_data.ini means. As far as I understand for the pitch moment calculation the ReferenceChord value is used. TK wrote: Therefore in my opinion the extra chord values don't make any sense. What am I missing here?

Here we go again...these wish lists pop up regularly every 1-2 years... Let's face it: TK won't expand SF2. Even if he does he has his own vision and wouldn't consider these wishes. Therefore, if you want new features, you have to do it yourself! Multiple options here: Extending the SF2 game engine: Because of non-access to source code, you have to "hack" the binary. -> In my opinion not viable. Waiting for the release of the source code. -> Will never happen! Write you own combat flight simulator: From scratch. -> Too much of an effort! Use/modify existing (open) source code. -> A little less effort than 2.1.) I'm a big fan of the open source flight simulator FlightGear. It has already the following features: world wide terrain weather FDM engines multiplayer rudimentary combat support via addons (e.g. Bombable,...) ultra flexible It's only missing some minor things as game play, dynamic campaign, AI, .... Anyway, I'm currently experimenting with converting SF2 aircraft to be usable in FlightGear. Maybe thats a start...

Of course is a 32-bit version possible. But as I wrote I have to find the prebuilt dependency library package for 32-bit (unless I build those libraries myself). Maybe I can find them somewhere. BTW. Do you know that you can run most 32-bit programs without problems on 64-bit Windows? Most likely you don't need a 32-bit Windows to run your old 32-bit programs.

Yes, that model is special. It contains nodes (meshes) that are located 44000 and 100000 meters from the main part: The LODViewer tries to show all nodes at once and therefore zooms way out. If you want to see the helicopter you have to hide those "special" nodes and then click "Fit View": If you want to see the "RescuedGuy" node you have to select that node, hide the unselected nodes and then click "Fit View".

Version 0.6.2 was uploaded. Changelog: Version 0.6.2 -corrected reading of ANSI files with non-ASCII characters -caseinsensitive handling of node names (e.g. for showing collision, pivot points or bounding boxes of selected nodes) -disabled mip maps. I hope this resolves the performance issues with hires (4K and above) textures. If not you can use the new option Settings->Display->"Limit Texture Resolution" to limit the (internal) texture resolution.

Yes, currently only 64-bit support: Even though I compile the OpenSceneGraph library myself, I rely on the prebuild dependency packages for OSG. Those I only found as x64 version. And to compile the dependency packages myself, I didn't find the time and motivation yet. I need the 64-bit OpenSceneGraph library anyway for a FlightGear related project. I didn't thought, that 32-bit Desktop-OS is still a thing.

Will be fixed in the next version. That means the "Use Vertex buffer objects" option doesn't help? Does the slowdown happen also with stock objects? Do you use 4K textures?

I didn't know that there is also a decal system for ground objects. After a first glance, it seems it only works with ships? It uses the *_names.ini (that contains [ShipXXX) entries) instead of numbers.lst. Is this correct? Are there other types besides ships? Until I implement the ground object decal system, you can view the hull numbers with this workaround: copy a NUMBERS.LST file that contains sufficient numbers, e.g. I used F-4B\USMCGREY1\NUMBERS.LST (contains numbers 0 - 99) into the texture folder. Then you can select the hull number via Individual Markings.

Version 0.6.1 was uploaded. Changelog: Version 0.6.1 -added decal texture file loading fallback: If numbered texture file is not found, it’ll then look for unnumbered file. -added option for using vertex buffer objects (Extra->Settings->Display->Use Vertex Buffer Objects) Maybe "Use Vertex Buffer Objects" helps with the performance problem some users have experienced with Version 0.6.0. Beware! Enabling this option while simultaneously "Write OSG log file" is enabled, writes A LOT to osg_logfile.txt. -bugfix: "Write Info File" didn't work in Version 0.6.0 -bugfix: Couldn't save UV Mapping as jpg file