kazereal

First one does not yet fire, just prepares guns for firing. Second command will actually fire guns. It makes more sense with a stick that has two "switches" in the trigger (like TM Warthog). In some WW2-aircraft you might have had machine guns and cannon to be used separately in slightly similar way. Edit: sorry, thought you were asking about F-5.. Can't remember what the first detend on F-86 does.

Looks like old code does not consider all combinations of commands to flight surfaces. It does take some input but does not go to same lengths in using those surfaces as should be. I'm looking into that now to combine inputs. For example, when flaps are commanded down, they still have some roll authority. At least that is my understanding, but I'll need to look at more information on that and other surfaces to get full use of them into simulation. Edit: and that brings a problem in the 3D model draw arguments: I think the draw argument for flaps needs to be disabled (removed) so that DCS is not conflicted on what values to use for drawing their position. Since the way the API works, we need to give some value there but we can't tell "don't use this value for drawing". Edit2: after I've done flight control changes, I need to go back to aerodynamics code and calculate values both sides that might have different deflection instead of just using same value for both sides.. That old aero-code does not handle those kinds of situations.

There's some cleanup of the units used in calculations: there was plenty of conversion back and forth in different places, I think those are now all gone. Check if you spot something that seems "off" somehow. Trailing edge flaps now follow landing gear up/down lever so that when gears are set down flaps will be coming down as well. Since flaps are normally used as ailerons it can be weird sometimes how they are. Edit: Also, looks like as a result of clearing the units in calculations, elevators don't have that huge flutter any more in supersonic speeds. Edit 2: another thing for testing: position of lift moves as function of speed, meaning that: * in sub-sonic speeds lift is in front of center -> tendency to pitch up * in supersonic speed lift after center (towards tail) -> stable flight This does not have proper calculation yet, it is just moved frontmost to aftmost position for now. There's plenty more to do in that regard anyway..

Flight control system code is now split into separate parts so it should be easier to make further changes. No functional changes at this point, just preparing code for further changes.

And here's another rant about people misunderstanding what simulation code means. If real aircraft has performance numbers like "roll rate is X, climb rate is Y" you don't input those values into simulator code, that would skip the whole purpose of the thing. For one thing, performance numbers like that depend on atmosphering conditions, payload and a large number of other variables. Performance numbers are mostly the "target value" you compare simulation peformance against. Actual simulation has the other things that actually determine what the performance will be: aerodynamic properties, engine thrust and efficiency at given altitude and so forth. Casual games often skip whole thing about simulating aircraft and use those performance values regardless if they actually fit the flight conditions. Simulators need to use more time for development and those values are not more than "guidelines" of how the simulated aircraft should perform in same conditions to validate that simulation works correctly: when different properties of aircraft are handled correctly they should be a match.

I've removed old hack that had hard-coded default pitch trim to -0.3 Now that there is working binding for trimmer use that instead if necessary. Removing some old workarounds and such should help make better end-result.

I've finished cleaning up the aero-calculations which used to calculate some things multiple times per each "slice" of simulation. Hopefully code is easier to follow now too. Have a look and let me know if you spot a new bug due to changes made. You don't need to report bugs existing before these changes, just if you spot something troubling that was not there before. Code is in usual place: https://github.com/ipr/F-16Demo/ Edit: changes I mentioned are pretty much limited to here: https://github.com/ipr/F-16Demo/blob/master/FlightModel/Aerodynamics/F16Aero.h You can compare with diff tools, split-view in github seems to work nicely (unified view can be difficult to follow due to amount of changes). Edit: for people interested, result of changes is that the file is now around 300 lines shorter than a day before (~730, down from ~1000). That should also make it simpler to modify the calculations and improve upon (goal is to have better supersonic aerodynamics at some point there).

There's a rough first prototype of the code for calculating "wet" mass center of gravity. Does not include external payloads yet (I haven't looked at external data yet). This is still rough and tank positions are not there and new cog is not used correctly in resulting calculations. Should work as example of the concept anyway. (I think I saw some values somewhere, need to go through documents again..) (And of course there are different coordinate systems and different units so as not to make things too easy..) Edit: for those interested, DCS and many many 3D software use coordinate system where origo is in middle of the aircraft (and there's two variations of that, left-handed and right-handed). The old NASA documents usually have system where origo is at tip of the nose of aircraft. Just an example of what the differences can be.

Cool :)

