Board index FlightGear Development Aircraft

Dual control for Boeing 777

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: Dual control for Boeing 777

Postby Hyde » Sun Apr 17, 2016 3:16 pm

Please forget about canvas for the moment.
I just want to display the CDU screen since it's simpler.

Condition is "Just display as same as captain", "No input from co-pilot side". Just observation.

At first, start up the captain side, CDU menu is displayed but not on copilot side.
Find that boeing.nas does not run because /instrumentation/cdu/serviceable is not set.
There is not /instrumentation/cdu/serviceable variable in co-pilot side because this variable is set in Electrical.nas which is not running on co-pilot (MP) side because set.xml is not called.
So I set it true in fo-set.xml then menu is displayed even pilot side is not started up.
Then I set the variable on TDM to update periodically but not updated by captain side data.
Could you, AndersG, explain why? And how can I solve this?

Thanks for your help.
Hyde
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Dual control for Boeing 777

Postby Hooray » Sun Apr 17, 2016 3:19 pm

I suggested to use the splash screen for starters, which is even (much) simpler than the CDU.
In fact, originally I suggested to just display a single property (radio altimeter) to ensure that the concepts are understood.
I agree that any complex MFD is too difficult to get working unless you really understand how to replicate properties, but also how to replicate independent MFD instances driven by control properties (usually just switches and mode selectors)
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: Dual control for Boeing 777

Postby Hyde » Sun Apr 17, 2016 3:41 pm

As you see, all the PFD, MCP stby ind, column, thrust lever are working well.
Image

I just wanted to know why /instrumentation/cdu/serviceable variable does not work like others.
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Dual control for Boeing 777

Postby Hooray » Sun Apr 17, 2016 3:54 pm

sorry, there is no way for me to tell you, except for loading the 777 and looking at the code in question, which I cannot do at the moment - which is why I suggested to simply load a static texture from $FG_ROOT and see if that shows up properly, if/when it does, I would take it from there and re-add relevant parts of the CDU/ND code respectively.
In the case of any Canvas MFD, you really only need to propagate relevant state changes, such as mode/range changes - which means that you will typically only need to update a handful of properties.

PS: sorry, I don't know/remember if Gijs' original ND code ever honored the "serviceable" flag or not - if you think that it's related to this, I would suggest to grep the ND sources for the corresponding property name/s - but I think most of this is predating Canvas avionics by many years, i.e. it's legacy stuff due to hard-coded avionics like the agradar/wxradar and other od_gauge based displays.
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: Dual control for Boeing 777

Postby Richard » Sun Apr 17, 2016 3:58 pm

Hyde wrote in Sun Apr 17, 2016 12:16 pm:These are implemented using nasal. All other indicators including MCP are xml and executed from Models/777-xxx.xml which is invoked from MP.
Nasal program is invoked from 777-fo-set-common.xml that causes different memory entity, MP and local.
If so, where can I put to start nasal program or how can I get MP pointer?


Normally the only Nasal available will be loaded from the model xml. The -set is effectively a placeholder for an invisible craft as you'll be sitting inside someone else's MP aircraft. The normal -set file isn't loaded at all. All properties need to be transmitted over MP, so if /instrumentation/cdu/serviceable is missing it'll need to be sent. It's a really strange concept that all of the normal stuff isn't where it usually is. It took me a while to figure out this for the F-14 RIO which I think is done in the same way
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Dual control for Boeing 777

Postby Hyde » Sun Apr 17, 2016 4:15 pm

Rechard,

That's exactly what I thought.
Do you know how to run the nasal program from model xml instead of set.xml?
I see some nasal code in Models/f-14b.xml, is this for that purpose?

Thanks,
Hyde
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Dual control for Boeing 777

Postby Hooray » Sun Apr 17, 2016 4:19 pm

if this is indeed so obscure, it may be a good idea to update the wiki docs accordingly
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: Dual control for Boeing 777

Postby Richard » Sun Apr 17, 2016 9:29 pm

Hyde wrote in Sun Apr 17, 2016 4:15 pm:Rechard,

That's exactly what I thought.
Do you know how to run the nasal program from model xml instead of set.xml?
I see some nasal code in Models/f-14b.xml, is this for that purpose?


