Blog

Two Features for Scenery Conversions

We have not been adding features into X-Plane specifically to aid conversion of scenery from MSFS (and I don’t think we will), but sometimes features we want outright help solve conversion issues too. Here are two new features I expect us to ship in version 10 that should help the conversion of overlay scenery packs.

Draped Geometry: I’ve mentioned this feature before; basically in X-Plane 10, the horizontal geometry that sits “on the ground” can be marked for real 3-d draping, rather than just polygon offset.  Draping is the process of actually cutting and shaping that geometry to perfectly ‘hug’ the ground – it’s how we can put a runway or taxiway on top of non-flat ground without Z thrash.

In X-Plane 9 you can create draped geometry, but you have to use .pol files; this can be awkward if you want to put an element in many times, share an element with other authors, or have an element on the ground match a 3-d object.

In most of the cases where I have seen serious Z thrash in scenery conversions, simply changing ATTR_poly_os to the new proposed ATTR_draped will fix the problem.

OBJ Elevation Control: X-Plane 10 will allow you to position an object vertically as well as horizontally, probably with something like this RFC.

For scenery conversions, this means that a scenery pack authored to a specific height elevation can be duplicated precisely.

For authors creating new work, this makes certain kinds of scenery possible that would have been very difficult before.  For example, we get asked fairly often about LPMA. which features a runway on pillars.  You can model as this as an OBJ with a hard surface, but in X-Plane 9 it’s very hard to predict what height that OBJ will be placed at. (Hack/work-around: place the OBJ in the water and model the geometry offset from the runway location.  Most scenery packs should have the water at MSL 0.)  With elevation control, the runway can be built at the real runway surface height and will be placed their explicitly.

Posted in File Formats by | 9 Comments

Random Stuff on the Side

I spend most of the time working on global scenery, shaders, v10, the big ticket items.  But there are always little things going on too.  A few random things:

I have a JavaScript taxiway-sign editor I’ve been working on – it lets you type taxiway signs with the keyboard, see them using the real sign artwork, and then get the sign code out (you know, that cryptic {^ul,@r}27-9{@@,no-entry} gak) automatically.  I was inspired by WordPress’s insanely nice back-end web UI to see if I could make a web-based sign editor that was reasonably usable.  The answer is: with jQuery – yes.  Once it’s further along, I’ll post it; maybe someone can help make the CSS prettier.

We put another download server up this week; as we transition between hosting providers, we’ll have extra servers for a week or two, so, um, enjoy the bandwidth!

Finally, I’ve been poking (very slowly) at the panel documentation on the wiki.  In particular, I’m trying to delete documentation of legacy features. A lot of the complexity in the panel system comes from the interaction between old backward compatibility features and the latest way to make a modern aircraft. My hope is that by documented only the “modern” path, the documentation can be clear, concise, and a lot less confusing to new authors.  I figure if you’re reading the Wiki, you want to know how to make a panel now, not how to make one for X-Plane 3 years ago.

The real work of the week was the new road system and debugging the new global illumination code.

Posted in Development by | 1 Comment

The world is under control…

So as Ben has mentioned, I’ve been working on giving X-Plane a new ATC system. To be clear, the task was not to add features or fix bugs with the existing system, it was to write a whole new one…from the ground up. Why? Because our goal is to lay the foundation for a system that can grow over time; a system that we can easily expand and add features to. So what does this mean? It means that starting with the initial release of v10, the ATC system will grow incrementally until we feel it suits the needs of most of our users. It will never be a replacement for VATSIM however!

There’s only so much that can be done with artificial intelligence and since starting this project I’ve learned that humans make decisions in ways that are really really difficult to quantify, so lines have to be drawn somewhere. If you want that human factor, that’s what VATSIM’s for. The goal for our ATC is to make it as realistic as possible within the confines of what’s reasonable. It also needs to cater to a wide range of users. Some who are real pilots and do not deviate from ATC commands at all while others are new to aviation and may make some mistakes (even some dangerous ones). In real life making some mistakes will get you killed or at least earn you a phone call to the FAA…in here, the controller may grumble that you’re not listening and encourage you to follow directions again. I know that some of you are thinking “Why not just add levels of realism that the user can pick from a menu” and we may just do that for some things in the future, but for now I can’t stress enough that the goal is to be reasonable and flexible in our system design so that we can grow the system over time…all while keeping it fun for all types of users.

Enough blabber, time for some pretty pictures. The shot below is a picture of X-Plane with the North American ARTCC/FIR boundaries turned on. This is just for development purposes but it’s kind of neat to see the boundaries overlayed on the planet. As you fly from one center to the next, you’ll get handoffs from facility to facility.

And the shot below is what happens when I turn on the boundaries of towered airports. Any airport in the apt.dat file that has some combination of Delivery/Ground/Tower specified in it will be given a living control tower.

This only covers a tiny bit about the ATC system which is quite complex even in its infancy but I’ll do my best to keep the posts coming so that you can learn more about what it’s capable of.

I don’t have time to go into great detail about subsystems just yet (that’ll be covered in other posts) but I’ll leave you with a juicy detail….See those dots in the first image in the ZBW (Boston) ARTCC’s boundary? That’s a custom ATC pack (similar to a custom scenery pack) that I created that perfectly replicates Boston (KBOS) and Bradley (KBDL) TRACON airspace. Yeap, that means you can customize the system how you want it. More on what that means in the future….

Posted in Air Traffic Control, Development by | 11 Comments

Captcha support added for commenting

