Blog - Page 120 of 145 - X-Plane Developer

Things That Are Not Jokes

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.

Posted in Development by Ben Supnik | 1 Comment

Instaling to the Desktop (Let’s Start a Riot)

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!

Posted in Development by Ben Supnik | 22 Comments

DataRefs, the Cirrus, and Opt-In

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.

Posted in Aircraft, Modeling by Ben Supnik | Comments Off

Road Overlays and Draping

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.

Posted in File Formats, Scenery by Ben Supnik | 6 Comments

You Can’t Replace Objects in Liveries

The livery system lets you replace the image files used by an aircraft’s exterior paint, and it lets you replace the image files used by the objects that are attached to the plane via the “objects” folder.

But the livery system does not let you replace the objects themselves.

(It also doesn’t let you replace or modify the actual ACF file or generally change the functional behavior of the plane. The livery system is just for paint, not airplane mods.)

Posted in Aircraft, File Formats by Ben Supnik | 7 Comments

More Threads – the Installer

Nine women cannot have a baby in one month – that’s the classic example that gets thrown around computer science for the difficulty of parallelization – that is, just because we have ten times as many resources doesn’t mean we’re going to go ten times as fast.

Problems of scalability via parallelization have become very important for graphics engines as everybody and their mother now has at least two cores, and users with more serious hardware are going to have four.

I get asked a lot: “will X-Plane utilize X cores…” where X is a number larger than two. My general answer is: sometimes, maybe, and probably more in the future. I can’t make strong predictions for what we’ll ship in the future, but the general trend for the last 18 months has been us using more cores every time we go into a piece of code to do major architectural changes.

I’ve been doing a lot of work on the installer this week – the first major overhaul of the installer since we originally coded it all the way back at X-Plane 8.15. And the new installers and updaters will try to take advantage of multiple CPUs where possible. A few cases:

The X-Plane updater runs an MD5 checksum over the entire X-Plane folder to determine which version of the various file components you have and whether they need to be updated. This s not a fast process. I am working on threading this so that more CPUs can work on the problem at once. It looks like there will be only modest benefits from this because the process is also highly bottlenecked on the disk drive.
The installation engine from the DVD will use more than one CPU to decompress files. For zip compression this wasn’t very important, but the scenery will be compressed via 7-zip compression to get us down to disk DVDs. 7-Zip compresses DSFs about 10% smaller per file than zip, but it’s horribly slow to decompress, so being able to throw twice the CPU at it is a big win.

Now on one hand, our top performance goals are for the sim, not the installer. On the other hand, faster installations are good. But my main point here is: when we wrote new code four years ago, we assumed one CPU and a nice graphics card. We now assume at least two cores and possibly more, and that informs the design of every new feature, not just the rendering engine. If we don’t create a multi-core-friendly design, we’re effectively leaving at least 50% of the CPU on the table.

Posted in Development by Ben Supnik | 5 Comments

When Will X-Plane Stop Saying It Is Beta?

If you look at the about box for X-Plane 9 RC1, it still lists itself as a beta.

Here’s the thing: that label is dynamic. Right now when X-Plane calls up the server to see if there is a new patch, it notices that its current version (900Rc1) is newer than the latest “final version”. (This is because we haven’t declared any version of 9.xx final yet.)

So it thinks for a second and goes “oh – I’m newer than the latest final version, I must be a beta.” And that yellow beta label appears.

When we finally declare a version final (which involves tweaking the versions listed on the servers) the existing code will then look at the server and go “oh, I’m the latest version” and that beta label will disappear.

Posted in Development by Ben Supnik | Comments Off

The Global Scenery Folder

Let me answer two questions right now:

If you bought version 9 beta DVDs, you will not have to buy new ones when version 9 goes final.
If you bought version 9 beta DVDs, you do not need to manually move around any of the global scenery files that our installers put on your hard drive.

Now about this global scenery folder…

