Next week is FlightSimCon 2015 in Hartford, CT, and it looks like a bunch of us will be there. Austin is speaking on Sunday, and I think Chris, Philipp, Marty and I will be there too. So if you are attending, come say hi – we’ll be at Austin’s talk and if there’s a cocktail party, we’ll be there too!
(Chris is a total hermit and prefers to communicate with us via a series of grunts, but since it’s face to face, he’ll have no choice but to acknowledge you with at least shifty eye contact! 🙂
Posted in News
by
Ben Supnik |
I’ve been meaning for weeks now to write up some notes about 10.40. I’ve also been trying to put the hood back on 10.40 so we can get it to public beta; instead the last few weeks have been a flying circus of driver bugs, expiring certificates, etc.
But we are making progress, so I’ll start off in this post by describing a change in how DSFs are loaded and the wide DSF box.
A Tangent: Stuttering and Pauses
A post that involves X-Plane pausing during flight is going to invariably bring up a bunch of blog comments: “X-Plane stutters while I fly on my really expensive machine!” This is not good, and from what I’ve been hearing, it sounds like something got worse recently; this is something that we are investigating now.
But I also want to mention that historically, X-Plane has never been “no-pause”. What we have done is periodically made the pauses much shorter; our goal is to get down to zero pauses, ever, but this will happen by finding every source of pausing and fixing them one at a time. In other words, we’re in the middle of a process of improving smoothness, but even if one source of pausing is fixed, another source might still be causing problems.
DSF Loading: the Old Way
X-Plane has, since X-Plane 9, loaded DSFs in the background on a second core while you fly. This cuts down the amount of time it takes to change scenery. (Older versions of X-Plane would pause while scenery was loaded and shifted.)
The old DSF loader did have a few weaknesses though:
- The sim pauses while DSFs are deleted. As DSFs become bigger, this pause is becoming more noticeable.
- If the loader ever gets behind by two scenery shifts, it just waits until it catches up. This is where the dreaded “Async load timed out after 30 seconds” comes in – it indicates that the DSF loader was so far behind that it locked up for half a minute and didn’t catch up.
- The old DSF loader loads one DSF at a time, tops.
DSF Loading the New Way
X-Plane 10.40 has the new DSF loader, which both loads and unloads DSFs on worker threads to keep flight smoother. It also will load more than one DSF at a time, limited only by the requirement that adjacent DSFs not be loaded at the same time.
X-Plane 10.40 also has the option of an extended DSF scenery region for sharper terrain; with this option off, two DSFs are loaded at one time during sim boot and one or two are loaded at a time while you fly. With the extended DSF region on, up to four DSFs are loaded at once during sim boot and one or two are loaded while you fly.
The extended DSF scenery region is optional; don’t use this if you’re using HD meshes or you’re short on RAM. The new DSF loader is always on.
It’s come to my attention that the Scenery Gateway has a serious shortcoming:
There’s currently no good way to get feedback from other users.
This is a shame, because when you upload scenery to a site like X-Plane.org, you get to hear from real people using your scenery—they might tell you how much they appreciate your work, or suggest ways you could improve it.
There’s a tradeoff here: because all airports on the Gateway are periodically exported to X-Plane, users don’t have to seek out your scenery in order to enjoy it; they get it automatically.
That means your work has a much wider impact—it benefits hundreds or even thousands of times as many users compared to posting to a download site. But, it also means people who use your scenery probably don’t know your name.
So, if you’re a Gateway artist, I’d like to hear your thoughts on a couple things:
- How do you feel about the current situation? Do you want a way to get feedback (and kudos) on your Gateway submissions?
- If so, what would be the best way(s) to give that feedback? A few possibilities I can think of include:
- A “like” button for your scenery pack or the airport as a whole
- Pros: Easy to understand, zero friction for people leaving feedback (means more people are likely to use it)
- Cons: Impersonal (compared to text-based comments like “I love this scenery!”), doesn’t solve the problem of hearing from X-Plane users who never visit the Gateway
- The ability for other users to leave comments on your scenery pack
- Pros: Very personal, the “standard” way to get feedback on other download sites
- Cons: Higher friction (fewer people will use this compared to a “like” button, for instance), doesn’t solve the problem of hearing from X-Plane users who never visit the Gateway
- Automatic estimates of how many X-Plane users see your scenery pack each month/year—for instance, you submit a scenery pack for KBOS, and you see that x,000 people fly there each month
- Pros: Gets “feedback” (such as it is) from users who never visit the Gateway, gives a very clear indication of how many users you impact
- Cons: Impersonal
- Something else entirely?
Disclaimer: As with any discussion of future features, I can’t promise we’ll implement any of the above… but I can tell you we’ll consider it.
So, drop a comment below and let me know what you think!
UPDATE: As of July 11, we now have a basic discussion system on the Gateway which integrates with the existing bug reports. Give it a try and let me know what you think!
I just posted WorldEditor 1.4 – “WED”, as we seem to call it most of the time – release candidate one for Mac, Windows and Linux – see the WorldEditor page for download links, report bugs on the gateway bug reporter.
Besides fixing a few bugs, this build has a new certificate so uploading/downloading from the gateway will work.
WED has a validate function that finds authoring problems in your scenery packs; two notes on this function:
First, I have been trying to improve the validation every time an issue comes up with a scenery pack. Therefore WED 1.4’s validation is quite a bit more strict than 1.3’s validation.
Once WED 1.4 goes final, it will become the required version to upload to the gateway. This ensures that we have the strongest validation, and saves Julian from having to hand check authoring issues.
This means that when you go to make a modification to your existing work, you might not be able to resubmit it until you fix existing problems. Your project didn’t change, the validation just became tighter.
Second, I have added the ATC layout error checks to the validation step. These checks (select crossing routes, select doubled nodes, select degenerate route lines) have been available since WED 1.2, but you now have to have a ‘clean’ layout to build your project. I’m hoping that this stricter validation will help fix layout bugs; when the layout is wrong, the AI aircraft’s taxi routes become even weirder than normal.
Posted in Tools
by
Ben Supnik |
Update: WorldEditor 1.3.2 is out now and has new certificates to work with the gateway; get it here!
I screwed up: WorldEditor 1.3.1 contains a certificate that allows it to authenticate that the X-Plane Scenery Gateway is who it says it is before WED transmits your user name and password during an airport upload. And this certificate expires in about two hours.
Last night we cut a new build (1.3.2) with a new certificate with a much longer time range, but Tyler said that for some reason the new certificate did not work. So it’s most likely that we’re going to run out of time before we get a new WED build posted. Here’s what this means:
- You will not be able to upload airports to the gateway with WED 1.3.1.
- Once WED 1.3.2 is available, you will be able to upload airports using WED 1.3.2.
- Every other function of WED will keep working.
- The Gateway’s public web page will keep working.
I’ll post an update here when we can get WED 1.3.2 “live” – unfortunately it will probably be more than two hours. I’m hoping to have this solved by the end of the day.
I will also cut a new WED 1.4.0 beta with the latest bug fixes and an updated certificate. That should be available tonight.
As a side note, I think that everything that is “must fix” for WED 1.4 is fixed, so this will be a WED 1.4 release candidate. We are deferring jpeg-2000 support out of WED 1.4 entirely so we can ship it.
TL;DR: 10.36 works around the latest NVidia driver – let X-Plane auto-update and everything will just work the way it should.
X-Plane 10.36 is out now – it’s a quick patch of X-Plane 10.35 that works around what I believe to be a driver bug* in the new NVidia GeForce 352.86 drivers.
10.36 has been posted using our regular update process and has been pushed to Steam, so if you’re running 10.35, you’ll be prompted to update. The update is very small – about 10-12 MB of download.
With this patch, you can now run the latest NVidia drivers. I have no idea if those drivers are good (I have anecdotal reports that they’re both better and worse than the last drivers, but these kinds of reports often have a large ‘noise’ factor**).
We patched X-Plane because we can cut an X-Plane patch faster than NVidia can re-issue the driver, and the driver issue was causing X-Plane to not start at all for any users, which was turning into a customer support mess. Past NVidia-specific patches have been to fix bugs in X-Plane, but in this case, we’re simply avoiding a pot-hole. I hope that NVidia will get their driver fixed relatively soon so that people installing from DVDs with older versions of the sim won’t be stuck.
Update: NVidia fixed this bug in the new 353.06 drivers!
[OpenGL, Windows 8.1 -x86/x64]: GLSL shader compile error. [1647324]
* The bug is that #defines defined within a function body don’t macro-substitute, but #defines outside a function body too. The work-around is to move some #defines out of function bodies. If anyone can find a reason why #defines can’t be in function bodies, please shout at me, but it’s a pre-processor.
** We’ve had reports of huge fps improvements and losses on beta updates where we’ve made only cosmetic changes to the sim.
Note: this issue has been resolved – please see here!
I’ve received a few bug reports about this today: NVidia’s new 352.86 WHQL drivers for Windows do not work with X-Plane 10. I’m contacting Nvidia now to figure out what has happened.
In the meantime, to fly X-Plane, use the previous 340.52 WHQL driver.
I’ll post more when I learn more; we’ll resolve this with either a driver update or an X-Plane update, based on what has actually gone wrong and which can happen first.
Update: NVidia was able to suggest a work-around in our shaders that avoids what I think is a driver bug. Since we can cut an X-Plane build faster than NVidia can re-release their drivers, I have cut X-Plane 10.36 rc1.
You can get 10.36 rc1 by running the updater and checking “get new betas”; the updater will run even with the newest NVidia drivers.
10.36 rc1 is identical to 10.35 except for version number and a single shader change, but it’s also highly untested; I wanted to get it posted ASAP to accelerate the process. So please give it a try and file a bug if it doesn’t work like 10.35 (but working with the new NVidia drivers.)
Update 2: Sigh…this is what happens when I try to rush out a patch. The 10.36 patch’s free space calculation is totally borked. This will be fixed some time today. (This will be the third time I cut a patch.)
Update 3: the meta-data on the 10.36 rc1 patch is fixed – if you haven’t installed it yet, try again; you’ll need 30-40 MB of disk space, not 30-40 GB. 🙂
Update 4: Steam users – 10.36 will be available for Steam in a day or two; until then, please run older, functioning drivers.
Posted in News
by
Ben Supnik |
I’ll post about X-Plane 10.40 next week – but just a quick note: apparently the Rift will ship Windows-only first:
Our development for OS X and Linux has been paused in order to focus on delivering a high quality consumer-level VR experience at launch across hardware, software, and content on Windows. We want to get back to development for OS X and Linux but we don’t have a timeline.
That’s from a much longer blog post describing the Rift’s hardware requirements and the difficulty of moving that many pixels at that high of a framerate with ultra-low latency. (The tl;dr version is that if you have a Windows laptop you probably won’t be able to run the Rift on it.)
I don’t know what the failure mode will be for not meeting requirements, e.g. will the Rift simply not run, or will it do the best it can with degraded performance.
To state the obvious, if there isn’t an Oculus Rift SDK and driver for OS X or Linux, then X-Plane can’t support those operating systems.
We’ve been quiet on the Android front for X-Plane 10 Mobile but typically around here, quiet is a good thing because it means we’re busy!
We’ve put in a lot of effort and we’re at a point now where we’re going to begin testing the product. More on that in a minute…
First, I’m excited to say that for the first time, our iOS and our Android products will be the same! In the past, Android came around much later than iOS did and the Android operating system and the devices running it were quite a bit behind Apple’s so we had to make our Android product different. This is no longer the case. Google offers all of the same amenities that we’re currently using on iOS. We will have leaderboards, achievements and multiplayer. The product itself will be effectively identical. It’s the same X-Plane Engine, flight model, scenery packages, aircraft etc. There will be no teaser screenshots because…well….it looks exactly the same as all of the iOS screenshots that we’ve already been posting.
Our goal, once the Android version is released, is to keep the iOS and Android products simultaneously up to date. If a new feature is added to one platform, it will be available on the other platform almost immediately (store approval times permitting).
Testing, testing…1,2,3
We’re going to begin testing relatively soon. I have a few odds and ends to tie up before we’ll be ready to go but i’d say in the next week or so we’ll begin our first round. If you want to be considered to be a tester, you can click on the link and submit a request. There’s no guarantee that you’ll get in. We can’t play favorites.
This testing will be slightly different from the norm. Typically we let users Beta test our products to find some bugs early and help us stabilize. With Android however, our goal is to release an early Alpha version to a small number of users and then slowly increase the size of the test group until we’re confident that it’s running properly on a wide range of devices. Then we will expand the group even more and begin Beta testing per usual.
Why are we doing things differently? With iOS, we had one operating system version to worry about (iOS 8) and twelve different devices (every supported iPhone and iPad) running one brand of GPU to test against. Between Ben, Tyler and myself, we essentially own one of everything. On Android, we have three (4.1.X, 4.4.X and 5.X) operating system versions, four major GPU manufacturers and (wait for it….) over six thousand different devices. Needless to say, we do not own one of everything! We need to ease into the testing to find driver issues and other device-specific problems early which is why we’re doing the Alpha test.
We’re mainly focused on testing the Android-specific pieces because 90% of the code is the same as what’s running on iOS which has already been thoroughly tested.
When will it be released?!
As soon as it’s ready! Awwww (sad face), I know you hate that answer…but it’s true. Our goal is to release it as soon as testing shows that it’s stable! This will probably be in a number of weeks, not days but also not likely months.
Last night I posted new versions of WorldEditor, MeshTool, and our command line tools. Follow the “tools” menu on this page to find them – developer.x-plane.com is the official home of our Laminar Research’s scenery tools. (We’re migrating scenery.x-plane.com and wiki.x-plane.com to just be on this site.)
Please remember that the scenery tools bug share the gateway bug reporter; please search the gateway bug reporter before you report a new bug – maybe your bug has already been reported. (You do not need to log in to Jira to search!)
WED 1.4 Beta 2
I have packaged a README with WorldEditor, and including release notes on all fixes since beta 2; bugs filed to the gateway reporter are also updated. Unfortunately I do not have release notes dating back to 1.0.
At this point there are still a number of Linux UI bugs, and Geo-JPEG 2000 support is still out. At this rate I expect to not ship Geo-JPEG 2000 support in WED 1.4 at all.
MeshTool 3.0 Beta 1
This is the first public beta of MeshTool 3 – so far there aren’t new features compared to MeshTool 2; the main change is that MT3 builds X-Plane 10 style DSFs using X-Plane 10 land classes. It is therefore appropriate for add-ons that target X-Plane 10 only.
I have linked to the config and land class files for both versions of MeshTool on the download page; it is important you use the right land class and config files for your project. (Upgrading MeshTool without replacing the config file or land class data won’t work.)
Scenery Tools 15-3
This is a recut of the command line tools. Not much has changed.
- ObjConverter is no longer included; right now we don’t have a compiling version for Windows, and frankly I can’t think of a good reason to use this tool ever.* If ObjConverter was, for some reason, part of your workflow, you can still download it from the 12-2 tools release; email me and I can also explain how to use a different, better option to convert your objects.
- DDSTool now defaults to sRGB gamma on input files. Both the old and new version read gamma information from your source PNG file, but if the PNG file is not tagged properly (and it’s very easy to have tagging go wrong, particularly when Photoshop** is involved) you would get classic Mac gamma in the old version. This is basically never what you want; the new recommended work-flow is to always work in sRGB, use the new DDSTool, and you’ll always get the right results.
* ObjConverter tried to convert 3DS and DXF files directly to OBJ. But since there is no standard encoding of animations, materials, and other X-Plane specific data in 3DS, the converter could only copy the mesh and texture map. This made it appropriate only as a way to get from one 3-d program to another.
But even this use is not a good way to move your data, because it strips out animation and meta-data. My suggestion is that you export directly from 3DS using an export script, or open the source 3DS or DXF file in a modeler that has native X-Plane support like Blender or ac3d.
X-Plane’s OBJ format is not meant as a way to move your models between programs; it is meant only as a final destination format for shipping your scenery.
** The problem with photoshop isn’t that it writes the PNG files incorrectly, rather the problem is that Photoshop is way too smart; it writes a full color profile when libpng only understands a few simple constructs like sRGB and gamma. So what I was seeing was libpng not understand the sRGB color profile from Photoshop because the encoding was too complex.
Defaulting to sRGB is a bit of a band-aid, but it also is what everyone should use all of the time.
