Dual control for Boeing 777

[Hyde]

Thank you Richard,

I could run the nasal program but couldn't display anything. I've given up.

I'd like to switch the gear.
Can't we invoke nasal program from inside of model.xml?
All other xml programmed instruments are executed from model.xml.
Nasal programmed instruments are not even it is part of model.

Impossible?

[Richard]

I could run the nasal program but couldn't display anything. I've given up.
Can't we invoke nasal program from inside of model.xml?

If you make a temporary branch and drop me an email with details about what exactly to do I'll have a look.

You can load a nasal module from within model.xml; most of the following is path resolution logic, it might not actually be required as it comes from when fgdata had aircraft (and particularly the F-14 which this is based on).

Code: Select all

            var self = cmdarg();
            print("Model load F-15 ", self.getPath());

 # Load the needed modules if it hasn't been done yet.
            if (!contains(globals, "f15_net"))
            {
                print("LOAD F-15 mp network", self.getPath());
                var fn_net = resolvepath("Nasal") ~ "/mp-network.nas";

                if (io.stat(fn_net) == nil)
                    fn_net = getprop("/sim/fg-root") ~ "/Aircraft/F-15/Nasal/mp-network.nas";

                if (io.stat(fn_net) == nil)
                    fn_net = resolvepath("Aircraft/F-15/Nasal") ~ "/mp-network.nas";

                if (io.stat(fn_net) == nil)
                fn_net = getprop("/sim/fg-root") ~ "/Aircraft/F-15/Nasal/mp-network.nas";

                print("Loading F-15 mp network from ",fn_net);
                io.load_nasal(fn_net, "f15_net");

                # Initialize network as observer.
                f15_net.mp_network_init(0);
            }


You can load the Nasal from your copilot-set.xml, or you can load a nasal module from the model, you can setup timers, invoke methods and pretty much do anything that is required.

[Hyde]

Yes, I understand nasal can be run but I don't know how to correlate the program and model object.
Canvas ND displays on "ND.screenL" and "ND.screenR" but which model.
If I run the nasal from fo_set.xml that object is related to not rendered copilot side model.
How to specify that object is related to MP.

Anyway, I push my change to dualctrl branch.
I'll take small rest to cool down my brain.

[Hooray]

in general, even variables with the same name, and even namespaces, will have a different meaning in a dual-control/multiplayer environment, where different Nasal interpreters are involved, i.e. each master/slave will typically be its own process - so, you explicitly need to map entities between the captain-set.xml and copilot-set.xml via "bridges" like cdmarg(), which is just a mechanism for getting the property root of a XML-based Nasal script, so that you don't have to do any manual housekeeping, but you could also use explicit naming conventions or a dedicated API for matching up properties between different clients.

Thus, cmdarg() is generally the recommended/standard mechanism for a Nasal script to determine its property-level context, e.g. what AI/MP model it is referring to, or even what CanvasWidget it is referring to (e.g. in a PUI dialog)

Anyway, I find it hard to follow your postings, because you are leaving out crucial details, even just the terminology - i.e. captain/copilot instance and the way the Nasal code is loaded and the way the 3D models are added to each cockpit.

In general, I would re-iterate my suggestion to use a much simpler Canvas code snippet for starters and then take it from there, you will find that you can really leave everything "as is" - the only thing that will differ between different instances is that you obviously have different Canvas textures, and Nasal interpreters, running in each process - so that the handle for the Canvas texture in process 1 (captain) may not necessarily match what process 2 (copilot) is using for the instrument - but that does not matter, you can manually assign a Canvas to an instrument.


Honestly, I am not going to be able to look at all the 777 markup/code or start it to see what is going on, but if you can suggest (or come up with) a really simple aircraft like the ufo or the ogel, we could use that as the testbed for demonstrating how to synchronize a Canvas between multiple instances, e.g. in a dual-control fashion - I don't know if there is any aircraft less complex than the ufo, or maybe one with an actual cockpit ?
But even a livery could be Canvas based - so we don't necessarily need a cockpit, and it may be much easier to demonstrate what needs to be done this way, because the number of necessary changes would be fairly small - e.g. some kind of dual-control ogel ?

Depending on Richard's plans for his Emesary work, he may also benefit from having such an environment to test/demonstrate the approach.

Another option would be using one of the ground vehicles and adding a Canvas based gauge to it to synchronize that.

[Hyde]

Horray,

As you said, I made simplest canvas nasal as

Code: Select all

var placement_left = "ND.screenL";
var placement_right = "ND.screenR";

var my_canvas = canvas.new({
  "name": "canvas-test",   # The name is optional but allow for easier identification
  "size": [1024, 1024], # Size of the underlying texture (should be a power of 2, required) [Resolution]
  "view": [1024, 1024],  # Virtual resolution (Defines the coordinate system of the canvas [Dimensions]
                  # which will be stretched the size of the texture, required)
  "mipmapping": 1      # Enable mipmapping (optional)
});

# Place it on all objects called ND-Screen
my_canvas.addPlacement({"node": placement_left});
my_canvas.addPlacement({"node": placement_right});

var group = my_canvas.createGroup();


var showNd = func(pilot='cpt') {
   if(getprop("sim/instrument-options/canvas-popup-enable"))
   {
      # The optional second arguments enables creating a window decoration
      var dlg = canvas.Window.new([400, 400], "dialog");
      dlg.setCanvas( my_canvas );
   }
}


This displays real canvas only and it's displayed correctly as black plane.

You can see canvas as black plane on Pilot side.

