• 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 Planner issues

U

upnaway

Messages
87
Country
germany
Hi there,

I am pretty new to scenery design and have nearly finished my first airport.
FSX Planner was/is a great help, but I experienced some things that I like to describe hereafter.

Maybe that the issues actually do not represent a bug, since I'm less experienced with FSX and SDK.


1. ILS coordinates
I added ILS to my RWYs and had to adjust the location for the LLZ and GS in accordance with the airport AIP.
But whenever I tried to alter the coordinates of the glide path, they were set to those of the LLZ!
So when I alter the LAT of the GS, FSX Planner set it to the same LAT as of the LLZ. LON behaves identically.

As a workaround I modified the xml-file directly.


2. Generic Building
Currently FSX Planner seems to be unable to display (at least the coordinates) generic buildings.
Furthermore it seems to exclude gen.bdlg-statements in the xml-file from being translated with bglcomp?! :confused:

I figured this out when I added gen.bldgs manually to the xml file, opened it with FSX Planner and started compiling from there.
After disassembly of the generated bgl file the gen.bldg-statements were gone.



3. Properties of elements (wishlist)
When generating elements like TWYs, parking locations, etc. the properties - like suface, lights, etc. - have to be adjusted for each single element.
That's a very exhausting process!
It would be very helpful if it were possible to mark a group of elements and change the values commonly.

I know the feature of smart taxiway creation, but it does not always work and does not help if I generate a couple of parking lanes, since those aren't in row.



4. Approach legs
The creation of approches is actually rather complex.
As far as I understand now, a leg consists of a Course/Track and a target point (e.g. fix).
The FSX Planner dialog for approach legs confuses me a bit.
The order is just the way round: First the fix to fly to, then the 'track' how to get there.
Furthermore the wording is missledaing. So the word "Distance" is used twice.
I would propose to use the original terms "theta" and "rho" instead.

To be honest, for me it's easier to hardcode the approach data directly in xml.


I just stumbled over a possible bug:
According to SDK the altitude for the leg should be coded in meter.
FSX Planner allows to choose the units meter or feet.
When I alter the dropdown to 'F' the value of Altitude 1/2 changes accordingly.
In case, I'm typing now a new altitude in ft (for instance 4000 ft) and click on "update leg" it turns out, that when re-opening the leg the altitude shows now 4000 M!!!
Obviously the entered value is being saved regardless of the chosen unit.

The problem does not appear with the distance-fields. Their conversion and save-process work properly.



Michael
 
upnaway said:
1. ILS coordinates
I added ILS to my RWYs and had to adjust the location for the LLZ and GS in accordance with the airport AIP.
But whenever I tried to alter the coordinates of the glide path, they were set to those of the LLZ!
So when I alter the LAT of the GS, FSX Planner set it to the same LAT as of the LLZ. LON behaves identically.

As a workaround I modified the xml-file directly.


Michael
Click to expand...


I'm not sure what you mean here. Are you referering to the localizer when you say LLZ? I haven't seen this behavior before.

-Russell
 
upnaway said:
2. Generic Building
Currently FSX Planner seems to be unable to display (at least the coordinates) generic buildings.
Furthermore it seems to exclude gen.bdlg-statements in the xml-file from being translated with bglcomp?! :confused:

I figured this out when I added gen.bldgs manually to the xml file, opened it with FSX Planner and started compiling from there.
After disassembly of the generated bgl file the gen.bldg-statements were gone.

Michael
Click to expand...

FSX Planner does not deal with generic buildings, only specific scenery objects.

-Russell
 
upnaway said:
3. Properties of elements (wishlist)
When generating elements like TWYs, parking locations, etc. the properties - like suface, lights, etc. - have to be adjusted for each single element.
That's a very exhausting process!
It would be very helpful if it were possible to mark a group of elements and change the values commonly.

I know the feature of smart taxiway creation, but it does not always work and does not help if I generate a couple of parking lanes, since those aren't in row.

Michael
Click to expand...

Right now you can't select multiple objects. This is on the list though. :)

