There is a bug in X-Plane 901 where, when you pick a “forward no panel view” (forward with HUD, forward no HUD) you see the 3-d cockpit in the Cirrus Jet. The forward no panel view is typically used to make the center display for a multi-sim setup where one computer drives each “window” of the cockpit, or three computers make a wrap-around set of screens.
(You would actually use forward-no-HUD for all of these views, with the view offset rendering controls creating the view-angle effect.)
It turns out that this bug reveals some pretty weird sim behavior; the rest of this post explains what’s going on and how it affects authors.
View Settings – What They Do
These fifteen check boxes can be found in the PlaneMaker “viewpoint” settings screen, under the “view” tab.
Each row controls the drawing of some part of the aircraft: the top row controls the drawing of the 3-d cockpit object, the middle row the inside surface of all aircraft parts, and the bottom row the outside surface. Since most aircraft parts have no holes in them (unless you “draw” them with alpha) usually it’s the exteriors you need drawn. Back in the old days, some authors wanted to have the interiors be drawn, but with X-Plane 8 and 9 authors usually create attached objects to draw the interior of the airplane. So that middle row is basically legacy.
Now the columns represent the different types of views, and this is where it gets confusing, because the labels are not so obvious.
- The first column applies to the forward 2-d panel view (‘w’ view).
- The second column applies to the 3-d cockpit view (‘ctrl-o’ view).
- The third column applies to the forward no-panel view (shift-w view).
- The fourth column applies to the side 2-d panel views (q and e views).
- The fifth column applies to external views (‘a’ view, etc.).
Here are some notes by number:
- If you check this, the 3-d cockpit will be used in the 2-d panel forward view. This is handy if you only want to make a 3-d cockpit. The F-22 that ships with X-Plane does this – the 2-d panel is really the 3-d cockpit viewed head-on.
- You always want to check this, otherwise the 3-d cockpit will have no 3-d cockpit object.
- You never want to check this, because you don’t want to see the 3-d cockpit in the forward no panel views! But see below.
- You can check this to use the 3-d cockpit object instead of 2-d side panels. The default P180 does this.
- Check this to draw the 3-d cockpit object in external views. You probably want this if it’s possible to see in through the windows of your plane, otherwise the cockpit will be empty!
- You basically never want any of buttons 6-10…
- They show the interior of the aircraft geometry, so you’d only want this to see the fuselage from the inside for example.
- But the inside of your fuselage will still have the external fuselage texture, which is ugly.
- That’s why most authors use objects to model the aircraft interior.
- So in summary, don’t check 6-10…use attached objects to model the inside of your airplane, as well as the cockpit object.
- Check this to see your prop disc in the 2-d panel.
- Check this to see your prop disc and wings in the 3-d panel as you look around.
- You probably don’t want to check this unless you want to see a prop disc in the forward no-panel view. See below.
- Check this to see you wings and prop disc from the 2-d side views.
- You always want to check this – otherwise you won’t see your plane from the outside!
That was a lot of detail, but hopefully it will act as a cheat-sheet for setting these up. In X-Plane 920, the user interface has been relabeled – those 15 comments are now in the mouse-over help.
How 900 Works
X-Plane 900 and earlier has two very strange quirks:
- It ignores all of the “forward-no-panel” check-boxes and simply never draws anything in this view.
- It defaults these check boxes to checked when you make a new aircraft.
These are unfortunate behaviors when taken together – it means a lot of aircraft have their forward-no-panel view flags set to true.
How 901 Works
The bug in 901 (and 902b2) is that it honors all view flags – even the forward-no-panel ones. So for the first time we can see that 3-d cockpit that the Cirrus Jet has been asking to have drawn.
How 902 Will Work
The short-term fix for 902b3 (or 902r1) will be to act like 900 – ignoring the forward-no-panel flags so planes just work. This is a quick-fix because 902 is just a localization patch.
How 920 Will Work
920 will feature a real solution. First, 920 will revise the .acf file version number. This is something we do fairly often – the version number was revised 5 times during the v8 run. Revising the version number does not change backward compatibility; 920 will open all of the aircraft that 902 does. What it does mean is that aircraft created for 920 will not open in 902. (This is necessary – a number of 920 features, like key-framed generic instruments, simply don’t exist in 902.)
This versioning gives us a hook to fix the forward-no-panel view for real:
- When an older plane is opened in 920, the forward-no-panel check boxes are cleared.
- 920 will honor those check boxes.
Thus all old planes will show nothing in the forward-no-panel view (that is the expected 900 behavior) because the check-boxes are cleared on load. But authors will have the option to check the forward-no-panel options and resave as a 920 aircraft, and thus choose to have a prop disc in the forward view, for example.
I commissioned PropsMan
to make me a test bed for some of the new 9.20 airplane features. Clearly he has never worked in a furniture store — this is what he sent me!
In his defense, it’s very comfy, flies surprisingly well, and is a great comprehensive test of a huge pile of advanced aircraft features. Yes, you can close and open the laptop with the mouse in the 3-d cockpit.
(One of the new features in 920 is “no-op manipulators
” – that is, the ability to make 3-d geometry “eat” clicks before they get to the panel, without having to use panel texture as the consuming surface. So when the laptop is closed, you cannot click on the buttons that are exposed when it is open.)
My real question is: how did he know about Laminar’s new secret test vehicle?
X-Plane 902 has an instrument limit of 400 instruments for the 2-d panel and 391 instruments for the 3-d panel. 920 will remove these limits, allowing you to build very complex panels via generic instruments.
(An altitude indicator might be built out of 3 or 4 generic instruments, so 400 instruments is a lot for pre-built but not for generic-instrument-based panels.)
The Manipulator RFC
has been rewritten…the new one proposal is less complex.
There are a lot of other panel and airplane-related changes coming in 920 too…
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.
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.)
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!
If you have a third party add-on and you haven’t tested it against X-Plane 9, well…honestly it’s probably a little bit too late to fix compatibility bugs now. We’re in RC, and only changes to fix critical bugs are going into the sim; everything else will have to wait for 9.1.
So if you have an add-on and you haven’t tested it against 9.0, for crying out loud, do it now! Submit the bug anyway – if we can’t fix it for 9, we can fix it for 9.1. But…after almost 14 weeks in beta, we’ve got to close this build up.
BTW a minor side note on fuel pumps…
In X-Plane 864, an airplane will run even if the electric fuel pump is off. (However, if the fuel pump failure is triggered and the electric fuel pump is off, either by switch or electrical-system failure, then you’re out of fuel.)
X-Plane 900RC1 restores this behavior; in beta 25, an electrical failure would turn off all sources of fuel. This is wrong for a plane like the C172 where gravity can feed the engine.
In the long term X-Plane does need a more complex abstraction (e.g. does this plane have gravity feed or engine drawn fuel, or engine driven pumps, etc. etc.) but for now the 864 model, while inaccurate and incomplete, causes less problems than beta 25, which was simply wrong for a number of planes.
Here’s a summary of the new airplane features in 9.0 (and some coming). Hopefully this will give you an idea of what new capabilities are available for modeling planes in X-Plane 9. This list will sound like a broken record – virtually all of these features are optional; you don’t have to recut your finished airplanes to use them in version 9.
2-d vs. 3-d Panel
You may have noticed the new “3-d panel” option in PlaneMaker 9. This allows you to build a separate panel for the purpose of providing the texture to ATTR_cockpit (or ATTR_cockpit_region). You can then:
- Provide alternate instrument artwork in a cockpit_3d folder. (This lets you have perspective artwork for the 2-d cockpit and orthogonal artwork for the 3-d cockpit.)
- Pack your instruments together tightly to save space. (There is a real cost to large panels, so using a 1024×1024 panel for the cockpit object is a lot better.)
The 3-d panel is strictly optional, fully replaces the 2-d panel only for cockpit objects, and is activated by providing a custom panel background in a cockpit_3d folder. (See the “Example Plane-Widescreen+objects” plane in beta 19.)
Cockpit regions are an alternative to using the entire 2-d panel to texture your objects. They provide a few advantages:
- Performance. By requiring a power of 2 and allowing you to use a sub-area of the panel, cockpit regions avoid a lot of wasted computing that ATTR_cockpit can cause.
- Next-gen lighting. Unlike ATTR_cockpit, real 3-d lighting is applied to the panel when you use this attribute. This means that you will get a gradual decrease in light on your geometry (correct based on the angle of the sun) that matches the rest of the object.
Please note that you can mix and match which way you get your cockpit texture and whether you use the 2-d or 3-d panel feature (above) independently. However, you can only use ATTR_cockit or ATTR_cockpit_region in your airplane, not boht. ATTR_cockpit is still supported.
Generic instruments let you build instruments that follow some basic shapes (needles, tapes, etc.) that can be tied to any dataref. This both lets you customize particular instruments very precisely or create an instrument driven by a plugin dataref. These instruments are optional in version 9 – the old “premade” instruments are still supported.
X-Plane 9 provides new datarefs targeted at airplane authors. The datarefs are better organized and have clearer names. But the old datarefs still exist, so legacy planes do not have to be updated.
Generally the entire cockpit should use only sim/cockpit2/ datarefs, and the plane exterior should use only sim/flightmodel2/ datarefs.
One special feature of these two sections: if your plane is used as an AI plane, these datarefs will animate the plane with the AI plane’s control deflections, not the user’s control deflections. So using these datarefs fixes the “AI animation” problem.
Plugins in Aircraft Folder
Version 9 airplanes may have a plugins folder (inside the ACF package) with fat plugins inside them. If you develop a plugin for your airplane, consider packaging it this way — this will allow your users to install the airplane with a single unzip for all platforms and no extra “drag-this-file-here”.
Plugins in the airplane folder is optional – you don’t have to provide a plugin, and plugins that are installed in the main Resources/plugins folder will still work. Still, I encourage you to use this feature because it makes the install process a lot simpler. The X-Plane SDK website will have documentation on fat plugins.
X-Plane 9 features a new “liveries” folder. Liveries (replacement exterior paint for airplanes and their attached objects) can be placed in packages in the liveries folder to greatly simplify the process of repainting an aircraft. See the “Example Plane-Widescreen+Objects” for an example.
While the liveries feature is optional, I strongly encourage anyone doing repaints to adopt it. Liveries can be switched by the user in the sim without any file manipulation; there is thus no risk of accidentally deleting or breaking an aircraft.
Large 2-d Panels
In X-Plane 9, a panel can be up to 2048×2048 in size. You pick the dimensions. The panel will scroll horizontally if necessary.
Note that if you use the new 3-d panel feature, the 2-d and 3-d panel do not have to be the same size. I would recommend a large 2-d panel (to fill large monitors) and a smaller 1024×1024 3-d panel (for performance).
X-Plane 9 will allow you to hide aircraft parts. Many v8 planes use OBJs to model the plane geometry, and use a transparent ACF texture to hide the ACF. Setting the parts to “not drawn” saves the CPU time that X-Plane would spend drawing the airplane, and is thus more efficient.
X-Plane 9 supports key-framed animation; this is useful for the scenery system, but for airplanes it allows for much more complex and realistic animation. OBJs that don’t have key frames still work.
This is a feature coming in the future: the ability to control how the user clicks and interacts with the cockpit object in detail. In X-Plane 9.0 we only support clicking on cockpit-textured geometry; manipulators will make features like draggable handles a lot more workable.
X-Plane 9 does not yet offer a lot of control of the in-cockpit lighting environment; we’ll be working on this in future versions. These features will be opt-in…that is, you’ll have to change your model to get the new features, and old planes will work the way they always used to. It is likely that you’ll have to use “modern” airplane-building techniques to use these new features (meaning OBJs, named or custom lights, lego brick instruments ,etc.).