But on the Copilot cockpit, it displays ND.screenR object only. No canvas screen,
I'm asking how can I display it. Only canvas screen.
Nasal program is invoked from fo_set.xml.

[Hooray]

Is it the same/identical cockpit (UV/texture mapped screen) ?

Are there any warnings/error messages shown ?
See the "status-msg" properties for the corresponding Canvas, and placement of the Canvas: http://wiki.flightgear.org/Canvas_Troub ... vas_Status



Regarding the black screen, I would at least show a splash screen or change the background color for troubleshooting purposes and maybe render the aircraft name, using something like this:

Code: Select all

var imgSize = 120;

# path is relative to $FG_ROOT (base package)
var path = "Textures/Splash1.png";
# create an image child for the texture
var child = root.createChild("image")
    .setFile(path)
    .setTranslation((width-imgSize)/2, (height-imgSize)/2)
    .setSize(imgSize,imgSize);


var text=root.createChild("text")
      .setText(getprop("/sim/aircraft"))
      .setFontSize(24, 0.9)          # font size (in texels) and font aspect ratio
      .setColor(1,0,0,1)             # red, fully opaque
      .setAlignment("center-center") # how the text is aligned to where you place it
      .setTranslation(width/2, height/2);     # where to place the text


The Canvas texutre should then look like this (without the GUI decoration):


(you could also add the status-msg to the screen for each pilot & display and use the aircraft's splash screen instead of a fixed splash - that way, it will be much easier for us to corellate your screenshots with the -set.xml you are using)

[Hyde]

Edit:I forgot to answer your questions.

Is it the same/identical cockpit (UV/texture mapped screen) ?

Are there any warnings/error messages shown ?

Yes, I'm running same program on one PC.
No error or warning is shown.



Can you find anything?
I think canvas is working well. Just can not be displayed on object.
Back ground color is different but does not matter, I think.

[Hooray]

How did you create the popup dialogs, manually or by clicking by the Canvas screen ?
Have you looked at the property tree (in /canvas/by-index) and checked the status-msg properties of the canvas and its placement ?
Like you say, the color should not matter, unless it's totally transparent (alpha) - but you definitely be able to exchange the static texture, unless there is something else going on, which is why I asked about console/log file errors/warnings.

To check if your code is working correctly, change it so that it uses the screen on the right where the PFD is shown - if that works as expected, your code is fine. Next, I would suggest to check that the 3D model/instrument is textured and UV mapped correctly.

You could also run both aircraft side-by-side and then use the property browser to compare the canvas textures side-by-side, i.e. the size/view properites and the status/placement properties.

It's probably something really simple/stupid, e.g. a typo somewhere or something like that - so that the texture cannot be replaced.
So, don't give up - if the aircraft were less complex, I could also try it, but I don't have an up-to-date sg/fg build system that would be able to run the 777, let alone two instances of it. The build system that is more or less set up to build sg/fg from source is an old netbook I once used for Canvas testing, so I cannot help directly with troubleshooting unless we can come up with a reduced test case, or if you continue to post screenshots and URLs to code/XML you are using.

You could also run a diff of the 3D/.ac files and 3D XML files you are using, side-by-side.

So, if in doubt, wait for Richard or someone else to provide feedback based on testing your changes, because I may be missing something really obvious...

PS: I only asked to change the background color for each aircraft, so that we can more easily tell what we are looking at - so the whole point was to assign an aircraft-specific texture (splash) to the screen, and show the -set.xml name and status properties, so that the screenshots are more self-explanatory, as it is otherwise difficult to tell what we are looking at.

[Hyde]

I find one difference in the property window.
/canvas/by-index/texture[1]/palcement/status-msg
Pilot side is"Ok"
Copilot side is "No match"
This makes sense.
Both has Node="ND.screenL"
Then what should be for Copolot side?

[Hooray]

looks like you have found something helpful finally
if the errors shows up after setting the placement, it has to do with that - i.e. it could not replace the texture, e.g. because it's using the wrong handle for the object and/or texture itself.

If in doubt, post your ND.nas equivalent for the aircraft not working (dual-copilot-set) - but like you said, it's a rather simple thing apparently, i.e. it cannot replace the texture, so that only the dialog works properly, because that is basically using a different/independent placement mechanism

good job so far

[Octal450]

I know I'm not good at all with Canvas yet, but shuoldn't the copilot be ND.screenR?

Since the pilots side is ND.screenL?????

Regards,

[Hyde]

I know I'm not good at all with Canvas yet, but shuoldn't the copilot be ND.screenR?

Since the pilots side is ND.screenL?????

Regards,

I meant Pilot side ship and Copilot side ship. Both has ND.screenL and ND.screenR.

[Hooray]

to be fair, I also struggled with the descriptions, which is why I asked for screenshots, and for different background colors/splash screens to be shown, so that it is easier to tell what we are looking at - it really is easy to confuse things, especially when both aircraft (which are the same...) are showing the same viewpoint/instruments

[Octal450]

Hmm OK

I saw you placed another canvas item on the screen?

So its the actual nav display part thats not working? Maybe some dependency issue...

[Hooray]

no, it seems that the only thing not working is the texture re-placement on the copilot aircraft, and copilot side - like Hyde said already, the Canvas itself seems to be working correctly, it just doesn't show up - which could be due to texturing/UV mapping, wrong identifier or some other minor issue - I already suggested a few postings earlier to check if the PFD can be mapped to that screen and vice versa to troubleshoot this further - at that point, Hyde will know where to look for the problem, i.e. if the PFD shows up correctly, it's obviously unrelated to UV mapping.