- If we code X-Plane to work around the problem, users get to enjoy the scenery, and authors will never fix the problem.
- If we code X-Plane to abort, users get grumpy, and authors fix the problem real fast.
Before WED some authors made apt.dat 850 layouts by hand using a text editor, and sometimes they forgot to include a closing code on their rings and chains. I can hardly blame them, writing an apt.dat file by hand is very difficult, and I am impressed (and grateful) that they did this.
The apt.dat 850 spec is clear:
- Pavement chunks (line code 110) must comply with the following:
- Chunks MUST terminate in a segment point of type 113 or 114.
- Linear features (line code 120) must comply with the following:
- Linear features must terminate in a point of type 113, 114, 115 or 116.
- Linear features do not need to be "closed".
- Airport boundaries (line code 130) must comply with the following:
- Boundaries MUST terminate in a segment point of type 113 or 114.
- Boundaries must be a closed loop and cannot contain holes. As with pavement chunks, the airport boundary cannot overlap itself.
So, you must have one of the closing codes at the end of a boundary, taxiway, or line. But X-Plane 860 doesn't check this and simply assumes a "closed ring" if no code is provided. With X-Plane not telling authors, the authors never caught this mistake.
So now that I know about this (and now that X-Plane needs the end codes to be right, due to other bug fixes) it's time for the spanking system. In future versions of X-Plane:
- Custom scenery packages with no ending code on a polygon block will automatically be adjusted to be "ring"-type on load-in, for compatibility with X-Plane 860.
- A detailed message will be printed per polygon in the log.txt file.
- A single alert box will be shown to the user saying "there is a problem with the custom scenery pack XXX".
No comments:
Post a Comment