Hi,
SimDirector and the FX Tool are useful for object and effects placement and I appreciate them. However, most of what is needed for editing airport records (Facility records) assumes some use of GIS tools such as Global Mapper, QGIS, or ArcGIS. This is okay, but there are other tools (from previous incarnations of ESP/FSX) that provide a better developer experience for airport editing (such as SceneBuilderX and Airport Design Editor. These tools are great, but they are not really supported for the P3Dv5 platform, particularly since 2020, as the authors have disappeared or have no time/interest in maintaining their tools to keep up with the evolution of Prepar3d.
The 3rd party landscape seems to be changing and Prepar3d could really use some additional tooling to support those who want to create higher realism in the airport environment. Frankly, P3Dv5 was a regression in this regard as many/most placements for objects, markings, parking, etc. in the 25,000 default airports is very grossly approximate.
It would seem that so many other improvements in the codebase are visual in nature, why not improve tooling for what is seen in the simulated world? There are two things that the Laminar Research X-Plane platform does exceedingly well and I write this to encourage Lockheed Martin to consider providing similar facilities for those of us who want to extend/customize the Prepar3d environment.
One would be an airport/facility editor with some reasonable default assets. Have a look at what is possible using default tooling for the upcoming XP12 here: https://forums.x-plane.org/index.php?/f ... nt=2378882
Second, the scenery gateway for X-Plane is a wonderful way to leverage the talents of those willing to put in the time to improve the default world. Presently, the default world is very much frozen in time in many key regards. For instance, I appreciate that many of these assets have actually been updated with respect to underlying data for vector features (roads, landclass, coastlines, etc.). However, despite all default textures being updated to PBR (thank you), the assets for the direct airport environment needs improvement. Better tooling would assist in this regard, particularly if it is accompanied with a repository of work.
I am not sure what the status of the Prepar3d franchise is, or where it is headed, but the tools that I am suggesting here could really provided extended utility and life for the platform.
Prior to its commercialization for the training/pro context that Prepar3d serves, the roots of the FSX/ESP codebase was enhanced as much from community contributions as not. However, for the last 15 years, all have come to expect that a vibrant 3rd-Party commercial contingent would take care of enhancements. My own experience as a consumer suggests that this is no longer the case. While there are some who appear to continue support for Prepar3d (iFly's 737 is a good case in point), many have moved on to new markets.
It would greatly help those who intend to remain within the Prepar3d ecosystem to know a few things: 1) some commitment exists to continue the product, and 2) developer support will improve.
It would seem to be that even higher-end (professional) users of the platform very likely depend on some pipeline of knowledgeable/skilled developers for the platform to be available for continued benefit for the primary use case for the platform. I would propose that this pipeline would be enhanced if the developer tooling received some care moving forward. I do not think that the same ground rules are in place now as opposed to the beginning of the Prepar3d product as an extension of the ESP cosebase for professional/educational use. The pain involved in using the toolset is greater now than many alternatives and the subject matter expertise is very likely increasingly lost. Even if the existing developers will remain, I would expect that costs for professional customers could be lowered if improved tooling attracted more developers.
Tutorials and how-tos for the tooling that come from Lockheed Martin are scant and perhaps was less necessary during the "salad days" of the 2010s. The documentation, while extensive, has many dead-ends, cul-de-sacs, and other shortcomings that make it very difficult for a new developer to get going. Here is a case in point: https://www.prepar3d.com/SDKv5/sdk/worl ... icBuilding
That documentation mentions a texture id for bottom, roof, and side textures and suggests that the reader: "Integer. See Generic Wall Textures." This is a dead-end as no reference for this exists. The only way to make sense of this is to coerce Google and then find 15-year-old out-of-date references to how folks might have made this work in FSX.
I think there was a time when Prepar3d relied on FSX expertise because Prepar3d was able to take the ESP codebase beyond its origins and the community followed. As a result, all of the dark arts and end-user tooling that were necessary for a broad set of contributions remained status quo. Maybe nobody bothered with this because few intended to use default airport environments anyhow. If both commercial and freeware extensions to the platform evaporate, then I am concerned for where that leaves those of us who might like to continue using the Prepar3d platform.
Anyhow, it is my sincere hope that those on the LM development/support team who do seem to check in on the forums regularly will have seen this, read it (thanks for doing so), and consider the points being made.
Thank you.
