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

Paddles-LSO

There must be a 2. file where some of the variables will be calculated

(L:GS_Deviation, number)
(L:CentreLine_Deviation, number) and so on
 
Are you referring to the FDO.xml as the 2. file? It works perfectly for the Swordfish it was designed for but not on the AH F3F I have to wait as I said for Scrubbs to complete the conversion of theCFS2 mdl to native P3D V4.5 because the gauges in the previous version of it don't work being FS9 or even FS98. You can download the Swordfish here if you would like to try and help
Download Swordfish
 
I don't own the Swordfish. So I gave you the link above. It works perfectly and does NOT need an ILS with the FDO.xml which you can open up from the swordfish panel. Only when I try and use the lso.xml and FDO.xml in any other aircraft with aicarriers do they not work the LSO just stands in the window with his arms outstretched. It has to be tested with aicarriers. I am using P3D V4.5 because though I have FSX my Dell/Windows10 does not work perfectly with the SP2 installed which is required by most programs to work within it. Thank you so much MS for your socalled improvements. My opinion of it. I do have the developer's written permission to modify the LSO gauge to work with other aircraft if we can get it to. The ACES xml is way beyond me.
 
Last edited:
The LSO standing on the carrier deck needed some vital information carried in the 3 L:VARs

(L:IsFlashTime, bool)
(L:GS_Deviation, number)
(L:CentreLine_Deviation, number)


I hadn't actually tested the gauge using these variables since the original computing gauge was not available.

So, just for fun and since I didn't have anything else urgent to do, I amended one of my standard gauges I use for testing within P3DV5 (I've had it since FS2004), a clipboard of sorts, so that it allowed me to assign values to those 3 L:VARs.

I made a video of P3D showing these L:VARs being altered.

The values of the L:VARs are shown on the clipboard.

I had been messing about with an old FSX C172 for a different reason so, since it didn't have to fly for this test, or land on the deck of a carrier, I left it parked there.

The value in (L:CentreLine_Deviation, number) is immaterial when the value of (L:IsFlashTime, bool) is 1.

I first set the Var (L:IsFlashTime, bool) to 1.

With (L:GS_Deviation, number) set to 0, the LSO is in the ROGER (OK) Position.

I decreased the value of (L:GS_Deviation, number) from 0 to below -0.5, when the LSO assumes the LOW (Climb) position.

When I increased the value of (L:GS_Deviation, number) to above -0.5 the LSO resumes the ROGER (OK) Position.

Increasing the value of (L:GS_Deviation, number) to above 0.5 the LSO assumes the High (Descend) Position.

Further increasing the value of (L:GS_Deviation, number) to above 1.0, the LSO assumes the Waveoff Position.

I'm not too sure what he would do at that stage...

I then set (L:IsFlashTime, bool) to 0.

The value in (L:GS_Deviation, number) is immaterial when the value of (L:IsFlashTime, bool) is 0.

I set the value of (L:CentreLine_Deviation, number) to above 1.00 and the LCO moved into the Tighten Turn Position.

Resetting the value of (L:CentreLine_Deviation, number) to 1.00 the LSO resumed the ROGER (OK) Position.

This test reassures us that if something happens to update the 3 L:VARs then the LSO will react.

By the way, I had to alter some of the <Visible> conditions in the gauge to prevent situations where the LSO was either armless or spiderlike - I presume if the values were changing rapidly in a small gauge these anomalies might not be visible.

Anyway, here is the video:



Walter
 
That is beautiful. Are you going to provide me with a gauge that I can add to my aircrafts that will work like it's supposed to? We still need to have the FDO.xml in the panel also so that the LSO detects the aircraft is within 5 miles and 30 degrees of the carrier's centerline. If those conditions are met at least in the Swordfish then he pops up in the cockpit window. I hope that it wilolo work like your gauge does in all my aircraft. I have permission from the designer to modify this and share it FOR FREE of course so a package can be put together that can be used in any USN carrier aircraft from 1930 through 1960. A really nice addition to virtual carrier aviation since VLSO was created. From what I can see it is no longer downloadable so I am very glad I archived mine.l
 