I've just had a look to refresh my memory; and it's roughly like this.

The nasal modules in f-14b-bs-set.xml are loaded and do the work of connecting the RIO to the pilot's aircraft. However the mp-network cannot be loaded until the model is loaded (can't remember exactly why, but it has to be done this way).

So the approach to take is to ensure that you use /sim/multiplay/generic/float or /sim/multiplay/generic/int (0..19 of each) to share the important properties over mp. This is the easiest way. If you look at the F-14 you'll see that a whole heap of animations and gauges are connected to the multiplay properties, because these will work either when flying or as an MP aircraft. If you don't want to change the animations then a nasal module inside the co-pilot to copy the multiplay/generic into the right place will work. See backseat instruments for an example of how this is done.

It gets more difficult if you need to transmit more than the permitted amount of parameters (40). Then you either have to start packing using bits, or use one of the string parameters to share the rest. Using the string parameters (as in the F-14 and the F-15) is quite inefficient and it is something that I'm working on fixing so that we have much better interaction between the front and back seats - but the first thing I'll do is to get the key properties transmitted using ints or floats, and then do the rest probably using the Emesary multiplayer bridge that I'm working on.

Oh, and I nearly forgot this, there are three ways that the F-14 transmits over MP, the missiles are done via mp-broadcast (using string[0]), the backseat instruments via string[1] and the normal MP properties. I have no idea why it was done like this (there was probably a good reason at the time); but I wouldn't recommend using either the mp-broadcast or string[1] the way the F-14 does. The missiles will pack nicely into a 32bit int; and the backseat instruments mostly should be in normal properties.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Dual control for Boeing 777

Postby Hooray » Sun Apr 17, 2016 9:53 pm

like you say, it's easy to fill up the number of standard properties - my guess is that the average MFD will typically require at least ~10-20 distinct "events" to be propagated/replicated between different fgfs instances for synchronization purposes - e.g. referring to things like ND range, ND modes and related "state".

Thus, my suggestion would really be to use packing by default or use a separate transport/encoding mechanism (e.g. Emesary).

Conceptually, a Canvas MFD instrument could be integrated with an encoder/transport implementation to automatically encode relevant state and set up the synchronization semantics. Technically, it would even be possible to use the replay/flight recorder config for those purposes (like we talked about in private).

Personally, I don't think we want to have aircraft developers implement such systems manually/explicitly in scripting space, especially not if it can be done in a semi-automated fashion by parsing some kind of markup/configuration file that sets up event channels, message types and update handlers for all cockpit/aircraft related state.
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: Dual control for Boeing 777

Postby Hyde » Sun Apr 17, 2016 11:30 pm

Thank you for your reply.

Fortunately I've finished every required properties are now transmitted correctly to copilot side.
Yes, I used most of int and float.
I can see all transmitted property not aliased one is in /ai/models/multiplayer. Aliased in the xml program is in the local property on the property window.
Confirmed they reflect the pilot changes.
String data is not displayed though. It may be a bug.

Problem is, as I and Rechard said, nasal program is invoked from fo-set.xml then referring local property. Not /ai/models/multiplayer property. That's why it displays local vacant aircraft data.
Can't we change property root automatically from / to /ai/models/multiplayer for nasal?

Hyde
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Dual control for Boeing 777

Postby Richard » Mon Apr 18, 2016 12:19 am

Hyde wrote in Sun Apr 17, 2016 11:30 pm:Can't we change property root automatically from / to /ai/models/multiplayer for nasal?


