• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSX:SE Switching/swapping PFD, Nav & EICAS displays

B

BlueSox14

Messages
45
Country
australia
Hi all,

Sorry, another question from me! This community has been brilliant in helping me progress my default 737 project. Actually I've nearly gotten as far as I want to with it and look forward to putting developing (or hacking?) down for a time and actually flying. Heh heh.

I want to emulate something I've seen in another aircraft I've used - actually the excellent default 737 upgrade by Alejandro Rojas Lucena. What he was able to do was have a couple of clickable buttons which resulted in the PFD, Nav and EICAS gauges switching between MFDs.

So the PFD on the left MFD would then swap to the right MFD and the Nav Display would swap to the left MFD. A couple of different combinations like this were possible.

I've had a bit of a think about how this might've been achieved and thus far, can only put it down to the black arts.

What I do know is that gauges in the virtual cockpit reference the $737_1 file with fixed coordinates in the x file. As far as I know, these coordinates can't be changed or tied to variables within the x file.

The $737_1 file is built within the panel.cfg file. The gauge xmls are placed into the $737_1 at fixed coordinates, and I believe this can't be changed or tied to coordinate variables either.

So all I can think of is that it is the gauge itself that switches to a different type of gauge depending on the variable updated by the click within the virtual cockpit. But this doesn't feel right.

Can anyone shed any light on how this devilry might've been achieved?

Much appreciated.

Trent
 
What about merging the code of the XML files for the PFD and MFD and assigning visbility conditions to each display's parent element?

When cloning the display polygons, mind that, while visibility tags do work for gauge polygons, each clone requires a unique material (with a unique $737...bmp texture) and its own, separate [VCockpitnn] section in the panel.cfg!
 
I have simple and easy way to do this with C++,
my Osprey is implementation a sample, it have 4 screen to dispaly PFD / MFD, from 1 source code. even it from 1 source code, it can work independently
 
Thanks Heretic & Kalong for your suggestions.

I've been at this the last couple of days following Heretics idea about multiple display polygons, or gauge polys.

This has worked really well after assigning visibility conditions to each gauge poly. What's more, after some testing for whatever reason, they all work with the same $737_1 texture, so I wasn't required to create additional [VCokpitnn] sections in the panel.cfg.

To be really clear, I didn't merge the code of the XML files for the PFD and MFD. I just created multiple gauge polys that display both the PFD and MFD in the same space. They're controlled by the visibility tag so I only see one at a time depending on the switches set in the Virtual Cockpit.

Thanks again for the suggestions that has helped me arrive at a solution.

Trent
 
Test if they're clickable (provided that the default 738's panel provides zoomed 2D displays). If they aren't, you'll need the extra [Vcockpit] sections.
 
Heretic, you're absolutely spot on!

The display units aren't clickable (although move around just fine) unless I add additional [Vcockpitnn] sections.

I probably would've been scratching my head about that for awhile if you hadn't had said something!

Is there any appreciable performance penalty on FPS introduced by adding additional VCockpit sections?

Ta,

Trent
 
Just sharing experience, nothing more.

Visibility tagged polygons are also useful for a rudimentary combination of animated rain and working windscreen wipers.




BlueSox14 said:
Heretic, you're absolutely spot on!
Is there any appreciable performance penalty on FPS introduced by adding additional VCockpit sections?
Click to expand...

I think there was back in the day, but nowadays not so much anymore.
 
Ok, I've hit a snag. Initial testing on one gauge that had interchangeable EICAS & Nav Displays using different $737_x textures worked (ie. they were both clickable).

However, when I extend this concept to the three other gauges, I'm having mixed success. It works on some, doesn't work on others and sometimes works on one gauge depending on the VC switch setting, but then when I rotate the switch and another gauge swaps in, the clickability is lost.

I've tried to identify a pattern or some logic as to this and just can't figure it out.

My basic approach at this point is to assign all PFD conditional visibility parts to a new $737_2 texture, Nav Displays to $737_3 and EICAS to $737_4. Panel.cfg updated appropriately. Any non-conditional visibility gauges continue to refer to $737_1.

Are there any other pitfalls I should be aware of when trying to implement this concept?

I came across this interesting discussion where it seems someone was having a similar problem and they found that it was to do with draw order. I don't fully understand it, but here's the link: https://www.avsim.com/forums/topic/256012-fsx-and-gauge-polygons/

