X-Plane 10.11 RC 3 Ready for Testing
X-Plane 10.11 rc3 is ready for testing. If you see a lot of spurious warnings about LOD errors in your Log.txt file on Windows, get this build by running the updater and checking “get betas” – it should help.
X-Plane 10.11 rc3 is ready for testing. If you see a lot of spurious warnings about LOD errors in your Log.txt file on Windows, get this build by running the updater and checking “get betas” – it should help.
Yesterday I was able to reproduce and fix a bug that several people reported against X-Plane 10.10; the bug is random, which explains why, when I tried to follow their reproduction steps, I did not get the same results. The last step in the bug report could have been “get lucky”.
The bug is: on Windows, sometimes the sim would output a ton of LOD warnings for objects (including default objects that ship with the sim) and then framerate would be reduced. Running a heavy framerate test on my PC I saw fps reduced from 25 to 15 fps when the failure happened.
The bug was 8bytes of uninitialized data deep in the OBJ engine; the impact depended on the random contents.
I will cut X-Plane 10.11r3 soon with a fix to this.
Reminder: please do not post bug reports to the comment section. This includes reports of “I saw this bug too or “I saw this, but on OS X” or “it works fine for me” or “why haven’t you guys fixed XXX.” Please report bugs via the bug reporter.
10.11 Release Candidate 2 is out – this fixes the constant hail that was showing up in 10.11r1. If you have 10.11r1 it will prompt to auto-update.
X-Plane 10.11 release candidate 1 is now available online – run the installer, and update with the “get betas” button checked to get it. This is a small bug fix build to get new Japanese strings out; most of these bug fixes were coded during 10.10’s release candidate period but held to keep the sim stable for DVD pressings. It’s a small update.
EDIT: Please stand by, the upload did not work right – it should be available later tonight.
EDIT 2: Okay – now we are live.
We may do one more small bug fix release (e.g. a 10.12) before we get to 10.20, which will introduce 64-bit and have a longer beta period. 64-bit porting is going well and I am happy with the progress so far.
A number of WED users have reported a really nasty bug: while mousing around, WED would put up a fatal error dialog box and quit, with work lost. This bug sucks, and what was worse, no one could find a good procedure to reproduce it. The steps appeared to be “do some work, get a lot of changes ready, click, lose work.”
That is, until now; the other day Chris round the reproduction case. I now have a fix, so I will try to cut a WED 1.2 beta 2 in the next week.
Well as I promised (11 months ago), here’s a tutorial on making ATC Taxi Networks in WorldEditor v1.2. Hopefully this clears up some misunderstandings about how the pieces of the system work and how they’re meant to be used. Perhaps the next video tutorial will be on creating Airport flows to teach ATC which runways get used for which operations.
Part 1 of 5
Part 2 of 5
Part 3 of 5
Part 4 of 5
Part 5 of 5
One thought on alpha and HDR and aircraft:
If you need to create a final flat part of a panel out of multiple layers, some translucent, and you are using panel texture, it is better to composite the entire piece of panel in the panel texture than to layer polygons in your OBJ.
For example, consider the annunciator display on the dashboard that many airplanes have. There are two ways to build this panel:
Choose option 1! Tom had to convert the Baron’s annunciator panel from method 2 to method 1. A few reasons to prefer method 1:
You won’t use up that more panel texture, but you’ll make your life easier. This technique wasn’t totally possible before, but now with GLOBAL_cockpit_lit you can alwys have your panel handle real lighting.
First, for the plugin authors: I am hoping to start a 10.20 beta for 64-bit in weeks, not months. I don’t know how many weeks it will be – there’s a huge potential for variation, but if you maintain a plugin, be aware that you’ll be able to actually test your plugin against a 64-bit X-Plane this year.
At this point we have launched X-Plane, 64-bit-style on all three operating systems. That doesn’t make it beta-ready but we have a heartbeat.
X-Plane 10.10 is final, and we may cut a small bug-fix patch (10.11) before we go into 64-bit. We have a handful of lower-priority bug fixes that we kept out of 10.10 for stability that we need to release at some point; the plan hasn’t been finalized.
Mac and 64-Bit: Not That Fast
So once I had a 64-bit X-Plane running on my machine, I did the obvious thing: crank the settings through the roof and see what happens. And I can now report the results:
Very low framerate.
The problem is: my machine was very close to maxed out with 32-bits. When I was able to crank the settings beyond where I could before, I simply overloaded it. Too many objects, too many textures, too many vertices, too much stuff. It’s a 2008 Mac Pro with a 4870 – not a spring chicken.
I mention this now because:
In other words, my Mac may be older and slower, but the very fastest ones aren’t that fast. There is no Mac equivalent right now to an Ivy Bridge i5 or i7 with a GeForce 680.
So while you may be hitting address space limits and crashing on your Mac right now, you may not have that much hardware budget left over, and it may be a short trip from 64-bits to finding you’ve simply maxed out your hardware.
It’s All About the Watts
One last thought on Macs falling behind Windows gaming machines: while this used to be a function of technology it’s really become a race with only two factors: watts and time.
My point here is: these two factors (revision time for models and power use profile) are unlikely to change any time soon – they are fundamental to Apple’s business model. So Mac users, on average you are never going to have the same performance options as your Windows brethren.
There is a bug in WED 1.2 beta 1 right now: if you somehow manage to get non-unicode data saved into your file*, you won’t be able to re-open it. This is definitely a bug and something I will fix as soon as I can, but it also means you can lose your WED project. This blog post explains how to fix an earth.wed.xml file that produces “bad token errors”.
An earth.wed.xml file is basically a very big text file. These instructions are for a Mac; on Linux the same tools are available – on Windows you can use the port of xmllint or find another, more friendly XML validator.
From the terminal, run xmllint like this:
xmllint --noout "/Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml"
If you have an XML bad character bug causing the bad token error you will get something like this:
/Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : invalid character in attribute value <hierarchy hidden="0" locked="0" name="parkeerlijntje?"/> ^ /Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : attributes construct error <hierarchy hidden="0" locked="0" name="parkeerlijntje?"/> ^ /Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : Couldn't find end of Start Tag hierarchy line 168705 <hierarchy hidden="0" locked="0" name="parkeerlijntje?"/> ^ /Users/bsupnik/Desktop/EHAMaptdatxml/earth.wed.xml:168705: parser error : PCDATA invalid Char value 16 <hierarchy hidden="0" locked="0" name="parkeerlijntje?"/> ^
In this case, the ? is the bad character being mapped to ‘?’ by OS X’s terminal. I now open the file in a text editor (I used X-Code), go to line 168705, and simply replace the string inside “name” with a new string, without a bogus character. Resave (make sure you are in UTF8 format) and you are good to go.
A future beta of WED 1.2 will fix this, but for now you can hand-edit; once you remove these XML errors your project should be good for further use.
* This bug is particularly insidious because WED 1.0 would very happily write junk data out to disk, then read it back again, so you could have non-unicode junk strings in your project for years and only upon moving to WED 1.2 realize what happened. A common way to get junk data is to import an apt.dat file with non-UTF8 airport names.
If you maintain a plugin for X-Plane, you can already take some of the steps necessary to go 64-bit. I am working on 64 bit code for 10.20; here’s what you can do to be ready for the beta:
Upgrade to the X-Plane SDK 2.1 headers. The 2.1 headers change the use of long to intptr_t to fix 64-bit issues. This will mean a one-time cut-and-paste pass over your code.
Note that you do not have to make your plugin v10-only (or 2.1 SDK only) to use the new headers. Your plugin will require the 2.1 SDK only if you #define XPLM210 to 1. By not defining the new APIs you don’t opt into them. Your plugin built against the 2.1 SDK will work with X-Plane 9 (or 8, 7 or 6 for API 1.0 plugins).
Find and fix any case where you cast a pointer to an int and back – in 64 bits that will fail. as you will see from the 2.1 headers, widget properties are now intptr_t to ensure that the property can hold a pointer.
Once you have have fixed these new header issues and int <-> ptr issues you’ll be in good shape to go to 64 bits when a sim is available.
Update: to clarify, with the 2.1 SDK you can write code that will be 64-bit safe, and you can probably even compile in 64 bits. But you can’t link your 64-bit plugin – we have not released library files or documentation on the appropriate fat packaging structure. So you can get ready by cleaning your C/C++ code, but you can’t actually finish a 64-bit plugin. (And if you could, how would you test it?)
We have a handful of users reporting crashes on Windows using NVidia drivers. So please email me (ben at x-plane dot com) if you meet all of these requirements:
I am looking to collect more in depth crash information to figure out what is going on. Sadly Chris and I both have NV-Windows boxes in our offices and both are stable.