Hypothetical question on Avionics in BMS
-
But I gave it 2 minutes of thought… the interfaces would be very complex, and bidirectional… Plugins would have to own rendering surfaces for their HUD, MFDs, and various RWR/DEDs/PFLs etc and map these onto texture-surfaces in the cockpit. It would have to be flexible enough to handle whole new systems like IRST that don’t exist in Viper.
On that note… this idea is not new. Its been proposed for BMS since at least 2013, for example.
Its been implemented in other video games already.
Kerbal Space Program has a fairly popular mod which does exactly this, called RasterPropMonitor. The mod as a whole is for cockpit (called 'IVA’s in KSP lingo) props, but it more specifically allows for MFDs to be defined in config files which are read at runtime. Im not suggesting this would be an easy plug and play arrangement for BMS, but the code is open source - so there is an example of this arrangement, already in the wild.
Github repo for RPM: https://github.com/JonnyOThan/RasterPropMonitor
I’d love to have a crack at implementing a proof of concept for BMS… but I dont have the time Bit busy with RL at the minute.
Besides, I havent finished the -last- proof of concept I started for BMS MFDs!
-
Its a shame. I always thought a basic F15A/C would be easy~ to do in comparison to other AC given its age and AA specific duties.
-
Actually, the interface could be standardized and allow something like 28 or 56 inputs per routine (groups of panels, say), with user selectable keys/callbacks outside of reserved ones. Then it would simply become a matter of the user determining the number and names of panels to use, and assigning them to a cockpit model as a set. All menu driven of course.
Not trivial, but not impossible…
-
On that note… this idea is not new. Its been proposed for BMS since at least 2013, for example.
Its been implemented in other video games already.
Kerbal Space Program has a fairly popular mod which does exactly this, called RasterPropMonitor. The mod as a whole is for cockpit (called 'IVA’s in KSP lingo) props, but it more specifically allows for MFDs to be defined in config files which are read at runtime. Im not suggesting this would be an easy plug and play arrangement for BMS, but the code is open source - so there is an example of this arrangement, already in the wild.
Github repo for RPM: https://github.com/JonnyOThan/RasterPropMonitor
I’d love to have a crack at implementing a proof of concept for BMS… but I dont have the time Bit busy with RL at the minute.
Besides, I havent finished the -last- proof of concept I started for BMS MFDs!
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? -
Its a time and effort thing, absolutely. Anything is possible with enough time and coffee.
As a non team member, I’m speculating with this next bit, but I think I Hawks comments above back this up: Its also a big priorities and cost benefits thing.
Its a big project, that would require lots of effort, and the benefit would be that other aircraft other than the one everyone is primarily interested in get improved…
My suspicion would be that you could take an approach similar to mav-jps approach with the flight model, and have a whole new piece of code for handling modular avionics. Drawbacks being, the huge amount of effort required, and the entire new category of possible bugs in MP - and in the case of the modular config files based avionics idea? The reason for putting that into config files would be to allow the community to assist in designing avionics…and we’ve already seen efforts asking the community to assist that have been more or less ignored.
My guess, FWIW, is that it’s an “all of the above” thing. Low priority idea, that would take lots of time, introduce lots of bugs, and would largely affect other aircraft rather than the F-16.
-
+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.)
-
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: