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).
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.
Posted inAndroid
by Chris Serio|Comments Off on X-Plane for Android is NOT Infected!
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.
I’ve yet to see an episode of “Hoarders” with an aviation theme but apparently people with that flavor of the disease exist because I’ve gotten a chance to talk with a few who have accumulated a serious amount of 3rd party X-Plane content over the years. I’m joking of course and don’t mean to insult anyone or make light of people with illness. If you want to complain about my faux pax, contact Ben Supnik. 🙂
There is a real X-Plane issue here however. X-Plane makes no assumptions about the locations of certain types of files. Aircraft/Airfoils/Objects/Bitmaps etc are allowed to be…well pretty much anywhere in the X-Plane folder (with a few exceptions). You can argue this is silly but for historical reasons, that’s the way things are today. In order to show you a list of all aircraft for example, X-Plane has to search everywhere within its folder in order to find them all.
In prior versions, if you added a new aircraft into your Aircraft folder for example, you had to restart the sim for it to appear. As of X-Plane 10.10, X-Plane now scans for new files every time the “Open Dialog” is opened. This is done intentionally as many users have asked for this behavior. For 99% of the population, this works fine because X-Plane’s file system is relatively flat but if you’re a hoarder and you have a HUGE amount of content in your X-Plane folder, you may notice a delay when opening new Aircraft/Airfoils/Objects etc. This delay always existed but it used to ONLY happen during sim load so it was hidden.
The problem is that you have to rescan the entire file tree each time the dialog is opened. I know a lot of you developers are saying “No you don’t! You can hook the OS and look for changes since the last time and rely on your cache if there were no changes!” and you’re right…but you haven’t seen X-Plane’s File I/O code. You’ll have to trust me when I say it’s non-trivial to support this on 3 different operating systems and it will only benefit a very small percentage of users. This is not where our time needs to be spent at the moment.
In the meantime, we did want to provide a workaround but before I get into that, I want to explain things in a bit more detail. The slowness I found in the few cases that I studied were caused by 3rd party folders within X-Plane that did NOT contain any X-Plane relevant data. In other words, there were no aircraft, airfoils, objects, scenery etc in it that were being used by the sim. That means, the sim had to search through the whole thing only to find…nothing. One common folder was “Custom Scenery (disabled)” which is apparently created by a plugin out there that lets you disable certain scenery packs. This folder has now (As of 10.10R2) been added to our internal black-list so that we know to automatically skip it when searching for data. There are other folders that were already in the black-list. Here’s a current list:
Global Scenery*
Custom Scenery*
Resources
Plugins
Liveries
Cockpit
Note that the * is a wildcard so anything can appear after and still match our filter.
This is very important to note…the black-listed folders are automatically skipped by X-Plane for one purpose only…Dialog Population! Files in blacklisted folders will not appear in any “Open Dialogs”. Examples include Open Aircraft, Open Replay, Open Situation, Open Airfoil (planemaker) etc. Files in these black-listed folders can still be found by the sim for other purposes. Notice that custom scenery still loads even though it’s blacklisted, plugins still work properly etc.
What we wanted was a way for users to specify their own black-listed folders. Some users are developers and have folder after folder of development data in the X-Plane tree that they’d want to blacklist. Starting in 10.10 R2, you can do this by creating a file called:
dont_search_here.txt
in the folder that you want to blacklist. The file can be blank…its contents are completely irrelevant as only the name matters. When X-Plane encounters a folder that contains that file, it will completely give up on the folder and not scan it or scan any deeper. So any Aircraft, Airfoils, Situations, Replays, Weapons, Objects, FMS files, Waves, FDR files or Bitmaps in there will not appear in the appropriate open dialogs.
My recommendations to you:
Do your best to keep non-X-Plane specific data out of the X-Plane tree.
If you can’t or don’t want to follow advice #1, that’s fine. If and ONLY if you suspect that your data is causing X-Plane’s various “Open Dialogs” to be slow, try dropping the dont_search_here.txt into the folder if it doesn’t contain any files you want displayed in X-Plane’s dialogs.
If you’re not experiencing noticeable slowness, don’t mess with this at all! This is not a widespread problem!
First, X-Plane 10.10r1 is out, at least for the next few hours; beta notes here. There are already two known issues:
10.10 is not particularly happy with current shipping ATI Windows drivers. We’re still figuring out what our best path is. We may have to disable functionality when we identify this driver set.
It turns out I broke the P-180 3-d panel, so we’ll cut a new release candidate pretty soon.
If you create add-ons, please go test this release candidate! We can’t fix bugs that are not reported, so now would be a good time to find out if your add-on is adversely affected.
Screen-Cast: Engine Settings
While the changes to the starter are pretty limited, Chris and I did spend a lot of time experimenting with the starters on a number of planes. (The starters are tuned on the 747, C90, B58, P180, and C172.) So I decided to try a screen-cast showing how to edit the starter settings.
This is not exactly the highest production value screen-cast you’ll ever see; rather it’s something I whipped out in less than an hour while the release candidate was uploading.
If this kind of resource is useful, please let us know. During the developer conferences, Austin and I did some short hands-on demos; it isn’t hard for us to turn that kind of thing into a screen-cast.
The screen cast and the blog are not meant to be a replacement for documentation; we’re working on that too. But creating demonstration materials is significantly easier in screen-cast form than document form.
I’ve yet to see an episode of “