I think Austin has made this clear, but…
IF you got x-plane 9.00 BETA, then you do NOT need buy version 9.00 final… if you just run the updater, then it will UPDATE your beta TO the final version.. there is no need to make another purchase.
BUT, if you WANT to have the FINAL version on DVD for backup purposes, or to get the latest DVD INSTALLER, then you should re- purchase x-plane 9.00 now… though i do not recommend or suggest that at all… you just CAN, if you want the FINAL, NOT BETA, on DVD
The key equation here is:
Beta DVD + Web Updates = Final Sim
Everything that has changed from the beta DVD to the final DVD is available for free using the updater. If you want to buy more DVDs, Austin’s not going to stop you, it’s a free country. But we made sure that everything that was big and couldn’t be downloaded would be there on the beta 1 DVD so that users could buy the beta DVD and have a complete sim.
So if you have a beta DVD, just use the updater to get the latest version (and RC3 is final, so if you have RC3, you’re already done) and you’re all set.
(Am I beating this to death? Yes…but…people get very angry at the idea that their DVDs are “not the latest” – so we put a lot of effort into making sure that you can buy the DVD early on and still have the latest!)
Now that X-Plane 9.00RC3 is final, we’ve released a complete set of “next-gen” updaters and installers, identifiable because they run at 800×600. With these new installers and updaters, we’ve changed the way updating the sim works.
In the past, we had one application (the “net installer”) that would:
- Update any existing files it found and
- Get any files that were missing.
This was useful in that you could get a fresh copy of X-Plane or update your existing one.
But it also made life a living hell for our tech support folks; the single biggest tech support item we would get is users who would:
- Go to update X-Plane using this tool.
- Pick a new location, not their existing install.
- Download 700 MB of demo instead of 30 MB of updates.
- Run the demo and discover they now have no scenery.
- Become confused and call or email us.
To try to combat this confusion, we’ve separated the concept of installing a demo from the concept of updating the sim.
The new “web demo installer” always makes a new copy of X-Plane. It will not install into an existing location; if you ask it to install to an existing folder, it will demand you pick a new name. It will always fetch the full 700-MB demo.
The new “updater” always picks from an existing copy of X-Plane (presented as a list of known X-Plane 9 installs, rather than a file picker – one of the big problems was people picking a folder inside the X-Plane folder). It always updates this existing folder, and will thus never fetch a new install or create a new install.
My hope is that users can identify the task they wish to execute (install a demo, or update what they have) and thus use an application that will guide them through a path without pitfalls. Top concern is that the updaters not install second copies.
Advanced users: you can still do anything with these tools that you could before – but the functionality is now split into two apps. The updater will never rename an existing folder name (as this breaks people’s shortcuts), and the installer will let you customize both the install name and the install location. You don’t have to install “X-Plane 900r3 Demo” to the desktop.
Finally, a note on beta: previously we had a separate set of tools for beta; searching for betas is now a check-box preference that puts nasty red writing up. This is mostly to keep me sane and the number of installer builds down to what I can count on my fingers. So when the next beta comes out, just take your updater and enable “search for betas”.
I had to do some research into compression algorithms recently, because we had to squeeze the global scenery onto fewer DVDs for retail distribution. We did this mostly by completely filling the DVDs, but we also had to use 7-zip compression to get about a 10% improvement in compression ratios.
DSFs are not the best test of compression efficiency because the format has been organized to help algorithms like zip compress them – the improvement with 7-zip and RAR was a lot less than you’d get with, say, a text file.
Anyway, my point here is: let’s not use RAR – it’s the new GIF. Every now and then a file format comes along with some kind of restriction that keeps everyone from doing everything with it. In GIF’s case, you had to buy the right to create GIFs, and in the case of RAR you have to buy the right to compress RARs.
I think that having these kinds of entanglements in fundamental low level file formats (like how do we compress our data or save our images) is really bad for the software community as a whole; it balkanizes raw materials. And file formats stick around for a long time – even though GIF is made obsolete by PNG you’ll still find them all over the web.
The lure of RAR is of course higher compression ratios than zip. But 7-zip can do the same thing, and unlike RAR, has the potential to be completely free, which means it can be completely ubiquitous.
Macintosh users understand the problem here: for the longest time “StuffIt” archives were the standard way to compress data on the Macintosh. The file format was proprietary, so you couldn’t even make your own program work directly with StuffIt archives. Now that zip has taken over on the Mac, getting data between Mac and Win is easy – you can just zip something using the operating system and send it to all your friends.
Let’s not go back into the “bad old days” of proprietary utilities and a lack of integration with regular apps. I say: if you can stand to use zip or bzip instead of RAR, vote for what’s open and has a future, not what is slightly better now but will just be a pain in the ass in three years.
I don’t know how much of a problem this is yet, or how much of a mess it’s going to make of people’s scenery. Here’s the background:
- ASCII defines 128 character values, mostly letters like A-Z. With ASCII, you can write English and that’s just about it.
- The byte that ASCII is stored in on all modern computers can store 256 values.
- Clever people got the idea to put some more letters in the other 128 values to create characters like é and å.
- People defined different “codepages” that have different sets of charcters in those “upper 128” slots. So one code page might be good for French, another for Russian.
- Modern software uses unicode characters, which have a lot more than 256 values, and can thus hold all sorts of characters in one string.
Code pages were around for a while, but they’re not a good idea. The problem with code pages is that the same numeric values are used for different letters. The result is that a correctly written Russian document, when converted to a different code page, looks like gibberish. And if you want one document with both French and Russian, well, one code page doesn’t do you much good.
Now X-Plane’s handling of non-ASCII characters is pretty poor in version 9.00 (and all previous versions). It will draw ASCII and take keyboard input from ASCII but not much else. If you hit the é key on your foreign keyboard, probably nothing will work.
But it turns out there is one way to use foreign characters in X-Plane – I just discovered it tonight. If you use Windows and your system’s codepage* is set for a foreign language, you can use those foreign language characters in an OBJ file to name a file on disk with the same name. In other words, you can have textures named été.png and it will work.
Sort of. If you then change your system to work in Russian (which changes the code page) your texture will stop working. The reason things stop working is that the file system uses unicode; that is, the OS knows that été requires a Latin character set that’s French friendly, but X-Plane is using Russian since the system’s set that way. The result is that the file system has no way name the file in Russian and we fail to load the texture.
So using the “high 128” characters from your system’s code page to make non-ASCII characters is a bad idea because your scenery won’t work on other people’s computers.
But it’s going to get worse in the future. X-Plane is going to start using UTF8 in a lot of places. UTF8 encodes unicode into one byte characters by using more than one byte for non-ASCII characters, but as a result it uses the “high 128” character codes for very different things. été.png in UTF8 comes out quite different.
I’m not sure how we’ll handle this yet (use UTF8 in the scenery system or have some kind of backward compatibility). But for now I can only advise one things: use ASCII only for your file names. In fact, a good guideline for filenames for the scenery system is to use only numbers, letters, and the underscore.
I’ll post more about scenery soon; this will be short and not terribly topical.
The X-Plane Plugin Wiki used to have no login requirements – anyone could just click and edit. All was good for a while, and then I logged in one day to find some of the most highly used pages stuffed to the gills with the phrase “Nigritude Ultramarine” over, and over, with links to other sites.
You can read about this phrase, why it was invented and what was going on here.
Our response was to put a user login requirement on the site, and we haven’t had a spam problem since (knock on wood) although we do seem to get what appear to be bogus signup requests. (They don’t really hurt anything, they just clog the user database. I’m not sure why anyone would sign up if they don’t intend to actually do anything.) But a few thoughts on Nigritude Ultramarine and people’s attempts to get junk spam sites into the top of Google’s search listing:
- I was pleased to see a real site (this FAQ) as the number two search hit for the term…this real link from a real blog to them can be sort of a contribution to their page rank.
- I have faith that Google will continue to fight the technology arms race against seach engine optimizers…Google has gobs of money and an immense motivation to do so.
- Apparently link farmers, in an attempt to raise their page rank, have been using bots to automatically steal blog content. I haven’t seen this myself yet and I’ve never had an X-Plane query go to a junk site. But some blogs I read have complained of this happening.
Only mildly related, there is an X-Plane Wiki, and I’ll try to point people toward it next week; I’ve been posting things there rather randomly in an attempt to get underdocumented stuff written down somewhere.
I just finished about 15 pages of emails, mostly to Andrew McGregor (who is the very first MeshTool user) and also Benedikt Stratmann (whose x737 is on the bleeding edge of plugin-based aircraft) and AlpilotX (we all know about his forests). Probably all three are wondering how the hell I have time to write so much on weekends. (The answer is of course that my frisbee game got rained out. Foo!)
In the meantime, probably about 300 other people who have emailed me in the last few
months are wondering why the hell they have heard nothing from me. My in-box looks like a mail server exploded. It’s not pretty.
So let me blog for a moment about the “relationship problem”. Simply put, there are two of us (Austin and myself) and about a thousand of you (third party developers doing cool and interesting things with X-Plane) plus significantly more users, some of whom have some very weird tech support problems.
In this environment, our algorithm for who gets “developer attention” is pretty broken and subject to total thrash…there is a huge element of random luck (who emails me when I am recompiling the sim vs. debugging a nasty bug).
I’m aware of both how hard the task Austin and I face and how frustrating it is for a third party developer because I’ve been on both sides. Before I worked for LR, I was a third party and I was always astounded that Austin couldn’t remember what we talked about last week.
Then I started working for the company and saw what it’s like. Imagine sitting at a train station watching the trains go by* (at full speed, not stopping) and someone says “last week I waved to you out the window and you waved back, remember me?”
So I would advise three things to the neglected third party:
- Be firm – you may need to ping us again because at busy times we can’t always keep track of who has asked for what.
- Be patient – if you need something the week we’re burning DVD masters for a second time (because the first set failed at the factory) then you’re going to have to wait.
- Don’t take it personally…a lack of a response usually indicates overload inside the company, not a poor opinion of your work!
This blog post has rambled enough, but it may feed well into the next one.
* This analogy is totally stolen from “How Doctors Think” by Jerome Groopman – he uses it to describe the task of primary care physicians trying to spot the early signs of a very rare illness among a fast-moving train of patients who are almost entirely healthy. I strongly recommend this book particularly for Americans – we need to understand the forces at work in shaping the quality of our medical care!
Just to clarify, these things are not April Fools Day jokes.
- RC3 coming out.
- The installer installing to the desktop.
And as always, relax, you will be able to put the install anywhere you want via the “destination” button.
I am intentionally announcing a decision that might make experience X-Plane users unhappy – my goal here is to solicit arguments against it (if there are any) since it’s a sort of a strange change.
The proposal is to make the default installation location for a new copy of X-Plane be…the desktop.
EDIT: to clarify some of the blog comments, this is a default installation location; the user will be able to customize both the folder name that is created to contain X-Plane (default will be “X-Plane 9”) and the folder into which this new X-Plane 9 folder will be placed.
The desktop? What are you hacks thinking? Well, here’s what we’re thinking:
- Our goal is to minimize tech support calls during installation. This means making an installer where the last computer-savvy users will not get stuck in the installation process. If you know what you’re doing, you’re not who we’re aiming at. (I reiterate, we get a lot of calls about installation problems from users who have never used a computer before.)
- We need a location that the user installing X-Plane has access to, guaranteed. That rules out places like the Applications folder on OS X – we expect the least sophisticated users to not customize the install location, so we need one that will work.
- We need a location that the user can find. This rules out their home folder (the user may not use their home folder or know it exists) as well as the C drive and the Program Files folder on Windows (both can have their files hidden by default on Windows XP to keep users from breaking tings).
The desktop solves all of these problems. Every user has write-access to his or her own desktop, and every user knows where it is.
If, like me, you don’t want X-Plane on your desktop, you can simply click the “destination” button in the installer to put it somewhere else.
As a final note, the strongest alternative to this on Windows was to put the app in program files and build a start menu short-cut. But this starts the sweater unraveling…if we have a shortcut, we need an uninstaller rather than trashing the folder…if we have an uninstaller, how do we cope with multiple installs…by the time you solve these problems you have a huge amount of new untested code.
I’d like to get a more Windows and Mac interface compliant installer, and we’ll get there eventually, but the work I’m doing now is aimed at the biggest real problems we face:
- Users not knowing where X-Plane is.
- Errors during the install in its default configuration.
- Problems installing and configuring scenery.
Okay, there it is, fire away!
There’s a bug in X-Plane 900 RC2 that will be fixed in RC3. Basically when you’re flying in the Cirrus with a friend (also using the Cirrus via multiplayer) you’ll see your own control deflections on his or her plane.
Understanding this bug gets into the way datarefs and object animation work. In simple terms, a dataref is an access point to data provided by some other part of the sim…the flight model, or another plugin. An object references a dataref as its source for animation values. So if you want to animate the wings, you use sim/flightmodel/controls/lail1def or sim/flightmodel2/wing/aileron1_deg.
Now the question is: when you access this dataref in a multiplayer context, which aircraft’s ailerons are you talking about? It turns out the answer depends.
- For all datarefs except sim/flightmodel2/ and sim/cockpit2/, if the dataref needs to access a plane, the access is to the user’s plane (flight 0), always.
- For sim/flightmodel2/ and sim/cockpit2/, the access is usually to flight 0. But if we are drawing an aircraft, these datarefs refer to the aircraft being drawn!
(Note: this second feature only works correctly in RC3.)
So when you want to animate the wings of your plane in X-Plane 9, by using the sim/flightmodel2/ datarefs in your object, you’ll get the behavior you want: animation with the first plane’s flightmodel when your plane is loaded as plane one, animation with the second plane’s flightmodel when your plane is loaded as plane two, etc.
Of course the rule of thumb is simple: if working on v9, always prefer sim/flightmodel2/ and sim/cockpit2/ when possible for animation work.
Could we have simply made the sim/flightmodel/ and sim/cockpit/ datarefs have this “pick the right airplane” behavior? Possibly, but I took the more conservative opt-in approach. Basically any time we want to change the behavior of the sim we can do one of three things:
- Change it globally – all third party content is affected; don’t like it, too bad. This is how pixel shaders work; if shaders are on you can’t disable the different fogging they provide for your airplane or object.
- Opt-in – you have to change your content to get the new behavior; old content defaults to unchanged. This is how the new datarefs work. You have to edit your content to use the new datarefs to get the new behavior.
- Opt-out – you have to change your content to avoid the new behavior. For a while cockpit lighting was like this, but I received so many reports of version 8 airplanes looking totally strange that I changed the cockpit lighting choices to opt-in.
Generally opt-in is the safest thing we can do to leave previous content working; if we make a change globally then we break any content that doesn’t work well with our changes. Datarefs are used so heavily that a fundamental change in how they work would probably not be safe.
Given a choice between opt-in and opt-out I’ve come to prefer opt-in; both require the same amount of work for LR (we have to write code to support the old and new behavior) so why not do the thing that provides better compatibility?
Finally a general historical note: sim/cockpit2/ and sim/flightmodel2 are not just there to provide new behavior with objects; they are designed to give us a clean start in providing only authoring-related datarefs in an easier-to-understand format. The original datarefs were meant only for programmers, so we didn’t worry too much about usability. Since then, datarefs have become the communications medium for panels and a lot of 3-d animation.
So not only do sim/cockpit2 and sim/flightmodel2/ provide correct animation behavior, but they’re also easier to read.
An important distinction between sim/cockpit2 and sim/flightmodel2 is that they partition the datarefs based on perception vs. reality:
- Generally sim/cockpit2 shows datarefs as the pilot sees them in the cockpit, and actions as the pilot commands them.
- Generally sim/flightmodel2 shows the plane’s behavior as it’s really simulated, and actions as they actually happen.
In other words, when the pitot tube ices up, sim/flightmodel2 shows the real airspeed and sim/cockpit2 shows the incorrect airspeed. When the hydraulic system fails, sim/cockpit2 shows that the pilot wants to bank, and sim/flightmodel2 shows that the ailerons aren’t really moving much.
What this means is that you should use sim/cockpit2 for cockpit objects and generic instruments and sim/flightmodel2 for objects attached to the airplane exterior. This will assure that failure simulation works correctly (e.g. failures are perceived correctly by the pilot) and the external control surfaces match the plane’s physical behavior.
If you’ve studied sim/cockpit2 a lot, you know it’s pretty incomplete. We’ll be adding the rest of the cockpit systems in 910. I would have liked to get the entire set of airplane changes into 9.0 but there’s a lot more to do – not just more datarefs, but also manipulators for 3-d objects and a new lighting model for aircraft interiors. I think 910 will finish what 900 has started in terms of new airplane features.
Final random note: RC3 will allow you to pick any dataref for a generic instrument, not just sim/cockpit2 and sim/flightmodel2. This is mainly so people writing plugins can easily hook their datarefs up to the panel by editing datarefs.txt instead of typing them by hand.
X-Plane 9 allows you to put roads in an overlay DSF, but this isn’t actually that useful yet. The problem is that roads are specified using MSL elevations – that is, they are positioned in absolute space. So you have to know where the ground is to build a road, which defeats the whole idea of an overlay.
This dates back to X-Plane 8.0 – originally all scenery load was done when a DSF was loaded, with the sim paused. In that condition, keeping scenery load fast was a high priority. So I set roads up to be “pre-draped” (that is, their heights are pre-determined when building the DSF). Back in the day it was a win.
Now we have multiple cores and DSF loads in the background, so we very easily could “drape” a DSF…but it gets weirder. A road’s sub-type is specified in the DSF – and sub-types are used to define bridges.
Now that’s not incompatible with a “draped” scheme – imagine a road whose height is specified AGL, so a height of 0 means “run the road along the base mesh” and a height of 10 means “10 meters above the base mesh.” Now you would set the road type to overpass as the height went from 0 up to 10 meters, then back to 0, forming a bridge.
The only problem is what happens if the ground is really weird looking. In practice what we want to do is keep the road’s slope as constant as possible and build out bridges based on that. The effect can be hard to see, but if you look at bridges in the US scenery, you’ll see that sometimes the banks to a river slope down but the road stays horizontal, forms a bridge, and then stays flat as the banks come up again. This happens because our road processing code (in the DSF builder) tries to limit road slope.
That’s not an easy effect to create in an overlay…you’d basically have to increase the road AGL at the rate the base mesh’s AGL is decreasing (if only you could know that).
So the questions I am debating now are:
- Are AGL-draped roads useful if we don’t know what the base mesh will be like?
- Does it make sense to have some other abstraction to help smooth roads when the base mesh is bumpy (and can we make something that is both simple and useful)?
Like most philosophical things I debate, this isn’t scheduled to go into the sim that soon. Improved shaders, a more complete airplane SDK, and a better texture pager are all ahead of road improvements, which pushes roads out quite a bit I think.
