Board index FlightGear Development Aircraft Cockpit development

FG1000 ready for integration into aircraft

Discussion about creating 2d and 3d cockpits.

Re: FG1000 ready for integration into aircraft

Postby Hooray » Fri Jan 11, 2019 9:30 pm

I believe it should be pretty safe to move any FG1000 specific options/settings or runtime commands into a dedicated Canvas GUI dialog and simply show a corresponding dialog by registering an event handler. That would even work for people working solely with the cockpit based device, kinda like an in-sim UI to configure the device (think to configure/customize some of its defaults or even to re-load/re-start the device easily)

Alternatively, a custom MFD page for debugging/troubleshooting purposes could be added, so that the MFD itself could be used to configure the device and any of its defaults
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: FG1000 ready for integration into aircraft

Postby StuartC » Sun Jan 13, 2019 5:45 pm

Des the properties for the FG1000 appear anywhere in the property tree?
StuartC
 
Posts: 2738
Joined: Fri Jun 18, 2010 8:18 pm
Location: Arse end of the Universe
Callsign: WF01
Version: 2018.3.2
OS: W10 64 bit

Re: FG1000 ready for integration into aircraft

Postby Thorsten » Sun Jan 13, 2019 5:57 pm

Since it's canvas I'm sure they do (if you mean the display content). Though the canvas property structure isn't really human-readable.
Thorsten
 
Posts: 11106
Joined: Mon Nov 02, 2009 8:33 am

Re: FG1000 ready for integration into aircraft

Postby StuartC » Sun Jan 13, 2019 6:12 pm

Im just looking for a way to change the screens while I don't have any buttons/functions configured in the XML.
StuartC
 
Posts: 2738
Joined: Fri Jun 18, 2010 8:18 pm
Location: Arse end of the Universe
Callsign: WF01
Version: 2018.3.2
OS: W10 64 bit

Re: FG1000 ready for integration into aircraft

Postby Hooray » Sun Jan 13, 2019 6:54 pm

It would be better to tell us exactly what you want to change, so that this can be made configurable - it should typically only take 20-30 lines of Nasal code to expose such things to some kind of UI (e.g. by clicking the display/screen). Alternatively, it would be possible to use instance specific properties for these defaults, and register a listener so that the fg1000 can apply any changes.

Regarding Thorsten's comment, that's true - what you will see in the /canvas/by-index sub-tree is basically a bunch of elements that are chained together in a cascaded fashion. While the Canvas system started out using solely the property tree, this is no longer the case - i.e. features added later on, would break this encapsulation boundary, so that most stuff involving the GUI, widgets and layouting no longer works primarily via properties, but via the so called cppbind mechanism - which is a much cheaper (faster) way to hook up OSG machinery to Nasal and vice versa - but obviously at the cost of not necessarily going through the property tree any longer, which is to say that certain stuff will break in multi-instance setups, or re-implementations of the Canvas system (think FQGCanvas).

It is out of this very realization that the people originally involved in prototyping Canvas instruments arrived at the conclusion, that the purely Nasal-based way of accessing the Canvas system is potentially problematic, because we are abandoning the property tree abstraction - especially in anything involving multi-instance setups (multiplayer, dual-pilot, FSWeekend/LinuxTag or FGQCanvas).such setups to work reliably

For the Canvas system to become future-proof, it would have to expose the simgear::canvas::Element API to scripting space, so that new/custom elements can be prototyped and implemented in scripting space, so that all crucial canvas state lives indeed in the property tree, so that such state can be propagated/synchronized (replicated) to other instances using solely properties.

While the corresponding elements would still be implemented in Nasal "as is", their interfaces would be better formalized by going through the sc::Element/PropertyBasedMgr structure, which in turn also provides for a sane way to deal with versioning and upgrading elements, even by re-implementing certain elements in native code, without any front-end code having to be touched at all.

Basically, our current way of using/exposing the Canvas system simply isn't very scalable, because it is too low-level for most non-coders, and it requires a fair amount of boilerplate code/machinery to deal with use-cases such as multi-instance setups.

This is why it is crucial to actually create frameworks to formalize/encapsulate such use-cases, or people will have to re-invent the wheel over and over again.

