Nils

Don't worry about X-plane's native autopilot. The 737 autopilot is coded by us from scratch. Currently around 2000 lines of code and another 500 the MCP.

Yes on the 1CH autoland capability.

Not sure if it's helpful but I like to think of it as a system aimed to reduce phugoid oscillations

We have experimented with hiding the exterior and cabin while in the cockpit, but did not see any measurable difference on our hardware setups. This does not rule out that there could be benefits on some hardware combinations, especially with regards to VRAM consumption, but the solution had problems which speak against it. If I remember correctly, one key issue was that the "view is exterior" dataref is updated with a one frame lag, meaning that we would see the aircraft 'naked' without exteriors for one frame when switching from cockpit view to exterior view. I'm developing on a rig that is soon 4 years old and I'm getting better FPS in the 733 than the default 747. Considering all that is going on during the rendering of a single frame in the sim, counting scenery, flightmodel, systems model, cockpit visuals etc, the task of drawing the aircraft exterior is apparently neglible by comparison.

http://developer.x-plane.com/2014/03/better-long-range-visiblity-in-x-plane-10-30/

Currently 994 and counting. And yes, saving ald loading all of those + the hundreds of internal variables, tables and system states that currently don't write to a custom dataref is quite a bit of work and not a v1.0 priority.

Our general design philosophy has been to always optimize solutions where possible, but to never omit critical functionality for performance reasons. Making the most realistic 733 possible is the primary goal. So far she's still performing acceptably and better than many way less complex and detailed models.

I have a pet theory that we are approaching a limit to how much of a modern airliner we can realistically model on a 'study sim' level with justifiable efforts and that in the future, we will mostly be flying ridiculously detailed models of old aircraft. This is because the aircraft industry is quickly closing the gap (or already closed it) between the amount of software development that goes into the real aircraft versus the simulator models provided for entertainment. Coding up a model of the 733 systems (like we are in IXEG) or even the NG is one thing because the real aircrafts are still very much based on 1980-1990's hardware and computing power (think 386 CPU's...) and this severly limits the range of functionality. And this still takes years and years! If you look at something like the Gulfstream PlaneView cockpit or, I assume, the latest gen Boeings and Airbuses, you have probably 10-50 times the software functionality to reproduce if you want a near-complete simulation. And if you manage to code it all, I doubt that our Macs and PCs are equipped to run the simulated cockpit software in parallell with X-Plane at acceptable framerate since the real aircraft probably has similar computing power to run the avionics software ONLY. I may be underestimating the capability of tomorrows simulator modellers a bit but I still think those of us who are into 'classics' with steam gauge or CRT/steam combo avionics are going to be way more satisfied in the future than those who crave latest gen cockpits. Now back to topic.

From memory, the SDK has no per-throttle override support and therfor only one of the throttle angles is actually tested against the joystick thro angle to decide when to hand throttle control back to the simmer. Probably the no 1 lever if I have to guess without looking at the code.

Those are textured. Of the features that are modelled on the nacelle, the three vents seen on that pic are among the smaller. Again, a matter of philosophy. There's a lot of sublime modelling work done that looks great in the ambient occlusion vapor-shots, but in the actual sim, textures usually work as good or better than additional polys, especially when you have normal and specular maps to play with.

Becoming a dad has kept me from the IXEG kitchen for a few months but I've had a little time again recently to work on engine textures. Figure I'd show the bottom of it because it's more interesting in terms of detailing. You won't fint many useful texture references of the bottom side of a CFM56-3 online, so as much as my crawling under one of these in a Lufthansa hangar amused the surrounding maintenance crews, it did pay off when it came to painting it. In case someone wonders about texture resolution and use of decals, the pic below is pretty illustrative of our 'target range' that we want stuff to look crisp at (click image for full size!). We discussed using as much as 4 times the texture space to achieve twice the resolutions, but we don't think it makes a good trade off between appearance and VRAM demand. We want this plane to at least load for you with 512Mb video cards. Regarding decals, we have hundreds of megapixel photos of decals and bolts and rivets covering virtually every square foot of the aircraft and we could certainly make every warning text on the entire fuselage readable using 'decal' techniques. By 'decals' I mean the use of 'skin' polygons sitting on top of the main aircraft geometry that are textured with a high-res picture of a warning label or maintenance panel. The thing with these however is that, if done to extremes, I believe they do the overall apperance disservice. At least to me, large differences in texture resolution on adjacent surfaces draws more attention to the lower rez texture and the visual effect of the decal, however crisp and sharp, is lost. A reasonably hi-res but consistent texture sells the model better than one with bits of extreme detail bolted on to it. So for the 737, we do use decals but make sure not to overdo them. The engine in the picture has a handful of them for the smallest warning signs - not to make them perfectly readable at any distance, only to enhance the sense of detail at a reasonable viewing distance.

Indeed we have. One challenge is when we predict initial climb out waypoints on "runway heading" and try to make those align reasonably well with Austin's runways headings which are incorrect/out of date. But as you point out, there's only so much we can address within the 737 project.

Hi, in your X-Plane 10 folder there's a program called Airfoil-Maker. Start that and then select "Convert all airfoils..." under the File menu.

Quite clearly, it's the aircraft type, not the modelling/sim representation that counts in this case.

Yeah, that's what I suspect too. Perhaps you'd consider a custom hard surface functionality using groundplane override sometime down the road? I really really like the idea of having all scenery available on demand without having to install stuff. I can see the potential for wiki-like collaborations once everyone starts adding stuff. Very cool. Re bullet physics, one could really see something like this as a great platform for games and missions too.

Awesome Ben! That's thinking outside the box! Assuming you're using the draw object API, have you checked yet if hard surfaces work on drawn objects? It'd sure be nice to be able to replace the hideous default heli pads.