“The images in the following chart, though, could not be used in X-Plane, due to either their resolution or file format…

NotSquare.png 1024 x 2048″

Dom, you are spot on with “isn’t there a way you can separate components so they don’t clash” – that’s what I mean by two orthogonal features. Two features are orthogonal if the operation of one doesn’t induce fine print on the other.

One of my goals with 10.10 and GLOBAL_cockpit_lit is to create a truly “orthogonal” interface between the 3-d panel and the cockpit object. When you use GLOBAL_cockpit_lit, all of the rules for lighting and texturing work just like they do for normal object textures, which helps orthogonality.

First: the new quiet warning is NOT noticeable to you; we are using it only for NEW warnings that we are adding to the sim. If a warning is already “annoying” (meaning it can cause the dialog box to pop up) it is going to stay annoying, and the annoying warning mechanism is going to, by design, remain annoying.

The idea here is that if we have a unified interface in the sim for issuing warnings that _may_ be annoying, we can start adding new warnings now, make them annoying later, and then even later rip out the feature, giving authors a progression (see other posts).

We are _not_ going to make the annoying warning quiet!! It is annoying _by design_. If it is not annoying, authors will simply never bother to fix the warnings, and the warnings would not be annoying if they didn’t need fixing.

Examples of annoying warnings include:
* Totally broken syntax in text files that causes X-Plane to have to simply discard part of the authors work.
* Missing art assets.
* Illegal use of X-Plane commands in text files that causes X-Plane to have to throw the commands out.
E.g. we don’t use the annoying warning without reason!

First: I don’t think I mean the same thing as you re “orthogonal”. By orthogonal I mean two features that have no impact on each other. For example, object manipulators and object material attributes are orthogonal because you can use the two and they do not change each other’s operations.

Re: power of 2 panels, it’s an efficiency thing, and it’s only for panels used as a source texture for the 3-d cockpit. In that case, we’re asking you, in your future work going forward, to pick a power of 2 size. Since the 3-d panel texture is usually “packed” anyway (no need for windows) aspect ratio should not be that important. We’ve been encouraging this for a while.

Re: square orthophotos, I have _no_ idea what you’re referring to here; there are no restrictions that I am aware of on draped pol or ter image usage. If something doesn’t work (e.g. “if my draped pol is non-square the sim crashes”) don’t post here, please file a bug, because there is only a power of 2, not an aspect ratio rule.

Some authors DO intentionally use square textures because the largest texture you can have (now 4096 x 4096) is sqaure – the max dim on both sides.

Right – I am trying to concentrate force a bit on one set of bugs here…

I know you are working hard to sort out the bugs, but I am just wondering if sometimes unintentionally you make more work for yourself by implementing new ideas which clash with existing code. Now, I am no programmer, far from it (10 print ‘run” lol) but isn’t there a way you can separate components so they don’t clash? Feel free to shoot me down as I am but a mere thicky when it comes to these things, lol

Dom

How is this noticeable? I still get the dialog box every time for various scenery packs. Very annoying, the packs work, despite moddifying them or a location using multiple ones. Rather not see that error each time

Non-orthogonal features are the way forward. Orthogonal is a step between textbook and full simulator: learning procedures and cockpit layout. At one point that’s all we had to fly with. That’s no longer the case, and what keeps me interested.

I’m not afraid of change but when a poorly documented change breaks a year and a half of work, it’s the community that misses out. Random example: Laminar models turbulence; we make heads bob, coamings move, wings flex, and even sounds tuned to all that. Change the turbulence model and all the fine tuning goes out the window. That applies to anything: engines, aerodynamic behavior, lighting….

I believe the first rule should be do no harm sans explanation on how to fix what one spent countless hours tweaking. (Not that I’m complaining; XP10 is breathtaking.) Point is, docs — with examples or verbosity aimed at those who use the new features as opposed to those who developed it — are important. The custom props and strobes are brilliant examples of such. Unfortunately not everything can move forward in-step.

On another point, I’m curious about the coercion on power-of-two panels and square, draped orthophotos. Rectangular ones seem to work fine on the latter. Is it purely efficiency or are there other practical reasons? I can: (a) leave it rectangular, (b) cut it into three squares (much more fitting work without a snap to line feature), (c) add empty space to square it and stretch the fit, or even (d) stretch the ortho and squeeze to fit….

You can expect two reports on deferred rendering issues (I believe) soon on b8.

Thanks, Ben. It sounds now more like you’re trying to get all of the HDR bugs out now, and once that’s done (will it ever be done?) then we’ll hear less about the rendering engine and backward compatibility and more about the growth of XP10 and the sim’s stability? It seems to me that the challenge of enhancing the plausibility of the world is a pretty important thing these days. I know you dislike hearing about other products, but you gots to know that the future is coming at us pretty darn fast. Ever read “Future Shock?” 🙂

No flame suit, it’s a valid question, and we can’t support everything forever. There are trade-offs:
– If we spend too much time making old stuff work, we won’t have enough time to make new cool stuff, and the sim falls behind.
– If we spend no time making old stuff work, the useful lifespan of an airplane will become small, which is a strong dis-incentive to make anything.

Two thoughts on the current transition:
1. HDR is just a tough nut to swallow, because the deferred renderer causes a lot of visual problems with even the _most_ modern content authored for v9. So to completely punt would set the backward compatibility window to be very very short. New content causes almost as much problems as old because the big variable is the change in rendering tech.

2. The real problem with the panel/aircraft system I think is creeping incremental development of non-orthogonal features. The scenery was a lot more carefully road-mapped and has been much cheaper to maintain. Many of the old decisions that cause problems in v10 date back to a time when both Austin and I were working on panels and airplane drawing, with no clear road map.

So my take-away is that the next set of panel work needs to be a single set of coherent changes in one shot that makes sense in a bigger picture road map…otherwise two years from those features debut I’ll be cursing myself all over again.