The relevant part from the x file of my model shows as follows:

Code: 
    AlphaData  {
      1;
      138.567001;
      "Greater";
      0;
      1.000000;
    }
    ZBiasOverride  {
      0.000000;
    }

Does there appear to be any problems with that in my gauge material?

Any suggestions/feedback will be warmly received.

Ta!

Trent
 
I think you have to Z-Write alpha as well, but I'm not sure what name that setting possesses in .x format files.

And the basic rule is "one panel.cfg VCockpit entry per visibility tag". So if you have three clones of the same gauge polygon. you need a separate $... material, visibility tag and VCockpit entry for each.


P.S: Impressive that you're doing all this in the .x file and with ModelConverter. I would have lost my nerve long ago and simply imported the model into a proper modeling tool at the cost of having to redo animations and materials.
 
Thanks Heretic.

I was initially trying to use 9 visibility tagged gauge polys with only 3 extra [VCockpitnn] sections in the panel.cfg. Having 9 [VCockpitnn] sections has done the trick.

I might release this model as freeware down the track if I can obtain the relevant permissions from people whom I have used their code or gauges...so I want to think about impact on FPS.

I know I alluded to it earlier but does anyone have any insight as to the FPS impact of ten additional [VCockpitnn] sections in the panel.cfg? Keep in mind that this is all in relation to the default 737 so it's a fairly performance friendly aircraft to begin with anyways.

If there is a noticeable performance decrease, can I mitigate that by reducing each of the $737_x textures from 1024,1024 to 260x260?

I tried converting one gauges coordinates earlier today (to the 260x260 format) and mucked it all up! But if I can be sure there is a performance gain to be had, I'll try it again.

Heretic, thanks for your feedback. I was warned several months ago that this project would be time consuming. I didn't realise it would consume quite this much time and probably wouldn't have bothered if I'd known then. Anyhow, it's just about done now and I'm really pleased with how it's all turned out. If I had my time over, I would have invested time into learning either blender or gmax to do all the heavy animation work. As it was all my changes have come about just by editing the .x, .xanim and modeldef files using notepad and testing changes within MCX which is a really stupid and lengthy way to go about things. Definitely not recommended! MCX however is an absolutely brilliant piece of software.

On a positive note, I've learned lots including a bit about quarternion math. Heh heh.

Trent
 
If you ever get into making the gauges themselves, you simply do visibility layers via L:var's and use Enums to set their numbers in showing up.

Example, when the sim starts up, Enum 0 is shown;
(L:Screen Layers,bool) 0 // bootup time

Then have a switch somewhere you click (or gauge, etc) and flip it through enum 0 thru 3 or more.

Then in each gauge (XML) you would have the main gauge you want at the top, and other gauges below it (in that gauges XML code, top of the code or XML sheet), then the other gauges below it in the same gauge. Example, PFD 1, MFD 2, EICAS 3, etc. So enum 0 is PFD, top layer. Below that is the second, MFD, and third is the engines.

Then on the second gauge, you can stagger (mis-match) the stack so that top layer (enum 0) is EICAS, PFD, and then MFD. Then on the third, exactly opposite of these two, so they all show different versions (if you wanted them to) with the same switch.

So many things you can do with 'layered visibilities.'
 
BlueSox14 said:
I was initially trying to use 9 visibility tagged gauge polys with only 3 extra [VCockpitnn] sections in the panel.cfg. Having 9 [VCockpitnn] sections has done the trick.
Click to expand...

:D

I know I alluded to it earlier but does anyone have any insight as to the FPS impact of ten additional [VCockpitnn] sections in the panel.cfg? Keep in mind that this is all in relation to the default 737 so it's a fairly performance friendly aircraft to begin with anyways.
Click to expand...

Eh, don't worry. Unless you're on a stone age PC.

If there is a noticeable performance decrease, can I mitigate that by reducing each of the $737_x textures from 1024,1024 to 260x260?
Click to expand...

If done in the panel.cfg, doing that will reduce the display's resolution.

On a positive note, I've learned lots including a bit about quarternion math. Heh heh.
Click to expand...

Well done, you've exceeded my knowledge (zero) in that area!
 
You must log in or register to reply here.
Back
Top