This is not terribly important (because X-Plane always does “the right thing”), but…what’s the difference between a trapezoid and a square that’s been tipped over? Well, consider the checkerboard below.
Note that in the “no-perspective” space the height of each row is the same; in the perspective case the bottom rows (which appear farther away) are less tall than the top ones. From a 3-d perspective, the middel image is the equivalent of stretching the square into a trapezoid; the right image is the equivalent of tipping it over a bit.
I mention this because PlaneMaker 920 will allow you to drag the corners of generic instruments to create perspective effects. When you do this, the positioning of the moving aprts follows the “perspective” pattern you see on the right. This means that if you make a trapezoid-shaped needle, the center pivot point of the needle will not be at the centroid of the trapezoid!
(Based on 3-d perspective it should not be, because the wide end of the trapezoid is “closer” – thus the center must be closer to the small side.)
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?
I am reading Predictably Irrational, by Dan Ariely. It’s a great read – definitely recommended – describing the consistent irrational biases that frequent human decision making.
The first chapter discusses our tendency to make relative, rather than absolute comparisons. When deciding whether a product is a good value, we will look at the pricing of similar models, rather than the actual relationship between the product and the money spent. (The implication being that a company can make a product seem cheap without changing its price by adding a second, more expensive but similar “decoy” product. Poof! The cheaper product is now a good deal.)
This behavioral tendency explains user reaction to the rendering settings, a subject that makes me irrational on a regular basis. 🙂
Time to Change the Settings
The rendering settings will let you select a range of sim detail between some minimum and maximum value. These values are based on the software, not hardware – because we don’t actually know how much load any given hardware can support (and with the interaction between settings, finding such a cap is basically impossible). We can only give you a range of choices and let you pick ones that work well.
When a new version of the sim comes out, we sometimes have to recalibrate the settings. If the minimum features the sim can support increase, the minimum setting will be mapped to a new, more expensive behavior. And if the maximum detail the sim can present has increased, the maximum setting will be similarly remapped. We don’t have much choice – if we need more “range” on the slider we have to recalibrate it.
I Can’t Max Them Out
Here’s where human behavior comes in. Humans make decisions based on the relative comparison of easily compared things. Given properties that are harder to measure and easier to measure, we’ll pick the easier one. Given a choice of a trip to Rome, a trip to Rome with free breakfast, and a trip to Paris, we’ll pick Rome with the free breakfast, opting for the easy to measure relative value. (Is the difference between a trip to Paris and Rome really less than the value of a breakfast? Probably not, but it’s a lot harder to evaluate.)
So when we recalibrate the settings, we inevitably here this complaint:
“I used to be able to set the sliders to the maximum setting and now I can’t.”
Previously I would have said “Why the hell do you care?!?!” — if the new slider’s 50% position looks the same as the old slider’s 100% position, why not just set it to 50% and go home happy.
But of course that’s not how we think – the immediately comparable is of immediate concern. Ironically we could make the sim less useful but more pleasing by limiting the maximum range of the sliders. Now more users could feel the joy of having everything “set on max” even if the ultimate utility of the sim is reduced.
This One Goes To 11
I’m not sure there’s a way around this. The best suggestion I’ve heard so far is that if we could attach some kind of units to the settings, then at least there would be a quantitative indication that the user isn’t losing some perceived value. But I suspect that even this misses the point; it doesn’t matter that you’re still getting 500 trees per square km – what matters is that you are getting the most you possibly can! (Perhaps this psychology also explains why people like to overclock.)
Austin tried to fight the psychology of “maximum sliders” by naming all of our settings absurd things. Ever wonder why “default” is the lowest object setting, and we almost immediately jump into “extreme”, “too many”, “insane”, etc.? He was trying to fight a losing battle against relative expectations. The natural human behavior is to pick some relative position for calibration, and based on that, every user who has to put objects below the center setting is going to be unhappy about having to use “lower than average” settings. Austin’s naming convention may be silly, but it does actually do a little bit to fight this.
Food for thought: how does having multiple levels of reflections change user expectations?
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…
I spent part of the morning tracking down installer issues. Here are some things I have learned:
-
If you have Windows Vista and User Access Control, there’s a good chance that the installer may get caught on permissions problems. I don’t fully understand what’s going on, but I don’t think it’s a coincidence that it is US GraphSim customers who see this.
Basically those DVDs, which went to press a little bit early, default to installing X-Plane on the C drive, which is not a generally accessible area. UAC then makes some guesses and allows some but not all operations (or something equally weird) and the user gets stuck.
I am still investigating, but I think the fix is to install to your home folder.
-
Some users have bad DVDs. It happens, and I think it happens more now that we’re dual layer. There’s also a variance in the sensitivity of drives – some users send us back damaged disks and they look bad but we can still read them.
Tech support will tell you this, but if you can’t install, one test is to simply copy the entire DVD to your hard drive; if the copy fails mid-way with “I/O error” or some other message about damaged media, call up tech support, they’ll swap you a new disk.
We try to find duplication facilities that do high quality work, but bad disks do happen. Tech support should be able to make this right for you.
- I’ve gotten a wide variety of weird reports on Linux – there are a lot of distros out there, so potentially a lot of versions of the OS code base. For Linux users I strongly recommend the X-Plane Wiki, where we are trying to accumulate all of the fringe cases.
If you are developing an add-on for X-Plane, you should always check the log file (Log.txt) after running. (Remember, the sim must quit before the log file is completely written to disk.)
There are three times you should check the log:
- Any time your content doesn’t look the way you expect. (Perhaps the error is described in more detail in the log file.
- Any time there is an error (especially the “a problem with the package X” message, which is always accompanied by details in the log).
- Right before posting your work as a last check.
Posting errors to the log gives us a way to provide verbose feedback to authors when the sim hits a problem without making the user experience too horrible; minor errors are logged and major errors are mentioned to the user only once per package and logged.
The flip side of this is that if you are working on content, you need to seek out these error log messages; the alternative is to have the sim quit every time something goes wrong.
In a previous post I said that our tech support guys will trouble-shoot the most likely problems first (based on what we see in our entire user base) – they’re playing the odds.
Well, a lot of our users do too. Over and over and over I see the recommendation “delete your preferences” as a cure for a wide variety of strange symptoms. And a lot of the time deleting preferences works.
I fear that deleting preferences has become a bit of a
Cargo Cult, that is, a ritual induced to fix the mysterious beast that is X-Plane without consideration to why X-Plane is broken. If the fix works, the previous problem is ignored.
Now here’s the thing: preferences files are relatively small and easy to read! And they’re really easy to save.
So next time you have a problem and consider deleting the preferences, simply move them outside your Resources/preferences folder to the desktop and restart.
If the problem goes away, you can then delete the newly generated (clean) preferences and put the old funky ones back.
If you then truly find a situation where one preferences file causes the problem, you can look at what’s actually different and file a real bug. (Unix nerds: most of the preferences files are text and can be “diffed”.)
At this point, almost every option in the preferences file has a user interface item, so if the preferences file causes the sim to run poorly, there should be a setting that has been changed that can be identified. Screenshots of the other airplanes, weather and rendering settings before and after the prefs might provide another quick way to compare what has changed. Control-period will take screenshots when dialog boxes are shown.
(Remember that the effect of preferences on framerate varies a lot with hardware. There may be some preferences that slow fps a lot but do not make an obvious change in what you see “out the window”. By comparing two rendering settings screenshots you might find something subtle that changed.)
I seem to be in a philosophical mood these days with my blog posts…thought for the day: the human mind easily goes from the specific to the general. Our brains are generalizing machines, pattern matchers finding the rule in the noise.
My preference in creating new scenery-system features is to make them very limited, and my reasoning is: our brains don’t go backward very well. We do not go from the general to the specific.
Now you might think: when making a scenery-system addition, the best thing would be to have a general feature, more useful because it can be used everywhere. But I say: the most important thing is to fully understand the feature – otherwise the feature comes out buggy.
(Consider the piles and piles of bugs and weird behaviors that you get when combining OBJ animation with OBJ hard surfaces.)
Since the human brain doesn’t go from general to specific well, it is hard to start with a rule (“let’s allow feature X in all parts of the scenery system”) and comprehensively derive all of the implications; it is human nature to be surprised later by some unintended side-effects.
It is always easier to extend a feature later to its natural full implications than to declare certain uses illegal later, after authors of planned or started trying to use the feature in that way. If the generalization of the feature makes sense, extending it is often quite painless.
Texture Paging – Scope For Now
Texture paging is the ability for X-Plane to raise and lower the resolution of scenery textures dynamically as you fly. This means more VRAM used for nearby things and less for far away things. In practical terms, this reduces VRAM used by orthophotos by down-sampling the far-away textures, making larger orthophoto scenery packages possible. As you fly, the sim reloads some textures at higher resolutions and some at lower. The cost of the features is the load time while you fly, which burns up some extra CPU cores.
It is my hope that we will productize some very simple texture paging in the next major patch of X-Plane 9 (that would be 920, not 902). But the usage will be pretty specific:
- Texture paging will only be available for .ter and .pol textures (we can extend to other scenery types later if it makes sense).
- Texture paging will require changing the .ter and .pol files (X-Plane will not automatically analyze your scenery to see what can be paged.)
- Texture paging will not be available for ENV scenery.
- If you share textures and texture page, the results will probably be really bad and cause chaos. Be sure to use only one .ter or .pol file (and reference that text file only once in the your DSF definitions section) if you want sane paging. We can extend paging to shared textures in the future, but for now orthophotos are the intended target.
I am also deferring work on dataref-driven textures; we’ll get there eventually, and the infrastructure from the pager will make it easier. But dataref-driven textures really need to be available in a lot more places – it’s a bigger, more complex feature* and I can’t keep adding scope to 920.
Make New Meshes!
While paging will be available for both overlays (using .pol files) and base meshes (using .ter files) I strongly, strongly recommend going the base-mesh .ter route. RealScenery sent me their new “State of Washington” package to use as test material; I was pleasantly surprised at the high framerate. Part of that comes from them using base meshes and not overlays.
Overlays cause the sim to draw the scenery twice (first the old scenery, then your overlay), burning a lot of pixel shader and fill power. Base meshes simply replace the old mesh which is at least twice as efficient.
(I’m just going to keep beating the dead horse of base meshes because I believe that the sooner everyone moves toward base meshes, the more bang for our hardware buck everyone gets.)
* In particular, remember that texture paging happens on threads. But datarefs can come from plugins that are not threaded! Insert anarchy here…
I’ve been reading Fooled by Randomness (highly recommended – it will either change your life or you won’t finish it because Taleb’s writing style annoys you) – and it has me thinking about the nature of certainty in software development. Consider two approaches to uncertainty and how they are completely at odds with each other.
No Weird Behavior
The “No Weird Behavior” approach goes like this: you never want a harmless behavior inside your code that you don’t understand. The reason is that if you don’t understand the behavior, you don’t really know that it’s harmless!
In fact this isn’t just a theoretical problem – I only truly started to believe in “No Weird Behavior” after fixing several very hard to find, hard to reproduce crash bugs, only to discover (once the analysis was done) that the broken code also produced a very frequent, less harmful behavior. Had I taken the time to investigate the “weird behavior” first (despite it not being of high importance) it would have led me to a ticking time bomb.
No Weird Behavior implies that a bug isn’t fixed until you know why it’s fixed, and that randomly changing code until the behavior goes away is absolutely unacceptable. This shouldn’t be surprising; if a bridge was
swaying would you accept an engineer who fixed it by randomly tightening and loosening screws until it stopped?
Wait And See
I get a lot of email with bug reports, questions, and reports of strange sim behavior. These emails have some unfortunate statistical properties:
- A good number of them are resolved by the user who emailed within a day or two.
- A certain percentage are simply never resolved. (Often I email a question that would point to a clear diagnosis and the user never writes back. I can only speculate that the user answered the question, found the problem, fixed it, and promptly forgot about our emails.)
- A certain percentage are solved by the user, who tells me what the problem was, and it was something I would never, ever be able to help them with. (Things like “I have this program called WickedMP3Player – it turns out if I set its visualizer setting to ‘Rainbow’ then X-Plane stops crashing” when I’ve never even heard of the WickedMP3Player program to begin with.)
- There is a high correlation between bug reports reported by a very small number of users and a resolution from the above categories, or a resolution by the user changing his or her local configuration.
So playing the odds, the right thing to do when presented by a third party with weird behavior is to wait and see who else reports it; the frequency of reports gives us information about the likely resolution.
(And for those of you who think our tech support are being lame when they ask if you’ve updated your drivers, they are playing the odds to the hilt – they ask you about drivers first because updating drivers fixes an absurdly huge number of the tech support calls we get.)
Getting It Wrong
So we have motivation to investigate everything (no weird behavior), motivation to ignore everything (wait and see) and a rule of thumb that the frequency of reports can help us pick which strategy is best. Of course, sometimes the rule of thumb is completely wrong.
One user reported a crash using the current web updater (version 2.04) – I had not seen this crash anywhere and it was inside the operating system UI code, so I assumed it was a local problem, e.g. some kind of extension or add-on that caused the OS problems.
The problem, it turns out, is simply low frequency – as the incorrect code made it into 902b1, I got a few reports from more users and realized that this wasn’t a local problem, it was weird behavior! (The bug will be fixed in the 205 installer and 902b2, both of which will be out in June.)
Consider this: if you make a measurement of a known quantity with a dubious measuring device, you learn more about the measuring device than the object you are measuring. (If you have a ruler and you don’t know the units, you could determine them by measuring yourself.)
In a number of cases, we have seen serious “should-happen-all-the-time” crash bugs that get reported by very few users. (Once we know the actual root cause of the bug, we can deduce logically whether the bug should happen to all users with the configuration or be intermittent.) We can then look back at the actual number of reports to make a judgement call on how much testing is really happening.
For example, we can make some guesses about how quickly a new Macintosh have saturated the X-Plane user base when there is a hardware-specific serious bug in just that machine.
We had this with the iMacs (where the runway lights were broken) and we could watch the machines sell – slowly at first, but then quite quickly. (BTW, I think that 10.5.3 fixes this and anti-aliasing problems.) We can even see who runs with anti-aliasing when there is a setting-specific bug (a lot of you do)!
In the end, I think the right approach to balancing “no weird behavior” and “wait and see” is to remember a truth about uncertainty that is very hard for humans to grasp:
The most likely outcome of an uncertain situation is not guaranteed to happen – in fact a lot of the time it won’t.*
So we can play the rule of thumb and wait and see, but we always have to keep one eye toward the improbable, which is still possible!
* Blatant blog cross-promotion…the point of my
big rant here was essentially the same…it’s easy to expect the most likely outcome, but the unlikely outcome will happen some of the time.
