Board index FlightGear Development Aircraft

MCDU/FMS - Generic framework vs. custom implementation

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

MCDU/FMS - Generic framework vs. custom implementation

Postby Hooray » Sun Aug 01, 2021 4:40 pm

Split off from the topic A320-family development. Quotes added for context.


Lydiot wrote in Sun Aug 01, 2021 2:19 am:
V12 wrote in Sat Jul 31, 2021 4:00 pm:I'm happy to use MCDU for flight planning (and other things). It is much more realistic than route manager.

But "ready to taxi" and "ready to start engines" is NOT more realistic. Still, they're there, right? So the argument that it needs to be realistic can be used against that too. But it isn't.

Octal450 wrote in Sat Jul 31, 2021 3:17 pm:It's not any harder to use the MCDU vs Route Manager. You still type what you want and insert... I fail to see how it's harder to get up in a air?

I didn't say it was harder to get up in the air, I meant it was easier for someone who already knows Route Manager to just keep using it instead of having to learn how to do something else.

V12 wrote in Fri Jul 30, 2021 9:07 pm:and SimBrief integration. Because as in the reality, You can download flightplan only with not running engines. For flight planning, check SimBrief, create an account - it is free. Make flightplan and You can download this flightplan and other OFP data into FMGC. Check this video for more details :

See the Route Manager in FlightGear is common to all aircraft that allow it. So I had to learn that only once. Now I have had to learn that and add "SimBrief" (I have no idea what that is) and create an account apparently. And watch another video to learn how to do it.

From the perspective of someone who already knows Route Manager and doesn't want to spend more time learning more ways of getting the same thing done this isn't really an improvement.

But since people are saying it's impossible to have Route Manager and this work at the same time it's really not worth talking about.
legoboyvdlp wrote in Sun Aug 01, 2021 2:17 pm:
Lydiot wrote in Sun Aug 01, 2021 2:19 am:From the perspective of someone who already knows Route Manager and doesn't want to spend more time learning more ways of getting the same thing done this isn't really an improvement.

But since people are saying it's impossible to have Route Manager and this work at the same time it's really not worth talking about.

Well, I agree there - this is all somewhat a moot topic since it's simply not compatible at all unfortunately. I do have a work in progress branch which reimplements it using route manager internals and it _might_ be possible to re-enable the dialog -- but I'm waiting for core fixes for nearly 2 years now and not too hopeful of ever getting them.

As far as the current situation; you've got 2 options:
  • Either fill out the MCDU in its entirety -- which is not very intuitive, but once you get the hang of it, its not too bad
  • Create a Simbrief flightplan online; set up your username in the FMGC --> Simbrief menu in the aircraft, and then press INIT request on the INITA MCDU page -- then with a single click the MCDU will be filled out for you; route, fuel, everything!



Besides, speaking in general, I wouldn't be too attached to the current route manager UI: The built-in UI (being based on PUI) has been in the process of being modernized for over half a decade meanwhile - and there still is the plan to re-implement the built-in GUI using Qt5/QQ2. A number of core devs have repeatedly pointed out that PUI's archaic feature set contributed to that decision, i.e. there is no support for many modern widgets (menubars with submenus, menubar items with check boxes, tree views etc).

In other words, sooner or later, the existing route manager UI is going to change/improve - and in fact, a number of aircraft developers have already begun migrating PUI based dialogs over to Canvas dialogs, in order to ensure that they're not affected by the upcoming migration, but also to be able to use modern UI concepts, without being restricted by PUI, but also without being limited by being only available in Qt5-enabled fgfs builds/binaries.

All of which is to say, the existing route manager UI is terrible and and is likely to change in the future anyway. So, being emotionally attached to it, doesn't really help the project in any way :D
Advising people to use older versions of an aircraft, or different aircraft altogether seems like a pretty solid suggestion already - especially because the increasing degree/fidelity of systems modeling, is unlikely to be easily matched by a conventional UI - neither using PUI nor using Qt5 - which is one of the reasons why aircraft developers have begun using aircraft textures (screens/displays and keypads) to simply show those in conventional Canvas GUI dialogs - that way, there's no disparity between the actual UI of an aircraft and the UI representation of it - this means much less coding/maintenance work for aircraft developers, too

To see for yourself, refer to some of the more completely modeled aircraft like the shuttle or the extra500, it would be a little far-fetched (unreasonable) to expect to match/map this sort of interface back into a conventional UI system like PUI:

