Board index FlightGear Development New features

Improvement in Gui launcher

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Improvement in Gui launcher

Postby benih » Sat Dec 16, 2017 10:27 am

Hello,
i recentky tried out the setup of a plane in airport mode with 10 miles approach setting. However, there i cannot enter how fast the plane should initialize.
Would it be possible to add the airspeed option there that is already present in the fix-offset dialog?
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Improvement in Gui launcher

Postby Thorsten » Sat Dec 16, 2017 11:15 am

It'd be a bad idea to implement this in the launcher because then people might assume this generally works- which it really doesn't, it has to be made work per plane.

So you need to enter this into the commandline box.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Improvement in Gui launcher

Postby benih » Sat Dec 16, 2017 12:27 pm

But in the other launcher mode this is implemented and working?

Open the launcher, select "Location", select a FIX and there the airspeed option is!
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Improvement in Gui launcher

Postby Thorsten » Sat Dec 16, 2017 12:29 pm

Try to initialize Vostok-1 with an airspeed of your choice at a fix, see how well it works. Try the Alouette-III next.

Many (especially more detailed) aircraft do not survive an in-air start.

The fact that there is an option does not mean that it works as expected.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Improvement in Gui launcher

Postby benih » Sat Dec 16, 2017 1:29 pm

I just talk about the launcher supplying the "--vc=knots" option conviniently in airport-location-mode when using "on final approach" option.

It works with the Ogle test aircraft, the sopwith camel, the c172, the c182, the F-16, the 747, the Twin-Otter and even the EC140 (Helicopter).
When initializing with this settings, the craft has the initial speed, and that is all i am talking about.

The rest (like starting with engine running etc), i agree, is aircraft specific
Also it is clear, that for some aircrafts really does not make sense to initialize the sim like this.

For all other aircrafts this would be a great addition, tough, because it massively eases scenarios like training approaches (with and without power-on).
One could easily choose an airport of their choice, select the distance and height to the airport, and (new) the initial speed and could hit "FLY!" to get started.
Every aircraft not supporting this could still be glided (power-off landing training), and aircrafts that support it, can automatically start the engine or at least let the user do it manually from some menu (autostart, which planes should have fr a decent rating anyways).
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Improvement in Gui launcher

Postby Thorsten » Sat Dec 16, 2017 3:55 pm

I just talk about the launcher supplying the "--vc=knots" option conviniently in airport-location-mode when using "on final approach" option.


Yes, and I'm telling you that unless this works as expected for every (or at least the vast majority) of aircraft (which it does not), this better not be a launcher GUI option, because then people expect it to work.

Which creates bug reports in the forum which someone has to answer.

Whereas you can easily be bothered to type this into the box, which does not create work for those who take bug reports.

For all other aircrafts this would be a great addition, tough, because it massively eases scenarios like training approaches (with and without power-on).


We can all agree it'd be nice if it would work, however it is a massive workload to make it work - so unless a dozen people volunteer to go ahead and do it for many aircraft, it won't happen.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Improvement in Gui launcher

Postby Octal450 » Sat Dec 16, 2017 4:23 pm

I disabled my Airbus' when starting in air for the following reason:
* The systems are not designed to be started like that, ,throughout the flight, they asses what the plane is doing, and different things happen.. Starting in air makes this impossible, since the systems do not know what has happened. Plus -- several MCDU/FMGS functions are are only available on ground with engines off, therefore, these items (which are required for some FMGS parts to operate correctly) cannot be set, causing inability to realistically fly the aircraft anyways...

It "could" work, but caused some problems, so I simply disabled the aircraft when air-start is done.

I do want to have some scenarios loadable for practicing approaches and such in the Airbus, but I am not sure if I will go through with 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: Improvement in Gui launcher

Postby Hooray » Sat Dec 16, 2017 5:27 pm

You kinda need a way to encode different situations, and aircraft configurations, and tell FlightGear to apply those - which is not just flipping a few switches, but also making sure that the underlying systems simulation correctly represents the corresponding situation/configuration. FlightGear was never designed with this requirement in mind, even though the SGSubsystem/Mgr structure is prepared to support a start/suspend/resume and reset/re-init sequence, this was never adopted, let alone enforced, by any of the core developers when David Megginson (designer and creator of the property tree/SGSubsystem infrastructure) left the project - In addition, even if that had not be the case, Nasal was added around 2003/2004, and an increasing number of features were implemented purely in scripting space, without any attention paid to such requirements, so that reset/re-init scenarios (think save/load and resume a flight) simply won't work at all.
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: Improvement in Gui launcher

Postby benih » Sat Dec 16, 2017 5:33 pm

Ok i understand.
But shouldn't we then be consequent abd remove the "offset from fix" launcher option too? (Or at least the option to set initial airspeed?)
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Improvement in Gui launcher

Postby benih » Sat Dec 16, 2017 6:10 pm

Maybe also defining the already proposed state interface and adding a new aircraft xml tag is a good compromise?
The launcher then should only provide the options when it knows from the selected aircraft that it can handle them, so tgere is the status-quo for all aurcrafts but developers can move ahead in their own pace.
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Improvement in Gui launcher

Postby Octal450 » Sat Dec 16, 2017 6:25 pm

Well, as I said, I could add scenarios which already contain a flight history, and set the systems up for that state.

But, remember, that the real plane can't just jump to 10000 ft at 250kts when the pilot wants -- so the systems are not designed with that in mind, so when I simulate it, it gets difficult.

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: Improvement in Gui launcher

Postby benih » Sat Dec 16, 2017 7:09 pm

Yes, and if the launcher recognizes the ability of the aircraft that it can handle in-air-starts it could provide the relevant options to the user.
Otherwise, such options should be disabled.
The aircraft developer could designate this with some additional xml attribute(s?) like for example the aircraft rating.
This way, aircrafts can be adopted slowly, and simultaneously prevent the bug reports mentioned above.
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Improvement in Gui launcher

Postby Thorsten » Sat Dec 16, 2017 7:11 pm

We can all agree it'd be nice if it would work, however it is a massive workload to make it work - so unless a dozen people volunteer to go ahead and do it for many aircraft, it won't happen.


FYI - even adding metadata tags to every aircraft (which can be done by everyone who can read Wikipedia at the expense of ~10 minutes per aircraft) is something the community has miserably failed to do.

I have no shortage of my own ideas how FG should be - but I do have a shortage in coding time.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Improvement in Gui launcher

Postby benih » Sat Dec 16, 2017 9:34 pm

So we put this to its grave because we think that developers would not add metadata?
Okay.

In my optinion it would be favorable to at least have "the way it's done right" that few are walking instead of having no way at all.
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Re: Improvement in Gui launcher

Postby Thorsten » Sat Dec 16, 2017 9:56 pm

So we put this to its grave because we think that developers would not add metadata?


Correction - we know that.

And we put it to the grave for the simple reason that no one is volunteering to shoulder the workload required - and that's including you.


In my optinion it would be favorable to at least have "the way it's done right" that few are walking instead of having no way at all.


We seem to be going in circles, but again:

* mostly non-working 'click me' feature in the launcher - lots of 'bug' reports and explanations required
* feature that works only via commandline box - (mostly) only people who know what they're doing use it, no bug reports

Your proposal is to add to my maintenance load because you can't be bothered to type a line into a box - and sorry, that's not exciting me (having said that, that's my opinion voiced here - others may see it differently, it's a community project rather than my project, but that's the way I'm going to argue this).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Next

Return to New features

Who is online

Users browsing this forum: No registered users and 11 guests