Couatl it's a Python language interpreter, which connects to the sim using Simconnect, which allows us to do features that are simply not possible with the standard .BGL format.
Being an external .EXE which connects with the sim using Simconnect in client-server mode, means it's safer for the sim, since even if it would crash, it won't bring down the sim with it (opposite to a .DLL module, which WILL crash the sim if it had a problem).
For the same reason, it's processing time does NOT affect fps at all, because as an external .EXE, it can enjoy the automatic allocation of threads among multiple core of the same CPUs, so it will automatically use the core with the most spare power available, curtesy of Windows, and this is particularly convenient in a sim which is known for using the first CPU core almost entirely, but with lots of spare cycles available in the other cores.
This means we can do even complex calculations without slowing down the sim, because the whole Python interpreter will run on a different core than the one used by the sim. Opposite to a in-process .DLL or .GAU, that WILL slow down the sim when executing complex code.
In addition to that, we don't use a "standard" Python interpreter, but the "Stackless" version, which is highly optimized to execute lots of lightweight threads, so it's perfectly suited for real time simulations.
https://blog.appdynamics.com/engineering/a-technical-deep-dive-into-python/Stackless Python is a language interpreter that does not use the C stack – instead, it manages programs inside the interpreter itself. The main advantage of Stackless Python is lightweight threading. Threads let you run multiple things at once in the same application. Stackless Python supports micro-threads, which are small threads utilized by multi-core processors. In effect, it offloads some overhead of the operating system and Python onto its own stack.
Depending on the scenery, we use it for a lot of things. Generally, we use it to dynamically create and control objects, depending on different conditions like time of the day, date, weather, visibility, distance from the eyepoint, etc. All things that are not possible to do with .BGL. Some of these are now possible to SODE, using an XML control file, but with a Python script, we have more flexibility, since every scenery can have its own script, which is tailored to that scenery needs.
With Couatl, we can have menus to configure the scenery at run time, without requiring to restart the sim. Many developers use external configurators, which simply switch .BGLs but, since switching .BGLs requires a restart, they are very cumbersome to use. Instead, since we create things dynamically with a script language, we can have different configuration options, like allowing users to turn on/off things to optimize fps, without requiring a restart, so it might be possible (for example) to turn off some options during the approach, to get the best fps, and turn them back on after landing, to get the best detail. Not possible using an external configurator that switches .BGLs.
Some of our latest sceneries, like KMEM, KCLT and KSDF, have *hundreds* of small scenes depicting human animated characters at the gates. Doing these .BGL would simply NOT fit in memory on a 32 bit sim (crashing the sim) or they would just destroy the fps on a 64 bit sim. So, we have a logic, made as part of the script that handles the scenery, which checks the airplane position, and will create just ONE animated scene, the one related to the parking you are closest to. And, since creating/destroying objects continuously cause stuttering, the script logic also checks the airplane ground speed, so it won't create/destroy anything, if the airplane is moving.
With our last two sceneries that use Dynamic lightning (KCLT and KSDF), we use Couatl to optimize fps, since DL can be *very* heavy on fps, something that has been obvious with the release of other developer sceneries that have dozen of dynamic lights active at the same time. Instead, our script is able to recognize the terminal the airplane is parked, and even the side, and will display ONLY 5-6 light sources at the most, so their impact on fps would be much lower than if we tried to light all the airport at once. And it's not a crude check like just a range check, but it's made over a polygon depicting the actual terminal shape, so we have full control how many lights will be displayed at any given time, which wouldn't be possible if using just the Effects SDK, with a range controller.
KSDF, of course, uses scripting extensively, to inform GSX about its special parking stands. There's a very strict cooperation between the scenery and GSX, since the scenery must inform GSX about the configuration of each stand, so the scenery script will tell GSX about the waypoints the human character will have to go through in order to push the container from the GSX loader into the warehouse, which something specific to the scenery.
Sometimes, we use Couatl scripting to sort out differences between FSX and P3D. In recent sceneries, we have different set of objects (some made with the FSX SDK, some with the P3D SDK), so the script will display the one correct for the sim in use, without requiring to install different set of files. In certain cases, we were able to fix P3D compatibility issues in old sceneries without requiring an upgrade, because Couatl has the ability to patch files so, for example, we sometime set specific P3D flags or material properties automatically, if the scenery is running under P3D or not. This is all done automatically, without users having to deal with different installers or upgrades.
We also use Couatl scripting to control multi-seasons and day/night transitions. With the standard SDK, both day and night textures for an objects would always be loaded, while we sometimes alternate between a day-only version of the object and a night-only version of it and, in addition to saving some memory, we can control more precisely the objects appearance. Same for multiple seasons, we can separate objects depending on season, without taking any extra memory to load out of season textures. Without even mentioning that FSX/P3D have issues with localtime and timezones, so we are not even relying on the default time and date but, instead, have a script that calculates the actual sun position using real world astronomical calculations. Again, this is done at ZERO memory and fps cost, since it's a script that runs entirely separate from the sim, in the background, using spare cores, which on a typical FSX/P3D configuration, are always available.
KMEM used scripting to allow the Avatar to take an elevator and walk inside the Control Tower in a realistic way, since Couatl handles a custom collision system which is more precise than the default one and can be optimized for the first person. And of course, it doesn't affect in-flight fps, since none of this processing is even attempted, if the sim is not in Avatar mode, and the user is not in close proximity with the Control Tower. Not even the detailed Control Tower interior is loaded, when is not required. Again, thanks to the flexibility of the scripting language, which allows us to fine tune every kind of check related to optimization.
We use scripting to control opening/closing of hangars. And, we use it to optimize their loading as well so, for example, a detailed hangar interior is loaded ONLY when the user open the hangar doors, and it's discarded from memory again when the doors is closed. All synched to the actual door position so, you won't be able to notice it. Yes, with 64 bit it might have been possible to load everything and just forget about it but, those textures and vertex buffers would still take memory on the video card so, 64 bit shouldn't be an excuse to be sloppy and forget about optimization, because even if OOMs might be a thing of the past, fps optimization is still an issue.
At KLAX, we used Coautl scripting to create a "choreographer" system for the famous colored Kinetic Light Installation. We don't just alternate colors randomly (which would still be a bit tricky with just BGL), but we have several programs that do things that have some sense, including the "July 4th" program, which alternates pylon lighting using stars and stripes colors which runs, of course, only on Jul 4th.
And of course, the whole GSX is written in Python. While other developers with complex products had to do lots of work (and sometimes they *had* to charge for it), to port their code in 64 bit, we had GSX and all our products ready the same day P3D 4 was released, June 2nd.
This because, THANKS to Couatl being a Python interpreter and an external .EXE client-server, we didn't had to convert our two most complex software to 64 bit, since the Python scripts (100% is GSX is written in Python) don't really care or know about 32/64 bit issues, and Couatl.exe can still remain a 32 bit executable, since external .EXE are not required to be ported to 64 bit in order to connect with P3DV4, only .DLL and .GAU do so, our work to move over to 64 bit, was limited the Addon Manager .DLL only, which doesn't do much today, other than being an interface for the product activation. This means, we were able to be ready for 64 bit the release date, and we didn't had to charge for it.
If GSX would have been a C++ program running in-process, it would have required a lot of rewriting to support 64 bit and Unicode, and it might have taken months to port it, and it surely wouldn't have been a free. Writing it in Python and using Couatl has been the correct choice, since GSX itself doesn't really care about the underlying sim architecture.
