Hypothetical question on Avionics in BMS
-
Hypothetically is it possible to add the avionics from other aircraft into BMS so its based on its own avionics instead of viper? Just asking.
-
Hypothetically is it possible to add the avionics from other aircraft into BMS so its based on its own avionics instead of viper? Just asking.
Hello,
this is totally technically possible.
It’s just a matter of :
- Decision
- Ressources (reference and manpower)
- Motivation
- Need
Which are all almost about zero for now !
Cheers,
Radium
-
Alright, wasnt sure thanks!
-
Hello,
this is totally technically possible.
It’s just a matter of :
- Decision
- Ressources (reference and manpower)
- Motivation
- Need
Which are all almost about zero for now !
Cheers,
Radium
Radium, and Martin,
IHMO, there’s also the issue of code access -
I suppose, if you wanted to debate semantics, you could consider “resources” to include trifling things like “access to BMS source code…”
-
Well, at some point I’m sure someone will pick that path of starting something. More than anything it’s a matter of 1 of the BMS coders to decide he wants to do that. I can clearly say that if my hands weren’t full already I would probably have started working on something, e.g A-10 or Hornet.
Resources - Yes there are, but again, it’s a matter of someone to decide (Not me at this time because I physically can’t, I have other commitments which take all my dev time and I still not finished)
Docs - If ED can do, we can do. Information exist and the point is to gather it all from ANY available source.Will it happen one day? I strongly believe so yes, because if no one will start that journey at some point, then I’ll probably will.
When? No idea and it’s hard to tell ATM.Anyway I agree this is a necessity for BMS. Not all coders in team share that thoughts, but as I said there is no matter of “consent” or mutual decision here, BMS development is free so if someone wants to do something, and as long as it’s up to the standards, he can do it.
Cheers!
-
In view that developing all avionics for another acft may be such a huge task for one person, I was wondering if it would not be more advantageous to tackle the problem in a kind of different way. Instead of developing the avionics for F-18, or the F-15, etc, why not develop a framework (building blocks) where the community could develop for each acft its own avionics?
The devs could put the placeholders for us in the code, and we would research, implement, and test the avionics for a given acft.
I thought about that sometime ago, even made a list of general avionics with possible categories and implementations.
For example, one could group the major types of avionics found in military systems:
Radar, Eletrooptics, Electronic Warfare, Communications and Identification, Navigation, Displays, Weapons Systems, + all other avionics found in airplanes in general.
Now imagine a dev creates a general definition as placeholder and we can specifiy what a given system in our aircraft will do= we add the a building blocks.
For example, one can have a general definition of radar with its basic functions. Additionally one could add the modes (e.g. via XML files) that a given radar may have, for example a TWS, ground-mapping, is a TFR, LPI, etc, with its own parameters. This way, one could build the avionics block by block, until one can implement the radar of virtually any acft. For those experienced with OO, its like the composition pattern if you wish so. -
In view that developing all avionics for another acft may be such a huge task for one person, I was wondering if it would not be more advantageous to tackle the problem in a kind of different way. Instead of developing the avionics for F-18, or the F-15, etc, why not develop a framework (building blocks) where the community could develop for each acft its own avionics?
The devs could put the placeholders for us in the code, and we would research, implement, and test the avionics for a given acft.
I thought about that sometime ago, even made a list of general avionics with possible categories and implementations.
For example, one could group the major types of avionics found in military systems:
Radar, Eletrooptics, Electronic Warfare, Communications and Identification, Navigation, Displays, Weapons Systems, + all other avionics found in airplanes in general.
Now imagine a dev creates a general definition as placeholder and we can specifiy what a given system in our aircraft will do= we add the a building blocks.
For example, one can have a general definition of radar with its basic functions. Additionally one could add the modes (e.g. via XML files) that a given radar may have, for example a TWS, ground-mapping, is a TFR, LPI, etc, with its own parameters. This way, one could build the avionics block by block, until one can implement the radar of virtually any acft. For those experienced with OO, its like the composition pattern if you wish so.Main problem I see here with this attitude is that there is too much diversity between different aircraft. Specifically if I take a simple example: F-16 has an ICP, F-18 has “Something else” (I honestly don’t remember the name) and a 3rd Aircraft may have a totally different system that has different “API” with relation to the other avionics. In other words while we can for example I guess add a Radar inherited class (And even here, stuff like submodes and aircraft-specific may become too different that you won’t be able to generalize it good enough that it’ll worth it), it may be a greater challenge for other avionics components.
Structuring such an API is probably possible but not easy and again may not work exactly as you think. I can for sure find the reason in making the avionics modular, but knowing not bad the F-16 avionics code we already have and the so many dedicated functions we have per system, it may become a huge challenge.
All that said - I try to stop say “Never” and so I’m open to suggestions. Talking specifically, stuff like a Radar, TGP or a “Display mode” of some weapon can probably be generalized enough between different platforms.
And last but not least - If you know OOP and you have the vision of such a modular system, then how about try to join in and implement it in BMS code? And I’m not joking or being cynical, I really mean that. Our door is basically open to anyone who like to improve Falcon-BMS and can prove to us that he can do it.
Cheers!
-
I was about to reply along same lines – really just wondering – if BMS team has ever considered a plug-in architecture (eg. COM or even just thirdparty DLLs, one for each plane, with a well defined interface of entrypoints).
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.
And to do this (eg. implement a phased-array radar, or IRST or similar) the plugin would need access to the entire local universe of objects, from an API exposed by BMS… the hardest class would be custom camera pods or optical weapons that would require the plugin to own 3D rendering of world objects… maybe that could be deferred back to BMS engine, if designed smartly.
There would be whole new sets of plane-specific callbacks (eg. just look at Hornet and Harrier as example) that plugins would need to register, and implement.
A plugin architecture could go beyond “avionics” and actually process stick/throttle inputs, manipulate control surfaces, and perform necessary physics calculations to implement a high-fi flight model for a plane…
And figuring out what this would mean for MP is a whole other can of worms. (Maybe verifying digital-signatures of DLLs to ensure all pilots have an “approved” set of plugins… no god-mode hackery.)
It would be awesome, but I can easily imagine refactoring BMS this way would be a grand undertaking probably on the scale of moving from DX9 to DX11.
Otoh adopting an interface/plugin architecture could be an alternative approach to open-source … ie. get much of the benefit of open-source without ever actually open-sourcing anything.
(Again, just asking if this was ever considered/rejected… not advocating.)
-
…I’ve been asking for this continually.
-
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)
…