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 wkitty42 » Sat Dec 16, 2017 9:02 pm

the thing is that there is already a way of doing this... each craft requires meta tags and the proper options to be added... there has been talk on the developers' mailing list about how to do in-air starts... the main thing is to allow the craft to cycle through its routines several times so that it does have time to spool up and get everything set and balanced for flight at that point in time... then the sim would allow the operator to take over and fly the craft... all of this preparation stuff would take place behind the cloak of the splash screen... i think, but am not sure, that the c172p has had some of this capability added to it... i don't recall if all the work in the sim and in the c172p were completed to be able to demonstrate this... it was certainly discussed and some work or thoughts posted...
"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: 5700
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Improvement in Gui launcher

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

I have seen the article in the wiki but do not know if the code is already in place.
benih
 
Posts: 96
Joined: Tue Aug 15, 2017 9:34 am

Re: Improvement in Gui launcher

Postby Hooray » Sat Dec 16, 2017 9:57 pm

frankly, it is a freaking mess to code this up for any non-trivial aircraft (i.e. anything more complex than the ogeL, ufo or c172p) - supporting this properly needs a fair bit of infrastructure which is currently misssing, or you're literally coding up all the missing infrastructure in a highly use-case specific fashion, which is likely to conflict with other parts of the simulation.
There is quite a bit of overlapping requirements and functionality when it comes to the MP system, dual-pilot, and especially the instant replay system - but also the checklist system, unfortunately these are all using hugely different approaches that are not exactly compatible either.

Technically, this would involve quite a bit of coding, and it would only be feasible to approach this by designing all systems (FDM, property rules, Nasal etc) accordingly - and that also includes a capability to implement state transition, including tinkering with the dt value of the simulated time, so that the simulation can literally "fast forward" (time acceleration) to get to the desired state behind the scenes.

Again, it's definitely possible - but not in a general fashion, it would have to be done right from the beginning, and it far easier to do with much less complex aircraft/systems, and ideally the simulator itself would provide the building blocks and infrastructure for the corresponding "situations" (aircraft configurations) and means to transition between these states - which is to say doing event handling, because under the hood, aircraft developers would still have to implement everything obviously.
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: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: Improvement in Gui launcher

Postby wlbragg » Sun Dec 17, 2017 4:55 am

See J3Cub under /states/j3cub-approach-overlay.xml and other states that are setup. Also there is a portion required in the .set file

Code: Select all
<state include="states/j3cub-approach-overlay.xml" n="0"/>
        <state include="states/j3cub-parking-overlay.xml" n="1"/>
        <state include="states/j3cub-tahoe-overlay.xml" n="2"/>
        <state include="states/j3cub-hilltop-overlay.xml" n="3"/>
        <state include="states/j3cub-glacier-overlay.xml" n="4"/>
        <state include="states/j3cub-mountain-overlay.xml" n="5"/>


And in the launcher settings
--state=approach or some other state.

And in the launcher under "Location" check "on final approach" if using the approach state.

I thought I had a couple of these set up for the c172p, but they are no longer included. They are easy enough to set up however.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4915
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: Improvement in Gui launcher

Postby Thorsten » Sun Dec 17, 2017 7:00 am

frankly, it is a freaking mess to code this up for any non-trivial aircraft (i.e. anything more complex than the ogeL, ufo or c172p) - supporting this properly needs a fair bit of infrastructure which is currently misssing, or you're literally coding up all the missing infrastructure in a highly use-case specific fashion


Mathematically, any aircraft is a set of coupled integral/differential equations.

