Hypothetical question on Avionics in BMS
-
aerodynamics/weight and control surfaces.
You can do that already! That stuff is in tables in your data folder.
-
How about going in the opposite direction with avionics and making the oldest Mig in the database (Mig 17?) flyable? What is the oldest US/EU plane in there? Would love to see a Sabre or Super-Sabre… back to 1952!
-
You can do that already! That stuff is in tables in your data folder.
Is there really just a single flight-model codepath in BMS that’s entirely data/table-driven? That’s pretty cool. (Or maybe there’s two… viz. the *afm.dat and non-afm files…? still pretty amazing.)
I guess I’d assumed these config files fed into (C++) classes for each plane, that would perform calculations differently. But the dat files seem pretty detailed, I guess can believe there’s just one or two flightmodel codepaths that are entirely config-driven.
Certainly even if there was a software-plugin architecture for avionics you’d want as much to be declarative / config-driven as possible… number of MFDs, their sizes/shapes/resolutions etc, number/sizes/shapes of other display panels, instrument lighting etc…
-
When I thought about that and reviewed the SP code many years ago, trying to figure out how to put that in practice, two major points raised as important for me: (1) one needs to think in a very modular way in order to emulate different systems for acft of different eras, countries, etc and (2) one should avoid at all costs an “open-chest surgery” on the code. You dont want to change the interfaces of all classes in F4. You certainly would brake the campaign and surely make everyone very angry with you. At the same tone, I would not go beyond avionics in a first attempt and surely would not work with DLLs for each new aircraft (=potentially too slow).
One should not think about IRST or ICP or DED, etc. You model, lets call it, a “device” (choose a better name please). A device can be anything you want depending what you add to it. It is a new class for BMS, and the dev working on that would need to design the (possible) components tree. The user would later add components to each platform as she/he desires.
The approach I would try was to take the methods already in each class in the SP and refactor that in components and algorithms.
Call a class “device” which declares an interface (but not behavior) and think about the general stuff every device in principle could do (IRST; DED, SMS, Fuel System, MDF). Then compose all devices by implementing behavior. What kind of general stuff that every device should have? A draw function, for example, or perhaps a mode. Whether the device will implement its behavior later or not depends on the device (=user choice)
What about new methods which are not declared in our main device class. We can add it by data driven input (=user choice, i.e. dynamically).Lets say the user wants to design a device for a given acft. The user will add as much methods as required to make it work as in the real acft.
- Can I see it in the cockpit? Yes, then I will add CPStuff.
- Does it show map? I will add a Map class
2.1) Is the map in color? I will extend its functionality by adding different strategies (“Color Map”, “B&W”, etc).
3)Does it show radar returns? I will add a RadarContact class - Does it show text? Yes, I will add a Text class.
4.1) I will add different algorithms to add text in different ways, positions, fonts, etc. - Does it have borders? Yes, I will add a Border class
- Does it show a compass? Yes, I will add a Compass class
6.1) How this compass look like? Implement different algorithms to load from HD/draw different kinds of compasses
…you got the idea.
All these points above of course need to be coded but the user will define how to put them together later. In order to cover most of the acft we are interested in BMS at the moment, a possible approach would be to choose a group of n planes and put together a kind of list of all its sub-systems, displays and look for common stuff and what differs. If one can implement the systems of these selected aircraft with the approach described above, than there is a good chance (I hope) that it will be applicable to more acft later.
What are your suggestions and why? Think that these acft will be the inspiration for building blocks…I will start:
F-16CM-50 (for obvious reasons)
F-16A-5 (70s era example, mixture of analog and MFD cockpits, share some weapons and sub-systems with the block 50)
… -
So all we need to do is turn the Mig 17 into a Mig-15, the F-5A into an F-86, make them flyable and it’s 1952!
-
+1 to what Blu3wolf and I-Hawk are saying.
Part of the problem is defining how far do you want to take it (ie. what do we mean by “avionics”)… just different-looking MFD displays? Or actual new features and functionality specific to individual planes. (eg. thinking of the flaps and auto-throttle on the Hornet … vtol and thrust-vectoring on Harrier)
And not just new/different callbacks, for clickable cockpit switches, but consider different planes have different button/hat layouts on their sticks and throttles… do we want an ability to define and select different HOTAS bindings for different planes? Probably … considering the various hotas switches (TMS/DMS/CMS etc) are coupled so closely with the F-16 avionics.
Need to model different types of DED displays and ICP input controls… again just look at the Hornet for example of how different it can be, for a plane of same era and same country of origin.
And if we’ve gone that far, may as well go all-in … customizable flight-models, aerodynamics/weight and control surfaces.
The lowest priority, might be … different radio sets, and different IFF and IDM-style systems etc for very old (or very new or non-western block fighters…
Nothing is impossible but it’s a huge* swath of work just to get to the level of “different looking stuff on MFDs” in a way that could be programmed and plugged-in by third-parties without source access. (*I base this estimate solely on looking at the Hornet in BMS… which was clearly a labor of love by people with source-code access, and really only has a slightly-different looking HUD and badly mangled DED from the Viper… but, as always, I would love to be told I’m wrong.)
Airtex, I believe that what is meant by “avionics” is the the whole deal (ie: 1:1 with stock jet ) Just to clarify, the current BMS Hornet is not a carbon copy of the Viper. Flaps and autothrottle are already in the BMS Hornet, and it’s FM has been refined (in the F-18C, at least.
What you write about HOTAS, switchology, etc. , is frankly my biggest concern, especially if you’re consider doing this in all the jets in BMS. That, and the needed DOCs. -
Brother, Stevie,
If I may, I’d like to ask a question. Hopefully, this won’t set someone off, as I’ve made it clear I’m a BMS Guy. But…
We see DCS and others you mention routinely installing different avionics. What IS keeping us from doing it in BMS? Obviously it will be a big and technical project. So,is it a question of the time it would require? Is it (no offense to anyone) an “it’s a Viper Sim” thing? Is it a technical thing with our BMS coding? All of the above, or something else?I think there are really only two things stopping BMS in their tracks - 1) information available to build hifi avionics models from; and 2) the number of devs/personnel available to actually do the research and coding (which isn’t just a BMS problem).
There isn’t really a lot that could be done about either…for a lot of cases. But for the easier ones - like the Harrier, and some of the other older jets - one could see works in progress.
-
I think there are really only two things stopping BMS in their tracks - 1) information available to build hifi avionics models from;
FWIW, we can always copy-paste stuff from DCS
and 2) the number of devs/personnel available to actually do the research and coding (which isn’t just a BMS problem).
I’d estimate that more than the above, it’s about motivation. Let’s say that BMS currently has ~6 fully active coders, and out of those 6 I’d say that 1 or 2 can choose to focus on avionics, possibly of other platforms as well, but it’s solely their choice to decide what they’d like to focus on. At the core BMS don’t have and never had a “plan” - it’s mostly about people deciding what to chase and just run for that (ad it makes sense because after all this is a free time based development, so while I can expect people to work and deliver something, I can’t really tell them what that something should be). It’s mainly in API changes where we have some kind of “plan” due to the nature of possible dependency between 2 WIP items.
And just to say it again clear and loud: Avionics coding is “fun”, at least in my eyes - I mean the APIs are mostly exist and you just need to start building the systems. I liked it when I did it for the F-16, it was an interesting journey and I’m almost sure that as long as I’m around at some point I’ll return to do that, possibly in parallel to other developments that I plan later.
There isn’t really a lot that could be done about either…for a lot of cases. But for the easier ones - like the Harrier, and some of the other older jets - one could see works in progress.
If there are people that want to help and have the ability to code in C++ and they can prove us they can deliver quality stuff, then I’m here to hear them. I think that ~2 Devs that has the ability can initiate something very interesting in the avionics field and especially of other aircrafts. Developing an API that will be a door for other aircrafts systems isn’t so easy but also not that hard.
Cheers!
-
Well now I have a reason to learn C++
-
… It’s mainly in API changes where we have some kind of “plan” due to the nature of possible dependency between 2 WIP items.
…
If there are people that want to help and have the ability to code in C++ and they can prove us they can deliver quality stuff, then I’m here to hear them. I think that ~2 Devs that has the ability can initiate something very interesting in the avionics field and especially of other aircrafts. Developing an API that will be a door for other aircrafts systems isn’t so easy but also not that hard.Cheers!
I certainly see the avionics development would brake a lot of classes before it is running again. In the old SP source (unless you guys changed), avionics were distributed over several places of the solution, Aircraft, Cockpit, Displays, Faults, FCC, ICP, IRST, Radar and RWR and classes therein would necessarily need to be refactored. If you are interested on really touching that, a PM was sent.
-
Don’t assume DCS is the “gold standard”…or any sim, for that matter. As I survey different sims I find that they ALL have both strong points and weak points and that in general if you want to get something “real” you need to know what you are looking at and mix and mate vice “copy and paste”. This is why having the information available to do a hifi model is of paramount importance. You’ll find that when you know what the real story is you’ll probably end up making changes/augments.
Not to mention that modern aircraft change substantially over time…and that’s even harder to follow.
-
Damn… How I’d wish to be a c++ expert now… :frusty:
-
Damn… How I’d wish to be a c++ expert now… :frusty:
@MartinGecko and @sasah320 … I am (or was) a C++ expert and wish I wasn’t. So if someday scientists figure out how to achieve a vulkan mind-meld … hit me up. lol
I consider those early years (~a decade) of my career to be a gigantic waste… the productivity of modern languages (C# or Java … or Python etc) is about 20x greater… and performance only a few % slower… I sincerely recommend to start with one of those, for anyone intent on learning software development.
-
@MartinGecko and @sasah320 … I am (or was) a C++ expert and wish I wasn’t. So if someday scientists figure out how to achieve a vulkan mind-meld … hit me up. lol
I consider those early years (~a decade) of my career to be a gigantic waste… the productivity of modern languages (C# or Java … or Python etc) is about 20x greater… and performance only a few % slower… I sincerely recommend to start with one of those, for anyone intent on learning software development.
The goal is to help the Devs… If C++ is what they need, C++ it is. But I am afraid we have to wait to Warp Drive to be available so I can go to Vulcan and hire somebody there to mind-meld us… maybe it takes a little long… :eyebrows:
-
the productivity of modern languages (C# or Java … or Python etc) is about 20x greater… and performance only a few % slower… I sincerely recommend to start with one of those, for anyone intent on learning software development.
I should probably amend that to mention Rust? Gaining a lot of popularity in the past year… and it’s actually much more C/C++ like than C#/Java/Python. (No garbage collection … ownership of memory-allocation is explicitly modelled in the language.)
I haven’t done anything with it, so can’t personally recommend it, but … well I’m actually a little bitter, it looks pretty close to the language of my dreams, back when I was doing a lot of C/C++ work.
And, I haven’t heard anybody else say this, but it might be a good on-ramp, for backing into C++. Easier to learn, modern docs and samples (as opposed to 30 years of cruft and crap and diverging standards) and certainly internalizing core Rust concepts (like RAII, immutability, and ownership of memory-allocation) will help you write better, cleaner, safer C++ code if eventually you do go that path.
https://doc.rust-lang.org/rust-by-example/hello.html
Ok I’m WAYYY OT now, sorry.
-
I should probably amend that to mention Rust? Gaining a lot of popularity in the past year… and it’s actually much more C/C++ like than C#/Java/Python. (No garbage collection … ownership of memory-allocation is explicitly modelled in the language.)
I haven’t done anything with it, so can’t personally recommend it, but … well I’m actually a little bitter, it’s pretty close to the language of my dreams, back when I was doing a lot of C/C++ work.
And, I haven’t heard anybody else say this, but it might be a good on-ramp, backing into C++. Easier to learn, modern docs and samples (as opposed to 30 years of cruft and crap and diverging standards) and certainly internalizing core Rust concepts (like RAII, immutability, and ownership of memory-allocation) will help you write better, cleaner, safer C++ code if eventually you do go that path.
https://doc.rust-lang.org/rust-by-example/hello.html
Ok I’m WAYYY OT now, sorry.One word, Assembly…
-
As the saying goes: “C allows you to shoot yourself in the foot easily while C++ allows you to take your entire leg off.”
I did a lot of C back in the Amiga days (Manx Aztec C and Lattice C later on), my physics thesis involved C++ in the mid nineties because no money or pain in the world would force me to program in FORTRAN, but that’s about it. I’ve never really grasped the core concepts of C++ (if there are any core concepts shared between the various “standards” and dialects), and today I really prefer python & friends for the stuff I’m doing, it’s fast enough for my purposes. Rust is being discussed for entering the Linux kernel landscape, that should be interesting so the language sure is worth a 2nd look I’d wager.
All the best,
Uwe
-
One word, Assembly…
Anyone can write assembly.
Its easy to write C#, and its not hard to write decent C# that the compiler will fix. Writing good assembly is an art form that I doubt I’ll ever acquire.
-
One word, Assembly…
lol, I started to write, that C/C++ evolved in a time when the only other alternative was assembly – for 8- or 16-bit CPUs with a tiny handful of registers – so it seemed wonderful at the time, but now it’s so painful…
Not trying to sound so negative about it – I guess my point is we should all respect and appreciate the deep dedication of everyone on BMS team who is still fearlessly wrestling with this 20+ year-old C++ codebase!
-
There are three different FMs in BMS
OFM (legacy)
NFBW
AFMThey are all configurable to a certain extend from the data files.
Let’s be clear about that. From my point of view there is absolutely no need to externalise more the FMs.
In 12 years of AFM existence , noeone has created another one
I created f18 , mirage 2000, harrier and su33 that are still very rough v’but noeone took the stick to improve them
Point is: BMS already allows huge possibilities to create FMs from the data files , VERY detailed
FMs (just open an AFM file to understand), but this is a very complex task and so far noeone took it (for AFM)My advice : better focus on avionics , this is what is lacking .