'fraid not. I've had a look at the original gauge, wow, it is way beyond me! I have a headache even from reading it. It seems to use infomation from the TrafficInfo gauge which I remember used to be vital to Radar gauges in FS9. :)
 
I know, it's written in ACES xml NOT standard xml like most gauges are. I even had a look atthe P3D SDK and my mind went spinning there. Maybe Eduhir who jumped in above can make sense out of it after reviewing your latest post to work with all carrier aircrafts. Very disappointing. I am nothing but a very very simple xml and SODE writer and almost always have to have the online checker show me where I missed or misplaced something. We can always hope for a new developer to hop in to this thread sometime too. Thank you for taking all the time you have spent. In the meantime, I am just going to fly from and to ground airports like I did yesterday: KMGW to KSUT both airports that I developed for P3D V4 with the help of Sketchup 2017, MDCx and ADE. I flew the Milviz Beech B58 they so graciously made freeware, a really nice aircraft. Used REX Sky 3d for real weather too. Nice 2.4 hour flight even when it rained and saw a few snow capped mountains on the way being November now. The Blue Ridge mountains are just a few hours away from where I live here in North Carolina. I have a post in SOH about KMGW developing its sloped apron which truly was a challenge.

Richard
 
Last edited:
I am interesting to have a look at this file. Looks like an interesting solution!!
So can you post here this file?
And can you post the name of the carrier or traffic name?
I am on P3Dv6.

Walter, your video looks nice:)
 
...had a thought just to try...I put the USN LSO xml code into the Swordfish panel with the USN bmps to see what would happen. In P3D V4.5 the Swordfish immediately located the CV6 USS Enterprises in aicarriers and popped up the LSO in the corner just as the FDO.xml should. The LSO has his hands up and other hands waveoff at the same time so that would need to be fixed. He otherwise directed the pilot left...left...too low and I was able to land the Swordfish and catch the first wire. Here is a screenshot ondeck which means that basically this works with the Swordfish just fine even the new code with a fix. So now the challenge is to make it work with other aircraft.

Swordfish ondeck.jpg
 
I searched in the xlm files for this variables
(L:GS_Deviation, number)
(L:CentreLine_Deviation, number)

none of the varible could be found!

You mentioned FDO.xml
There is no FDO.xml in the panel folder and no entrance in the panel.cfg
Could you post this FDO.xml and your panel.cfg.
 
For some reason, the email notifications for this thread got turned off. Sorry, I was not ignoring you and really appreciate you taking the time to help. Here is the whole panel and the FDO.xml separately (it is in the swordfish folder).
 

Attachments

  • Files Requested.zip
    1.1 MB · Views: 45
Thanks for posting!
very interesting. Like it! And a lot of possibilities to improve:stirthepo


At the panel.cfg in [Window02]
FDO.xml is missed.

Also i found that the LSO - panel is opened if you are in the range of the glide slope and will be closed if you are off!

Code:
                <Macro Name="LSO_ON">(L:LSO, bool) 0 ==
                            if{
                            (&gt;K:PANEL_4)
                            1 (&gt;L:LSO, bool)
                            }
                            els{
                            }
                            </Macro>
                <Macro Name="LSO_OFF">(L:LSO, bool) 1 ==
                            if{
                            (&gt;K:PANEL_4)
                            0 (&gt;L:LSO, bool)
                            }
                            els{
                            }
                            </Macro>

As far as i remember K: PANEL_4 uses [windows03]
you maybe have to test it!

delete
[windows02]
.
..
.
.
-----------------------------------------

the new [windows03]

XML:
//--------------------------------------------------------
[Window03]
Background_color=0,0,0
size_mm=128,128
window_size_ratio=0.200
position=2
visible=1
ident=10004
window_size= 0.290, 0.295
window_pos= 0.050, 0.190