Can you give me an example of when the smart taxiway creation doesn't work?

Thanks!
-Russell
 
upnaway said:
4. Approach legs
The creation of approches is actually rather complex.
As far as I understand now, a leg consists of a Course/Track and a target point (e.g. fix).
The FSX Planner dialog for approach legs confuses me a bit.
The order is just the way round: First the fix to fly to, then the 'track' how to get there.
Furthermore the wording is missledaing. So the word "Distance" is used twice.
I would propose to use the original terms "theta" and "rho" instead.

To be honest, for me it's easier to hardcode the approach data directly in xml.

Michael
Click to expand...

Yes, approaches are very hard to create. There is a lot of information involved. The words used, such as distance, are straight from the SDK at the moment. Perhaps we'll be able to come up with a better way in the future.

-Russell
 
upnaway said:
I just stumbled over a possible bug:
According to SDK the altitude for the leg should be coded in meter.
FSX Planner allows to choose the units meter or feet.
When I alter the dropdown to 'F' the value of Altitude 1/2 changes accordingly.
In case, I'm typing now a new altitude in ft (for instance 4000 ft) and click on "update leg" it turns out, that when re-opening the leg the altitude shows now 4000 M!!!
Obviously the entered value is being saved regardless of the chosen unit.

The problem does not appear with the distance-fields. Their conversion and save-process work properly.

Michael
Click to expand...

I'll have to look into this. Thanks for pointing it out.

-Russell
 
rf360m said:
I'm not sure what you mean here. Are you referering to the localizer when you say LLZ? I haven't seen this behavior before.

-Russell
Click to expand...

Russell, pls have a look at these screenshots:
Screenshot of ILS before change
Screenshot of ILS after change

Prior to any change you'll find the ILS beam located on the right end of the RWY and the GS transmitter on the left.

When I set the mouse cursor into the field "Longitude" of the GS and then leave the field with <TAB> (with or w/o typing data) the LON-value turns automatically to the same value as of the ILS(LOC/LLZ)-LON. (see ils_issue_after.jpg)
Same thing happens when trying to alter GS-LAT.
Sometimes it occurs that both, GS-LAT and LON, are being set to the values of the ILS simultaneously.

Maybe you can reproduce this behaviour.




rf360m said:
Can you give me an example of when the smart taxiway creation doesn't work?

Thanks!
-Russell
Click to expand...

Regarding the inheritance feature it might be, that I expected more than FSX Planner actually offers.
I've read once again the tutorial and so now its clear that this feature only works if you have a node, that has just ONE TWY connected.
So in most cases this function doesn't help me much further since TWYs usually interconnect instead of being a just line of nodes.
Thus a feature would be very handy that allows to change the properties of several TWY-segments at once. (as mentioned above)

Michael
 
Last edited:
Severe bugs in approach data

Hi Russell,
it's me again.

Yesterday I coded some approach legs directly in XML and converted it sucessful with bglcomp.

Little later I opened this XML file in FSX Planner to edit some other things.
Afterwards I intended to convert the file out of FSXP into bgl. Surprisignly it failed!

According to bglcomp there should suddenly be errors in approach code despite I did not make any changes!

Obviously FSXP altered my hand-coded approach data, which was originally correct and working.

I figured out that FSXP has some bugs in interpreting and writing leg data.

I've spent some expenditure to check the implementation of the different leg types in FSXP against the ARINC spec 424 (p.65, attmt. 5, "Path and Terminator")

Here's the result:
(Shown are the correct attributes of the related leg types)

CI: TM/DST: n/a!
CR: theta: required; TM/DST: n/a
FA: ALT one: requ.
HA: TD: requ.
HF: TD: requ.
HM: TD: requ.
RF: CRS: optional
TF: CRS: optional
VA: CRS: requ.
VD: TM/DST: requ.
VR: theta: requ.; rho: n/a!

(n/a: not applicable)

I hope it's possible to fix these bugs soon, since they destroy correct approach data when the xml file is being saved or converted via FSXP.

Michael
 
You must log in or register to reply here.
Back
Top