Scenery Design Bugs and Issues in FSX

[Guest lowellyerex]

I have been attempting to add missing airports to FSX by hand coding xml according to the FSX SDK, then compiling with the bglComp tool. As I come across various issues and bugs I intend to note them in this forum. Some of these may only be a result of my ignorance, in which case if anyone can offer useful advice I'd be delighted.1. Hopeless DocumentationThe first, and biggest, issue I have with the FSX SDK (SP1)is the scant and unhelpful documentation. It maybe ok if you're already familiar with scenery design, but if you're starting from scratch it's a nightmare. The documentation needs more detailed examples of usage, as well as better explanation of exactly what some some of the variables do, and when they are applied. However, by way of a lot of trial and error, I have managed to nut a bit of it out.There are also some errors in the SDK documentation to watch out for. One that tripped me up was example code I copied for adding coms to an airport. The attributes (frequency, type, name) all had capital initial letters in the documentation, where they should have had small letters. That confused my for a while!2. Can't Get the Fuel Trigger to WorkI have spent a lot of time trying to add a refueling trigger scenery object to an airport, without success. An example of the xml I have used is pasted below. No matter what I have tried, I cannot get this code to create a working fuel trigger. I also cannot get triggers to display inside the game by adding the ShowTriggers=0 line to the fsx.cfg file. This may be a bug, or a result of the documentation not mentioning a critical point regarding the coding of fuel triggers.3. Windsock Scenery Object Indicates Reverse Wind DirectionWindsocks placed at my airports (located in New Zealand) using the windsock scenery object indicate the reverse of the wind direction. Existing game windsocks in the same region work as they should.Also, have you noticed how you can't tell the wind direction from the windsocks in general, when viewing them from ground level?4. Approach Legs in the GPS Show True Headings, Not MagneticOh boy did I spend a while trying to work how to program an instrument approach so that it worked as intended. SDK explanation and examples are non-existent. There is only a reference to the definitive ARINC document (424) at the ARINC online store. Cost, a cool US$255!Anyway, I had at least one issue (without documentation, I can't tell if other issues I have are bugs, or work the way they are intended to) with the way the resulting legs are listed in the GPS. Namely, the legs headings are indicated as magnetic headings, but are in fact the true headings. This happens regardless of whether true or mag headings are given in the xml code for each leg. By the way, I'm happy to share what I've learned regarding approach programming, leg types etc. and would also be keen to learn from anyone else with experience in this area. It can be very frustrating, but very satisfying to fly a working approach that you've programmed.If anyone else has discovered issues with scenery design and the FSX SDK, please post them so we can keep each other informed.

[rhumbaflappy 113]

Hi Lowell.Concerning fuel trigers:http://forums.avsim.net/dcboard.php?az=sho...16464&mode=fullI don't think the code has changed from FS9.Dick

[rhumbaflappy 113]

This works for me: The "SHOWTRIGGERS=1" addition to FSX.cfg (SCENERY) doesn't work very well... top-down view shows it somewhat. You need to park in the bounding box for a bit for refueling to occur.Dick

[Guest lowellyerex]

Now there's the great thing about forums; the helpful people who use them. Thanks for that, it works a treat. I suspected that I was missing something about fuel triggers. It emphasizes my point about the documentation though; how difficult would it have been to write "you must specify a bounding box using the vertex element for fuel triggers"? You know, I did wonder how the horizontal active area was set, but had assumed that there must be a standard size for fuel triggers.And guess what, I also solved (mostly) the problem of the reversing windsocks! I had copied some scenery object wrapper code from somewhere else, which had a heading of 180 specified. I probably looked at this and thought the orientation of a WDI probably doesn't matter, as the orientation of the sock part will be set by the wind direction. Fool! As I was making the fuel change I thought "I wonder..." and sure enough, the heading must be set to north - or there abouts. There's still something going on: setting the heading to 0 and setting a wind direction of 360 in the game resulted in the socks indicating a direction of about 334 degrees. The difference is 3-5 degrees larger than the mag variation, so even that doesn't seem to explain it. It can be compensated for however, so I'm happy. Of course, once again, agony could have been avoided by a simple note in the windsock section indicating the importance of the heading value.Thanks again,Lowell.

[jvile 1]

The GPS displays either True or Magnetic headings. It depends on who is writing the code and what leg type is being used. Many don't understand what type leg is suppose to be used with what type approach. A ILS vs a RNAV or a VOR approach use different type legs. If you use the wrong leg type you will get different results when viewing the GPS receiver for headings and distance.There are cerain cases in approach coding that you want the GPS to read Ture headings and in some cases Mag headings. It is all explained in the ARINC 424.

[Guest lowellyerex]

Ah, the elusive ARINC 424! If anyone has a copy they can lend me please let me know.I don't know exactly what type of legs to use, I have just experimented until I can get the aircraft to fly a suitable approach. I have mixed and matched to a certain extent to achieve smooth turns and intercepts - after all, for the user it's really just about how well the aircraft autopilot can follow the approach, not so much whether exactly the correct type of leg has been used.I went back and had a play, and sure enough, TF (track to fix) type legs display only the true course in the GPS, regardless of whether true or magnetic course has been set in the code. This behavior may well be faithful to the ARINC 424, I don't know. The bug is, that the Flight Sim GPS indicates them as magnetic headings when they are not. Perhaps the approaches in FSX don't normally use TF legs? (I will have to examine some for this error).Indeed, after some fiddling I abandoned most of the TF legs in the GPS approach I was working on. I found the leg from the IF to the FF needs to be a CF type (course to fix) to allow a "vectors" transition to gradually turn the aircraft to the correct inbound course prior to the final fix. I also discovered that transition legs ending in sharp turns can be programmed as FC (course from a fix to a distance) legs. If the distance is set slightly short of the fix-to-fix distance, the aircraft will turn early and turn smoothly past the waypoint. I don't think this is the correct leg type, but it works. When I tried, all CF and TF legs resulted in the aircraft over-flying the waypoint, regardless of whether "fly-by" was set or not.I should note that when I checked, CF and FC leg types indicate the correct mag heading in the GPS when the "magneticCourse" parameter is used. When "trueCourse" is used, the GPS shows the true course (despite indicating that it is magnetic). So far, only TF legs display true course regardless.Lowell

[jvile 1]

LowellMost of what you are doing as been discussed in depth for the past 3 years over on Project AI Afcad forum (how to write approach).The IF/TF combination should be avoided (use IF/CR) if working with ILS Approaches and Transitions. Transitions are not honored by ATC when added to a ILS approach unless they start from a non-terminal VOR. The User plane can select and fly them if not using ATC.Selectable Transitions seen in the ATC voice box must be embedded as part of a RNAV or GPS approach. These type approaches do use the IF/TF leg types where True Course will be displayed. Those approaches must also have their own WAYPOINTS/TERMINAL_WAYPOINTSThe correct combination of leg types (do not mix) is very important to achieve desired results for the User Plane when locked to the GPS/NAV autopilot. Always "LOAD" and "ACTIVATE" the approach code that is written in XML. When the dll processes the XML, changes may occur in the way the approach is drawn on the GPS display. Each leg type in the dll is a independent leg pattern and we are only connecting the dots so to speak which shows a continous path. By default in FS9/FSX some leg type patterns in the dll will not draw properly without tweaking the rho, theta and distance values in your XML.

[Guest lowellyerex]

Thanks Jim, do I sense a touch of impatience? I haven't seen the forum, but have nutted out a GPS approach through trial and error myself. Sometimes I think it's the best place to start as it gives you a first hand understanding of what is possible, especially in a brand new version of FS. For example, you say use IF/TF leg types for GPS approaches and do not mix leg types. Why not? As I said, I started with an IF/TF transition, and eventually ended up with a DF/FC transition which, although not correct in terms of the ARINC 424, gives a much better autopilot track when there is a 90 degree turn involved. In fact I just counted, and in that GPS approach I have used 6 different leg types (could have been 7, but because of the MDH, I didn't need a VA leg for the missed approach - not that any of that matters with no GPS VNAV)! Let me just conclude this by saying this I started this topic to dicuss some potential bugs/issues with the FSX SDK. It turned out that a couple of them were just a result of my ignorance, combined with very unhelpful documentation. However, there is still one that stands. It may be minor compared with the some of the bugs/issues that FSX has, but here it is for what it's worth:True headings derived from approaches (from TF legs or where a true course has been specified)are wrongly indicated as magnetic headings in the DTK column on the Active Flight Plan page of the FSX GPS. Note that they are indicated correctly on the moving map page. This applies to both user added approaches, and the built in approaches. Fly a GPS approach and check it out.Lowell.

[scott967 62]

Lowell, Check this out. Not perfect but of some benefit:http://www.ecacnav.com/downloads/iss3_0.pdfscott s..

[Guest lowellyerex]

Thanks Scott,That is an interesting document, something to ponder over breakfast!Lowell