gauge00=Swordfish!LSO.xml,  0,0,128,128
gauge01=Swordfish!FDO.xml,  0,0,1,1

//--------------------------------------------------------

Don't forget to copy the FDO.xml into the   Swordfish - folder


[Window Titles]
rename    Window02=LSO   to   Window03=LSO


describtion from the FDO.xml

//-- Search for ships with catapults
//-- and store Vehicle ID
//-- NOTE will stop at the first carrier it finds!!

for an other carrier you have these variables to adapt
//-- Set variables for specific carriers
//-- FLIGHTDECK = Height in feet
//-- FLIGHTDECKOFFSET = landing point distance from model centre in nautical miles, +ve to stern
//-- FLIGHDECKOFFSETANGLE = landing point bearing from model centre, 0 deg ship's head
//-- FLIGHTDECKALIGHNMENT = Angle off landing deck from centreline, -ve to Port

hope it works!
 
EduHir,
I didn't understand why the Window02 should be deleted and Window03 put in place so just to test, I just replaced the original Window02 copy with yours and it works. I didn't change any values in FDO.xml and just used Enterprise which the original Swordfish recognized. The F3F gauge didn't recognize the carrier but I remember reading from original Swordfish readme just to SHIFT03 and popup the LSO and that worked and he directed the F3F into the carrier but this pilot was not adept to hook a wire so I had to bolter. Satisfied that it works, I am going to see what I can do now like using Walter's rewrite and see how that works and compare it for differences if it doesn't and then use the waveoff too. Thank you for all your help. More posts here as I progress. Phil the original designer is also supposed to revisit it so I will stay in touch with him too.
 
As i wrote above, there is no need to use shift-03 because if you are in der range of the carrier it will popup automatically!!
But you have to adapt window[..] or K: panel_x !

This is the code for opening the panel!
Code:
                <Macro Name="LSO_ON">(L:LSO, bool) 0 ==
                            if{
                            (&gt;K:PANEL_4)
                            1 (&gt;L:LSO, bool)
                            }
                            els{
                            }
                            </Macro>
                <Macro Name="LSO_OFF">(L:LSO, bool) 1 ==
                            if{
                            (&gt;K:PANEL_4)
                            0 (&gt;L:LSO, bool)
                            }
                            els{
                            }
                            </Macro>

But of course you can change
XML:
    (&gt;K:PANEL_4)      against   (&gt;K:PANEL_3)

as far as i remember  window00 is linked to  (&gt;K:PANEL_1)

so window02 is  to   (&gt;K:PANEL_3)
and
so window03 is  to   (&gt;K:PANEL_4)

so you can change   [window..]    or  (&gt;K:PANEL_x)

it's up to you!

one probleme, different solutions  as always!

As i wrote above it's a very nice gauge, but nevertheless there some improvments are possible
for ex. as you mentioned "wave off" and other things.
 
I remember that there could be a probleme with panel initialisation during aircraft loading.

so move from

[window02]
..
gauge01=Swordfish!FDO.xml, 0,0,1,1

to
[window00]
.
.
gauge..=Swordfish!FDO.xml, 0,0,1,1

Renumber the gaugenumber proper!


.
 
Good catch. Window00 will always load but you can't guarantee that any other window will be active at the time of the aircraft loading. It is possible in C/C++ to force a second (or third or fourth...) window to go active immediately but I have no idea if it can be done in XML. What I have done in the past for a simobject with 2D panels is to devote Window00 to 'systems' gauges and then force Window01 to go active immediately. In a mixed panel.cfg (2D and VC) any systems gauges must go into the VC VCockpit01 window as this is always active (visible or not). In a pure VC with multiple windows you must still use VCockpit01 for anything that has to be active at launch.
 
I'm using an init - gauge at [window00]. So the first 5 secs at aircraft - reload i'm open and close all my panels, about 25 subpanels.
 
Back
Top