This is known in the model.xml file; that's what cmdarg is - the root for the model but this isn't going to get into the nasal unless you load the nasal from the model xml and pass it in (I know this works because I've done it just recently); the nasal can then either find the path from the cmdarg or just use .getNode and .getValue

With the F-14 RIO we know the pilot node (as it is selected in backseat.nas), so you could in here loop around and copy the properties into the root tree.

What you can't do is load the nasal in the -set.xml and then automatically find out the cmdarg from the model, as there could be multiple models loaded so the only way is to know the callsign or load the nasal and pass the cmdarg; but this isn't necessary if you've selected a pilot node.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Dual control for Boeing 777

Postby Hyde » Mon Apr 18, 2016 3:05 am

Code: Select all
      <![CDATA[
         var self = cmdarg();
         #print("LOAD 777 ", self.getPath());

         # Load the needed modules if it hasn't been done yet.
         if (!contains(globals, "cdu")) {
            var fn_cdu = resolvepath("Models/Instruments/CDU") ~ "/boeing.nas";
            # print("Loading 777 CDU nasal from ",fn_cdu);
            io.load_nasal(fn_cdu, "cdu");
         }
         if (!contains(globals, "b777")) {
            var fn_ND = resolvepath("Models/Instruments/ND") ~ "/ND.nas";
            if (io.stat(fn_ND) == nil)
               fn_ND = resolvepath("Aircraft/777/Models/Instruments/ND") ~ "/ND.nas";
            if (io.stat(fn_ND) == nil)
               fn_ND = getprop("/sim/fg-root") ~ "/Aircraft/777/Models/Instruments/ND/ND.nas";
            # print("Loading 777 ND nasal from ",fn_ND);
            io.load_nasal(fn_ND, "b777");
         }

         var livery_update = aircraft.livery_update.new("Aircraft/777/Models/Liveries-200", 10);
      ]]>

I put this to model xml to load boeing.nas and ND.nas.
How can I pass the cmdarg to nasal program and how to use it?
Can't we use same nasal program for pilot and copilot?

Hyde
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Dual control for Boeing 777

Postby Richard » Fri Apr 22, 2016 1:37 am

you can use the same program - but it'll probably need to be modified. What you do is after loading the nasal is to connect the cmdarg to it.

something like. Note the use of if (!contains) to decide if the module has already been loaded (which should be the case if it's part of the nasal section in the -set.xml

Once you've loaded it you can set a variable (eg. model_root) for use in the module *or* call methods directly.

# Load the needed modules if it hasn't been done yet.
if (!contains(globals, "your_nasal"))
{
var fn_your_module = resolvepath("Nasal") ~ "/your_nasal_module.nas";

if (io.stat(fn_your_module) == nil)
fn_your_module = getprop("/sim/fg-root") ~ "/Aircraft/YOUR-MODEL/Nasal/your_nasal_module.nas";

if (io.stat(fn_your_module) == nil)
fn_your_module = resolvepath("Aircraft/YOUR-MODEL/Nasal") ~ "/your_nasal_module.nas";

if (io.stat(fn_your_module) == nil)
fn_your_module = getprop("/sim/fg-root") ~ "/Aircraft/YOUR-MODEL/Nasal/your_nasal_module.nas";

io.load_nasal(fn_your_module, "your_nasal");

your_nasal.model_root = cmdarg;
# or
your_nasal.do_something(cmdarg);
}
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Dual control for Boeing 777

Postby Hyde » Sat Apr 23, 2016 3:56 am

Thank you, Richard,

Now I confirm that nasal program is running.
I just want to know how to use the cmdarg in nasal program.
Nasal program is like this

Code: Select all
var cdu = func{
        setprop("/instrumentation/cdu/output/title",title);
        settimer(cdu,0.2);
}

_setlistener("/sim/signals/fdm-initialized", cdu);

var copilot = func(v){
    cdu();
    print("start copilot cdu", v.getPath());
}

Since "/sim/signals/fdm-initialized" does not exist I made copilot function and call from model.xml. It works.
Then property is made at "/instrumentation/cdu/output/title".
How to change it at "ai/model/multiplayer/instrumentation/cdu/output/title" using passed cmdarg()?
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: Dual control for Boeing 777

Postby Richard » Sat Apr 23, 2016 9:40 am

Hyde wrote in Sat Apr 23, 2016 3:56 am:var copilot = func(v){
cdu();
print("start copilot cdu", v.getPath());
}


in your copilot(v) above, assuming that v is cmdarg()

v.getNode("ai/model/multiplayer/instrumentation/cdu/output/title").setValue("your-value");

or

setprop(v.getPath()~"ai/model/multiplayer/instrumentation/cdu/output/title", "your-value");

you can of course do something like

var my_root = v.getPath();
setprop(my_root~"ai/model/multiplayer/instrumentation/cdu/output/title", "your-value");

Personally in this case I prefer to use getNode() and setValue(). Usually I prefer setprop (performance reasons), but in this case code structure is the overriding consideration
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 19 guests