What you perceive as 'aircraft on the ground' or 'aircraft in flight' is a near-equilibrium steady state solution of these equations (there's nothing trivial about the aircraft standing on the ground - this happens only if the equations of the gear spring potential and tire friction let it settle into this state).

What you perceive as 'control' of this aircraft is a perturbation of the steady-state which makes it settle into a new equilibrium.

There's a host of other solutions which are wildly oscillating, diverging to infinity and doing other nasty things - and we don't want to run into these.

Whenever you try to init an aircraft, it has to be done in such a way that it converges into equilibrium reasonably fast. What that means depends on the current environment settings - you may have to go as far as provide a fake history invented for the current environment to make it work.

Even leaving any infrastructure questions aside, even on the most abstract algorithmical level there is nothing simple about this.
Thorsten
 
Posts: 11113
Joined: Mon Nov 02, 2009 8:33 am

Re: Improvement in Gui launcher

Postby adam_one » Sun Dec 17, 2017 3:39 pm

Crappy community when Thorsten takes every opportunity to blame people.
If I would've had your email address I would've told you to quit that crap, and not in those words.

Seriously, you're messing crap up, quit it, it's not wanted here.
adam_one
 
Posts: 64
Joined: Tue Jan 05, 2016 2:41 pm
Version: alpha
OS: pirated

Re: Improvement in Gui launcher

Postby Thorsten » Sun Dec 17, 2017 3:41 pm

Be my guest:

thorsten@science-and-fiction.org

(not really hard to find out on the mailing list either - but be warned, you don't get privacy protection for insults and abuse)

Seriously, you're messing crap up, quit it, it's not wanted here.


Um, yeah - apart from 53 posts, what exactly is it you're contributing here?
Thorsten
 
Posts: 11113
Joined: Mon Nov 02, 2009 8:33 am

Re: Improvement in Gui launcher

Postby adam_one » Sun Dec 17, 2017 3:57 pm

There's not a lot to discuss here.
If you can't discuss in a thread without being self-entitled and blaming away - then don't.
adam_one
 
Posts: 64
Joined: Tue Jan 05, 2016 2:41 pm
Version: alpha
OS: pirated

Re: Improvement in Gui launcher

Postby Thorsten » Sun Dec 17, 2017 3:59 pm

If you can't discuss in a thread without being self-entitled and blaming away - then don't.


If you'd just follow your own advice... :D

So no mail from you then?
Thorsten
 
Posts: 11113
Joined: Mon Nov 02, 2009 8:33 am

Re: Improvement in Gui launcher

Postby adam_one » Sun Dec 17, 2017 4:12 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.

something the community has miserably failed to do.

Criticism is fine, unasked for blame is not.

Merry Christmas.
adam_one
 
Posts: 64
Joined: Tue Jan 05, 2016 2:41 pm
Version: alpha
OS: pirated

Re: Improvement in Gui launcher

Postby Thorsten » Sun Dec 17, 2017 4:35 pm

Yes - which is why I criticized the idea brought forward, explaining my reasoning for doing so, whereas you blame me personally for something (I don't really know what - supposedly blaming someone which, well, doesn't really emerge from the quotes - after all, no one has volunteered, that's the simple observation of a fact, not criticism or blame)

And well, that has been quite unasked of you...

I can only repeat:

If you'd just follow your own advice...
Thorsten
 
Posts: 11113
Joined: Mon Nov 02, 2009 8:33 am

Re: Improvement in Gui launcher

Postby swampthing » Mon Dec 18, 2017 3:45 am

I have an idea. Take off, do a pattern and land, or climb to the desired altitude, fly back and enter the glide slope and land. :)
www.opredflag.com
I have sworn upon the altar of God, eternal hostility against every form of tyranny over the mind of man. -Thomas Jefferson-
swampthing
 
Posts: 534
Joined: Wed Oct 28, 2015 4:10 am
Location: Missouri
Callsign: swamp
Version: 2018.2
OS: multiple

Re: Improvement in Gui launcher

Postby stuart » Tue Dec 19, 2017 10:45 pm

Thorsten - I think you're being overly pessimistic here, and far too negative. After all, you've coded up ways to set up the space shuttle at various stages, including IIRC the ability to save off the current command state.

wlbragg - I had forgotten about the various states that could be set. From memory I think James was thinking that these could be used for in-air starts and having well-defined names for common scenarios. Might be worth talking to him about his thoughts on this, as it seems slightly wrong to have to indicate the required state being set from a command-line option.

swampthing - That's not that great an option if you want to practise multiple instrument approaches, particularly when you're learning.

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

Re: Improvement in Gui launcher

Postby wlbragg » Tue Dec 19, 2017 11:11 pm

I had forgotten about the various states that could be set.

I guess it got set aside for the time being.
Yes, to have to include a command line argument to activate it doesn't seem like it would be the way to go.
I think the idea was to eventually have some predefined state identities that would be selectable from the GUI (Approach, Parked, Taxi, Circuit, etc). Maybe even be able to have the GUI pick up developer supplied custom states. That is how I would do it.

I think it has great potential.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4915
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: Improvement in Gui launcher

Postby Thorsten » Wed Dec 20, 2017 6:34 am

Thorsten - I think you're being overly pessimistic here, and far too negative. After all, you've coded up ways to set up the space shuttle at various stages, including IIRC the ability to save off the current command state.


First of all, mission stages and save/load for the Shuttle is a ton of extra code - including init flags which activate special alternative channels inside the JSBSim systems and special Nasal logic that switches on current guidance targets. There's nothing trivial about this, and worse, nothing that would readily generalize to other aircraft.

Second, much of the init actually involves initializing the FDM in space - which is a fairly easy task, since you have zero perturbations, you you know what the PID controllers must do up-front. Initializing in the upper atmosphere is considerably harder even in the absence of winds, initializing in the lower atmosphere is a mess which requires extra init support in the PID controllers of the FCS (again alternative channels).

I've spent a total of more than 30 hours creating these functions for the Shuttle - even if you assume that other aircraft take 1/10 of the effort, it still doesn't scale will to all aircraft on FGAddon.

In fact, the reason I am negative is because I have done it and know the work that's involved pretty well.
Thorsten
 
Posts: 11113
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to New features

Who is online

Users browsing this forum: No registered users and 0 guests