Board index FlightGear Development New features

Spacecraft-menubar.xml

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

Spacecraft-menubar.xml

Postby Hooray » Sun Oct 15, 2017 4:00 pm

Hooray wrote:Re: https://sourceforge.net/p/flightgear/ma ... /36051600/

Thorsten wrote:the hard-coded standard way how you're supposed to interact with aircraft is insufficient if you look
at the details of how a more complex aircraft actually works.

So in fact we should better come to prepare for a scenario where the majority of how to interact with an aircraft resides aircraft-side, not
FGData-side, and that FGData only provides default templates for the less complex craft.


Actually, this could be accomplished by removing the generic stuff from the default menubar.xml and explicitly adding it at the aircraft level on an opt-in basis, i.e. via -set.xml which would load the "default" (generic) AP/route manager and failure manager components. More sophisticated aircraft would obviously use their own UI dialogs.

Thus, this is primarily a matter of formalizing best practices and making sure that people understand why to use them.
Doing so would not require any changes in terms of PUI, Qt5 or even Phi/Canvas - it's just a matter of commenting out problematic defaults from menubar.xml and explicitly re-adding them at the -set.xml level if people want to use those.

If that is something that is considered too fragile or problematic for other reasons (work load caused ...), we could just as well use/support conditions (properties) in the menubar and allow aircraft to explicitly opt in/out as needed, even if just by setting a few properties using a dedicated "mode" property.

I don't think this needs to be any more complicated than that


moving the PM talk to the public forum, because I have been thinking about this in the context of the shuttle/trajectory map not making that much sense in the map-canvas.xml dialog - likewise, many of the default menubar entries and GUI dialogs don't make much sense for spacecraft.

Thus, I think it would be easier to introduce a a dedicated "spaceflight-menubar.xml" and add sensible stuff there (probably in collaboration with other folks working on spacecraft, e.g. Vostok ?), while renaming menubar.xml to something like "default-menubar.xml" or "airplane-menubar.xml".

This would free up quite a bit of UI space for any spacecraft, and not clutter up the default menubar with other irrelevant stuff.

It would also allow us to review the default menubar to better classify certain elements according to the use-case/aircraft they have in mind - for instance, jetways may make little sense for GA aircraft or helicopters ?

Speaking in general, this is really about introducing dedicated "modes", depending on the kind of aircraft people are using - and given that we have been supporting cars, trucks, motorbikes and even vessels, it may not be all that far-fetched to think about having other modes.

And James has been working in a so called Developer Mode anyway, so why shouldn't we have a "spaceflight" mode, too: https://sourceforge.net/p/flightgear/ma ... /35693664/
James wrote:Hi,

I’ve pushed a build system change, to do the following:

- define a FG_BUILD_TYPE in Cmake, with values ‘Dev’ (default), ‘Nightly’ and ‘Release’.

(other values can be added if meaningful, eg ‘release-candidate’)

- replace the existing FG_NIGHTLY and ENABLE_DEV_WARNINGS Cmake options

- add a /sim/developer-mode boolean flag

- initialise the default value of this based on the build-type. *Right now*, the only controversial thing is that Nightly builds default to developer-mode=true.

- allow developer-mode to be forced on and off in *any* build from the command line

—developer (switches it on)
—developer=false (switch it off, for testing in a self-compiled build)

- use this to switch the severity of the SG_DEV_WARN and SG_DEV_ALERT log messages up or down

- replace all the previous compile-time conditional warnings controlled by ‘ENABLE_DEV_WARNINGS’ to be dev warnings at runtime.

- report the build type in lots of places, eg via JSON, on startup, etc

I also just updated the fgmeta build script used by Jenkins to pass (I hope!) correct values for FG_BUILD_TYPE to Cmake for our nightly and release builds, but this layer can be improved now, I guess.

Please test: the new splash-screen shows a red warning text for Nightly builds, we could also show something in developer mode if it's useful. We can also have a discussion about hiding UI elements or picking different defaults based on the developer mode; since it’s a run-time switch, we aren’t excluding anyone from contributing by hiding things in ‘out-of-the-box’ mode in release builds, is my opinion.

Candidate things to hide, more suggestions welcome:

- the entire Debug menu
- wireframe mode in Rendering settings
(and probably a few more things there)