No idea what that could provide. Basically you can input anything you like and get something as result, if that is usable is another matter entirely.. If by CG coordinates you mean center of gravity location that we know already for the "dry" configuration. The thing that I have planned is calculation for new CoG when fuel tanks have different amounts of fuel in them (for example, leak in one tank from shrapnel -> change in balance). And there are multiple internal tanks like in many aircraft. Basically weight of the fuel remaining in the tank and location (relative distance to reference CoG) is the thing that is needed for calculation. I haven't got around to it yet since I've researched some other things that will be needed later. There's already plenty of aero coefficients available, CFD would not provide much new information (unless you do it better than NASA). For that you would need very detailed CAD model and that is not simple thing for professionals either to find the coefficients (buddy does CFD stuff for a living). Basically, adding more data does not help for aero stuff, quality of the data is different matter and there's no simple solution to getting that unless you are prepared to spend a lot of time on it.. If you can reliably verify existing data with that and determine what is "trash data" that would be more helpful since that would reduce amount of work.

It does need some bugfixing though.. :music_whistling:

I've added a rough light-blinker handling: this supports having different sequences so that you can put different patterns of blinking for the lights. There's only one hard-coded sequence used now and only input-binding for navigation lights is there. Something to test and play around with though. In theory that could be made configurable. Have fun :) Now back to researching other things..

For people who are not that familiar what simulation approaches are like let me try to explain.. Let's use engine thrust output as example. There's different approaches here: 1) Using simple multiplier "this much throttle gives this much thrust" - it might be fine for demonstration purposes, but real world is not that simple. Especially since there is rarely linear rate like that.. Engine management uses sensors to determine amount of air and amount of fuel required so that fuel/air mixture can ignite and burn most efficiently. 2) Better approach is to use lookup-tables (*). These work better in non-linear cases where air density (altitude) and pressure ("ram effect") can change amount of air entering engine and you need different fuel amount for the mixture. And as a result, engine thrust output changes too. Performance of lookup-tables is generally very good but depends on "resolution" of data (amount of data points in range). Using lookup-tables often needs interpolation between datapoints to improve accuracy but data "resolution" still is a major factor here. Aerodynamic coefficients are in lookup tables in this F-16Demo (for example). (*) Simple lookups can be hacked with if-else but these are: A) hard to maintain (if parameters change) B) really really complicated when number of parameters increase (combinations of multiple conditions/parameters), and C) often slowest possible way to run simulation. Even with branch prediction, instruction cache and so on CPU are still very slow to handle branching code comparing to unconditional (non-branching) code. So for small amount of parameters/conditions these can be fine but better to avoid in complex things. 3) Mathematical equations. These can provide best accuracy without having large amounts lookup-values. When the equation is correct and has enough parameters it can adjust to wide range of different scenarios. When amount of air entering engine changes, fuel mixture changes but also if fuel parameters change (energy output, ignition point etc.) you can use same bit of code to simulate wider range of flight conditions and aircraft conditions. Bonus is that you can often reuse same code for different variations (different inlet size, compression ratios and so on) with just changing the parameters of the equation. Downsides are that this needs most research into understanding what parameters you need and how they relate to make equations and program them. Also if you don't have some parameter included, it might not work outside some conditions. Adding more complex equations with larger amount of parameters also increase computation time. Code structure and optimization plays a part here. So this is my short explanation why some progress is slower than other, why results are often different and why there are different approaches/considerations to writing code.

Like said many times before, this is tool for learning sim development. Aim is not to make a final module or even playable mod, primary point is for people to learn how to develop modules: how things work with DCS, what kind of stuff you need in a module and so on. Getting it all right takes plenty of time of course, learning how to simulate various things. That takes time to research, experiment and test things to learn how to do them. Result of course can be more or less usable simulation of the F-16, but that is not the end goal: learning and demonstration of how to do simulation is the primary goal here. If someone has other ideas of how to use this stuff they can fork (branch) their own and continue from there. Publishing it as for-sale thing is out of the question: license rules for the 3D mesh prohibit that. Getting permission for the NASA data and Smiley's original code would be needed too. Plus permission from GD/LM, PW, GE..

