Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 28 million developers.Sign up
XPlane2Blender is now X-Plane 11.30 ready! Not much has changed since beta.3, just some fixes to the particle stuff.
Sound Emitter has been removed from the Empty Special types menu. One day it will be back in!
This small update has fixes related to particle emitters.
Special Empty Types has been moved from the over bloated Objects tab to the Data tab. In addition, a checkbox enables and disables the use of the Array Index.
Sound Emitter is still in the menu even though we don't have sound emitters because I'd rather not mess with enums when it is just going back in there anyway.
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.
- #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 Glasswas in the same drop down menu as
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.
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.
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.
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!
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!
This beta has new features and changes to the data model! We don't predict they're particularly dangerous changes, but as always, make backups of your work!
Dataref Search Window
Next to any Dataref Path text field will be a Zoom In magnifying glass. Clicking on this will open the new Dataref Search Window!
You can scroll through the list or search for datarefs using X-Plane's Dataref Editor syntax.
In this picture, we're searching for anything that matches (
N1) OR (
N2). Only the dataref path is searched, the units field is not.
When you click a dataref, it will be inserted automatically in the associated Dataref Path text field.
You can also click the Zoom Out symbol to close the Search Window without selecting any dataref. The datarefs it searches through come from the included Datarefs.txt file. The search window lists, in order, the path, type (and array size), if it is writeable, and its unit. Description is not included.
Virtual Reality Manipulators!
Virtual Reality manipulators for simulating throttles, rotating objects on a hinge, dragging flap levelers, trim wheels, and other such devices can now be specified in XPlane2Blender! Set your X-Plane Target Version to v11.1x in the scene settings to gain access to these. Backwards compatibility note: these manipulator types are not available in previous versions of XPlane2Blender!
Manipulator Property Autodetection
Previous manipulator types required much data entry to put in things like DX,Y,Z, values, and used datarefs. New smart manipulators autodetect these for you!
- Drag Rotate (useful for Trim Wheels)
- Drag Rotate With Detents (useful for throttle quadrants)
- Drag Axis With Detents (useful for flap levels)
- Drag Axis (the old manip type now enhanced. Opt into new autodetection by using the checkbox
All of these can inspect their animation and parent's animation to find these properties, but datarefs can always be overridden and set manually, similar to how textures can always be overwritten and specified manually. This should be very very rare
The requirements for what chains of animations are needed to use seem complex but have a constant pattern to them. See the Animation Requirements For Smart Manipulators for more details.
Custom Light RGB Overrides
If you're a person who uses Custom Lights (which are not deprecated but also not recommended!), and need a way to put in custom values for RGB (since new Blender color pickers don't allow negative and custom color values), you now have a new checkbox and properties to help you.
As far as I know there are an extremely small number of authors who use Custom Lights, so if you're saying "What? Custom Lights? Color Picker?", don't worry about it.
This RC has two simple fixes that are non-breaking and totally awesome.
- #347: Optimization that brings export time down by a third to a half. The file size remains the side and nothing is needed to activate it. Using the "Optimize" checkbox was not optimized this time around.
- #350, #351: Two animation bugs that would cause strange offsets when using bones. You may or may not have experienced this. Again, there is nothing to do to activate this, it is part of every export.
If you run into problems, please file a bug. If you do not notice a decreased export time with large models, also please tell us. We'd love to benchmark this on more data.
We made it people!
This release encompasses all of the beta. You can read through the beta notes for more details, but, here are the highlights:
- Single button to "Export OBJs", skipping the file selection box
- Autocorrecting spot lights - the light points where you point it, not where the parameters tell it to go!
- X-Plane 11 support for Blend Glass, Normal Metalness
- New clean UI, better laid out, more consistent look, and some properties smartly hide when they're invalid or not relevant
- Support of 1 LOD box
- Enhanced build number and plugin history to help debug files and track update problems. After installing this rc.1 version, your scene settings should look like this. The green check mark means "most safe" to use.
- No more reading the lights.txt file. The list of lights and their parameters can now be found online
- Though unsupported and largely irrelevant to most authors, a "Plugin Development" section has been added with some neat tools that you probably shouldn't use.
- EXPORT directive (really only useful for LR toolchains. Documented here for posterity's sake)
- Animations have been optimized
- Bones, nested bones, and complex parent-child relationships with armatures now work better,
- Animation types have been synthesized to just Transform, Show, and Hide instead of Loc, Rot, LocRot, Show, Hide
We could not have gotten this far without the incredible support of our beta testers, new authors, bug reporters, and all the wonderful artists who give us the inspiration and energy to make this product better! It has been an incredible journey diving into this facet of the community and I look forward to even more releases, including VR manipulators, full WYSIWYG lights, and more!
One big massive bug fix! (and some optimizations!)
#264 caused some people's lights to be put in the wrong place. The fix involved Ben coming up with awesome math to put things back in their place by a certain offset, and then us creating a way to parse the light.txt file that controls much of the lighting in X-Plane.
This Changes Nothing in Your Blend files!
Seriously! No Blender data should change!
However, It Could Change Your OBJs
XPlane2Blender is now more consistently WYSIWYG! Meaning that if you point a spotlight at a wall, it should show up pointing in that direction, regardless of what a named spill light thinks or the parameters of a param light think.
This is good news for new authors and authors suffering from the bug, but depending on how you've been making your lights appear rotated, it could result in needing to change the rotation or parentage of existing lights.
What Lights Are Affected?
All of the following conditions must be true for a light to be affected by this change
- Be a Blender non-point light, for instance a spot light
- The light's
XPlane Typemust be Named or Param
- The light's
XPlane Namemust be found in the lights.txt file inside the addon's new resource folder
In rare edge cases, special and less used lights will be excluded from auto correction.
So, as you can see its either somewhat common or very specific which lights are affected. So, if your eyes haven't glazed over yet,
Please Send Reports Of How This Affects You - Good, Neutral, Or Bad!
We try our best for backwards compatibility and a bug free existence, but we don't know everyone and their situation until they say hi! If you are faced with large hurdles to continued productivity, please file a bug! Preferably with before and after pictures and .blend files. Automated fixes may be developed for people affected.
This is just one step to a more WYSIWYG XPlane2Blender.
Build Version Numbers
XPlane2Blender's new version number system is will allow us to debug .blend and .obj file even faster. It should also make making updates to the data model easier to implement.
- Every exported .obj file's footer contains information about the addon version, when it was compiled, and why. For example:
A break down of the components
3.4.0: The traditional Blend addon number
beta: The type of build cycle we're in. Other choices you may see are
dev(a developer build),
rc(for full release)
5: the build type version we're on. Since this is beta 5, the build type version is 5.
The elements after the + are generally less meaningful to the average user
1: The version of the data model (the properties and settings for XPlane2Blender, used for comparing changes
20170922151901: The "build number" date this source code was packaged and released in the form of YYYYMMDDHHMMSS in UTC.
The build version number is partially shown (elements after the + are hidden) in the scene settings under
Compile Normal-Textures, potentially along with warnings about the stability of the build you are using.
- A developer writing and testing unreleased code
- Someone who didn't head the warning against using such code, or get scared off by the nuclear symbol and extra warning about a lack of a build number
It is the worst case scenario for stability and traceability, hence the nuclear symbol.
Why the extra warning about a lack of a build number?
A lack of a build number indicates that you do not have a good dialog (e-mail, chat, this release page, or other channels) with a knowledgeable and attentive developer. This means your work is more likely to be run through a bad version of the code and damaged, or your bugs will be harder to diagnose and repair.
In this case, despite the code appearing to come from a stable era of the code near a release, there is potential for something to be wrong and have very poor ways of tracing what it could be - hence the lack of green check mark and big red warning symbol.
If you see some new pre-alpha feature you'd like to try, just ask us about it first. Going forward, we want to start with a dialog about potential dangers, testing, and intentions of an incomplete feature rather than an autopsy later on. Don't be scared, we always love hearing from users before there is a problem, not after!
Build Version History
Also, all .blend files will be keeping a log of every different version of XPlane2Blender that they are opened and saved with. This is automatic and needs no involvement from the user. Those who are curious can look in the Plugin Development Tools section at the bottom of the scene settings and see the history of their file.
Note: This does not record any history data about Blender versions, other addon versions used, timestamps opened or saved, or changes made to it (including XPlane2Blender settings changes). It is purely useful as a debugging tool, and is not fool proof.
This .blend file started as a legacy 3.4.0 pre-beta.5 file, and was then with a copy of 3.4.0-beta.5, with no build number. Then it was used with 3.3.12, then finally, used with a build of 3.4.0-beta.5 created on 09/18/2017 at 01:27:30am.
One could use this information to guess what transformations the data could possibly have gone through along each step of its journey.
- #294 - A case where autodetect off was not fully trusting the author for Aircraft exports
- An uncaught spelling mistake
__updateLocRot. The fix for the updater altering the animation types was written for object's dataref animations and bone's dataref animation troubles. However, with this spelling mistake and Blender's uncanny ability to eat exceptions from addons, it wasn't realized until later that bone's weren't also getting updated. Fortunately, the updater can be run-again without fear of messing something else up.
Do I need to re-run the updater to fix my Bone's Animation Types?
Ask yourself these two questions:
- Do you have animated bones with datarefs?
- Have you noticed that they are not working or have their animation types screwed up?
If you answered yes for both, read the next section. Otherwise, don't worry about it!
Can I safely re-run the updater to fix my Bone's Animation Types?
- Did you avoid or reverse Animation Types getting corrupted during
3.3.9(See note) and/or
- Did you NOT make changes to the bone's dataref animation types?
If you answered yes for both, read the next section.
Re-running the updater
At the bottom of the Scene Settings, check "Plugin Development Tools". Use the Re-run Updater tool at the bottom: Put in
3.3.12 in "Fake Version", and click the button. Make backups and Please e-mail me if you have problems!
What was the 3.3.9 unofficial release?
There was no real 3.3.9 release, its just the name I'm giving for the code pushed at e8b4173. Some people chose to get the latest (and obviously not greatest) code which started the LocRot headache sooner for them than waiting for 3.4.0-beta.1.
Did I ever use the 3.3.9 unofficial release?
- Do you use git to get code?
- Did you checkout, directly from git, the commit
e8b417334675564, (committed 8/7/2017 4:31:13 PM),"Removes loc/rot from properties, adds auto-upgrade of said properties to just Transform. In addition, it also comments out the propfile ui compontent that we removed the property for"
If you answered yes for both of these you probably did!
- Some spelling and capitalization in the UI. Great care has been taken to ensure that none of the actual value or order of the addon properties has changed!