X-Plane stores its scenery in packages – a scenery package is a folder that contains all of the files needed for a given scenery element, whether custom or default. In X-Plane 7, scenery packages were only used for custom scenery, and always lived in the Custom Scenery folder directly next to the X-Plane application. This provided an easy way for users to drag third party packages into a single location to install them. (Before the custom scenery folder, installing scenery could involve a lot of “put this file here, and that file there”.)

X-Plane 8 added a second location, the Default Scenery folder, which is hidden away inside the resources folder; it acts as a repository for scenery packs we ship with the sim, such as the one that contains various airport elements, and the default road packs.

In X-Plane 7 the global scenery lived directly in the resources folder in its own home; in X-Plane 8 the global scenery lives in packages inside the default scenery folder…this allows us to use one piece of code (the package loader) to load all scenery, custom and global.

The only real differences between the default scenery and custom scenery folders was priority and intended use; custom scenery is loaded with higher priority than default scenery (so you see your custom add-ons replace our default work), and the intention is that the default scenery is for Laminar to update via the web-updater and custom scenery is for you to put things into that you download off the web, etc.

With X-Plane 9 we are introducing a third location for scenery packages: the “Global Scenery” folder. It will live next to the Custom Scenery folder and X-plane application and be the location for global scenery. Its priority is intermediate – higher than default but lower than custom.

Now here’s the funky thing: the X-Plane 9 beta DVDs place the global scenery into the custom scenery folder. If you’ve ever looked at the ranking of scenery packages, you’ll see that they come out lower priority than all custom scenery, regardless of the alphabetical sorting that is usually used. The sim recognizes the peculiar placement of the global scenery and effectively labels it “global”.

Future DVD pressings will simply place the global scenery in the new global scenery folder. Thus we get to the original two answers:

You won’t have to buy new DVDs if you have the betas; the sim will continue to work with either the beta or the newer layout for global scenery for the entire v9 run.
Because both layouts work you don’t need to move anything around. I suggest you not move any files to lower the risk of breaking things.

Posted in File Formats, Scenery by Ben Supnik | 3 Comments

Scenery Tools Release

I have posted the first “combined” scenery tools release. Basically ObjView, ObjConverter, and DSF2Text (now named DSFTool) are packaged together with DDSTool (for making DDS images from PNGs) and the new MeshTool (for making base meshes); a UI application called XGrinder provides drag & drop support for most of the converters.

The tools releases will be by month (e.g. March 2008) and each release will contain the latest for all of the tools in the release. WED and the AC3D plugin will continue to be separate downloads.

I have also posted another snapshot of the source code, and generally I’ll try to do a source code post whenever I do a tools post to keep the two in sync.

The AC3D plugin has been updated; I hope to have a new WED posted in the next few days.

Posted in Scenery, Tools by Ben Supnik | 1 Comment

X-Plane 9: What Comes Next

X-Plane 9.00 is going to be going final pretty soon – we’re on RCs right now. But this is hardly the end of the road; rather it’s the first step for a number of new development areas. What comes next?

Tools: I am working on tools releases now; a few users already have alpha copies of MeshTool. My hope is to have some new tools posted tomorrow, with more by the end of the week

More rendering engine/shader work: X-Plane 9 only begins some of the shader work we want to do; more engine enhancements will be coming in 910. Like 9.00, more advanced rendering will consume more hardware, and will be scalable via rendering settings.

Systems and Airplane SDK: X-Plane 9 introduced a lot of new features for airplane modeling, but there’s still more to do. I hope to have the panel region system and advanced lighting options all fleshed out for 9.10. Austin is doing a lot of work on systems modeling. We’ll be making more new airplane-related datarefs to tie it all together.

Orthophoto Scenery: I don’t know if this is going to happen or not, but we get more and more requests for large-orthophoto-scenery support in X-Plane; MeshTool is only going to increase that desire by making it possible to cover large areas with orthophotos without sacrificing framerate. So I would like to do some work on the texture pager, but I do not know if I’ll be able to do that in time for 9.1.

My hope is to get 9.1 into beta early so that we can start getting third party aircraft authors involved with trying new features. If you are working on an advanced airplane, keep in touch!

Posted in Aircraft, File Formats, Scenery by Ben Supnik | 6 Comments