Paraffin

Are there any plans for an updated DC-3 for v11, including pbr reflection bare-metal? I would pay full price again for that! I always thought a great-looking bare metal livery like the classic Eastern Airlines was the one missing feature for this plane. Well, that, and a less funky fuel transfer switch, if we ever get a new version.

That's great Cameron, thanks! That will let me pick and choose between static or updated, depending on real-world conditions. I'm really looking forward to this.

A question about how this works: I do almost all my flying in the FSEconomy game, where it's fun to have the variety from real weather and the cloud effects from SkyMaxx Pro, but I still have to complete each assignment in the FSE game. No weather diversions allowed! So, what I'm doing now, is to load up X-Plane's default "real weather from the Net," at the departing airport, then see if the winds or cloud base would make the landing too difficult. I'm usually flying short enough hops that it's basically the same weather at the destination airport. Many of the airstrips I fly into with FSE are small, with non-precision approaches, and I usually fly light stuff like GA bush planes and helicopters that can't handle severe conditions. If the weather doesn't look like I could complete the FSE assignment, I adjust it on the X-Plane weather page by backing down the winds and raising the cloud base if needed. In other words, I'm flying with hand-tweaked real weather, when the conditions are really bad out there in the real world. Can I do the same thing with RWC? In other words, have it load in real weather but adjust it and "lock" it on the fly so I can complete an FSE assignment? Or am I always flying in downloaded weather full-time when I'm using RWC, take it or leave it?

Over on the PPRUNE forum the speculation is running along these lines: First, it was a crew transfer flight -- no passengers or baggage, so the plane was very lightweight and harder to "stick" on landing than a normal flight. There were (unconfirmed) reports that it bounced high on touchdown. If the thrust reversers were inhibited by a weight-on-wheels sensor during the bounce (a normal safety precaution to prevent accidental use in flight, but I'm not sure if that's how the Tu-204 works), then the reversers couldn't be used during the bounce. From the speed it hit the highway, it looked like the pilot might have attempted a late go-around, with (unconfirmed) reports that the crashed cockpit had the thrust levers in TOGA position. Brake failure might also be involved, but it wouldn't be needed if all the other holes lined up like that.