Ok, I expected as much but good to know. :thumbup: Ok, no worries, no rush :) Point is about learning to make sim stuff, not about rushing to some end.

Currently, all you need is install Visual Studio 2013 Express edition (update version 4). It is called "Visual Studio Community edition" or something now.. That is free for private use. Github has desktop client if you don't want to install the command line git with msys. It used to be trickier before with older versions. FM should be pretty self-contained now without external dependencies.

That looks interesting. Thanks for information :)

The other part of advanced cockpits is the rendering of displays like HUD and MFD. I'm not expert on the cockpit related stuff so sorry about confusion.

Ok, sorry about that, hard to read a tone from text :)

Well, one thing that causes confusion is about what "systems" you need for cockpit and what "systems" you need for flight model. Clickable cockpit would need the ED SDK, so that likely won't happen. Things like radar, advanced comms and weapons I don't know (someone else might have to look at those). Then there's the systems that you need for advanced flight model since they affect flying. It is not something with clear separation but we'll see how far we can push things.. So it might end up being somewhere between SSM and ASM possibly but I can't promise anything.

Personally, I hope to achieve at least AFM level EFM (EFM by itself does not really mean anything except "outside ED control"). But since this is a hobby that I'm doing out of interest to learning, there's of course things to consider if real-life decides otherwise. As it is, there's a lot of work to do in the systems code to get into AFM level simulation. (And I do mean LOTS). You can take a look into history and this did not have much in the systems and flight model has it's limits (no supersonic model, for example). The original NASA TP report data only covers subsonic speeds (upto ~.6 mach). And since it is EFM (not using SDK or code from ED) things like ground effect, engine thrust simulation, hydraulics and so on and so on need to be coded there. People seem to forget about this when asking for different things now that this has more life into it again. Things really need much much more work to get done RIGHT. I'm not interested in just hacking something awful together quickly: I'm really into learning how to do this properly. The crude hacks that may be there occasionally are meant as temporary solution until I or someone else has time to research and/or implement it properly. I mean, there's tons of crappy mods with bits and pieces from other aircraft thrown together or something other like that. I don't care about those, do them if you want to but the one in my repository is going to be long way around, meaning that it WILL take time and effort. And because the original code was not planned to include detailed systems it is taking shortcuts that need to be undone to make progress in the longer route. One more thing to clarify: software development needs lots and lots of iteration. That means making a prototype, seeing how it works, what you can learn from it and then improving it or replacing with better code. So there will be short term things and trials to see how things work, how to integrate with DCS and so on. It is a learning process, there's no book about "this is how you make detailed simulation". (Maybe this thread can serve that purpose, I don't know.)

I can relate to that ;) Btw, if taking off seems odd now there's two things: - old code did not use fuel weight, just "dry" weight (well, it still does not use it in every place..) - there is no ground effect in simulation (looking at that) When comparing to some full-blown simulations remember that everything is not there yet and you can get odd results. Also it is a bit of SFM&EFM mix now too. My intention is to sort these out but that does take time..

Nice :)

Well, that is simple to answer: there is no maximum for it. The actuator code I've worked on is not there for flight surfaces yet, just airbrakes use it now and even there the movement rate is just multiplier I invented. Maybe at some point with more time I can try to look for better rate information and more detailed but for now it is what it is. People, take down the expectations.. It is not THAT detailed since there's very little systems simulation there yet. I'm looking into engine simulation currently, that is pretty essential and now it is just "if throttle is this give this much thrust" to put it simply. So not simulated at this moment. For example, it has no spooling up or down (no engine inertia), it does not consider atmospheric pressure or density at all and very little about the speed. So there is much to research and develop to make it into simulated. But it is something I'm interested in doing now.

People are always complaining about how they don't hear enough about development so.. ;) Anyway, here's all the "one step forward, two steps back" of development.