- There aren't any planes to "migrate away" from Couatl.
- There weren't many "other developers" using it and moving away from it. There was just one, Flightbeam, which didn't really use it or require it for doing what is supposed to do (a script language that allows to do things impossible otherwise), and instead used it only for its less important feature, which is copy protection. Paying a license to use 1% of the features is not very sensible. We use it at its fullest, of course.
- Couatl is very stable because, being an external .EXE file, it's entirely safe and can even crash *itself* without bringing down the whole sim, which is instead what can happen with each and every other addon module you installed in your sim. Everything that is a .DLL can be "unstable" and unsafe, risking the simulator stability in case of problems. Couatl, instead, is very safe and it's not posing any risk to your sim.
- Most other sceneries only require basic things like making things appearing/disappearing on demand based on some conditions, and that surely doesn't require something as powerful as Couatl, which is a full blown programming language, but we don't usually stop there. Why you think Flytampa docking systems (for example) offer you a choice between P3D native with limited functionality or more functionality but made for FS9 ?
The new KORD has working dynamic information panels on gates that shows AI informations, with ETA/ETD, stand coordinates, even reads your own flightplan dep/dest airports and shows even the progress of the GSX boarding/deboarding process, how else you think this (that no other developer has even come close to) could work, if not with a proper Python script that runs, you guess, under the Couatl interpreter ?
We even have a working AI informational panel inside the terminal, which is almost like a whole separate add-on functionality (similar to Flight1 Supertrafficboard, which is a separate addon), INSIDE the scenery. Again, a Python script that runs under Couatl.
And of course, the whole GSX and GSX Level 2, are written entirely in Python running, again, under Couatl.
So no, "moving away" from Couat doesn't obviously make any sense for us, because it would mean losing to many features we require, and losing our best-selling product too.
As an example, in case we'll ever want to start supporting X-Plane, and of course the most requested program there is GSX, the first step doing that would be programming a X-Plane version of Couatl first. After that, it would be basically done, since GSX doesn't even know it's an FSX/P3D addon: it's just a Couatl script that might as well run inside another simulator (assuming there's a Couatl for it, and it works exactly the same), without even knowing it.
That's what allowed us to be able to support P3D4 ON ITS RELEASE DAY, without dumping FSX as the same time, while many other developers are still struggling with it now and some products were even lost forever (one was AES...), because they were too heavily connected to the host sim, so they couldn't be ported very easily.
That's what allowed us to make old FSX airport working nicely in P3D4 without doing massive patches: Couatl is working behind the scenes, calling different objects and using different techniques and even different memory management, so we can just update only what is required to be update, and it's all done in the background. KMEM, for example, has a very complex terrain management system which cause some fps hit and visual issues on FSX, but it switches to a native P3D terrain in P3D4 that performs much better, without requiring two separate installs or patches, because the Couatl script that runs it does different things depending which simulator is being run under.
We'll do the same in handling the difference between PBR and non-PBR objects in what I think it's a very elegant way, still allowing everybody to use the product (not requiring *everybody* to update to P3D 4.4 *now*) in the next GSX update, which will introduce PBR, and will eventually end up replacing, gradually, all GSX objects and animations with new versions, without disrupting the program workflow. Again, all courtesy of Couatl, which is handling the two methods without requiring too many changes to GSX itself.
Other developers experienced massive fps hit with dynamic lighting. Not us, since Couatl can handle a specific fps optimization for DL that is not possible without a software module, which use advanced LOD methods (not just based on range, but using actual regions with custom shapes), showing only the DL lights closest to you, when they are required.
I haven't even started mentioning:
- The custom collision system (100% Couatl) that makes the KMEM interactive Control Tower possible, which we'll also use a lot in KORD.
- The new custom camera system we'll introduce in the next GSX update, which uses a new hybrid system of Simconnect+PDK, so we can create custom cameras on the fly WITHOUT messing with any of the default cameras in the default cameras.cfg file (like any other camera add-on out there does), and yet still be easy to manage since, again, thanks to Couatl and its integration with the Addon Manager to do the PDK part, it's all exposed to us as new Python commands, so it's all very coherent and easy to maintain.
Seeing how much complex AND powerful P3D4 has become, but has a very steep learning curve, which requires knowledge of both Simconnect and the new PDK, I can safely say we are positioned way better than anybody else to be able to fully exploit its capabilities to do something better because:
- Simconnect, which is better suited for add-ons running as external executable (due to its client-server nature), requires a .EXE module, and we have Couatl for that.
- The new PDK, which is hugely powerful and still almost entirely under-used by developers, requires a .DLL module, and we have the Addon Manager for that, which IS a PDK plugin.
- The fact that some things are only possible with Simconnect, some only with the PDK and the best way is to use that, requires a communication between your two modules, and we obviously have that.
- The fact this is all very confusing and difficult to use, since the PDK *requires* C++, while Simconnect can use C++, C# or Visual Basic, has been fixed by us long ago so, instead of losing time integrating different languages (Simconnect devs usually prefer c#), we write everything in Python, so our code is totally platform independent, and Couatl is what makes all that possible. We can easily have a line of code calling Simconnect, the next line calling the PDK, the next one calling a custom function that does, for example, animation, all from within a single script. Again, Couatl.
So no, again, asking if we'll ever "move away" from Couatl, is as a silly question as asking to Microsoft if they will ever "move away" from Windows because, as complex and sometimes infuriating Windows might be, it's not replaceable.