Goran, thanks for the info. If the wing leveler will hold a heading, then that should work. Here's what I'm still curious about though, and I understand a reluctance for "adding something that isn't in the real thing," The Wiki page about the history of autopilots (http://en.wikipedia.org/wiki/Autopilot) says the following, about the development of the Sperry system: A hands-off heading hold for three hours is not what the current LES DC-3 autopilot is doing, and that demonstration was back in 1930! On a strictly mechanical level, if the gyrocompass isn't drifting, and the AP is slaved to the gyro, then why would the AP have drift? I guess I'm still not convinced that this is an accurate model of the Sperry AP, based on the info I've been able to dig up. I'm happy to stand corrected, if this is really how it worked. I just wonder how Sperry could have sold this system in the first place, if it couldn't hold a heading for more than a minute or two.

Well, the world is larger than X-Pilot forums. Here's a quote from the FsEconomy forum about available DC-3 models in the X-Plane sub-forum: Here's the full thread if you can see it (not sure what the guest status is over there): http://www.fseforums.com/forums/thread-view.asp?tid=81339&posts=6&start=1 If you're just zooming around the scenery and sightseeing for 20 minutes at a time, it's not a big deal. Virtual airlines like FSE where you have to complete long flights (i.e. what this ship is designed for), is where the problem really shows up.

Hi, and Happy Holidays to the X-Pilot, X-Aviation, and LES crew! Since it looks like we're on hold for an update until v.1.2 final, have you had a chance to take another look at the heading drift in the Sperry autopilot? Here's the previous post about it: http://forums.x-pilot.com/index.php/topic/3225-chasing-the-autopilot/ If this drift is historically accurate (and I'm still not sure about that), then maybe there could be a setting the user could adjust somewhere for a conventional heading hold? It makes flights of an hour or two very labor-intensive. You can't leave the pilot's seat long enough for a cup of coffee, without coming back and being seriously off-course. That's a problem for the longer assignments in FsEconomy, among other things. Even if it's accurate, I think there's a justification for allowing a steady heading hold on autopilot, as the DC-3 was never flown without a co-pilot. With a co-pilot, you would trade off managing heading drift in a way that can't be done as a solo flight sim pilot.

Goran, first let me preface this by saying that I'm getting a major kick out of flying your DC-3, it's a wonderful model. It's worth swapping out plugins to fly this model, in case any onlookers who haven't purchased the DC-3 are wondering about that. It's the best DC-3 in X-Plane, and I say that as someone who has bought and supported the other available payware model and flown it as a money-making vintage airplane in FSEconomy for a couple of years now. This is something special. Well, there is that autopilot drift thing , but still... an amazing model and well worth the money. Okay, after that preamble... What you're seeing is that, as an end-user, we're frustrated with having to deal with this issue at all. This isn't our job. We bought a payware plane, we want to use it without conflicts. It's asking a lot from both the Gizmo and SASL sides of the conflict for the end-user to deal with any of this. What will end up happening, is just a practical choice of how many planes use Gizmo in our aircraft sub-folders, and how many use SASL. If we spend more time flying planes that use SASL, then Gizmo-enabled planes get demoted to a status where we move that plugin to the Desktop. And that will kill off any plans to use Gizmo for features that aren't plane-specific.

Just a customer comment here, not an argument (I hope). I think it's reasonable from the end-user's perspective to wonder why a plugin has to be enabled at the top level, when it doesn't appear to be doing anything useful when flying a non-Gizmo enabled plane model. The future plans for Gizmo -- "where Gizmo is headed, the fact that it is NOT to be utilized just for aircraft (yep, not aircraft-specific!), etc is precisely why it's been done the way it has" -- don't affect the current situation. Right now, it's only a plane model enabler. BTW, the latest conflict example I ran into is the Hydroz PBY Catalina. I have to move Gizmo out to the Windows desktop to fly that plane, otherwise there is an engine sound conflict. I haven't bought the new Carenado Seneca yet, or any future Carenado products that might use SASL, but this is rapidly turning into a situation where instead of moving Gizmo out temporarily to fly a non-Gizmo plane, I'm going to be thinking of Gizmo as something I leave out of the system most of the time, and only move it in when I want to fly the LES DC-3. Or the MU-2 and Falcon (although I haven't moved those into v10 yet, pending updates). Whatever future plans are in store for Gizmo as a universal plugin, it won't help if users are thinking of it as a special case to be enabled only for certain planes anyway. In other words, it's going to be treated as a plane-level plugin, whether it's intended that way or not. Again, this isn't an argument about what's "proper" for handling plugins, just a statement of the current situation from the customer's perspective.

Yeah, ^^that stuff. I think the other two major areas of scenery development need to be: 1) Seasonal changes in the terrain, especially for Winter effects at high and low latitudes and high elevations. It's boring to fly constantly in Summer. 2) Do something about the uniform drab water color. Coastal water should not look the same in the Florida Keys, Caribbean, or Mediterranean as it does in the Pacific Northwest. It would be nice to see tropical rivers with a typical brown color instead of blue also, but that's probably asking too much. I think those are the two big ones, along with more believable cities. Personally, I'd also like to see better modeling of heavy weather, especially big anvil-head head thunderstorms in the distance that you have to steer around. The cloud modeling in v10 is much better now, but there's still a ways to go in modeling severe weather. Turbulence modeling also needs improvement, with more randomizing of the effect. On the plane model side, I'm not a modeler so I don't know what the main concerns are in the flight model. There seem to be some issues with turbines not having accurate modeling, but again I'm not an expert there. Actually, the *one* thing I'd really like to see on the plane side, is adoption of a set of uniform standards by aircraft designers for UI control of cockpit instruments. It's one thing to include a special manipulator for something unusual in a plane model, but everyone going their own way on basic things like how you tune a radio frequency, or input a GPS code, is not ideal. I shouldn't have to learn a unique UI for each separate plane model (outside of the special plane-specific stuff). If the designers can't agree on a common UI, then maybe it needs to be set as a top-down UI standard by Laminar?

Me neither, I mentioned it because it's only relevant if the AP is working as a trim adjustment without an outside reference, like a gyro. If there was a gyro reference with manual control lock-out, then X-Plane trim should be irrelevant, unless you engage the AP with the plane badly out of trim. Thanks for looking into this, it would make a big difference for those longer flights that this ship was designed for. I think the key is to figure out if it did indeed reference a gyro in a feedback loop for holding a heading. That seems to be indicated in at least that one reference image above, although maybe this is a different model. To make things even more confusing, I found some references to the early Sperry using the rudder for directional (heading) control, and that seems to be the arrangement in the image linked above. Apparently one of the earlier versions of Flight Simulator had a DC-3 that worked this way, but they reverted to AP aileron control for the DC-3's AP in FS2004 and FSX? Maybe because it was easier to hook into the flight model, or it was just more efficient. Even if the real thing worked that way, I think it would be an acceptable fudge to use roll for heading control in the LES model. That would help, although even if the increments are 1/4 or 1/2 degree for the roll, there will still be a need for continual adjustment of heading if the AP isn't slaved to a reference like a directional gyro. Still, that would be worth trying if you don't want to use that approach. And again, thanks for taking a look at this. Now the next thing I have to work on, is a 2-wheel landing without bouncing.

