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.