In other words, people not using the FG1000 approach (namely, Richard's MFD framework in conjunction with Emesary) are unlikely to come up with a structure that actually scales - so that such Nasal/Canvas contributions will continue to reflect badly upon Nasal and Canvas unfortunately - whereas it would actually be prudent to expose the core sc::Element/Group APIs to scripting space so that contributors can create their own Canvas based elements using the existing, and PROVEN, Canvas API:
http://wiki.flightgear.org/Canvas_Devel ... FlightGear


Anyway, if you really do have a need to navigate such a Canvas structure at run-time, it is fairly straightforward to open property-browser.xml and add roughly 30 lines of code to it, so that it can recognize any Canvas structure, and create a deep copy of the current node to render a preview of the group/node, which can be a great asset for troubleshooting purposes:

Image

(the canvas widget can be trivially hidden/shown as needed, by evaluating the currently selected property path)
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: FG1000 ready for integration into aircraft

Postby stuart » Sun Jan 13, 2019 7:03 pm

Hi StuartC,

Are you wanting to use the FG1000 without the models that surround it and provide the buttons and knobs?

As Hooray has alluded to, the FG1000 UI isn't really property driven. Instead it uses Emesary messages. If you look at the code in Aircraft/Instruments-3d/FG1000/Nasal/GUI.nas you can see the fgcommand() calls that are used to send the Emesary messages.

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

Re: FG1000 ready for integration into aircraft

Postby StuartC » Sun Jan 13, 2019 7:51 pm

Hi other Stuart.

Yes its for using the function within custom models.
It would be handy to be able to flick through the various pages to see if it all fits before going to far and having to pull it all to bits again.
StuartC
 
Posts: 2738
Joined: Fri Jun 18, 2010 8:18 pm
Location: Arse end of the Universe
Callsign: WF01
Version: 2018.3.2
OS: W10 64 bit

Re: FG1000 ready for integration into aircraft

Postby Hooray » Sun Jan 13, 2019 8:22 pm

StuartC wrote in Sun Jan 13, 2019 7:51 pm:Yes its for using the function within custom models.
It would be handy to be able to flick through the various pages to see if it all fits before going to far and having to pull it all to bits again.



In that case, I would use an event handler that responds to clicking either the screen or its outer shell, and simply bring up the variant that is based on the Canvas GUI dialog, along with Michat's SVG/Inkscape based skin - that way, the whole thing should be usable without requiring cockpit bindings.
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: FG1000 ready for integration into aircraft

Postby wlbragg » Wed Jan 16, 2019 5:05 am

Hi Stuart,

I am getting the same buggy behavior with the GUI and the entire in model FG1000 implementation as I get with the inset when turning it on and off.

To explain. in the J3Cub implementation I can select and de-select the FG1000 option for the panel. If I de-select it, the next time I select it (in the same session) the PFD doesn't work anymore, as in the AI, compass and airspeed don't respond anymore. The screen has an image, it simply doesn't update anymore. The MFD doesn't show a map anymore, it is just black.
Same thing with the GUI implementation I setup in my menu. If I close it and try to reopen it, same thing as the model 3d displays, quits working in the same manner.
That is the same thing the inset did when I shut it off and tried to turn it back on.

This is the file that is loading both the GUI and 3d model version.

Code: Select all
var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/";
io.load_nasal(nasal_dir ~ 'FG1000.nas', "fg1000");
io.load_nasal(nasal_dir ~ 'Interfaces/GenericInterfaceController.nas', "fg1000");

var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance();
interfaceController.start();

# Create the FG1000
var fg1000system = fg1000.FG1000.getOrCreateInstance();

# Create a PFD as device 1, MFD as device 2
fg1000system.addPFD(1);
fg1000system.addMFD(2);

# Display the devices
fg1000system.display(1);
fg1000system.display(2);

#  Display a GUI version of device 1 at 50% scale.
var toggle_fg1000_PFD = func {
  fg1000system.displayGUI(1, 0.5);
};
var toggle_fg1000_MFD = func {
  fg1000system.displayGUI(2, 0.5);
};

var fg1000 = getprop("sim/model/j3cub/fg1000");
if (fg1000) {
  fg1000system.show();
} else {
  fg1000system.hide();
}

setlistener("sim/model/j3cub/fg1000", func(n) {
    if (n.getValue() > 0) {
      fg1000system.show();
    } else {
      fg1000system.hide();
    }
}, 0, 0);


This is the only debug I get. I think the "Element::childRemoved: unknown transform:" may be when I try to re-initiate the GUI or the 3d model?
The PFD_Device errors may just be me hitting stuff that is not implemented yet.

Code: Select all
############
#  FG1000  #
############

PFD_Device: Error loading MAP - STORMSCOPE: svg layer StormscopeGroup
PFD_Device: Error loading MAP - WEATHER DATA LINK: svg layer WeatherDataLinkGroup
PFD_Device: Error loading MAP - TAWS: svg layer TAWSBGroup
PFD_Device: Error loading WPT - AIRPORT DIRECTORY: svg layer AirportDirectoryGroup
PFD_Device: Error loading WPT - AIRPORT DEPARTURE INFORMATION: svg layer AirportDepartureGroup
PFD_Device: Error loading WPT - AIRPORT ARRIVAL INFORMATION: svg layer AirportArrivalGroup
PFD_Device: Error loading WPT - AIRPORT APPROACH INFORMATION: svg layer AirportApproachGroup
PFD_Device: Error loading WPT - WEATHER INFORMATION: svg layer AirportWeatherGroup
PFD_Device: Error loading WPT - USER WPT INFORMATION: svg layer UserWPTInfoGroup
PFD_Device: Error loading AUX - TRIP PLANNING: svg layer TripPlanningGroup
PFD_Device: Error loading AUX - UTILITY: svg layer UtilityGroup
PFD_Device: Error loading AUX - GPS STATUS: svg layer GPSStatusGroup
PFD_Device: Error loading AUX - XM RADIO: svg layer XMRadioGroup
PFD_Device: Error loading AUX - XM INFORMATION: svg layer XMInfoGroup
PFD_Device: Error loading AUX - SYSTEM STATUS: svg layer SystemStatusGroup
PFD_Device: Error loading FPL - ACTIVE FLIGHT PLAN: svg layer ActiveFlightPlanWideGroup
PFD_Device: Error loading FPL - FLIGHT PLAN CATALOG: svg layer FlightPlanCatalogGroup
PFD_Device: Error loading FPL - STORED FLIGHT PLAN: svg layer StoredFlightPlanGroup
PFD_Device: Error loading NRST - NEAREST USER WPTS: svg layer NearestUserWPTGroup
PFD_Device: Error loading NRST - NEAREST AIRSPACES: svg layer NearestAirspacesGroup

[snip]

Element::childRemoved: unknown transform: /canvas[0]/by-index[0]/texture[4]/group[0]/group[0]/group[0]/group[0]/map[0]/group[3]/group[8]/text[0]/tf[1]

[snip]

Element::childRemoved: unknown transform: /canvas[0]/by-index[0]/texture[4]/group[0]/group[0]/group[0]/group[0]/map[0]/group[3]/group[7]/text[0]/tf[1]
HTTP request: set failure:404 reason Not Found
Failed to get image /home/wayne/.fgfs/cache/maps/stamen-terrain-background/11/198/483.png 404: Not Found


NOTE: The GUI implementation you set up in the debug menu doesn't do this, it works on subsequent shutdowns and re-loads.
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: FG1000 ready for integration into aircraft

Postby Knüppelrührer » Sun Jan 20, 2019 7:42 pm

I am just trying on the DR400 and everything looks fine.

But where the heck is "inner" and "outer" FMS knob?

Tried all variations this afternoon just to input a flightplan. Moving the mouse pointer pixelwise, but always the same double-arrow symbol. With shift, without shift, left to the knob, right to the knob, below it, above it.....left button, middle button..... no chance to add second letter of a waypoint.

Can anybody help me out with this?
Or are there possibilities to increase the usability here?


edit: Got it. With shift. In my zoom state it was not visible, that the cursor was already on the next underline.
edit 2: I managed to put in one waypoint. But for the next one I cannot get to a second letter...
Knüppelrührer
 
Posts: 79
Joined: Thu Oct 25, 2018 9:06 pm

Re: FG1000 ready for integration into aircraft

Postby stuart » Mon Jan 21, 2019 2:05 pm

@wlbragg: Apologies for the delayed response. I haven't had the chance to debug this, but I notice that the calls to fg1000system.show(); and fg1000system.hide(); don't include an argument (see http://wiki.flightgear.org/FG1000#Load_ ... 000_system)

@Knüppelrührer: It's really difficult. Use shift to move to the next character. I've made some changes on "next" so you can use multi-key to type in values on most MFD pages. Type ":GM" and then the text you want to enter. You don't need to be in CRSR mode to do so.

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

Re: FG1000 ready for integration into aircraft

Postby Knüppelrührer » Mon Jan 21, 2019 10:18 pm

Thanks for the hint! Good to have a keyboard mode.
It gives <unknown> for :GM. I have a few issues with my installation, so this is something to be sorted out on the weekend.

Just some open thinking:
I have not yet found a good solution in sims for a knob with push-inner ring-out ring-function.
Most of the times it is not easy to keep flying with one hand and dialing in a new frequency or such.
In FG the mouse is never far away to change view and using keyboard takes away immersion.
How about this:
Left mouse on the button gives "push"
first click with mousewheel activates outer ring and it stays activated (to avoid "loosing" the function, when the aircraft moves and pointer is not at the button anymore)
New value can be dialed with the wheel.
Next click activates inner ring. Same procedure.
Next click (can be anywhere so you don't have to search the knob again) cancels the knob selection and it is back to normal.
Orientation can be given by a small ring/large ring symbol for the pointer so it is easy to see which ring is turned by the wheel at the moment.
As there are plenty of things to do, this is just an idea.
Knüppelrührer
 
Posts: 79
Joined: Thu Oct 25, 2018 9:06 pm

Re: FG1000 ready for integration into aircraft

Postby Thorsten » Tue Jan 22, 2019 6:49 am

I have not yet found a good solution in sims for a knob with push-inner ring-out ring-function.


In FG, those things actually are on a 'by knob' basis (in practice it ends up with plane specific conventions, but in theory the same plane could carry knobs with different conventions).

The advantage of this is that you can customize your planes to whatever interface you prefer.

The disadvantage of this is that it's de-facto impossible to define a standard, because you'd have to go through the whole collection of aircraft and adapt every one of them.
Thorsten
 
Posts: 11106
Joined: Mon Nov 02, 2009 8:33 am

Re: FG1000 ready for integration into aircraft

Postby Robertfm » Sat Jun 08, 2019 4:30 pm

stuart wrote in Tue Jan 01, 2019 8:12 pm:Hi StuartC,

Happy new year!

I think the problem is you haven't started the interfaces that map from the properties into the FG1000: http://wiki.flightgear.org/FG1000#Load_the_Interfaces_to_provide_data



Code: Select all
var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/";
io.load_nasal(nasal_dir ~ 'Interfaces/GenericInterfaceController.nas', "fg1000");

var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance();
interfaceController.start();


I expect when you do this, most of the instruments will work, but some won't - for example the engine displays, which assume a single piston engine. So you'll need to copy the GenericInterfaceController.nas to the aircraft and then probably create your own version of GenericEISPublisher.nas to map an appropriate set of properties. You'll also need to create your own EIS display, as described in the wiki. That involves creating an SVG. I've just updated the wiki to provide more detail on how to do this http://wiki.flightgear.org/FG1000#Create_an_EIS_Display. Shout if it isn't clear - writing good documention for this is hard when you're so familiar with how it works.

Good luck!

-Stuart


As a relative new comer I am still finding my way around. I am interested in being able to use the FG1000 in the Diamond DA42 (it already has G1000 it but info comes from FG not by setting it, none of the buttons work) and the Piper PA28 which I fly the most. I am far from being Tech minded but can follow simple instructions. Is there a code that can be put into FG Settings which will activate the FG1000 in those planes.
Robertfm
 
Posts: 535
Joined: Thu Apr 25, 2019 4:56 pm

Re: FG1000 ready for integration into aircraft

Postby stuart » Tue Jun 11, 2019 4:27 pm

Hi Robert,

I used a version of the DA42 as an early testcase for the FG1000, but it's a bit out of date now. If I get the chance I'll get it working again and make the files available.

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

PreviousNext

Return to Cockpit development

Who is online

Users browsing this forum: themexicannon and 1 guest