This could spark a whole discussion about how difficult it is to trim any X-Plane model so it "settles" in straight and level flight, but I won't go there. As close as I can get it, and stabilized in cruise mode, the autopilot still won't hold heading for more than a minute or two without drifting. I'd like to hear what anyone else here is experiencing, especially on long flights. This was tested on FSEconomy assignments that were one or two hours long, where constantly fiddling with the AP really isn't an option. If you use time compression (which I sometimes do, on long flights), the problem is magnified. Time compression works fine on every other model in X-Plane, because the AP holds heading the way you expect it to. Are you sure that's how they worked? I'm no expert on this stuff, but a little Googling turned up this old 1933 reference to the Sperry autopilot being driven by a gyrocompass: http://books.google....tosphere&f=true That would act in a feedback loop to maintain a steady heading: In other words, not just "fixing on where your control input was" when you engaged it. Aside from just my personal wish to fly this plane hands-off for long periods of time in FSEconomy, I think that anyone coming from the MSFS side of the fence to X-Plane will be expecting at least a steady heading hold when AP is engaged. This is such a great DC-3 model... it needs to be practical for long, real-world flights, not just zooming around the pattern at a simulated air show. About the yoke input being disabled, that's a lesser issue. It just looks weird because moving the yoke or joystick doesn't move the 3D control column in the cockpit when the AP is engaged. It's not that big a deal.

Is the Sperry autopilot supposed to drift this much on the roll axis? After I get the plane trimmed straight and level as closely as I can in cruise mode, I enable the AP and it engages just fine. But it never stablizes in roll axis. It will drift very slowly to the left or right, so every minute or two I have to manually click the roll knob to regain my set heading (and then an equal number of clicks back to the "center" on the knob). The drift is something like 5 degrees every minute and a half. This is with zero winds and turbulence. I can understand an imperfect, early system, but that's much more pilot input than I would think is necessary. Especially if it's supposed to be coupled to a gyrocompass. The way it's working now, it's acting like just a fine-tuned aileron trim control, with no feedback loop from a gyro or other heading reference. Maybe this is the way the real one worked, but if so, then I might not be able to use it like was planning to in FSEconomy for long-distance flights. It's just too much drift and too much constant attention needed. By the way, the pitch function works okay. It can be a little finicky, but eventually I can get it to hold a level altitude. Another odd thing is the way the AP locks out all control input from the yoke. I don't know how the real one responded to control input, but I don't think it would have been possible to mechanically disable the yoke this way. This isn't as bad as the lack of the AP to hold a stable heading, it's just something that feels weird in a vintage airplane like this. P.S. in every other respect, this model is a lot of fun to fly.

I have a mixture controller (analog "Incr" wheel on the Warthog throttle quadrant set up for mixture). But it's a continuous control setup. That won't work here, because if I understand this correctly, it's a discrete switch with different states -- "Off," "Auto-Rich" and "Auto-Lean." It's not a continuous control like normal mixture. You'd need a 2-way momentary or three-position button to control it from a joystick or throttle quadrant. Take a look at how they do this in the Hydroz PBY Catalina model for X-Plane. I assume this is the same thing, from the same era in radial engine planes. Here's the .org forum post where they added a fix for controlling it with a joystick button: http://forums.x-plan...showtopic=57550

My $.02 opinion, is that this would be the best way to handle it, instead of adding a modern EGT gauge that wouldn't look right in the old-style panel. This would be similar (or the same) as what Hydroz is doing with their recent PBY Catalina model. If you add this control, then please make sure you do what they did, and allow mapping joystick buttons (or keys) to the carb settings, so they can be quickly adjusted without using a mouse to manipulate the controls in the cockpit.

This is a wonderful model. If you haven't read "Fate is the Hunter" by Ernest K. Gann, then buy it and read it now! It's about the early days of civilian and military aviation, and a good portion of the book is about flying the DC-3. I only had one ride in a real DC-3, and it was a long time ago in Venezuela, on the run out to Angel Falls/Canaima. I'll never forget that.

Here's the thing about 100 mile visibility. There are some parts of the world where there are geographic landmarks that really define the area, and it doesn't look right without them. I live in one of those areas: Puget Sound near Seattle, which is dominated by Mt. Rainier. On a clear day, I can see Mt. Rainer 100 miles away at ground level, let alone up in an airplane. The whole Puget Sound area just doesn't look right, without it. With X-Plane's current visibility limits, Mt. Rainier doesn't look at all realistic. You can't even see it until you're already flying close to the foot hills. You never get to see the classic postcard image of the mountain. Same thing with Fuji in Japan, Popocateptl in Mexico, or any other distant, clearly visible landmark mountain. Ideally, there would be a way to have X-Plane recognize prominent landforms like this, and display them at a distance without having to draw everything out to 100 miles. But that's probably not going to happen. It's easier to use the brute force approach, and just force visibility out to 100 miles.

