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.

Re: Improvement in Gui launcher

Postby wlbragg » Wed Dec 20, 2017 8:28 am

it still doesn't scale well to all aircraft on FGAddon.

That is a fact, even something as simple as setting up an "On Approach" state for similar aircraft like the Cub VS the c172p won't scale perfectly. There are several differences that have to be accounted for. Add in some developer customizations and then it becomes real messy.
I think that is why something like custom states written by the developer, specific to an aircraft, but read into init by the GUI is a logical way to go.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Improvement in Gui launcher

Postby wkitty42 » Wed Dec 20, 2017 4:00 pm

that's my understanding, as well, wlbragg... it is up to the craft maintainers to code these states for their craft... especially since each craft can be so different from others... even like craft made by different people can be hugely different...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Improvement in Gui launcher

Postby benih » Thu Dec 21, 2017 12:49 pm

This is the way i proposed in my first post: let the gui request a well defined state of the aircraft (that is, set a common known state property). Let the aircraft handle the rest. Only provide the selection in the gui with aircraft that tell it it can handle it.
This enables us to enhance aircrafts slowly by time. No harm is done to the sim but enables progress over time.

I dont support the idea to solve this init stuff on the simulator core side.

If most addon aircrafts arent including this, so be it.
If aircraft devs let signal their craft wrongly that they support an state but don't, they have to deal with the bug reports.
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 » Thu Dec 21, 2017 4:25 pm

This is the way i proposed in my first post: let the gui request a well defined state of the aircraft (that is, set a common known state property). Let the aircraft handle the rest.


This is manifestly not what you proposed in your first post - what you proposed is that:

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?


Aka - you proposed to be able to set a user-defined airspeed, not to request any state from the aircraft and not to check whether that state is defined at all.

If you want to discuss seriously, please don't take us for fools.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Improvement in Gui launcher

Postby benih » Thu Dec 21, 2017 5:08 pm

Sorry, no offense intendet. I confused this with the other thread, because we were discussing states now here too.
You are right i asked for the airspeed element.

Ok, i hope i summarize this correctly now, i understand the situation as following:
- setting initial airspeed at the gui translates to the --vc=knots option. This works for most aircrafts but is not desired, because usually the plane cant handle this (one ends up with for example cold&dark plane in the air)
- the solution would be to initialize consistent states.
- these states are not formally designed yet, but proposal exists.
- It is too complex to implement this in the core because of the unknowable types of aircrafts possible
- it is not feasible to update all aircrafts to support the states because of workload.
- the idea to let the aircraft inform the launcher of supported formalised states so it can make them selectable, combined with the need to implement state-support aircraft-side was not fully discussed.

Correct?
- enabling the gui to parse plane metadata in order
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 wlbragg » Thu Dec 21, 2017 6:47 pm

I think that is close to summing up my understanding of the situation.

However, beware, I tend to see these proposals through my personal background, experiences and expectations. This doesn't always parallel the historical path of the project or the intent of the developer who may bring forth an initial idea.

For example, I think this started out to be a solution for a "few" specific start up states. States that the project once supported out of the box.

I'm not sure the addition of developer designed states that the GUI could potentially read and execute we're ever the ultimate goal. That I think is my own expansion of the concept because I see major potential down the road with something like that.

After working with the current state of the "state support system", I see great potential and versatility. To see it to fruition would require the person responsible for the GUI to buy in to the concept and move forward with it.

As it stand now, it is possible to create startup states, that doesn't necessarily mean that the project supports that idea or wants to see any expansion in that area, at least until there are some guidelines established.

That kind of parallels with something else I recently read on another thread. A developer has decided that the sophisticated aircraft they are developing should be flown without auto-coordination so they disable it by default. I can see a valid reason for wanting to do such a thing. But that is not consistent with the long established norm of allowing the user to decide that condition. The same would hold true for certain graphic settings that the GUI allows the user to decide upon, yet there have been instances where the developer thought a certain setting was best and overrides the default GUI choice.
A lot of these nuances are only understood after considerable time with the project.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Improvement in Gui launcher