https://wiki.flightgear.org/Extra_EA-50 ... t_planning
Image

Image

Also, this type of situation is neither uncommon nor undesired - it's merely a symptom of an aircraft's development pace outgrowing the capabilities of the underlying UI engine (which is actually a good thing once you think about it - given that all modern avionics are likely to be implemented using the Canvas as its back-end, we also have a straightforward option that doesn't put any extra work on the shoulders of developers).

Likewise, we cannot expect that aircraft like the 777 or the shuttle can be reliably controlled using the existing autopilot or route manager dialogs - sooner or later, aircraft development has to make a decision, between being crippled by an archaic UI engine (like PUI) or by reusing all the systems modeling routines that already exist in Nasal and Canvas space, and merely displaying those in a dedicated Canvas UI window, while supporting conventional Canvas event handling to support mouse/keyboard input.

Once the new Qt5 based PUI replacement becomes actually available, we will once again encounter this dilemma, because there will be yet another option to provide an in-sim UI, at the cost of re-implementing UI dialogs using Qt5's QML language (which offers a plethora of modern UI widgets, none of which are required to implement a flight simulator, and none of which are specific to flight simulation - whereas people who have previously put effort into coding up avionics in scripting space using the Canvas system, will simply have the option to reuse their avionics code to provide an in-sim UI experience that matches the real thing, insofar as the corresponding systems modeling has been completed)
Last edited by Johan G on Mon Aug 02, 2021 6:16 am, edited 1 time in total.
Reason: Split off from the topic A320-family development. Quotes added for context.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: A320-family development

Postby Octal450 » Sun Aug 01, 2021 5:37 pm

it makes no sense to make a generic.

Most planes MCDU/FMS work differently with some similarities... I don't understand why you are always pushing for "generics".

If you want to make the route manager better, please do! I would be very interested in seeing how you can improve it - but in order to make realism we must customize. Generic route management is just not a good idea -> hence why there not a single realistic sim who use it!

Kind Regards,
Josh
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: A320-family development

Postby Lydiot » Sun Aug 01, 2021 5:44 pm

Octal450 wrote in Sun Aug 01, 2021 3:45 pm:
Lydiot wrote:But "ready to taxi" and "ready to start engines" is NOT more realistic. Still, they're there, right?

That is an invalid argument.


No, it is not an invalid argument. You clearly just don't understand it.

Octal450 wrote in Sun Aug 01, 2021 3:45 pm:Those buttons set up the plane exactly how it would be in that real life in that condition. Comparing them to the route manager vs FMGS is like comparing apples to orange.


When a real pilot sits down in a real A32x, does he have the option of pushing the one button that sets the airplane "ready to taxi"? Please answer that question just so I know if I got that right.

Because if the answer is "no" then "ready to taxi" isn't a proper simulation of how that aircraft works in real life, and is therefore not realistic.

Octal450 wrote in Sun Aug 01, 2021 3:45 pm:Very sorry. We are NOT going to handicap the plane just because you don't want to learn how its done in real life.


But you were willing to implement "ready to taxi" even though that's NOT how it's done in real life?

Also, you're misrepresenting what I'm asking for which is pretty disingenuous or careless: I did NOT say that you should take away the current functionality, I said I thought it would be better to have both. You understand that difference, right?

Octal450 wrote in Sun Aug 01, 2021 3:45 pm:Since the very first day I ever posted about the A320 back in 2016, I said the goal was to be a "study level" simulation one day. And as our team work towards that, the plane will get more complex to fly like a real plane. If you don't like it, the solution is simple -> take an earlier commit or fly a different aircraft.

Kind Regards,
Josh


I just gave my input of what you could do to give more people the ability to enjoy flying your aircraft if technically possible. You could simply say "it isn't my goal" and leave it at that. There's no need for the attitude.
Lydiot
 
Posts: 1016
Joined: Tue Oct 22, 2013 11:50 pm

Re: A320-family development

Postby Lydiot » Sun Aug 01, 2021 5:52 pm

V12 wrote in Sun Aug 01, 2021 9:53 am:Dear Lydiot :If You want simulation, use A320family with all features and start in Cold 'n Dark state, if You want game, use one of the many other less developed aircrafts - for example 737-800YV without MCDU, but with Route Manager.


It really doesn't make much sense to force people to do one or the other IF it's possible to do both (which apparently it isn't). And besides, as I said, it doesn't make much sense to use an argument against one 'gaming' approach yet ignore it against another.

I actually don't mind going through the start-up procedure and pushing all the buttons etc. btw.

Hooray wrote in Sun Aug 01, 2021 4:40 pm: the existing route manager UI is terrible and and is likely to change in the future anyway. So, being emotionally attached to it, doesn't really help the project in any way :D


I'm not emotionally attached to it, it's purely practical. If there's a new version of it I'll learn it. But the benefit of having one route manager applicable or available to all aircraft is that it's similar to the automatic engine start in many models: It cuts down on the time it takes to get in the air (or the time and effort learning how to get it done). So rather than having to learn how to start each aircraft you skip steps if the model allows it. Same with routes.
Lydiot
 
Posts: 1016
Joined: Tue Oct 22, 2013 11:50 pm

MCDU/FMS - Generic framework vs. custom implementation

Postby Lydiot » Sun Aug 01, 2021 5:55 pm

legoboyvdlp wrote in Sun Aug 01, 2021 2:17 pm: I do have a work in progress branch which reimplements it using route manager internals and it _might_ be possible to re-enable the dialog -- but I'm waiting for core fixes for nearly 2 years now and not too hopeful of ever getting them.


[sad face]

legoboyvdlp wrote in Sun Aug 01, 2021 2:17 pm:As far as the current situation; you've got 2 options:
  • Either fill out the MCDU in its entirety -- which is not very intuitive, but once you get the hang of it, its not too bad
  • Create a Simbrief flightplan online; set up your username in the FMGC --> Simbrief menu in the aircraft, and then press INIT request on the INITA MCDU page -- then with a single click the MCDU will be filled out for you; route, fuel, everything!


Good to know.
Lydiot
 
Posts: 1016
Joined: Tue Oct 22, 2013 11:50 pm

Re: A320-family development

Postby Hooray » Sun Aug 01, 2021 6:49 pm

Octal450 wrote:t makes no sense to make a generic.

Most planes MCDU/FMS work differently with some similarities... I don't understand why you are always pushing for "generics".


Not sure if this was in response to my posting ? If so, you missed my point completely.

Implementing a generic route manager/autoflight framework would mean quite a bit of work - and would only get you so far.

Basically, this sort of effort would require an orchestrated effort among people/developers working on related aircraft (single engine, multi engine, piston, jet, airliners) - sort of like a tiered approach, where common/shared functionality would end up in each tier, and more specific functionality in higher tiers.

That way, differences between different Airbus or Boeing variants could be implemented by inheriting from a corresponding "AirbusJet" or "BoeingJet" specification, while customizing each layer as needed.

However, that'd require the sort of layered coding that's hardly intuitive to people without software training/education, so unlikely to appeal to the majority of aircraft developers - and this can in fact be seen by the adoption of the MapStructure framework, which is using exactly this sort of tiered design, with pre-customized components that can be configured/styled and customized further - it took many people years to realize how this works, and how to use this sort of framework - even today, the majority of contributions to the MapStructure framework seem to come from trained software developers or long-time FlightGear contributors.

Right now, we're seeing another instance of this with Emesary and the FG1000 specifically - the sort of coding required here, is very different and not very intuitive if you don't have a coding background.

PS: Getting back on topic, Emesary is actually what could be used in this instance, too to have your cake and eat it - if you're using an Emesary based interface (wrapped via fgcommands), it's trivial to load flight plans/route using a variety of means, including the MCDU, PUI dialogs, Qt5 dialogs, Phi or Canvas - and even telnet, and that has nothing to do with "generics" per sé :wink:
From a functionality standpoint, loading flight plans directly could be added to the checklist system, which already provides short cuts to set up an aircraft - and which is a great asset when regression testing/developing an aircraft (release)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: A320-family development

Postby V12 » Sun Aug 01, 2021 7:11 pm

Hooray wrote in Sun Aug 01, 2021 6:49 pm:That way, differences between different Airbus or Boeing variants could be implemented by inheriting from a corresponding "AirbusJet" or "BoeingJet" specification, while customizing each layer as needed.

IMHO, very bad idea. We have Airbus style ND and Boeing style ND in the FGDATA. Both are incomplete and poor optimized. Situation with Airbus / Boeing MCDU is more compicated - MCDU is very tightly connected to the ND and other very important systems (IRS, FADEC etc). In the result, very few functions will be reusable. And we have more aircrafts with MCDU.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: A320-family development

Postby Hooray » Sun Aug 01, 2021 7:31 pm

right, but even you missed my point: this is exactly where using Emesary would help people accomplish a design that works - you mentioned the various ND styles, these too fall short because of what's happening outside the MapStructure/ND department - the fact remains, most FlightGear aircraft systems are not designed/implemented by trained software specialists - the few that are, don't suffer from such problems :wink:

again, your observations are valid, the conclusion is just a little short-sighted, because by using a layered approach, you can have your cake and eat it - people who have previously used such designs, will immediately understand how Emesary relates to the challenges you outlined - to see for yourself, you only need to look at the way the FG1000 is structured :D

(none of this is to say that this is a good idea, because the learning curve is rather steep - but it also isn't correct to suggest that you cannot develop a decoupled A320 EFIS and reuse parts of that on an A340 or A380 - the differences are irrelevant once you are using a design where you focus on common functionality and use IoC to substitute different components - and yes, that's also what's commonly done in real life, on real avionics - you do have shared sub components, they just happen to use a common bus - which is where a system like Emesary can help people, because under the hood Emesary can be understood as a "message bus" system too)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: A320-family development

Postby Octal450 » Sun Aug 01, 2021 7:50 pm

Hooray, you are missing the point and I've tried to get this across for years. On a modern jet airliner, things are far too tightly integrated for your approach to work! In General Aviation, things are DESIGNED to work with each other.

But in these type of aircraft, everything is designed to work exactly with the other parts of the plane.

You have one Boeing ND style. As far as I can tell it "tries" to be like the 777 ND... But 767, 757, 747, 737 all have different ones. So not even your own nav display is doing the job you are asking... why should I? Does not even support power states or IRS...

most FlightGear aircraft systems are not designed/implemented by trained software specialists - the few that are, don't suffer from such problems :wink:

Nothing that I have seen backs up this statement... I would say the "best" thing in FG overall is the Space Shuttle, and its full of custom things! Because Generics do not suit the role of advanced craft where everything must be tightly integrated.

You're approach seems to be "lets make one shoe that fits all"... How are you going to account for EVERY combination?? This is not general aviation world like FG1000 where its the same instrument in 10,10,10 planes! How will you do that?

My approach is, lets make something designed for the job we want it to do. This is what A320 team are doing. I'm not saying we cannot allow some configuration... but never to the extent that you are hoping for. I don't care if the A320 PFD helps the A340 A380 etc, because it is made for the A320. But making one for those planes? Easy. Take the current code, modify, remix, adapt. Boom done.

I would love to see your detailed airplane and how you have made your one-size-fitting-all avionics package work, please direct me to example. Because I can't found any. Its all using custom!

Kind Regards,
Josh
Last edited by Octal450 on Sun Aug 01, 2021 8:04 pm, edited 3 times in total.
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: A320-family development

Postby Octal450 » Sun Aug 01, 2021 8:01 pm

In other words, sooner or later, the existing route manager UI is going to change/improve - and in fact, a number of aircraft developers have already begun migrating PUI based dialogs over to Canvas dialogs, in order to ensure that they're not affected by the upcoming migration, but also to be able to use modern UI concepts, without being restricted by PUI, but also without being limited by being only available in Qt5-enabled fgfs builds/binaries.


Nothing wrong with this. you want to improve route manager, go for it!

But it will never come close to the requirements to replace the MCDU. Literally every plane has a different one -> how the hell can you account for all these differences??

Kind Regards,
Josh
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: A320-family development

Postby Hooray » Sun Aug 01, 2021 8:09 pm

sorry, but you failed the reading comprehension test once again, big time :wink:

(for starters, despite your responses, I really didn't disagree with you - and I am perfectly aware of the restrictions that are in place, but these have more to do with the way the FlightGear project works, rather than with software design in general - FWIW, it's not "my ND" at all (I believe it was created by Gijs, and focused on the 744 at the time, then customized by Hyde/777), how the ND stuff (and specifically MapStructure) came to be, can still be researched on the forum (it took all place here), and some of the people involved in the R&D process are actually coding avionics for a living (obviously not in Nasal or C++, but in Ada95 at the time). The ARINC 661-related features of MapStructure were inspired by someone involved in the actual A661 committee ...FlightGear is a hobbyist project, so all these restrictions are in place for are a reason, but you're deluding yourself if you think that an A380 EFIS in a flight simulator cannot reuse components of an A340/A320/A310 or even a bunch of Boeing aircraft - the requirements are very much overlapping, especially once you properly decouple the architecture to account for all of these differences (visuals, capabilities, functionality) - and this is exactly how MapStructure came to be originally, which is why it's using an MVC-based design, and this is also where Emesary could help aircraft developers have their cake and eat it :D )

To be perfectly clear about it, in the last couple of postings, I carefully explained why most aircraft devs are migrating towards a Canvas-based UI, since they can then simply reuse their MCDU/EFIS components and trivially show those in different UI dialogs - and I applaud people for doing that, since I wrote basically the tutorial on doing this, because of the very benefits that many of you are really just discovering - as in, years ago :D

Granted, all this took place years ago, long before you showed up on the forum - but your postings, and attitude, have already changed over the years, and you are now using Nasal and the Canvas system for things that you previously considered difficult or even impossible - so don't underestimate your capability to adapt over time, stuff like Emesary or the FG1000 isn't trivial, not even if you hold a bachelor's degree in software engineering - but like you have undoubtedly noticed by now, your experience and expertise grows too over the years - and things that looked impossible years ago, are now apparently a piece of cake ? :lol:
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: A320-family development

Postby Octal450 » Sun Aug 01, 2021 8:41 pm

sorry, but you failed the reading comprehension test once again, big time :wink:

Sorry... but you write so longly that it can be tough to understand at times. I am slightly dyslexic. (Did you known, I wrote "Flight Dyanmics" in my credits on the aircraft for 4 years without notice? :mrgreen:)

you're deluding yourself if you think that an A380 EFIS in a flight simulator cannot reuse components of an A340/A320/A310 or even a bunch of Boeing aircraft

I never said that. In fact I advocated "FOR" that. Did you notice how easy it was for me to adapt one set of DU technology from the airbus to the MD-11? so easy! It took me so much lesser time to make the MD-11 displays because I already had the Airbus ones as a base! :mrgreen: Actually Airbus and MD-11 have a lot in common even if the graphics differ. The longest part was drawing the new graphics!

What I advocated against was your approach of a generic ND system that sits in FGData that I change parameters on to work like my plaine.

aircraft devs are migrating towards a Canvas-based UI

Then you will be very happy I report we are doing everything in Canvas since years! And Canvas based Aircraft Config 2.0 with load manager is on the maps also.

but your postings, and attitude, have already changed over the years

This may be true, and I appreciate the kind words but I have maintained one consistent attitude as always (even that I sometimes got a little "passionate" about it!) was... "chose the best tool for the job and implement it. Don't worry so much what others are doing". I discovered the lovely world of Canvas in 2017 with the AIRBUS A320 EWD (Upper ECAM). Soon I did other things. Check it out, the PFD went from this:
Image

To this:
Image

I think its a MASSIVE improvement. Even more things be added this picture is old. And we were actively porting code from the A320 to the A330 EASILY due to how the design was made of the canvas! Even the differences in 330s! So I have always advocated for this maybe you didn't understand me.

And look how similar the MD-11, easily porting the code back and forth.
Image

Kind Regards,
Josh

PS: Every few weeks you start a this vs that discussion in here... why not do it in another thread instead?
Last edited by Octal450 on Sun Aug 01, 2021 8:52 pm, edited 2 times in total.
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: A320-family development

Postby Octal450 » Sun Aug 01, 2021 8:43 pm

Lydiot wrote:No, it is not an invalid argument. You clearly just don't understand it.

I understand you perfectly. You want route manager support because you and I quote "the Route Manager in FlightGear is common to all aircraft that allow it. So I had to learn that only once" and "From the perspective of someone who already knows Route Manager and doesn't want to spend more time learning more ways of getting the same thing done this isn't really an improvement"

My point is it IS an improvement because the Route Manager is extremely unrealistic. The FMGC/MCDU are goal to be exactly like real.

then "ready to taxi" isn't a proper simulation of how that aircraft works in real life, and is therefore not realistic.

Neither is the ability to slew the airplane from the launcher or around in the sim. But why is that ok? Because the features target a different goal.

Slewing the plane around, setting the airport to spawn, setting panel states, all of this sets up the simulation to be used by the pilot in question -> as done in real simulators. These exist so that we can define the scenario on which you are starting. They all undo any changes made by the pilot and thus resetting it to a blank. After you click the button and it finishes, then you start your simulation. If you set up your autopilot settings and flightplan in the MCDU, set your V speeds, performance data, switches for overhead etc... Well when you load a panel state, all of that is reset immediately to default, all your customizations and data are instantly lost. Using these buttons during the simulation ends the simulation and starts a new one with the new state. The panel states are meant as training aids like real life (or testing the simulation). They are not a part of the actual simulation itself.

-------------------------------------------

The route manager is a generic "F-PLN page" implementation similar to the FSX GPS, it exists as a "compliment" or "add-on" to the simulation that is designed to be used by the user throughout the entire flight. It is a rudimentary flight navigation system. The FMGC/MCDU is another flight navigation system except that is has been highly configured and customized to the exact behavior as best we can of the AIRBUS A320 by videos, manuals, and pilot report. There are hundreds of new values that are set by either the pilot, of the FMGC. The other parts of the aircraft interact with this to work on their behavior. However, both systems still use the underlying NASAL FLIGHTPLAN technology which actually manages finding the stuff from the NAVdata as well as the structure of the flightplan. Its a great system and a good example of how generics can be used! But they are manipulated by the custom system. Thus, using the route manager it is impossible to properly configure all the data needed for the real plane to accept this without adding all sorts of compatibility layers to it that watch what the user does, or using a custom route manager, and then you get a mess. I see no reason why that should be developed when the FMGC/MCDU are there... This is the same reason why in other sim like P3D, X-Plane, none of the advanced add-ons integrate with the default GPS or Map systems.

Does that clear it up?

TL:DR Route manager and the FMGC/MCDU conflict and compete with each other and supporting both makes a huge mess wheras the panel states are a similar thing to defining what airport you are starting at.

I did NOT say that you should take away the current functionality

I never said you said we should -> I believe this was unclear due to perhaps you are not aware of the way the route manager would impose limitations on the simulation. If we support route manager, lots of logic becomes way harder to implement properly with the FMGC. Sorry I should have been more clear about that just I had this conversation many times.

There's no need for the attitude.

No hostility from me sir, I can promise that.

Kind Regards,
Josh
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Re: A320-family development

Postby Hooray » Sun Aug 01, 2021 9:02 pm

Like I said, fundamentally, we don't seem to disagree at all - so no need to continue this. Besides, I really didn't "restart" a "generics discussion" either.
I am aware of what you are doing, and how you are doing it - and why you are using your current approach (and like you rightly pointed out, Thorsten is using a similar strategy on the shuttle, and it has served him rather well obviously).

That being said, conceptually the "take the current code, modify, remix, adapt. Boom done." approach is what a trained software architect would disagree with, it mostly boils down to the differences between "copy&paste coding" versus using design patterns to pretty much accomplish the same thing, by using software design and different architectures.

And that is in fact why stuff using Emesary (think the FG1000) or the MapStructure framework (and to a much lesser degree the ND) seem to be so freaking complicated/convoluted to newcomers without formal software training: it's a high-level form of coding that requires identifying generic components and components that are less generic (or even custom altogether).

The point being, copy & paste coding will obviously get the job done, but once you are tackling multiple instances of the same thing (display/avionics), or even just "variants" of it, the person using software design, has a clear edge - obviously, someone focusing only on a single manifestation of an instrument, can get more done in less time, because that person doesn't have to use any fancy coding patterns.

So once again, we don't really disagree - often, it isn't worth the effort to go the extra mile. Also, like you rightly pointed out, there are less generic systems that are still well-designed, despite being hardly reusable (or not at all). The Extra500 is certainly one of the most developed GA aircraft, with an extremely nice cockpit and fancy avionics - unfortunately, that work cannot be easily reuse elsewhere (despite other aircraft developers wanting to use the R9000 on their aircraft - i.e. they're rather customize/reconfigure the avionics, than having to redo them from scratch, let alone use copy&paste coding)

Thus, it's definitely a pain/gain thing - the chicken/egg problem is a different one, because even despite having MapStructure, we are still seeing people not using it (properly).

And to be perfectly clear about it, if I were to discuss/review and design MapStructure today, I would also structure it differently (no offense intended or taken to other involved in it at the time). But there definitely are lessons to be learnt from the way MapStructure worked (and succeeded), and where it failed.

If you are into funny anecdotes about generics vs. special design and performance, you can find literally dozens of topics on this forum, and many people made excellent points in favor of NOT using generics at all (Thorsten comes to mind).

But we also had the exact same discussion about a generic 2D drawing system that could be property driven, right here on the forum - and later on the devel list, many people disagreed with the idea, pointed out the differences between avionics/systems, and the latency/performance issues that would become a problem sooner or later, due to going through scripting space/the property tree etc - fast forward a couple of years later, someone actually rolled up their sleeves and prototyped a system - which is what many of you now know as the "canvas system". :lol:

And here's, how it all started out: https://wiki.flightgear.org/w/index.php ... ldid=43497

Likewise, we had the same type of discussion about enabling a generic property-driven rendering pipeline - that too was highly controversial, because it was about doing something in a generic fashion, that was considered impossible/difficult at the time - meanwhile, many of you know that Fernando succeeded at implementing this generic rendering framework, and it's called "compositor" :D

search.php?st=0&sk=t&sd=d&sr=posts&keywords=rembrandt+zan+canvas

Things only look difficult or impossible until someone rolls up their sleeves to prove others wrong :wink:

(and yes, once you understand how Emesary works, you will realize that you can indeed have your cake and eat it, without having to use copy&paste)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: A320-family development

Postby Octal450 » Sun Aug 01, 2021 11:06 pm

Hooray - its becoming evident that you just do not understand at all what I'm saying. You believe you do but you're not getting my point.

That being said, conceptually the "take the current code, modify, remix, adapt. Boom done." approach is what a trained software architect would disagree with, it mostly boils down to the differences between "copy&paste coding" versus using design patterns to pretty much accomplish the same thing, by using software design and different architectures.

I might take this as an insult if I didn't know better.

I did no t copy/paste a nothing. I created and MFD framework designed specifically to suit my needs (with the help of Necolatis -> I was new to canvas back then and he answered many questions of me). I created a MCDU framework to suite my needs (initially poor, now in the last months I made a much better one built from the ground up on object orientated programming), I created a canvas 2D panel framework that I can use to make many 2D cockpit panels easily.

So what are you talking about with the copy-paste and all kind of things? Are you even read what I wrote? And that is only the Canvas related things I've done... Almost all the code I've committed was written by myself.

seem to be so freaking complicated/convoluted to newcomers without formal software training: it's a high-level form of coding that requires identifying generic components and components that are less generic (or even custom altogether)

The problem is not that I don't understand it. I really don't like the attitude of saying just because I have a poor review of something, that is because I don't understand it. The problem is that I have evaluated and found that it offers me nothing and thus have chosen not to re-invent the entire avionics suite using it. The plane works great right now, and all 6 DUs and 3 MCDU's in the MD-11 are drawing the same FPS drop as one FG1000 MFD. (No offence to Stuart, FG1000 is not finished obviously and he's done a great job so far)

because even despite having MapStructure, we are still seeing people not using it

Well that's because most people I've discussed with (I won't namedrop out of respect) seem to jump to the same conclusion I did almost 4 years ago which I wrote above -> it offers me nothing I couldn't do in a more efficient and simpler way. So why would I make my life more complicated?

And who has? I'm still waiting for you to show me some realistic airplane using this. Because all I can find are "tech-demos". Its cool tech, but where is the implementation by developers?

You are always trying to sell me MapStructure in this threads, you can go back read all the times. Anytime someone mentions anything you start to sell it. Which brings me to ask, what is your goal here? Do you honestly expect me to adopt it and spend my time re-programming each and every display in every planes when there is nothing to be gained for the aircraft's project, and you have no examples to offer me of even why I might like it?

I'm NOT creating "generic MFDs" to be used by whoever because I don't care about that. I care about programming a simulation of some cool aircrafts. That's what I'm doing.

So, what do you want from me????

Kind Regards,
Josh

PS: I have nothing against Emesary. Its a cool system and I look forward to looking into it later, but MapStructure offers me nothing.
Skillset: JSBsim Flight Dynamics, Systems, Canvas, Autoflight/Control, Instrumentation, Animations
Aircraft: A320-family, MD-11, MD-80, Contribs in a few others

Octal450's GitHub|Launcher Catalog
|Airbus Dev Discord|Octal450 Hangar Dev Discord
User avatar
Octal450
 
Posts: 5583
Joined: Tue Oct 06, 2015 1:51 pm
Location: Huntsville, AL
Callsign: WTF411
Version: next
OS: Windows 11

Next

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 14 guests