Guys, this is not confirmed as arsenic life. It's all way overblown. The group behind the study are getting a lot of flack from others in the field, for doing "science by press release." See this: http://www.slate.com/id/2276919/pagenum/all/#p2 NASA is getting a little desperate for good press these days. On the other hand, there actually was good space-related news today. The SpaceX private launch company got Dragon into orbit, and back down safely. First launch to orbit and recovery by a private U.S. company: http://www.spacex.com/

There's no denying that big screens help immersion in a sim. However, I have some side projects that require pro-level, calibrated color accuracy. That's hard to get in super large large sizes without spending a fortune, and the refresh rates for monitors in that class tend to be too slow for running games and flight sims. So right now I'm stuck at 21". But man, the colors are nice...

I think one potential flaw in this poll, is that "eye candy" can be internal (cockpit) or external (plane exterior), and people will differ on how important each element is. Some people only want models with 3D cockpits, while others couldn't care less and are happy with 2D cockpits. Or they don't have the hardware to take advantage of 3D cockpits, so they'll downrate that aspect of the sim. I use TrackIR and seldom fly any planes that don't have 3D cockpits, so you know which side of the fence I'm on. I had to vote "want it all," although I really only care about the cockpit and I don't care that much what the outside of the plane looks like. This may reflect another split between the airline sim pilots and the light GA sim pilots, who spend more time flying VFR, and less time staring at the panel.

Not even a US state, but more specifically a Midwest or Northeast industrial US state. Miami doesn't look like that, Los Angeles doesn't look like that, let alone New Delhi, Paris, Mexico City, or Rio. I know it's just textures on cubes, and a lot of little bitmap textures will fit on a hard drive. But still, they'd better have a ton of world building textures and vegetation, if this system is going to work outside the USA. On the other hand, this should work fine for autogen airport buildings, since those tend to be very generic, modernist/functional architecture all over the world. There are a few exceptions like LAX, and those are likely to be available as custom scenery anyway.

Wow, I hope they can throw a few more digits on that AP selector. I've been doing a lot of FSE flying down in New Zealand and often have to go 12,000 - 13,000 over the mountains. I think the service ceiling is somewhere around 20,000 isn't it? On the instability under AP, I wonder if that could be a problem with the C.O.G. settings, where the AP runs out of trim and starts to oscillate? I've seen that in one other model, the free Pilatus PC-6 Porter. It sometimes has a tendency to wobble on AP, and I've had it actually depart controlled flight and head to the ground. I only notice it when the plane is loaded close to MTOW,

Arrrgh!.... cue my standard rant about model designers deciding they have a wonderful new UI idea, resulting in an instrument that works differently than it does in any other plane model (grumble) I've already read on another forum that the ADF doesn't work in the new X-Plane release. It sounds like the user just didn't grok the "new" way of doing things. Do we really need two or three different ways to twist a knob in the sim? /end rant I'm looking forward to reading some more reviews of how it flies, although I'm still not sure I'll buy it. Right now I'm doing most of my flying in FSEconomy, and I'm mostly interested in planes that are virtual money-makers there. The Mooney doesn't carry enough cargo or have enough seats. Tom, bring on that Caravan! ;D And whoever is doing that Twin Otter... that one too! And both with floats, por favor!

For what it's worth, I just posted a question on the .org asking for feedback about the flight model quality, and that was before seeing your post here. I'm assuming your objection was something related to the flight model and not the cockpit modeling? That could use some clarification. It will be interesting to see how this goes, and I can't help but say that I'm bringing out the popcorn for this one.

Same here. A flight sim isn't a flight sim without some version of a light Cessna and a DC-3. Everything else is gravy. Although, I have to say that Heinz' DC-3 is fun to fly, and it looks pretty good on the outside. The main thing lacking is a 3D pit that's up to current visual standards. One other thing... I hope that if and when we get an AAA-grade model for X-Plane, it's available in both vintage and modernized cockpit versions with GPS, autopilot, etc. I spend a lot of time flying Heinz' DC-3 model in FSEconomy, and I appreciate having handy autopilot controls, as well as the GPS. BTW, there's a new DC-3/C-47 coming out soon for FSX. Click on the "more screenshots" button, it launches a separate browser window with images you can enlarge: http://www.justflight.com/developProduct.asp?pid=532#