We received a lot of questions about the Custom Scripting Engine, which we mentioned in our kickoff post. Therefore, we will now go into more detail.

Basically, X-Plane provides a large number of functions by default. For the average addon this is often sufficient. For us, however, it was clear from the beginning that we wanted to implement things in the C421 that X-Plane does not provide. Therefore we looked at different options at the beginning, such as:

Xlua: A variant of Lua adapted for X-Plane, which is also used by standard X-Plane aircrafts like the 737. It is characterized mainly by its rather simple approach. Even less experienced programmers or even complete newbies can achieve good results after a short learning curve. Disadvantages, however, are a limited range of functions and only moderate performance.

In contrast, SASL is available as a comprehensive, professional tool, with which almost all wishes can be realized. However, deeper programming knowledge is required for this. The market knows only a small number of resources who are familiar with this and there is no one in our team. Bringing in external programmers is often difficult as well. While they can learn quickly, they often lack the aeronautical understanding to adequately implement an instrument or logic.

Basically, we wanted both: an easy-to-use scripting language with an extensive feature set. So we had to create this ourselves. To explain this in detail would go beyond the scope. But simply speaking, it is an upgraded XLua variant that has been integrated into the syntax of the scripting language wren, which can be compiled into all three supported X-Plane operating systems (Windows, Mac, Linux). Of course we did not start from scratch but used common callbacks like AfterPhysics or FlightStart. Therefore a migration of a xlua script is not too complex. But thanks to our several additional functions we are able to solve complex issues quickly and efficiently without the need of a highly skilled coder.

A few examples:

We can store data in different preference levels via a simple module. For example, we can store user-specific data in the output/preferences path, which can still be available after uninstalling the aircraft, so that an update or reinstallation can fall back on the previous settings. Or we can store configurations of the aircraft within the livery, such as the choice of landing lights. As mentioned in the kickoff, the C421 comes with either 1 or 2 retractable landing lights in the wings or retrofit LED lights on the front engine cowling. The user can save this configuration per livery and repainters can also pre-configure this for users.

We can extend or override standard X-Plane commands. This is useful when we want to simulate an instrument with a custom display that includes functions beyond the X-Plane native functions. For example, in the GTX330 Transponder. By means of the X-Plane Commands the transponder mode can be controlled and the code can be entered – so far nothing new. However, the GTX330 has modes that use the same buttons (=commands), but have completely different functions. For example, a countdown time can be set with the number buttons. Without our code, the transponder code of X-Plane would always change. We can now suppress this situationally. On the other hand, we can always ensure that the customer can continue to use all of X-Plane’s standard commands and does not have to map all of his hardware to his own commands (at least as long as X-Plane provides a command for the corresponding button).

Furthermore, we can display content not only on an instrument, but also in the entire X-Plane window. We use this, for example, to display the breathing mask if the pressure control is not set properly.

In addition, there is an extensive in-game debugging, with which we can analyze the code in real time and also reload it within seconds, without having to use X-Plane’s own reload function. A really comfortable way.

We also implemented the activation logic developed by Stairport, as already successfully used in products like shadeX and ProCam. With this, we not only have an automatic integration to large online stores like x-plane.org or Aerosoft, but we can also perform an automatic activation in the background for Steam users.

In terms of performance, we have achieved great values, but they have become somewhat worse in the meantime, simply because we now have an incredible number of calculations in this aircraft. However, our modular approach also allows us to disable partial scripts when they are not needed at all. So depending on the situation, performance can vary slightly. However, hopefully hardly any user will notice this in normal use. On our test system, we got about 80 fps with all code disabled, and still about 77 fps with all code enabled. Of course, we are still working on making all the code as efficient as possible.

There would be many more examples. However, with this post we don’t want to praise ourselves, we just want to give you a glimpse behind the scenes. It is important to mention that there are other ways to achieve our results (cue SASL). However, we would not have been able to implement this with our know how in the speed.

We are still missing modules that we would like to incorporate in the long run. We are working our way from instrument to instrument, let’s see what is still to come.