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:
- The overwhelming majority of users telling us they want 64 bits are Mac users. On 64-bit Windows OSes, X-Plane has significantly more address space headroom, so you have to push the sim a lot farther to run out of memory.
- Macs just aren’t that fast. You either have a laptop (highly constrained by the need to be power-efficient) or an iMac (power constraints and no update for over a year) or a Mac Pro (with the best graphics card two generations old and no real CPU update in a while).
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.
- The older a model gets, the farther behind the curve it is. So the Mac Pro is really behind due to being age constrained; if they update it with a current-gen desktop GPU and an Ivy-Bridge based Xeon CPU it won’t be cheap, but it will be competitive. For desktops the big issue is one of cost: you can get the latest mobo at any time for Windows and a game machine is significantly less than a Mac Pro.
- Watts: how much GPU power you get is a function of the power budget of the card, and both the iMac and laptops are constrained relative to desktop machines. The new Retina-Book MacBook Pros are nice, new, top of the line laptops, but they are also using the GeForce 650M, a decision to trade off some GPU power for battery life, heat dissipation, etc. There will inevitably be an AlienWare laptop that ways 12 lbs, burns through its battery in five minutes, but ships with a bigger mobile GPU for better performance. I’d rather use the lighter laptop, but my concern is traveling with my work, not flying.
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:
- You have an NVidia graphics card.
- You are running Windows 7.
- You are running X-Plane 10.10r3.
- You are running the latest (306.23 WHQL) drivers.
- X-Plane crashes in a reproducible way (e.g. every time you turn up shadows, crash).
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.
Edit: see the end of the article for a GUI tool to manage joystick permissions.
I’ve already briefly discussed some of the changes necessary to get joystick devices working properly but I thought it’d be a good idea to consolidate all information into one post for easy reference as 10.10 is nearing it’s release to the masses.
First, why the change? In the past we used the “joystick” interface to joystick devices on Linux. This interface is extremely basic and is really only useful to games that require minimal knowledge of the actual hardware. X-Plane really does not fit this specification at all. X-Plane needs to work with the spectrum of hardware from the most basic one axis trim wheel to the most complicated home-built cockpits that have dozens of axis and literally hundreds of buttons and switches. In order to support this properly, in 10.10 we’ve switched from using the “joystick” interface to using the “input” interface. This gives us ALMOST the same quality of low level access to the hardware that we get on Win/Mac. The problem with using the “input” interface is that almost anything can be an input. Your keyboard and mouse for example are “inputs”. As linux is a multi-user operating system, there are permissions concerns regarding input device reading. You wouldn’t want another user snooping on your keyboard as you’re typing credit card numbers would you? Many Linux distros by default restrict access to these devices with some exceptions handled in ACLs. If the device LOOKS like a joystick, anyone’s allowed to access it since the security risk associated with joysticks are pretty much zero. But the definition of a joystick is something that has two axis and some buttons. Therein lies the problem. Rudder pedals don’t have any buttons. Trim wheels don’t have any buttons either and they only have one axis. Because of this, the ACL for the devices does not kick in and you now need root access to read from the device.
The solution…run X-Plane as root! I’m joking though some people will have no problem doing this. If you’re cool with that, be my guest but it’s generally not regarded as a safe way to run a system. For the rest of the population, there are rules than can be created that will detect your hardware and automatically set the permissions appropriately so that X-Plane can access the hardware. These are called UDEV rules. For a typical Linux user, creating a UDEV rule should be walk in the park but for a novice it might seem tricky. Luckily, it only needs to be done once and will work for good.
A big thank you goes out to Bill Good who is a member of the X-Plane.org community. He put together this tutorial for you guys to benefit from.
- This is an optional step but it really makes things easier. Each piece of hardware has a Vendor ID and a Product ID. These are called the VID and PID in industry. These two ID’s together are used to detect a device’s existence. You’ll need to know the VID and PID of each device that you care about. To determine this, you can get a tool called “lsinput” which makes this a bit easier. Just run “sudo apt-get install input-utils” on a debian based system. If you’re Red Hat based, i’m sure you can run the similar “YUM” command.
- Run “sudo lsinput” which will list all /dev/input/event ‘s that are attached to the system. Find the hardware that you care about. Here’s a sample output for a Saitek Pro Flight Rudder. Notice the Vendor and Product lines which have hex values of 6A3 and 763 respectively. That’s what we need.
/dev/input/event6
bustype : BUS_USB
vendor : 0x6a3
product : 0x763
version : 273
name : "Saitek Saitek Pro Flight Rudder "
phys : "usb-0000:00:16.2-4.1/input0"
uniq : ""
bits ev : EV_SYN EV_ABS
- Create a file called “99-X-Plane_10_Joystick.rules” in your /lib/udev/rules.d/ directory. I’m not sure if this path is distro specific. You may need to look up where udev rules go on your distro. EDIT: Users report that a more appropriate path may be “/etc/udev/rules.d/” which has the added benefit of being a location that gets grabbed by backups. Either path will work fine however.
- In the 99-X-Plane_10_Joystick.rules file, create one entry for each device that you wish to include. Put them all in this file…each hardware entry on its own line. Only the ATTRS sections need to be set by you, the rest is boilerplate. Notice the Vendor and Product values of 6A3 and 763 from before in the sample below (Make sure to scroll horizontally. On smaller monitors, the whole string may not be visible).
KERNEL=="event*", ATTRS{idProduct}=="0763", ATTRS{idVendor}=="06a3", MODE="0666"
- The last step requires a restart of the system. There MAY be a subsystem that can be restarted instead of taking the whole system down but i’m not aware of what that may be so it’s best to just restart the whole thing.
Update: One enterprising Linux X-Plane user has written an open source GUI tool to manage joystick permissions. Here it is!
Chris and I wince whenever we see a forum post like this*:
Every time I start up the left engine of the KX-1000 turbojet, rain appears on my right windscreen. I hope 64-bit fixes that!
Seriously though, 64-bit seems to have gained a reputation in the community as the messiah that will cure all evil. This reputation is unfounded.
64-bit will do one and only one thing: allow X-Plane to use significantly more virtual memory without crashing. If you crash because you run out of address space, 64-bit will help you. It is not going to fix anything else.
Here are some things 64-bit will not do:
- 64-bit will not make X-Plane faster. Using more memory doesn’t make things faster. (Nerds: using
IA64x86_64 doesn’t make things faster. We’re not register bound because secretly x86 chips do crazy register renaming. We are, however, L2 bound, and making all of our pointer-based structures 2x in size isn’t a move in the right direction.) Past tests indicate that 64-bit is performance neutral.
- It won’t fix any bugs. If a system is broken in 32-bits, it will be equally broken in 64 bits.
- It won’t make anything look any better. The same settings should produce the same image in 32-bits or 64-bits.
- It won’t bring world peace. For that you need 128 bits.
Actually, that second-to-last statement is slightly not true . With 64 bits, some settings will become possible for some users that were strictly memory bound before. For example, if you couldn’t run extreme texture res and extreme forests only due to memory limits, 64-bits will let you use extreme res and forests, and that probably will look better than having to pick one or the other.
Of course, with the address space limit removed, users will run into a series of new limitations:
- Some users will run out of physical memory. Fortunately RAM is very cheap, but it’s not easy to upgrade in a laptop
or iMac. (I stand corrected: apparently iMac RAM upgrades are now slip-in, which is cool. I think a while ago you had to pop the case, which wasn’t much fun. The TiBooks used to have a RAM drop-in under a pop-off keyboard, which was cool but put constraints on how strong the keyboard could be. But I digress.)
- Some users will not be able to show all of that extra 3-d “stuff” at reasonable framerates.
- Some users will run out of VRAM at the higher texture resolutions.
There’s always one thing that limits performance…64 bit simply ensures that it isn’t the needless artificial limit of a 32-bit process.
* Whenever we see such a post by accident while looking at online shoe catalogs. We do not read the forums! Do not assume that a forum post is a bug report. Insert the rest of the rant here, etc.
It has been brought to my attention that Android users that have Webroot’s Antivirus app for Android installed are getting false reports that X-Plane contains a trojan virus.
This is of course a complete false-positive on the part of the Anti-virus software. I’m doing my best to get ahold of Webroot’s developers to aid them in correcting their software. In the meantime, rest assured we’re not doing anything dirty to your android device.
X-Plane 10.10r3 came out this weekend – go use it! This is my expectation over the next week:
- Barring a truly horrific bug, we’ll probably declare 10.10r3 to be the final build of 10.10 and make it live to everyone.
- We will probably cut a 10.11 bug fix patch within the next week.
Why do I expect 10.11 so soon? Because there is always one bug that we don’t find out about until we make the rc live to everyone – inevitably one hour after the build goes live, someone reports something that no one saw in development, no one saw in the company, no one saw in beta, that we want to fix. Murphy’s law is irrefutable.
In the case of 10.10, the rate of bugs coming in on 10.10 has slowed down a lot, so if we continue to fix bugs in rc, we’ll be fixing bugs at a very low rate without moving on to the next thing. Thus it’s likely we’ll “kick it out the door”, get our one late bug, and cut a quick patch. We may also get additional localization into 10.11, depending on what we get from our translators.
It looks like the next sim patch after 10.1x (e.g. 10.10 plus any bug fixes) will focus on finishing and shipping 64-bit, hopefully with more autogen coming along for the ride.
As always, please report bugs to the bug reporter, not the blog, and not email; link is on the right.
(A quick side note/rant: my email server kind of exploded a week or two ago – lots of emails bounced, lots of emails were lost. This is one reason why I do not want bugs by email! I am always threatening “if you don’t file a bug, it might be lost.” Well, if you sent me a bug by email, for all I know it was lost. Please use the bug reporter!!!)
X-Plane 10.10r3 is out – release notes here. Go use Rc3! This might be the final RC – we’ll know in a few days.
Now that people are using 10.10 more frequently, I’ve received some bug reports that turned out to be problems prioritizing scenery packs.
The rules for how scenery packs are prioritized have changed! Please read this carefully!
The Rules
Old: Scenery packs are loaded alphabetically by name.
New: Scenery packs are loaded according to the .ini file in Custom Scenery
That’s pretty much all there is to it. The .ini file means that you can organize your scenery by reordering the .ini file rather than renaming packs. That in turn means you don’t have to worry about having crazy names like a_Overlay b_SecondOverlay, and you don’t have to do a massive rename of a lot of packs to get the names right.
If you don’t want our scenery, disable them in the .ini file (by replacing SCENERY_PACK with SCENERY_PACK_DISABLED). The installer won’t re-download them.
The .ini file sets the stage for a future UI or third party utilities that edit priorities, and installers that can set up custom priorities.
How Packs Are Added
When X-Plane runs, any packs that are found in Custom Scenery but not in the .ini file are added to the top of the .ini file. If more than one “new” pack is found, the new packs are added in alphabetical order (but still before every old pack).
Any missing scenery pack is removed from the .ini file when X-Plane runs.
This means a few things:
- If an overlay isn’t high priority, you can remove it, run X-Plane, then put it back and run X-Plane. This moves it to the top of the list. (Or just edit the .ini file – which is probably easier.)
- If you simply want alphabetical order, delete the entire .ini file – every pack will then be added on the next sim run, in alphabetical order.
You know you’ve got a good bug when a user reports that his airplane’s wing disappears when he turns the battery switch off. It turns out that this is the same bug as the 747 rolling over to the side.
X-Plane 10.10 (beta 1 all the way through RC1) has a bug in the IO code that scrambles the electrical system of airplanes on load, sliding the electrical system selections on the “bus 2” page of Plane-Maker over by one slot (except for the last two columns, which get totally scrambled). Then, due to an accident chain that would make the NTSB blush, the results pop out in the flight model, often as an incorrect roll tendency for airliners.
This (and a number of other bugs — thanks to all of the airplane authors who tried their planes and reported bugs against rc 1) will be fixed in rc2, which will hopefully come out “real soon now™”.
If your plane is saved in X-Plane 10.05 format, this bug won’t affect you – the fix to X-Plane will cause your airplane to just work. If you have already saved your airplane with Plane-Maker 10.10, you may have to re-enter some of the amperages and bus choices for your electrical system – the amount of data scrambling depends on how you used Plane-Maker. The good news is that the damage is limited to the second electrical page so at the very worst, you’ll have to re-enter some electrical system data using rc2.
Trusting Beta Plane-Maker
This bug brings up the question: how much should you trust a beta or RC Plane-Maker? The short answer is: “not very much”. Here are my recommendations.
- Never, ever, ever release an airplane against a version of the sim that hasn’t gone final. Things do change in release candidates, sometimes major things when we find a bug like this. Wait until the version is declared “done” before you release your airplane!
- While always saving backups of your work is always a good time, it is especially important when using Plane-Maker betas. Assume a beta Plane-Maker might erase the .acf you are working on entirely; while we’ve never had it do something that bad, it has produced incorrect ACF files before due to bugs.
- Beta Plane-Makers are good for testing and trying new features and experimenting, but not for production work; wait until we go final to permanently change tool chains.
- The warnings about beta go for release candidates too!
I am working on a v9 -> v10.10 checklist for airplane authors; the actual “busy work” of editing the ACF file should be less than 30 minutes per airplane if you know what new values you need to enter for parameters that need updating, so a reasonable work-flow might be to experiment with the new features and report bugs until we go final, then make the actual update on a fresh copy of your plane from an older version.
How Did We Miss This?
The sobering thing for me is that this bug has been in our betas for four weeks and (1) we didn’t notice it and (2) no one reported it. I take a few things away from this: clearly we need to test our own planes more carefully. In 10.10 we did a lot of detailed work on our own fleet, but ironically this hid the bug from us. But I also take away from this that a lot of authors don’t even look at the build until RC.
If you make an add-on, I encourage you to at least look at a few betas before RC. Even if you don’t retest every one, taking a peak early means we can fix bugs that affect your add-on early, which is good for everyone.
