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.

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.

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)

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.

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,

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

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.

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.