I wil gradually review warnings for dev-mode suitability, using the ‘can an end-user do anything meaningful with this message?’ criteria, I believe Richard Harrison also volunteered to do a review of that.

Any feedback on this system is welcome, we have a whole release cycle to decide what, if anything, we change in developer-mode vs normal.

(Oh and the launcher will get an ‘enable developer mode’ checkbox in the near future)

Kind regards,
James

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: 11115
Joined: Tue Mar 25, 2008 8:40 am

Re: Spacecraft-menubar.xml

Postby Thorsten » Sun Oct 15, 2017 5:02 pm

Thus, I think it would be easier to introduce a a dedicated "spaceflight-menubar.xml" and add sensible stuff there (probably in collaboration with other folks working on spacecraft, e.g. Vostok ?),


Yeah, that'd be also me these days, I'm the current Vostok maintainer.

It's not a bad idea, but I simply have no time to work on this. I'll be at FSWeekend, I want to have the next Shuttle milestone tested and debugged by then, and while GinGin is of enormous help with the testing part, the debugging part is nastier than ever because the new BFS simulation opens up a whole new can of worms.

So I'll be happy to give my input, review or commit stuff, but I won't actively work on such things for the near future.
Thorsten
 
Posts: 9753
Joined: Mon Nov 02, 2009 8:33 am

Re: Spacecraft-menubar.xml

Postby Hooray » Sun Oct 15, 2017 5:13 pm

Okay, thanks for the feedback then - didn't realize you were also involved in the Vostok these days ;-)
Anyway, have fun at FSWeekend - I am sure we can revisit this and we'll see if people like the idea or not.

Not sure what the BFS stuff is all about, but if it's about troubleshooting Nasal code, I may lend a helping hand - as long as you can dumb-down the problem, as in explaining it to a 5-year old, because I am not going to read any shuttle manuals to make heads and tails of dozens of acronyms ;-)

Okay, could not resist - according to google, it seems that BFS stands for "back-up flight software" ? If so, the degree to which you are simulating these things is admirable, but admittedly I am really only willing/able to help with structural stuff/code organization,
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: 11115
Joined: Tue Mar 25, 2008 8:40 am

Re: Spacecraft-menubar.xml

Postby Thorsten » Sun Oct 15, 2017 5:47 pm

Not sure what the BFS stuff is all about, but if it's about troubleshooting Nasal code, I may lend a helping hand


It's unfortunately about the sort of bug where the code is syntactically and even logically sound, but not in agreement with what reality does.

Basically it's inserting conditional branches in strategical locations where BFS does something different from PASS (the whole control logic has been written for PASS so far). Which means you can't help without knowing how PASS and BFS software internally works and what is supposed to happen in certain situations.

The bugs typically are already rare code branches where some BFS specific thing should be done but is not.

(The last one I've found was that the transition to Major Mode 305 is usually automatic, but the conditional which manages the detection of the condition did not talk to BFS, so it never happened when BFS was flying the Shuttle and had to be called manually).

Point being - you can't really help...
Thorsten
 
Posts: 9753
Joined: Mon Nov 02, 2009 8:33 am

Re: Spacecraft-menubar.xml

Postby Hooray » Sun Oct 15, 2017 6:04 pm

I agree, but just to state the obvious, and without being familiar with the underlying code - assuming you've previously heard the term FSM (finite state machine) - that is what is commonly used to express such logics, i.e. using nested conditionals may be more work than you think to deal with such complex state transitions.

Even if you decide not to use one, you may want to check the wikipedia article introducing the concept and showing a simple C/JavaScript implementation - it may save you tons of time when dealing with the code, because you may begin thinking differently about structuring the problem.
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: 11115
Joined: Tue Mar 25, 2008 8:40 am

Re: Spacecraft-menubar.xml

Postby Thorsten » Mon Oct 16, 2017 5:53 am

because you may begin thinking differently about structuring the problem.


I already think differently about structuring the problem right now - the issue is that as usual in hindsight (after working through the detailed documentation of how it really works, and after coding it once and running into issues) one realizes how one should have done it.

As things stand, eliminating a modest amount of bugs in otherwise well-tested code is far less trouble than re-writing it more elegantly and creating a ton of new bugs in the process.
Thorsten
 
Posts: 9753
Joined: Mon Nov 02, 2009 8:33 am


Return to New features

Who is online

Users browsing this forum: No registered users and 2 guests