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.

Re: A320-family development

Postby Hooray » Sun Aug 01, 2021 11:27 pm

wow, look: you're -once again- responding to something that I neither said/wrote, nor silently expected you to do.

So, there's really no point in continuing this discussion right now, because it's a vicious circle - you fail to realize that I specifically mentioned we do agree on a number of issues.

Thus, given that brevity is not exactly my greatest forte, and since you mentioned dyslexia possibly being another factor on your end, I'd suggest to leave it at that - and maybe let another 5+ years pass by, because this type of communication clearly isn't doing us any favors ? :lol:

(no offense intended or taken, but this is more than just pointless if we're not even on the same page, or rather, if one party doesn't recognize that we're indeed on the same page (more or less))
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 » Mon Aug 02, 2021 1:12 am

Fair enough - maybe language barrier. As I saw it you said "I agree" followed by something different to what I said.

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 » Mon Aug 02, 2021 4:20 pm

Octal450 wrote in 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.


Your argument against using the one way to enter a route is that it's "extremely unrealistic".
That same argument can be used against "ready to taxi" - because it is "extremely unrealistic".

That's why your objection is inconsistent. You're basically just saying "well it's ok to sometimes let the sim be 'extremely unrealistic' for 'reasons'", but that's just pushing the qualifier for when you allow extreme unrealism, not if it is or isn't extremely unrealistic. That's why your argument is inconsistent.

Tell us why the "ready to taxi" is targeting a different goal.

From my perspective the goal is exactly the same - both are unrealistic but allow me as a user to get to flying faster, or more easily, or with less of a requirement to learn things custom to a specific aircraft.

As a matter of fact I would argue that in terms of "realism" you've got your priorities completely backwards if you're choosing between these two items, because you don't actually need to use autopilot following a route at all to fly the plane, but you do need engines to be running and electrical systems to be set up etc. So in terms of priority you're actually allowing the user to skip the most important step in flying the plane. If you want realism that seems backwards.

Octal450 wrote in Sun Aug 01, 2021 8:43 pm:Slewing the plane around,


The above as well as what follows seems to be an explanation for why you can't program it in a way where we keep the past and also get the new. I don't need a technical explanation for that. If it can't be done it can't be done. All I was saying is that it sucks that it can't be done. But then people argued why it shouldn't be done, and that's something I just disagree with. If it could be done, I think it should be done... Or more accurately: If it could have been done the old way should have been retained.
Lydiot
 
Posts: 1016
Joined: Tue Oct 22, 2013 11:50 pm

Re: MCDU/FMS - Generic framework vs. custom implementation

Postby merspieler » Mon Aug 02, 2021 5:20 pm

Your argument against using the one way to enter a route is that it's "extremely unrealistic".
That same argument can be used against "ready to taxi" - because it is "extremely unrealistic".


If you look at flight simulators in which airline pilots train, they DO have the option to start with engines running... but they DO NOT have a full external route manager. They might have a simplified one for inserting an approach into the MCDU that suites the startup location on final but you can't program an entire flight on it.

The difference is the usecase:
Engines running is INTENDED FOR TRAINING a specific situation, imagine how much time would be wasted by going through the preparation every single time you want to train a takeoff.
Route manager replaces a procedure without any time benefit (assuming familiarity) which has to be done on full flights only and has NO TRAINING BENEFIT.

So one is for training a certain situation, the other is not.... that's the difference.


(also loading certain states is really helpful for developing by jumping right to the part that is affected by the new code, same can't be said about the route manager... so if you're so inclined to call it "extremely unrealistic", then feel free to see it as a developer tool which is not intended for normal users.)
Nia (you&, she/her)

Please use gender neutral terms when referring to a group of people!

Be the change you wish to see in the world, be an ally to all!

Join the official matrix space
merspieler
 
Posts: 2241
Joined: Thu Oct 26, 2017 11:43 am
Location: Wish to be in YBCS
Pronouns: you&, she/her
Callsign: you&, she/her
IRC name: merspieler
Version: next
OS: NixOS

Re: MCDU/FMS - Generic framework vs. custom implementation

Postby Hooray » Mon Aug 02, 2021 5:36 pm

Indeed, those are very valid/good points - I don't think the feature is the real problem, rather the UI (which is why I responded referring specifically to PUI). You can definitely create a simple fgcommand/Emesary-based interface to preload routes using a number of simplifications, i.e. where the back-end would make some assumptions and use those to preload said routes.

(I am not saying this is a a good idea or even a feature request, but your point about regression testing and more rapid turnaround times on full motion sims is definitely worth considering - though certainly not with a focus on the A320 or Octal450 specifically (for the sake of our sanity, let's keep the discussion general).
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: MCDU/FMS - Generic framework vs. custom implementation

Postby Octal450 » Mon Aug 02, 2021 11:48 pm

@Lydiot,
I didn't say what you are saying I said.

How they differ:

The Route Manager and MCDU/FMGC are 2 separate and competing ways to enter and manage a flightplan. They are not intercompatible and supporting both is not possible because we cannot "guess" information about your flightplan that is not provided by the route manager -> so we proceeded to support the more realistic option, being the MCDU/FMGC.

Panel States are a completely different thing, exist in real sims and do not conflict with manual starting of the airplane -> if they did conflict with the ability to manually start the airplane on real checklists, we would have made the same decision, and removed them, in order to stay true to the more realistic option.

The Flightplan systems are part of the A320 simulation itself. Panel States are not, they are part of the simulator's configuration (like airport location). That is why they don't conflict with manual starting, but the Route Manager does conflict with the MCDU/FMGC. Does you understand?

Our project goal is realism first.

I believe you are looking at the subject from the point of view of someone with your preferences on what you want from a plane -> and from what you describe, it sounds like an accurate FMGC/MCDU is not one of them. That's fine, to each his own style of flight simming.

Our team look at it from the perspective of lets make this as real as possible. Lets also try to add things that make it easier to test/develop if needed, but if we cannot, then lets stick to what is in the real airplane. (and as merspieler stated, real flight sims also use panel state technology... and as I stated above, panel states do not conflict, thus I do not have to "choose" between them and manual starting, like I have to "choose" between MCDU/FMGC and Route Manager.

Hooray wrote:I don't think the feature is the real problem, rather the UI (which is why I responded referring specifically to PUI).

Correct. The current Route Manager system doesn't provide near as much info as the MCDU/FMGC which is why the conflict exits.

The actual flightplan system underneath Route Manager we also use in our MCDU/FMGC -> since the flightplan system is a framework, we have set up our implementation to match A320 real. If the route manager some day supports enough options that we can function properly, then of course we can re-enable for the users who prefer to use him instead.

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: MCDU/FMS - Generic framework vs. custom implementation

Postby Lydiot » Wed Aug 04, 2021 3:36 pm

merspieler wrote in Mon Aug 02, 2021 5:20 pm:
Your argument against using the one way to enter a route is that it's "extremely unrealistic".
That same argument can be used against "ready to taxi" - because it is "extremely unrealistic".


If you look at flight simulators in which airline pilots train, they DO have the option to start with engines running... but they DO NOT have a full external route manager. They might have a simplified one for inserting an approach into the MCDU that suites the startup location on final but you can't program an entire flight on it.

The difference is the usecase:
Engines running is INTENDED FOR TRAINING a specific situation, imagine how much time would be wasted by going through the preparation every single time you want to train a takeoff.
Route manager replaces a procedure without any time benefit (assuming familiarity) which has to be done on full flights only and has NO TRAINING BENEFIT.

So one is for training a certain situation, the other is not.... that's the difference.


I'm betting >95% of us here aren't pilots and aren't "training" to become one.

How many do you think are starting up FG and loading up the plane in question are doing so to simulate a real-world simulation as opposed to simulate a real-world flight? I've never loaded up an airplane in FG with the goal of simulating a flight simulation.

merspieler wrote in Mon Aug 02, 2021 5:20 pm:(also loading certain states is really helpful for developing by jumping right to the part that is affected by the new code, same can't be said about the route manager... so if you're so inclined to call it "extremely unrealistic", then feel free to see it as a developer tool which is not intended for normal users.)


But I'm not arguing against "ready to taxi". I'm arguing for keeping a way of setting a route. And the argument against the latter was that it was "unrealistic" and all I was saying was that it applies too to the former.
Last edited by Lydiot on Wed Aug 04, 2021 3:52 pm, edited 1 time in total.
Lydiot
 
Posts: 1016
Joined: Tue Oct 22, 2013 11:50 pm

Re: MCDU/FMS - Generic framework vs. custom implementation

Postby Lydiot » Wed Aug 04, 2021 3:50 pm

Octal450 wrote in Mon Aug 02, 2021 11:48 pm:The Route Manager and MCDU/FMGC are 2 separate and competing ways to enter and manage a flightplan. They are not intercompatible and supporting both is not possible because we cannot "guess" information about your flightplan that is not provided by the route manager -> so we proceeded to support the more realistic option, being the MCDU/FMGC.


That point was made before and there's no need to reiterate it.

Octal450 wrote in Mon Aug 02, 2021 11:48 pm:I believe you are looking at the subject from the point of view of someone with your preferences on what you want from a plane -> and from what you describe, it sounds like an accurate FMGC/MCDU is not one of them. That's fine, to each his own style of flight simming.


I want a plane to be realistic. But we had a way of creating routes that applied to a lot of planes in FG and it also existed in this plane. Learning that system happened once and then it could get applied to all planes that supported it. Didn't matter if it was this plane or the 747 or 777 etc. I just thought it was a bit sucky that it disappeared in this plane.

Octal450 wrote in Mon Aug 02, 2021 11:48 pm:Our team look at it from the perspective of lets make this as real as possible. Lets also try to add things that make it easier to test/develop if needed, but if we cannot, then lets stick to what is in the real airplane. (and as merspieler stated, real flight sims also use panel state technology... and as I stated above, panel states do not conflict, thus I do not have to "choose" between them and manual starting, like I have to "choose" between MCDU/FMGC and Route Manager.


See above.
Lydiot
 
Posts: 1016
Joined: Tue Oct 22, 2013 11:50 pm

Re: MCDU/FMS - Generic framework vs. custom implementation

Postby Octal450 » Wed Aug 04, 2021 3:54 pm

That point was made before and there's no need to reiterate it.

Only repeated because you still didn't get what I said. Both the points of it being an unrealistic as well as causing limitations to the complexity of the simulation are valid.

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: MCDU/FMS - Generic framework vs. custom implementation

Postby merspieler » Wed Aug 04, 2021 3:55 pm

I'm betting >95% of us here aren't pilots and aren't "training" to become one.

We (A320 team) aren't either...

How many do you think are starting up FG and loading up the plane in question are doing so to simulate a real-world simulation as opposed to simulate a real-world flight? I've never loaded up an airplane in FG with the goal of pretending I'm simulating flight.

You're getting it wrong, we don't want to simulate a simulator... we want our simulation to be as good as the prefessional one

I'm arguing for keeping a way of setting a route

We've never said, we remove the ability to set a route... you can and always will be able to set the route........ throught the MCDU.


I want a plane to be realistic. But

`but` is a bad word... it negates everything you've said before... ;-)
Nia (you&, she/her)

Please use gender neutral terms when referring to a group of people!

Be the change you wish to see in the world, be an ally to all!

Join the official matrix space
merspieler
 
Posts: 2241
Joined: Thu Oct 26, 2017 11:43 am
Location: Wish to be in YBCS
Pronouns: you&, she/her
Callsign: you&, she/her
IRC name: merspieler
Version: next
OS: NixOS

Re: MCDU/FMS - Generic framework vs. custom implementation

Postby Johan G » Wed Aug 04, 2021 3:57 pm

Lydiot wrote in Wed Aug 04, 2021 3:36 pm:How many do you think are starting up FG and loading up the plane in question are doing so to simulate a real-world simulation as opposed to simulate a real-world flight? I've never loaded up an airplane in FG with the goal of pretending I'm simulating flight.

While not having flown airliners in FlightGear I can easily imagine some pilots wanting to practice for example shooting ILS approaches without having to go through all checklists, take off, fly around an extended pattern and then, maybe some 10-15 minutes later, shoot the approach, and maybe 5 minutes later shoot the next ILS approach. Much easier to start in a preset state and just shoot the ILS approach. :wink:
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: MCDU/FMS - Generic framework vs. custom implementation

Postby Octal450 » Wed Aug 04, 2021 6:18 pm

merspieler wrote:we want our simulation to be as good as the prefessional one

Exactly. So if a real simulator can, why don't we?

Johan G wrote:without having to go through all checklists, take off, fly around an extended pattern and then, maybe some 10-15 minutes later, shoot the approach

Currently, you: load sim, open aircraft config centre, press Ready For Takeoff, takeoff, fly around (time acceleration is awesome here), and shoot the approach.

As I recently said on Discord:

Josh on Discord wrote:modern Airliners are heavily state based
lots of things happen between taxi->takeoff->climb->cruise->descent->landing->taxi->reset
So I have to figure out which state we are in, and configure everything to be in that state.
It would be a bit easier if everything wasn't so computerized


I am working (slowly) on a way to make in air starting possible by having the aircraft config "detect" the phase and sync the systems logic up to it, but this will take alot of time. I built the MD-11 systems and the parts of the A320 I did with state syncing in mind, I am not sure if legoboyvdlp build the reworked A320's systems with that in mind -> but it can probably be easily added.

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: MCDU/FMS - Generic framework vs. custom implementation

Postby stuart » Wed Aug 04, 2021 6:20 pm

Octal450 wrote in Mon Aug 02, 2021 11:48 pm:The actual flightplan system underneath Route Manager we also use in our MCDU/FMGC -> since the flightplan system is a framework, we have set up our implementation to match A320 real. If the route manager some day supports enough options that we can function properly, then of course we can re-enable for the users who prefer to use him instead.


If you haven't already done so, it would be worth talking to James about what features are missing from the existing Route Manager. Implementing them in the existing Route Manager is likely to be far less work than creating (and maintaining!) a custom route manager.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: MCDU/FMS - Generic framework vs. custom implementation

Postby Octal450 » Wed Aug 04, 2021 7:16 pm

stuart,
I believe its better focused to improve the behind the scenes Flightplan system -> legoboyvdlp has already made some things, and James is a bit busy and he will get to them when he has some time :mrgreen:

The things that are missing are different in every FMS system. So how can be added? If I suggest the Airbus/MD-11 way (they use almost exact same system) then that will be unusable by any of the various Boeing FMSs, or the MD-80, or ANY of the "retrofitted" FMS's in airliners, or the Embraer, or the private jet people... etc...

Specific to airplane features I am not sure how that can go into a generic when its different on so many planes?

Vs something like IT-AUTOFLIGHT where most of the features are similar, just a few tweaks to the logic and annunciations per aircraft.

For us its way easier to create our own MCDU/FMGC system that handles the Flightplan system then to "customize generics".

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: MCDU/FMS - Generic framework vs. custom implementation

Postby Hooray » Wed Aug 04, 2021 8:12 pm

Octal450 wrote in Wed Aug 04, 2021 7:16 pm:The things that are missing are different in every FMS system. So how can be added?


As previously mentioned, that's perfectly possible using IoC (inversion of control), e.g. design patterns like so called "delegates" (which are in fact already being used in various places by the RM system, if you are not aware of that being the case or how to make use of such flexibility, we obviously need better documentation/examples).

Either way, that is exactly why I mentioned MapStructure elsewhere, not so that you can begin using it - but to make the point, that you can indeed have your cake and eat it, and indeed Stuart's FG1000 could be considered the reference implementation of doing exactly that (regardless of MapStructure itself, the takeaway being IoC via Emesary or other design patterns - e.g. delegates for starters, or abstract interfaces to inherit from in order to sub-class an interface and customize an implementation).
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

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 12 guests