If you haven’t already noticed, I’ve added some captcha’s to our comments to try to combat the spam we’ve been getting. I don’t particularly like captchas….I usually spend several minutes staring at them like a Rorschach Test but I think this will save time moving forward. Please let us know if they’re causing any problems beyond the severity of just being annoying.

Posted in Development by | 2 Comments

Spammers: You will be nuked

An advanced apology to anyone whose comment gets nuked as spam.  This blog, like all blogs, gets attacked by spammers who put links in their comments to boost their pagerank.

So if I’m not sure if you’re a real commenter or a spammer, sorry, but I’m going to err on the side of the chainsaw.

Posted in Development by | Comments Off on Spammers: You will be nuked

Next-Gen Twin Prop

The Cessna 172SP isn’t the fastest plane, but it would get you there a little quicker if it was a twin prop.

(This is what happens when I leave the AI planes on while randomly testing rendering bugs in the middle of nowhere.  On the bright side, the two planes do shadow each other.)

Posted in Air Traffic Control by | 1 Comment

From Robin: submissions for V10 still accepted

Robin sent this out to the news list:

A quick note for X-Plane airport designers (if you are not an X-Plane airport designer then please disregard this message).

Good News – it is still possible to submit new or revised airport designs for inclusion in the X-Plane version 10 scenery generation process. Please send me any submissions before February 7, 2011 so that I can consolidate them and generate the special data files that will be used to generate the new global scenery. I need just the apt.dat file for each airport – if you have multiple airports, please consolidate the data into a single file.

Why is this important? When new global scenery is generated for X-Plane 10, the latest airport data will be used to:

  • Define the “land use” in the vicinity of the airport. This will ensure that an appropriate terrain texture is used under the airport, and will also suppress the trees and auto-gen buildings.
  • Smooth any terrain undulations in the vicinity of the airport.
  • Ensure that runways have “land” underneath them – especially important for airports alongside rivers, lakes or oceans.

The best way to help this process is to define an accurate airport boundary in World Editor (WED). If no boundary is defined, we will try to approximate a boundary based upon all other available data for an airport. If you only have time to create an accurate boundary (but not the rest of the airport details) then that is fine also – I can still use such data for this process.

Let me know if you have any questions
– Robin

My apologies for the earlier false deadline – we thought we were going to cut the global scenery a lot sooner.

Posted in Scenery by | 4 Comments

What’s the Log File For?

X-Plane’s log file is our attempt to capture everything we could possibly want to know about your computer in case something goes wrong.  (There’s no personal information in there – we want to know things like what kind of CPU and graphics card do you have.) We do this because a fair amount of tech support comes from configuration problems; having the sim tell us the configuration saves tech support time in explaining how to gather configuration information and eliminates the risk of user error.

This matters because a fair number of bugs and tech support requests come from strange system configurations…often we don’t even know what was wrong until the user later reports fixing the problem by adjusting a piece of hardware that we didn’t know existed.  Here’s one example from last week:

Hi Guys, I just wanted to let you know, I got X-Plane working!  It turned out it was my sound card. I don’t actually have a sound card…I replaced my RealTek USB speakers with a small gnome that lives on top of my motherboard.  The gnome yodels what he thinks I should be hearing.

Well, it turned out that last week the gnome went on a wicked bender and passed out and shorted out my PCIe bus…I think that’s what was causing X-Plane to freeze.  I gave the gnome some charcoal pills and black coffee and the sim runs great!

BTW when is X-Plane 10 coming out?  Do you need beta testers? 🙂 🙂 🙂

Okay, I admit, I made that up.  But…that’s not far off from reality – just replace “gnome” with your favorite barely-compatible-with-DirectSound pro-level recording sound card.  Anyway, our response to this kind of thing is visible in the log…e.g.:

Sound Card: gnome (B.A.C. = 0.02%)

There is one down-side to the log: some users seem to like to report every single line of the log to us, with the question “is this a problem?”  We’ve been trying to make it more obvious what’s an error and what’s just information.  (Hint: most of it is information…except for the lines with the word ERROR in big bold letters.)

Therefore I make this suggestion to plugin developers re: the use of the log file.

  • Do identify all log output as coming from your plugin.
  • Do log serious errors that will be needed in crash forensics.
  • Do not log errors that are reported to the user.  If the user opens a file and it’s the wrong version, and your plugin presents a dialog box, you probably don’t need to also log the error.
  • Do log configuration information needed to triage a system.
  • Do not log routine status from normal operation – not in a release build please!
Posted in Development by | 5 Comments

Android Web Market is live!

Google announced today that the Android market is now available on the web. It’s really quite nice and the best feature is that apps can be purchased directly from your desktop computer and installed over-the-air (that means no tethering like in iTunes) directly to your Android device. It’s quite cool!

Here are the links to our stuff. Please share them with your friends. You can even tweet about it right from the market listing.

https://market.android.com/details?id=com.laminarresearch.xplane_default
https://market.android.com/details?id=com.laminarresearch.giant_robots

Posted in Android, News by | Comments Off on Android Web Market is live!

New Installers…Shiny!

Well, they are new at least.  The new installers/updaters are now posted.  Version 2.06 fixes Linux DVD problems, but also has two features that should be nice for users who beta test heavily (and grab full demo installs off the net to do so):

  • The new installer/updater keeps net connections alive, which really helps download rates per connection.
  • The new installer/updater connects once to each server, balancing the load between servers.

Previously you had to pick one server and poke around until you found the fastest one.  By keeping connections alive and using all servers, we should get fast, even download times for everyone.

Posted in Development by | 11 Comments