We’ve been doing some work behind the scenes to modernize our servers; as part of that, I have moved the scenery tools code to GitHub.

The GitHub public repositories are the official repositories for WED and the other scenery tools that live in the XPTools code base; I push my changes directly there.

using GitHub means much faster clone times (since the server we had the code on was getting long in the tooth), better public browsing, and you can do all of the normal GitHub things that you’d want, like forking, making pull requests, etc.

If you are using our CGIT browsing (at //dev.x-plane.com/cgit/cgit.cgi/) please switch to GitHub; CGIT will be going away soon. Similarly, if you have the code checked out, you should change your remote’s URL to //github.com/X-Plane/xptools.git.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

7 comments on “Scenery Tools Source Code on GitHub”

  1. When are we going to see some specifics and renewed forward progress on the desktop sim, Ben?

    The scenery tools code is of interest to a very narrow audience. Who cares about digital download difficulties in the larger community? I can see why you’d continue to work on Blender scripting — but the core sim’s needs are still calling out for more attention. This is what I see in the past several months, off and on, in these blog posts.

    There are major areas that still need work. ATC. Clouds. Distant view of the global terrain mesh. Seeing terrain through mountains. The OBJ particle generator that’s been teased. The sound engine that is currently lagging lightyears behind what we should have had years ago. Things that have been started, but left incomplete, some since the sim was released, not to mention the raft of instrumentation in Planemaker that’s good for XP7 or 8, but hardly worthy of XP10.

    It’s frustrating. This is OT from your post, but I have to express this frustration since I watch daily for new blog posts, hoping to see. As a loyal X-Plane user and proponent, I would really appreciate seeing Laminar Research development focused on their product, not ancillary items. How about it, my friend? I know you don’t talk about the future as a matter of policy, but where we see meandering away from the mainstream of the sim, we also see potential for dissatisfaction, and with that maybe even a loss of interest in those that tire of waiting for better times for XP10. (Not me! I’m going to be around forever! 😉 ). Apologies for not keeping this to myself. I know you have a very lonely, very difficult job. I hope this has been constructive.

    1. Hi Steve,

      I’m constrained in my posts on the dev blog…I don’t post about:
      – Work that’s being done that is too low level and not user-facing and therefore won’t make any sense.
      – Features for the sim itself that are not yet done and therefore may not ship. If we tease a feature and then it doesn’t ship for some reason, that patch becomes about “hey you promised us birds that poop on the windshield and I don’t see any bird poop” instead of what we DID ship. I have seen features that we thought would be ready end up not being ready for lots of reasons.
      – Features for the next major version of the sim. We don’t want to talk about the next major version way in advance and kill sales of the current version; current version sales fund the development of the next version.

      By comparison, the scenery tools are all open source – so I can post about them at any time.

      The result is going to be a bias in what you read toward smaller features and dev tools. It doesn’t mean work on the sim isn’t happening – it means I’m not going to talk about it until it’s ready to ship.

      Finally, I -hope- that one of the major audiences of this blog is -third party developers-; I try to post complete and up to date information about third party development issues and tools to keep third party developers up to date.

      My next post is probably going to be about 64-bit WED. If you don’t use WED, you probably don’t care. But if you _do_ use WED and you’ve been seeing WED crash due to out-of-address-space problems, and you can’t complete your custom scenery due to this problem, it’s pretty much the best news ever.

  2. Ben,

    I appreciate the discussion of the bias, not to mention the understandable concern regarding sales. I hadn’t even thought of that, but I can relate. Perfectly understandable, and it removes a bit of the angst and impatience. But as someone who’s been dabbling in third party things too, this blog is quite interesting and informative regardless. Those posts you have shared regarding features have definitely spoiled me.

    One thing I’d appreciate an update on in a blog post sometime soon would be the state of the SDK. Given there’s likely new functionality that could be exposed, especially with a guy like Phillip wrangling code for LR. It would be good to know about where that particular train might be going. Sure wish someone would take over for Sandy Barbour. We dev’s miss the guy!

    1. Yes, if it’s reasonable code! If you’re not sure about what whether what you’re doing is appropriate for the master copy of WED, email me with a brief proposal for the mod and I can tell you if there’s a reason why we wouldn’t take it.

      (For example: “I plan to make WED show Google map tiles!” would be an “I’m not taking that” due to the copyright infringement problem. “I wrote code to import OSM data” would be “sure, we’ll use it!”)

      1. Sounds perfectly reasonable!

        What version of X-Code are you using to compile on Mac? I ran into quite a few bumps compiling with the current version; it may make sense for me to wait for you to finish modernizing the mac code before I really look at contributing.

Comments are closed.