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
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
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)