mue

A question to the FM gurus: How do you develop and test your flight models? I'm especially interested in how to gather telemetrie data (e.g. velocity, height, acceleration, turn rate, ...) and how to plot graphs from those data (e.g. velocity over time, height over time, ...). I know about the debug display. But is there a way to output this data into a text file?

The time complexity of the lookup in a table with a fixed data interval is constant. That means the number of entries in the table shouldn't matter.

I don't see what the problem with a fixed data intervall is, other than that you have to also input high resolution data in the "uninteresting" not much varying Mach areas. Or is it, that the game engine can't handle high resolution tables in general?

I don't think there is a simple analytical solution for this. To create E-M-diagrams you have to fly the aircraft at the altitudes you are interested in over the whole velocity range. For different velocities you then determine the max g you can pull in a level turn. From g and true airspeed you can then determine the turn rate and radius at that velocity. To help gathering this data, this is there my proposed tool for postprocessing the debug hud output can come handy.

Thank you very much for the information! So it seems, the only way to get the flight data from the game engine is to observe and manually note the desired flight data parameter from the hud debug output while flying the aircraft. Mmmh...I have an idea: Why not record a video of the flight (e.g. via shadowplay or the like) with enabled hud debug mode. Then afterwards postprocess the video to extract the data from the video images. I think it shouldn't be too difficult to write a small tool in python by using opencv and a ocr library to extract the data. Then we have access to all hud debug parameter over the whole flight time. My reason for getting the flight data is the following: I wonder if it's possible to implement the SF2 flight model engine with/in JSBSim (used e.g. by FlightGear) since AFAIK both use aerodynamic coefficient buildup method to compute aerodynamic forces and moments. Thereby the coefficient tables from the SF2 ini files could be used in JSBSim. And if I decide to give it a try (implementing the sf2 model in jsbsim) I wanted to know how to test/compare both models. Getting the needed flight data from JSBSim is easy but to get the flight data from SF2 I didn't know if there was another way besides the hud debug output. But why implementing the SF2 FM engine in JSBSim? 1.) To teach myself something about aerodynamics, aircraft control and simulation,... 2.) The JSBSim model can then be used to assess and develop flight models for the SF2 engine. Similar to the tool streakeagle wrote. 3.) If someone is interested in building a (maybe community driven, open source) combat flight simulator, he could use jsbsim/flightgear and use already available coefficient tables from SF2 inis.

Of course it's possible to write an exporter for 3ds max. But I don't plan to do it myself because: 1.) I don't own 3ds max 2.) My priorities are more in providing a free/open source toolchain for strike fighters 2

Nice to see some results.

It's one material per object.

I know Yankee Air Pirate is controversial here. But through this addon I learned about and came to the strike fighter series. So it seems Mike was partly responsible that I'm here in this community now.

I fixed the bug in version 0.2. I updated the link in the first post. Please redownload the script and reinstall it into blender. I tested your cube with blender version 2.78 and 2.79:

Nothing wrong with your cube. Seems to be a bug in my code. Although with the blender version I use (2.78) it works. I'm working on a bugfix. Stay tuned...

Correct! The monkey is Blenders mascot "Suzanne". I exported it with my exporter to a lod file. I will release a first version (e.g. no animation support yet) of the lod exporter for blender within the next days.

Ok, I had a look at the Madagascar terrain. What Stary did is the following: He still used stock (alpha) tod object types (eg. x-trees with base). But made them bigger in the horizontal direction. Then he textured those single objects with the multiple tree texture (the .tga file you mentioned). So that one single tree object appears as multiple trees. Nice solution!

Mmh.. I thought Stary did just that: put a lot of single tree objects onto the tiles. Maybe I'm wrong here?

AFAIK no one from the modding community has created custom shaped TOD objects yet (besides on guy who made a feasibility test )

I think the relevant entries are in <terrain>_data.ini: [TerrainMesh] SolidObjectVertexCount=12288 SolidObjectIndexCount=18432 AlphaObjectVertexCount=8192 AlphaObjectIndexCount=12288 I haven't investigated it myself yet, but I think they define the maximum numbers of triangle vertices of solid (buildings) and alpha (trees) objects (per tile?). By increasing those values it should be possible to plant more buildings/trees.

The tool should work with up to 999 target areas. I thought target areas can only have 3 digits: from TargetArea001 to TargetArea999 ? Can you confirm that the game engine can handle more than 999 target areas?

Try opening the base.ini file, not the .lod file.

My catextractor expects the SF2 install directory folder structure. But you can easily create a "fake" SF2 install directory structure: e.g. create a directory "fake_sf2_install_directory". Within this directory create a subdirectory "objects". Into this objects subdirectory you copy all cat files you want to examine. Then you only have to point my catextractor to the fake_sf2_install_directory.

You can use my catextractor. Enter *.lod into the filter field and press apply filter. In the file list window you can see now all lod files and in which cat/dlc files they are contained.