Postby wkitty42 » Thu Dec 21, 2017 7:52 pm

wlbragg wrote in Thu Dec 21, 2017 6:47 pm:For example, I think this started out to be a solution for a "few" specific start up states. States that the project once supported out of the box.

yup! that is true... one of those states is to be able to start at (eg) 10nm out, on scope, and inbound (aka the classic landing practice scenario)... being able to do that allows for a multitude of others... standardizing the default list was done, IIRC... i don't know if the implementation that was discussed has been completed or not... it may be stuck on the todo list behind a few other more important items...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Improvement in Gui launcher

Postby Hooray » Thu Dec 21, 2017 9:11 pm

that is true, originally the subsystem architecture was prepared with the suspend (save/load) and resume scenario in mind - however, this got crippled pretty quickly when all sorts of features were added that would no longer work with these application-level pre-defined "states" - moving that responsibility over to the aircraft domain does make sense for all the reasons previously mentioned. These days, that is probably the only reasonable way to deal with this. However, the more aircraft begin supporting such states, the more it would make sense to review what is needed (useful/helpful) at the application level in the form of infrastructure (or even just hooks) to support the corresponding "states".
We do have a number of more or less related systems and features that could greatly benefit from formalizing the data/systems modeling requirements, e.g. multiplayer, instant replay/flight recorder (fgtapes), dual-control, reset-reinit, checklists and, more recently, Emesary - the requirements here are very much overlapping. And a number of long term contributors have repeatedly tried to have the exact same discussion, including even Jon S. Berndt (JSBSim) - as a matter of fact, there is tons of related materials to be found in the devel list/forum archives - but if you don't want to do much reading, just make sure to look up Jon's original posting: https://www.mail-archive.com/flightgear ... 20398.html

The idea itself is long-standing though, a number of related pointers are collected here: http://wiki.flightgear.org/FDM_engine_f ... ardization

The most recent summary is this, suggesting the use of aircraft-side "situations" represented in the form of different aircraft/system states (state vectors actually) using a combination of existing features like automated checklists and different startup situations to represent different aircraft configurations.

Unfortunately, this never got updated later on - however, it may make sense to review the corresponding discussions and see if this article (or a new one) can be updated to represent the latest "brainstorming".

PS: Originally, the save/load and resume functionality got broken when the "presets" feature got added a long time ago, see David Megginson's comments quoted at: http://wiki.flightgear.org/Fixing_Presets
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 » Tue Jan 02, 2018 6:16 pm

Hi, just a little follow up on this, i implemented ut now using http://wiki.flightgear.org/Startup_Profiles together with an optional "auto" mode that detects in air starts and sets velocity accirdingly in the presets.
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 » Thu Jun 21, 2018 7:36 pm

Hi there,
recently we got the new overlay selector in the launcher. This was a cool addition and it supports the c182s well :)
Thank you for that!

However the launcher always initializes the drop down with the first entry selected. I think it would be very nice, if the launcher remembered my last selection (like in nearly all other launcher selections), so i don't always have to readjust before starting flightgear.

My usecase in the c182s is:
- the first state is "Automatic", so the plane initializes according to selected user position. This is especially important for the first startup and for new users, since the user gets a ready-for-takeoff plane at the default airport this way.
- I however like to fly "used" and thus nearly always want to use the "saved" state selection (second in row). The catch here is that if i forget to reset the state in the launcher only once, i loose much of my flight history (battery and tanks level; and in the future maybe wear-and-tear of the engine and clogging of air filters to simulate long term maintenance).

How can i reach the maintainer of the launcher to discuss this with him?
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 bugman » Thu Jun 21, 2018 11:06 pm

You need to send an email to the flightgear-devel mailing list.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Improvement in Gui launcher

Postby benih » Fri Jun 22, 2018 9:17 am

Ok will do, thanks!
Done
User avatar
benih
 
Posts: 1689
Joined: Tue Aug 15, 2017 10:34 am
Callsign: D-EBHX
Version: next
OS: Debian Linux 64bit

Previous

Return to New features

Who is online

Users browsing this forum: No registered users and 7 guests