Category: Development

Art Controls Are For Hacking

Sidney posted a detailed write-up a few days ago as to why developing an add-on by modifying our shaders is not a good idea. The short version is that, like art controls, the shaders are an internal part of X-Plane that we don’t lock up so you can see them and muck around with them. But there is no stability, documentation, or any attempt to make them useful the way the plugin system is.

This confused a number of commenters. Do we want you to use them or not?

To resolve the mixed messages, Sidney created this fantastic flow-chart.

Hopefully that clarifies where the line in the sand is between “I was poking around” and “I made a serious add-on”. Pretty much everything here goes for the shaders as well as the art controls, only more so.

Posted in Development by | 24 Comments

Our shaders don’t like to be touched

X-Plane has always shipped with the shaders visible to everyone as plain text in the Resources/shader directory. Partly this was due to making it convenient to load the shaders into OpenGL itself, but we also don’t have anything to hide there either so it doesn’t make much sense to try to hide them. You are more than welcome to look and poke at our shaders and if you learn something about X-Plane in the process, that’s awesome!

However, the one big caveat to that is that we never considered the shaders to be part of the publicly accessible interface and they are in no way stable across versions. X-Plane is an actively developed product and we are making a lot of changes to the codebase, including the shaders, so you should never ever distribute a plugin or tool that modifies the shaders. Since we give no guarantee that our shaders will remain stable across versions, you’ll always be left worrying that we might break your add-on.

Additionally, there is a big change to the shader system coming in 11.30 that will definitely break all existing plugins that are modifying shaders. This blog post will cover the upcoming changes and hopefully convince everyone that the shader system is in flux and not to be relied upon as a basis for add-ons. Read More

Posted in Development, Plugins by | 30 Comments

XPlane2Blender v3.5.0-beta.2 is out!

This beta brings in many new bug fixes and heavily requested new features! As with any beta, be aware that this could break your project SO MAKE BACKUPS! We don’t think there are any drastic changes to the data model, but, better safe than sorry.

Bug Fixes

  • #355 – A small UI fix relating to too many manipulator fields being shown
  • #360 – A bug fix for Drag Rotate manipulators giving false negatives
  • #353, #363, and #260 – All relate to warning people and correct what was allowed with NORMAL_METALNESS and BLEND_GLASS. Previously Blend Glass was in the same drop down menu as Alpha Blend, Alpha Cutoff, and Alpha Shadow. Now it is a checkbox allowing you to correctly specify a Blend Mode and apply Blend Glass to it. Existing materials with Blend Glass will see this new checkbox automatically checked. Blend Mode will be set to Alpha Blend or, if your plane is old enough to have been worked on during X-Plane 10, it will be set to whatever it was back then.
    3_5_0_beta_2_blend_glass_checkbox

See the internal text block “Updater Log” for a list of what got updated, including this. You may see, for example:
INFO: Set material "Material_SHADOW_BLEND_GLASS"'s Blend Glass property to true and its Blend Mode to Shadow

  • #366 – An Optimization! Useless transitions in the OBJ were being written, now they’re not. Custom Properties still work, there won’t be any visual changes to your OBJ. We haven’t done any profiling but it might have decreased OBJ loading time by a small amount too.

Features

Command Search Window

Thanks to #361, just like the Datarefs.txt Search Window, we now have the same capabilities for searching Commands.txt (for manipulators). We are shipping with X-Plane’s latest Commands.txt file, but of course you can replace it with your own (as long as you keep the name the same). One day we hope to make it much more flexible.
3_5_0_beta_2_command_search_window

Particle Emitters (not very useful to most yet, I know)

Thanks to #358, some people who have access to X-Plane’s cutting edge particle code can use XPlane2Blender to specify particle emitters. Don’t worry, we’re all working as hard as we can to get these into the hands of others. Fortunately, XPlane2Blender users can hit the ground running the minute it drops!
3_5_0_beta_2_particle_screenshot

Build Scripts And Test Runners

  • #302 and #307 – Are you a professional XPlane2Blender maintainer and developer (if so we should probably talk!) Then you need a better build script, and a test script to match! Introducing mkbuild.py, the build script for the modern developer! It creates, it tests, it renames without messy mistake prone human intervention! To top that off, how about a testing script that doesn’t give false positives!
Posted in Aircraft, Aircraft & Modeling, Cockpits, Development, Modeling, Panels by | 8 Comments

X-Plane Live TODAY

A quick correction – the X-Plane Live session will actually be today, Tuesday at 4 pm (20:00 UTC) – I apologize for the total confusion and chaos on this one.  We have your questions from the developer blog and social media, and we’ll try to take live questions as best we can.

