Today Lori and I head to France – we will do a bit of site-seeing before the conference, and then Austin and I will go to Italy to work with Sergio.
So first, my email connectivity will be dubious at best for almost an entire month – if you send me a bug report and hear nothing for several weeks, you’re just going to have to wait…our internet connection in Italy doesn’t really deserve the name “internet connection”, and often doesn’t work at all. (If you need tech support, contact info at x-plane dot com – you should not be trying to reach me for tech support in the first place!)
I fixed a number of beta bugs this week; Austin will probably cut beta 11 before the conference, and then there will be a pause while we’re off the net. Once we get back, hopefully we can kill 930 off. (Most of the crash reports I’ve received turn out to be a single bug in the OBJ-handling code, fixed in beta 11, so hopefully the next beta will be stable.)
Now here is my request to everyone at the conference: please … go easy on me if I cannot remember who you are.
The tricky thing about a conference like this is that I mostly know people in the X-Plane community by an email address; if I see a face it is only once every few years. So if I jumble who you are, what you look like, and what you do with X-Plane, I apologize in advance. It is not a reflection on the merits of what you do, but rather an indication of the disorganized state of my (soon-to-be-jet-lagged) brain.
Posted in News
by
Ben Supnik |
I have received a number of emails bringing up crashes and performance problems in the X-Plane 930 betas – some of the writers are concerned that 930 might be a lame patch, going final with crashes and lousy performance.
To assuage this concern, let me make a few comments on where we are in the beta process, the likely future schedule, and the problems themselves.
The Schedule
X-Plane 930 has been an absurdly long beta. Going into the beta I had the mindset that we should take the beta slowly to have time to discover driver bugs on a wide variety of hardware – why rush and miss something?
I think we took this too far. To run a “slow” beta we have run other development simultaneous to the beta, but that in turn has stretched the beta to epic lengths.
We are starting to try to clamp down and close out the beta now, but it is going to get interrupted again. Austin and I will be traveling to attend the
X-Plane conference in France, and from there we will spend two weeks working with Sergio in Italy. Given how rarely we go to Europe, we cannot pass up the opportunity to work with Sergio in person – we have a few problems in the sim where getting the three of us in one room is the best course of action.
Unfortunately our internet connectivity during the trip will be limited, and we can only bring some of our equipment, so closing out the beta while on the road is really not an option. Thus there will be yet another beta delay. Hopefully when we return, we can close the beta out for good.
Performance Problems
I have seen a number of emails regarding framerate with 930. A few notes on framerate and betas:
I try to save framerate for last in a beta. Most performance problems have two possible causes.
- We communicate with the video card driver in a way that is fast on our systems but astoundingly slow on other systems. We discover this from slow performance in a particular piece of the code on other hardware.
- The new beta does something new that is more expensive than what the old build did, and users have not figured out how to (or do not have a way to) turn this more expensive option off.
The solution to case 1 is to use another driver call; the solution to case 2 is to make sure the rendering options provide a way to turn the feature off. (We simply cannot guarantee that a new, nicer looking feature run without a fps penalty – we can only give you a choice between better visuals and faster fps.)
Either way, framerate work tends to be the last thing on my beta list for this reason: other bug fixes may cause framerate problems, typically in category 1 – that is, a bug fixes makes use of a new driver call that we find out has hurt performance. Thus I try to do all performance fixes at the end of beta when we won’t be adding new code.
This means that in practice, I have spent nearly zero time looking at performance. I am just starting that process this week, so it will be a little bit before I find problems.
Unfortunately often performance problems manifest only in the hardware I do not own – despite having a pile of computers in my office (a pile that seems to grow deeper and less manageable every year) there are just a ton of systems out there. So a lot of the performance bugs will get fixed by users trying experiments and reporting back to me – a slow process despite some of the really great efforts by our users.
Crashes
Crashes sometimes are manifestations of gross code defects, but often they fall into the category of driver problems too. I will be working to piece together the puzzle of strange behavior over the next few weeks; usually the solution is to not do some action that we thought was legal but fails in some hardware cases.
Don’t Panic
As always, my final message regarding the beta is: don’t panic. When it gets quiet over the next few weeks, it is because of travel, and even once Austin and I are back in the office, it will be slightly slow going to piece together problems on hardware other than our own.
This year Austin, Sergio and I will be attending the X-Plane 09 Conference this year, near Paris. I am excited by the turn-out – a number of people in the X-Plane community who all do great work will be there, in some cases meeting each other in person for the first time. And there will be cheese!
The conference is officially French, and I must admit, I don’t speak a word of the stuff. Fortunately, my beautiful and very patient wife will be there, and she speaks French quite well. So I have asked her to translate the rest of this blog post – a greeting to my French readers.
Bonjour. Ecoutez: Ben croit que je traduis le reste de son article sur ce blog, mais il ne parle pas du tout le français. Lorsqu’on était à Cannes, il a essayé d’apprendre à dire “Le chat est sur la chaise” – ce qui lui a fallu deux semaines! Donc il n’a aucune idée de ce que je suis en train d’écrire, et il ne saura pas non plus si traduis sa présentation correctement ou non.
Lorsqu’il commence sa présentation, je vous expliquerai toutes ses mauvaises habitudes. Est-ce que vous l’avez vu travailler? C’est tellement bizarre! D’habitude il ne porte pas de pantalon. Il s’asseoit devant l’ordinateur en buvant du café et en maudissant les “DSFs” – qu’est-ce que c’est? Je lui ai dit qu’il faut porter un pantalon à la conférence.
I am a very lucky man! I will see you all there.
Posted in News
by
Ben Supnik |
It seemed like opposite-day at Laminar Research…Austin saying that an error shouldn’t quit the sim and me saying the error was never okay, ever. Well, I relented: with X-Plane 930 beta 8, if your scenery pack is missing objects, you can still fly. Instead you get a single error message like this:
That is the “non-fatal” error dialog box – you will see it only once for each scenery pack with a problem for each time you run the sim. It means that at least one thing is wrong with your scenery pack, but you need to look at Log.txt to see what’s wrong. For example, you might see this in the Log.txt file:
Failed to find resource 'KSBD_example.obj' at 'Custom
Scenery/KSBD Demo Area/KSBD_example.obj'
Failed to find resource 'KSBD_example.obj' at 'Custom
Scenery/KSBD Demo Area/custom objects/KSBD_example.obj'
Failed to find resource 'KSBD_example.obj' at
'Resources/objects/KSBD_example.obj'
Failed to find resource 'KSBD_example.obj'
at 'Resources/KSBD_example.obj'
***Error with scenery file "Custom Scenery/KSBD
Demo Area/Earth nav data/+30-120/+34-118.dsf"
(/Volumes/RAID/code/design/HLutils/Files/io_dsf.cpp: 503.)
Unable to locate object: KSBD_example.obj
In this case, X-Plane couldn’t find the object KSBD_example.obj – the sim is also listing all of the places it looked. Note that only the first location is a good location – the other 3 are legacy search paths that date all the way back to version 6. It is likely that in the next major version we will trim down our search paths significantly.
A few comments on this whole situation:
-
Authors, do not ignore error messages like the dialog box above – every one of them indicates a condition serious enough that we think you should fix it. Non-fatal errors like these may crash future versions of the sim, or your content may simply stop working.
If you file a bug against a future version of the sim saying your scenery pack used to work and is now broken, and we find that the old scenery pack had errors, we’re not going to fix the bug – we’re going to laugh maniacally and dance around you in a circle while singing “told you so”.
Okay – we’re very unlikely to do that – but if you have errors in your scenery pack, you’re doing something wrong and you need to fix it – treatment of illegal data is not stable between versions of the sim!!
-
I was never very sympathetic to this whole bug report because X-Plane has never accepted a DSF with missing objects – this has been a fatal* error since X-Plane 8.0 when DSF was introduced. So I simply don’t understand why there are any scenery packs floating around with objects missing. Why would you place an object if you don’t want to see it? The whole issue strikes me as a total failure to check quality by authors, since even running your pack once would reveal this kind of problem every time!
-
The motivation to make missing objects illegal comes from version 7 and ENVs. When looking at ENV scenery, I found that a large number of ENV scenery packs were missing at least some of their objects (an error that was silently ignored in ENV). It seemed like we were hiding an error and the result was authors not noticing simple mistakes that might “lose” an object (e.g. renaming an OBJ file).
Hence the “harsh” policy for DSFs – it was in response to a real problem with existing scenery!
- You don’t need to have missing objects just because you use library objects from another scenery pack (that might not be around). Use the EXPORT_BACKUP command in your library and a single blank OBJ as a place-holder for the objects you want from a library that might be missing. OpenSceneryX provides a stub library that authors can include so that their scenery will load without errors even if the OpenSceneryX library is not installed.
Anyway, Austin was right to make the error non-fatal. Besides being a little bit nicer for users who don’t know (or care) why their pack is gone) it lets authors get a list of all missing objects with only one run of the program.
* Fatal? In computer terms, a fatal error is one that makes the program quit, e.g. the error is fatal because it kills the program.
With X-Plane 930 beta 8, we finally integrated the latest version of Max’s Cessna 172 SP. Grab the new beta and try it – he’s added a number of new features that demonstrate some of the newer X-Plane 9 airplane features.
- Real 3-d lighting in the 3-d cockpit. Note how the map light tends to illuminate only some of the cockpit as it fades out.
- 2-d back-lighting on all of the major steam gauges.
- A bunch of parts can now be dragged in 3-d, including the door handles. This is done via manipulators.
- Walls! In 3-d cockpit viewer mode you won’t be able to leave the airplane until you actually open the doors. The cockpit viewpoint is constrained.
- The model has the glass parts separated out for correct shadowing, and the glass works correctly from all viewpoints.
- Panel uses cockpit regions for accurate lighting.
The cirrus jet has been similarly updated. I plan to use the Cessna for a series of tutorials showing how to use these recent X-Plane features.
I have said this before, but now it’s finally true: new file specifications are subject to change in the middle of beta!
In particular ATTR_light_level has changed slightly from beta 7 to beta 8. If you are using this feature in your objects, you will need to update your objects.
A new ac3d beta will be posted later today that supports the updated syntax.
You can read about the syntax here.
I get asked about the maximum mesh density in X-Plane a lot.
First, I must note that X-Plane’s mesh is adaptive – the triangles are not arranged in a grid, but rather they’re arranged to maximize the quality of the mesh with minimal triangle count, while preserving the outlines of water bodies and airports. These pictures show a dynamic mesh fit to a section of the grand canyon (both with and without the shaded DEM for reference):
Second, the actual maximum mesh density is almost certainly limited by system resource constraints. The maximum spatial resolution in a DSF is about 0.6 millionths of a foot. You’re going to exceed the maximum number of vertices, or much more likely, the maximum amount of available memory in X-Plane long before you have a grid at that resolution.
(That doesn’t meant that resolution isn’t usable – remember, the idea of the adaptive mesh is to have very high densities in very improtant places, but not everywhere.)
But in practice this is all moot if you don’t code your DSFs by hand – the question that really matters is: what is the highest density mesh that you can use with the current scenery tools.
Until recently, MeshTool was limited to a 1201×1201 (90 meter) input DEM. The input DEM is a simple grid, and the finished DEM is never higher resolution than the input. So until now, it would have been just about impossible to make a really high res mesh, even if X-Plane could handle it.
The most recent changes to MeshTool fix this – MeshTool can now handle a 10801 x 10801 (10 meter) input DEM, which X-Plane should be okay with as well.
This new version will hopefully go into beta relatively soon.
Propsman caught something:
…is modifying the value of a batch of ATTR_light_level tris comparable [performance-wise] with toggling the state of a backlit generic instrument? Instinct tells me that you must have the latter more streamlined than the former, but maybe not?
He is right: in the current implementation, ATTR_light_level is probably a bit more expensive than using generic instruments. This may not be true in the future though.
- The generic instrument code is pretty tight.
- Right now ATTR_light_level sometimes has to adjust shaders, which can be expensive.
- In the future, ATTR_light_level has the potential to be very heavily optimized, while the generic instrument code will always be CPU based.
But to put it in perspective, all instrument drawing is slow compared to scenery drawing – in the scenery world we draw 50,000 triangles of identical OpenGL state in a row, and modern cards do that very, very well. In the panel, we have to put in a lot of CPU time to figure out how to draw each quad or tri-strip. Fortunately you probably don’t have 50,000 individually programmed flashing lights in your panel. Heck – there’s “only” 3608 datarefs published by the sim.
Perhaps other questions are important when picking ATTR_light_level vs. panel texture:
- Which is more useful: to be able to have several variant images and variant images that are not “lights” (this is only possible by generics) or the ability to vary the light level gradually and not just have on or off (this is only possible with ATTR_light_level)?
- Which is simpler to author given the rest of the panel?
In other words, it’s all pretty “slow”, but fortunately “slow” isn’t that slow. If your light has to blink, you may want to pick what looks best and is straightforward to author.
In my previous posts I have tried to explain the difference between commands and datarefs, and when you might use each. To review:
- A dataref represents information. You can always read it, and you might be able to change it.
- A command represents an action. You can always invoke the action, but you can’t tell if it worked without looking at a dataref.
So…why is there so much overlap and duplication?
Dataref Vs. Dataref
There is duplication in the datarefs because we don’t delete old datarefs when we add newer, improved ones. The old datarefs stay in place to keep old plugins working. Here are a few reasons why we’ve added new datarefs:
- The
cockpit2/ and flightmodel2/ sections were added as a new, simpler, easier to use interface for authors in version 9. (Read more here and here and here.)
- In some cases, the old dataref was a bit-field while the new one is a simple integer. While plugins can use bitfields, modelers cannot animate using bit fields.
- In some cases, the old dataref did not represent a clean view of the data. Some old datarefs exposed X-Plane internal structures that are not appropriate for long-term use.
To see this in action, let’s look at the autopilot. How many ways are there to set the autopilot mode?
sim/cockpit/autopilot/heading_mode. This is the original heading mode, and it is marked deprecated, because it exposes a bunch of internal X-Plane autopilot values.sim/cockpit/autopilot/autopilot_state. This is the ideal autopilot dataref for plugins. It provides all functions, but since it is a bit-field it is not useful for authors.sim/cockpit2/autopilot/heading_mode. This is a clone of the original heading_mode into the cockpit2 domain. Honestly I am not sure how it got there – I know it was me who put it there, but it sure is a dumb idea; the original dataref is deprecated, so it was stupid of me to duplicate it!sim/cockpit2/autopilot/heading_state. This is coming in 930 and provides a heading-state enum set appropriate for authors…basically an enum that matches the two heading bits of the autopilot_state dataref that programmers were using.
How do you sort through this? Three rules of thumb:
- Try to use
sim/cockpit2 and sim/flightmodel2 when possible.
- More recent datarefs are usually better.
- Use the most useful dataref you can find.
Commands Vs. Commands
Sometimes there is some duplication of commands, e.g.
Here it’s a lot more obvious why there are multiple commands: they affect the carb heat in multiple ways. Typically this is done because commands are mapped to joysticks and other USB hardware; some hardware generates a button press when a command is toggled, but some hardware generates two commands, one for the off and one for the on position.
The rule of thumb is: use the command that gives you the action you want.
Commands Vs. Datarefs
Very often there will be a command and a writable dataref. Typically we need them both:
- The command is needed to let users set up their joystick and keyboard.
- The dataref predates version 9 – writing it was the only way to invoke an action.
Newer datarefs are more likely to be read-only, as we put new “changing the sim” functionality into commands. To go back to our autopilot example, we have on command: sim/autopilot/heading that lets us arm heading mode. This command is probably preferable to any of the datarefs for changing the autopilot state.
My
previous post discusses writing to a dataref. vs. actuating a command in more detail.
It turns out that understanding what a command is doing gets really complicated.
The key idea to untangling it all is this:
- Commands have duration, and that duration is the amount of time you “hold down” the button or key that actuates the command.
- Not all commands do things for the entire duration.
An example will clarify this:
- When you press and hold down the ‘p’ key to pause the sim, the sim pauses (or unpauses) instantly the moment you press the p key. Holding the p key down for a long time does not change this. Pause is a “momentary” command.
- You have to keep the starter button/key held down for a few seconds to start an engine. If you press it and release it, the starter motor will only run for a fraction of a second, which is not enough time to start an aircraft engine. Engine start is a “duration” command.
Virtual Datarefs
A “virtual dataref” isn’t really a dataref at all – it’s a string you can enter into an OBJ or generic instrument that looks like a dataref, but actually is something else. There is one “set” of virtual datarefs in X-Plane right now.
In X-Plane, you can enter
into a generic instrument or obj animation – this creates a “virtual dataref” around the command’s “activation status”. The virtual dataref acts like a read-only integer-type dataref whose value is 0 if the command is not being pressed right now and 1 if it is.
For example, if you animate a push button using
CMND=sim/starters/engage_starter_1 (key framing the animation to be “out” when the virtual dataref is 0 and 1 when it is in) then you will have a button that appears to be pressed whenever the starters are engaged. This will happen
no matter how the starter is engaged – your animation will happen whether the user presses a joystick button, holds down a key, clicks on a manipulator, or a plugin runs the command.
Basically, virtual datarefs that provide “activation status” of commands exist so that you can animate the buttons in your virtual cockpit to match what the user is doing with the mouse, keyboard, etc. These datarefs are read-only; use trigger generic instruments and command manipulators to actually run the command.
For Programmers
In that last section I pointed out that a virtual dataref is not a real dataref at least 3 times. Why am I harping on this? Well, programmers, you cannot use
XPLMFindDataRef to access virtual datarefs yourself. Sorry.
Virtual datarefs exist to give authors of OBJs and panels access to command activation status, something they would not normally have.
Plugin programmers don’t need this – if you are programming a plugin you simply use
XPLMRegisterCommandHandler and you will be told when the command is being actuated and released. Using a command handler is a lot more efficient than reading a dataref because you will receive a call
only when the command is pressed, instead of having to check the dataref value every frame. If you need to monitor a lot of commands, the callbacks are a lot more efficient.
Command Activation Is Not The Same As System Activation
Let’s go back to the case of the “pause” command and review. Here’s what we know about the pause command.
- The command
sim/operation/pause_toggle will change the sim’s pause state. The instant this command is pressed, the sim will pause (if it is runnning) or unpause (if it is paused).
- Holding down the
sim/operation/pause_toggle command has no effect beyond its initial press. Hold it down for an hour, it doesn’t matter.
- The virtual dataref
CMND=sim/operation/pause_toggle tells you if the pause command is being held down at any instant.
Here’s what we know about the pause dataref.
- The dataref sim/time/paused is 1 if the sim is paused, 0 if it is not.
- This dataref cannot be written!
So here’s what I mean when I say: command activation is not the same as system activation.
This becomes important when you start to model the buttons in airplanes. Take for example an autopilot button for altitude hold. In many planes, the button can be pushed in, and the moment you do, the altitude hold “arm” light will turn on. Keep the button held in and it doesn’t have any more effect. Altitude hold arm is a momentary command, but it has a system status indicator light.
I receive a number of questions about how to model this – and the answer is: take advantage of the fact that command activation (is the button pushed in) and system activation (is the light on) are not the same.
- You would use a read-only dataref for the autopilot state to turn on the indicator light. (There are two ways to do this: use ATTR_light_level to turn a _LIT texture on and off, or use panel texture and map a generic instrument like a rotary or an annunciator.)
- You would use a command to make the button work. Probably you’d use a command manipulator on the button mesh.
- You would key frame the button’s animation based on the virtual dataref wrapped around the command you are using with the manipulator.
The result will be a button that lights up when the AP is armed but pushes in while it is being pressed (whether via the mouse in the 3-d cockpit or a joystick button press or a keyboard button press).
In my final post, I’ll comment on how much overlap there is between datarefs and commands.
