Lego Brick Code

When Sergio first proposed generic instruments, his model was "lego bricks". The idea was to provide a number of very basic parts for panel makers and let panel makers mix and match. The result would be huge flexibility for airplane authors without code bloat.

The problem with non-generic instruments is that there is such a huge variety of behavior among airplanes...if Plane-Maker were to have options for every possible plane, the "special equipment" screen would require 3000 tabs and be completely unusable. Hence the need for a smaller unit of modeling: the lego brick.

The prop disc is the first feature I have done that is meant to be used only by a plugin, e.g. "lego brick" code. The X-Plane systems code sometimes suffers from the same "code bloat" problem as the instruments: a ton of very specific, very tweaky behaviors that interact in strange ways and become very difficult to manage. It's not that the systems code is bad code - it's that the scope of the problem is simply too large. That is, you can't expect X-Plane to cleanly simulate the systems of every airplane ever in a ton of detail through an a la carte menu of check-boxes.

The idea of the prop disc is: someone (LR or otherwise) can write a plugin that encodes a certain style of prop disc. That plugin can then be picked up and moved around like a generic instrument between planes (perhaps with a corresponding text file to control it).

If someone else comes up with a different/better prop-disc algorithm, compatibility isn't an issue...that person writes a new prop disc plugin and the airplane author selects the one desired. Think of it as sort of a portable flight model that stays with your plane.

So we win in three ways:

• Anyone can write the prop disc algorithm, not just LR.
• The code lives with the plane, to avoid compatibility problems.
• More than one plugin can exist, giving authors an a la carte menu.

That's the theory at least.