EDIT: T-minus 30 minutes to live stream! We’ll be live here on YouTube.

EDIT 2: If you missed the live stream, you can watch the recording: Part 1 and Part 2 (split due to technical difficulties).

Posted in Development, News by | 30 Comments

FlightSimExpo 2018 Slide Deck

I meant to post this weeks ago, and basically just lost track of it, so thanks for the reminders in the comment sections.  Here is a PDF export of our slide deck from FSExpo.

Flight Sim Expo 2018 Slide Deck

There is professionally shot video of the event, but it wasn’t shot by us, and I’m afraid I have no idea when it will be posted. We’re looking into using our own cameras next year so that we can ensure a video post on a more timely basis.

 

Posted in Development by | 24 Comments

X-Plane 11.25 Release Candidate 1

X-Plane 11.25 release candidate 1 is live. If you were using an 11.25 beta, you’ll be auto-notified to update. If you’re not using the beta, you can check “get betas” to get the beta. (Steam users: 11.25b1 is available as a Steam public beta – we’ll put the release candidate on Steam early next week if nothing blows up.)  Release notes are here.

This update includes the addition of the “High Roller” Ferris wheel/rotating bar to the strip – when we were at FSExpo, the High Roller was very close to the Flamingo, and it was quite clear how visible it was to the skyline.

Posted in Development, News by | 29 Comments

X-Plane 11.20 Escaped Captivity

X-Plane 11.20 is, of course, final! Like all good Klingon software, it was not so much released – rather it escaped captivity, leaving a trail of blood in the path of all whom opposed it.

I am aware of two plugin-related issues we are tracking:

  1. Some legacy plugins with widget UIs are missing buttons when the UI is at 150% or 200% scaling. We have a fix for this, but for now you can work around the problem by turning off UI scaling in the graphics settings tab.
  2. Some Mac plugins compiled against libstdc++ crash with the Steam version (but not the non-Steam version).

Philipp and I are still discussing what to do about this second thing, but if your plugin is in this category (so far we’ve seen it with HeadShake and X-Ivap), my suggestion is: compile and link against clang’s libc++ on OS X – it’s the native Mac C++ runtime and the one that’s going to work well in the long term.

We’ll release an 11.21 release candidate either late this week or early next week, once we collect the bug fixes that got away.

EDIT: HeadShake has been fixed by SimCoders!

Posted in Development by | 26 Comments

Plugin Developers: Please Try This Fix

X-Plane 11.20r2 has only one bug that we are trying to fix: a bug in the plugin SDK that can cause some plugins to crash when creating and destroying windows.

Tyler and I dug into this and found that the fix was a bit more intrusive than we wanted for this late in an RC.

So: if you are a plugin developer and you are working with the new SDK, either for VR compatibility, to use the new 3.x APIs, or just because you are updating the plugins, and you have time this weekend, please email me and I can send you our new fixed XPLM DLLs.

My hope is to get half a dozen plugin developers to bang on them over the weekend, so that when we cut 11.20r3, it really will be the release.

Edit: RC3 is live – thanks to everyone who helped!

Posted in Development, Plugins by | 4 Comments

Deleting Your Missing Scenery Packs Is Not a Bug (But Is Kind of Dumb)

We received a last minute bug report that X-Plane 11.20r2 deletes scenery packs from scenery_pack.ini. This is true! It is also by design, not a bug, the same as X-Plane 10, and not particularly brilliant on my part.

scenery_packs.ini persists the order of your packs (putting newly discovered packs “in front” in alphabetical order upon discovery) and maintains enable-disable status. But it does not retain any other information. The file is totally rewritten on every run and the following otherwise useful stuff tends to get destroyed in the process.

  • Comments and notes to yourself
  • Whitespace and formatting
  • Any scenery packs that can’t be found

Unfortunately this means that if you symlink to an external drive that is unmounted and run X-Plane, your scenery pack order gets lost. This definitely does suck.

In a future version, I can fix this. But we’re not going to mess with it now during RC because it’s totally not changed or broken compared to all past versions of X-Plane since we introduced the scenery_packs.ini file.

For now: you can lock the file as a hack-around to preserve your well-created order while your remote drive is unmounted – when you re-mount and restart, your order isn’t lost. But in this order, new packs aren’t persisted to the file, although they will be used.

If there’s things you want the scenery_packs.ini file to do, commenting on this post would be on-topic. One thing to consider: if we can’t drop missing packs, how do we know a pack was uninstalled? How does the file ever get cleaned?

Posted in Development by | 44 Comments