Few of you guys were asking about the manipulator and stuff in aircraft dev. Was trying my best on Discord, but with the glitchy formatting and all that, it's just a meh.
But after a night of coding on that auto link-break stuff and ended up with no luck, it feels shit.
Imma take a further look later, just not today :/
Back to the topic. Imagine you wanna make a car door in X-Plane which could be open and closed by dragging or clicking on the handle object, how can you get it done with the collaboration between the visual model and its manipulator?
Before we dive too quickly, what is a manipulator?
Generally speaking, the manipulator is the one that manipulates the processing and exchanging of raw data between the user and X-Plane itself by outputting manipulative commands. Ruled by default setting, an aircraft shall only have one manipulator object, which however may contain multiple objects by grouping them together using an axis or similar non-exportable stuff in Blender.
However, as we're trying to export some sort of command to the system, the Dataref must be writeable, like the ones in sim/aircraft/controls but not those fixed data running solely by the system.
Referring to the graph below, the "Clickable" group in this particular project is the one with honor, who acting as a manipulator and collecting everything from the minions, ended up with a holistic "data pack" for X-Plane to read and process.
Manipulators do few things: 1. Collecting user mouse output from 3D cockpit view 2. Register a clickable spot by using Dataref 3. Identifying advanced movement (In cases like "Wheel Delta" and "Drag XY/Axis" param) 4. Deliver a command to the system urging for a change on each interaction 5. **Obey the change in parent object**
The number 5 is seemingly confusing, lemme explain a bit here.
Manipulators are model(s) which have been marked as "cockpit clickable region". The system read it as normal art assets, just hesitate to draw it simply because you have given it an "ATTR_draw_disable" command by ticking off the "Draw Object" command in the Texture Panel.
Along with this theory, the manipulator can be treated like a model, there's thus plenty of room for us to make some moves like animation and all that. You can either make the model animative on its own, or you can grab an axis to be its parent which is a more secure choice in most cases. But whatever you choose, remember that the animation has to be driven by a solid float/int Dataref. Yet, don't forget to adjust the array number in  or it won't be shown correctly.
Some of you may remember the quote from the movie "Interstellar" about love...
Well, the thing is, Dataref is another thing that transcends time and physical space in X-Plane.
Back to the door example above, if we toggle the sim/cockpit2/switches/door_open to 1.0, the cor-responding sim/flightmodel2/misc/door_open_ratio will rise. However, this global attribution also impacts the parent object of the manipulator, which resulted in a rotation on the manipulator (clickable region) and empowers it to be able to "follow" the track of the visual mode, given that they're using the same rotational pivot.
Notice how the door handle (green clickable region) moves with the door in the gif below, compare with a static button.
By giving the manipulator the same treatment as a visual model, in terms of its correct displacement in space, they (the clickable area, the green region) will then be able to move along with the change on data in real-time, with zero delays. In other words, both the visual object and the manipulator's parent object have been affected by the change in Dataref, resulted in a coordinative move in these two.
Probably this is gonna be the first post on PlaneMaker rather than scenery dev, but I'll definitely do more in the future. And yes, a completed handbook regarding primary aircraft development is on the way.