With regards to the scenery system, the idea of orthogonality is this: each part of the scenery system should be unaffected by other parts, such that they can be used together in any combination. This allows you the most options in creating scenery for a given set of features.
One way we try to achieve this is by only having one way to implement any particular feature. For example, because it is possible to place custom objects in overlay DSFs, we are unlikely to allow custom objects to be placed via the apt.dat file. Having two ways to place custom objects would invariably lead to subtle differences in how the two worked; not all features would be usable everywhere. It would also mean more code (read: longer time before you get to use the feature) and more subtle bugs.
Once we have a feature only available in one form, we can try to use that mechanism everywhere. For example, objects can be animated. Because any object can be animated and objects are used both for cockpits and scenery, the work we did to provide animation allows for animation in both scenery and the cockpit. When we get cars back on the road, they’ll probably be objects; navaids are also objects now, and someday hopefully ships and oil platforms will be too. Each time we recycle OBJ8 for a part of the system, animation becomes possible in a new domain.
So usually the ‘orthogonality’ strategy, code something once and use it everywhere with no duplication, means more flexibility and features being usable over a wider area. Every now and then though it bites us in the ass. Flexibility is a strength and weakness; the more we allow any part of the scenery system to work with any other part, the more likely two parts will be used together in a way that we never expected, potentially revealing bugs.
Here’s an example that I only realized existed today, after talking to Peter about animation: it turns out that if you use a textured light inside an animated object, the light (which is secretly a flat square that always points at the camera) will actually turn with the object, revealing that it is flat, and being invisible most of the time (either because it’s facing sideways and is very thin, or because it’s facing in the other direction entirely).
The problem is: when working on animation, I forgot about the textured light system and forgot to cope with the case where they interact. When the code is truly separate, an orthoganal design works well; where the code has internal interactions, it does not.
Do you care? Well, we are looking at some new features for the textured lighting system in 850; there is probably going to be some fine print about how you can use the new textured lights with animation. Even though the features are orthogonal, the code that runs it is interdependent, so some cases may not work right without extra work. How many strange cases we fix, and how many we say “just don’t do that” for will depend on how useful they really are. For example, not being able to have lights on animated objects at all would be a real limit, but perhaps not every kind of light needs to be usable within an animation. For example, VASI lights are usually just mounted on the ground.