The shimmering of TODs and target objects and the flickering of shadows in the thirdwire game engine always anoyed me. And since I'm playing FE2 recently, there this problems are more intense,I decided to have a closer look at this issue and possible solutions. This is what I came up with: As many of you already know, the shimmering of the objects and flickering of shadows is caused by the limited precision of the z-buffer. The precision of the z-buffer depends (besides the buffers bit depth) on two values: the near clipping plane distance (znear) and the far clipping plane distance (zfar). To increase the z-buffer precision you have to shorten the interval[znear,zfar], either by decreasing zfar or by increasing znear. Whereby increasing znear is FAR more effective for increasing z-buffer precision. Changing zfar: I'm not quite sure what *.ini setting defines zfar. But I think that decreasing the horizon distance in the game options menu decreases zfar. But I found to see any (minor) effect (regarding reducing shimmering/flickering) I had to change the horizon setting to Near. But I like the horizon setting at Very Far and I will let it at Very Far. Changing znear: znear is defined in the flightengine.ini by FE2: [NearSceneClip] NearClipDistance= SF2 with object fading disabled (fading enabled I haven't investigated yet): [ForegroundSceneClip] NearClipDistance= But there is an exception: If in the <aircraft>_cockpit.ini OpenCockpit= is set to TRUE, then znear is defined by (the usually smaller value) ExternalClipDistMin=. Thats the reason why in some aircraft the shimmering happens, while in the external view it does not. The external view uses the flightengine.ini setting. The znear value has to be increased as much as possible. Unfortunately this value can not be increased arbitrary without side effects: e.g. clipping issues. You have to experiment until you find a maximum znear value without side effects. If you are lucky then the znear increase was sufficient to stop the shimmering/flickering. If not, then you have to tweak further. Tweaks against flickering shadows: Against the flickering shadows I don't know any tweaks. The only solution is to switch them off: Shadow option = High switches TOD shadows off, = Medium also switches target object shadows off. The following tweaks are meant to reduce the shimmering caused by z-fighting between the terrain and the TODs / target objects. What the tweaks do is to increase the z value distances between the terrain and the TODs / target objects. Tweak against shimmering TODs: In the <terrain>_data.ini set [solidObjectTextureMaterial] ZBufferOffset=2.0 or higher (in FE2 I set it to 5.0 to stop the shimmering) That modifies the z value by an offset so that the TODs are put a bit "forward" in the z-buffer. But this doesn't affect target objects shimmering. Tweak against shimmering target objects (and TODs). The solution I found is to modify the terrain shaders: TERTERRAINEFFECT.FX (near terrain) TERFARTERRAINEFFECT.FX (far terrain) TERWATEREFFECT0.FX (terrain with water, Water Detail = Low) TERWATEREFFECT1.FX (terrain with water, Water Detail = Medium) TERWATEREFFECT2.FX (terrain with water, Water Detail = High) In each shader I added the following lines in the vertex shader code const float zOffset = 3.0e-7; output.pos.z += zOffset * output.pos.w; That adds an offset to the z value so that the terrain is put a bit "back" in the z-buffer. This tweak ALSO affects TOD shimmering. But it has a side effect: The TOD / target object shadows are a bit shifted if viewed from greater distances. It's a tradeoff: choosing a greater zOffset value lessens the shimmering but shifts the shadows more and vice versa. You can try to decrease/increase zOffset in small steps (e.g. 1.0e-7) to see which offset fits best. The terrain shaders for FE2: fe2_zbufferoffset_shaders.zip Put the shader files (*.fx) into the Terrains\<terrain> directory. @admins/moderators: I also have modified SF2 shaders. But I don't know if the combatace policy allows to upload modified LOCKED shaders. Update: The terrain shaders for SF2: sf2_zbufferoffset_shaders.zip

Nice project! Regarding flight modeling. You mentioned that flightgear has the flight physics done correctly. Among other FDMs, flightgear uses JSBSim, a sophisticated open source FDM: http://jsbsim.sourceforge.net/ It's written in C++. However I found another (abandoned) combat flight simulator project written in java: "SimuLab" https://sourceforge.net/projects/simulab/ , that also uses JSBSim for the flight physics. I think they started with accessing JSBSim via JNI but later ported JSBSim to java.

Das erwähnte Zitat scheint wohl besonders in AfD-Kreisen die Runde zu machen. Es ist aber so dermaßen aus dem Zusammenhang gerissen, daß ich mich frage, ob das (Herausreißen) mit Absicht geschah oder ob die AfDler den Kontext wirklich nicht verstehen. Zumindest in der Vergangenheit hatte die AfD ja bereits Schwierigkeiten gehabt eine Äußerung im (Satire-)Kontext zu verstehen (Weidel vs Ehring). Also was hat Käßmann wirklich gesagt: (Quelle: https://www.landeskirche-hannovers.de/evlka-de/presse-und-medien/nachrichten/2017/05/2017_05_26_2 ) Sie hat also NICHT gesagt, daß Menschen mit zwei deutschen Eltern und vier deutschen Großeltern Nazis sind. Sondern sie hat ein Teil des AfD-Parteiprogramms mit dem kleinen Arierparagraphen verglichen und die AfD damit in die rechte Ecke aus der der "braune Wind weht" gestellt.

Top notch work! I'm curious if (stock) First Eagles objects are really scaled down. I could only check stock objects in First Eagle 2 since I don't own First Eagles 1. In First Eagles 2 the stock objects seems to have real life size: With the lodviewer I measured e.g the wheelbase of the Type J Lorry = 4.25 m (real life = 4.15m) or the length of the Beutepanzer IV = 7.88 (real life = 8.05) Maybe someone can check some stock objects in First Eagles 1?