As the development of the plugin was progressed so the complexity it allowed for designers.
The main goal was: You will fill in the values in the XML, the plugin will play by these rules.
This translated to: zero code writing from the designer, it was up to developer to deliver the implementation inside the plugin. That, of course, made the plugin more and more complex to write and maintain. The number of small features like "delay message" were neglected at some point, and were not tested as part of QA, so for all I know it might be broken, or not.
This led me to try something else... I did not publish it yet, and I have no idea how it will be accepted by designers, but it is an exiting yet concerning feature in some way, to those who adapt to the way the plugin works. By that I am referring to "embedded scripts". There are many pros to embedded scripts and you can find some implementation in flywithlua, or x-plane own lua implementation for aircrafts, sasl etc. But the major concern from my part is: performance and simplicity.
When you write in C/C++ which is the native code for X-Plane plugins, you can expect a certain performance from the plugin, but once the plugin asks another "engine" to execute a code while running, it raises lots of performance concerns. My main concern was FPS hit.
To make long story short, I started checking the capability to implement "embedded script" inside Mission-X plugin, I read about LUA, python, wren, Squirrel , Pawn, MY-BASIC and others. To tell the truth, I have no idea which one is best, but I know that I'm searching for an embedded solution that will allow:
- Simple Syntax for designers
- Expandability - easily adding commands that will interact with the plugin.
- Performance - No performance degradation when running a script from the plugin.
- Hopefully - easy to integrate with C++ project - Not too many files and libraries and dependencies to achieve my goal.
My current candidates are: MY-BASIC and Wren.
From performance point of view, MY-BASIC is probably not the fastest, but from syntax point of view it seem the simpler. On the other hand, Wren should give a better performance but I haven't test it enough to give any concrete opinion.
I have done some tests with MY-BASIC, and so far it is quite promising, it is also important to understand what is the goal of the embedded scripting vs what you can do with it.
In any embedded scripting language, you can write a short or long script to do simple or complex work instead of the native code. In our case C/C++. For example: the script can write to HDD or do some calculations or even draw GL Lines, Its code is simpler to write (in most cases) and more readable and you do not need to compile the code for every change, you just need to "reload" it (take Flywithlua as an example).
My intentions are completely different, I do not want the designer of a mission to start and construct an elaborate code just to add a feature or capability to the plugin, no, that is not what I want or the plugin needs. What I do want, as a proof of concept, is to allow a designer to add logic code in specific locations in the plugin, to allow him/her enhance the experience of the mission. I want the designer to be able to:
- Query step name (real name not the title).
- Fetch Dataref information (only int/float/double datarefs are supported, no arrays).
- Send a message (communication message).
- Send visual cue message (print on the top right of the screen).
- Abort the mission.
This might not seem like a flexible interface to work with, but it is a starting point. My current intention is to allow a designer to write a "post_step" script to run his/her logic in it so you can add special messages or logic to handle the step. The truth is that I think that in the current state, an "instructor" like implementation will benefit from it, but in the long term almost each aspect of the plugin will be wired to the "embedded script" mechanism, In most cases as an option but in some cases as a complimentary implementation.
My end goal will be for each logical part to execute a script where we could have a more flexible way to manage flow but the code must be to the point from performance point of view.
What does it mean for current missions
Embedded scripts as a central implementation of the plugin will undoubtedly lead to a new major version for the Mission-X plugin and will need a new set of missions, or at least to re-write them to adhere to the new rules and syntax.
What are the main goals for the future Mission-X plugin
This is a tough question to ask at this stage, since the design is still in its first stages, but I can admit that I want the plugin to be:
- Simpler to implement, in terms of code (C/C++).
- Less internal features will be transition: let's face it, only small amount of features are being used by designers. It might be too complex to use them or documentation was not clear enough.
- Logic will be divided between "plugin" implementation and "script" implementation.
This sounds like crippling the plugin. I really hope it won't.
When I think of features and concepts to keep, I think of the following:
- Steps: this concept of defining many steps to reach an objective should be kept. It allows a designer to break the mission to parts and restrict simmer to move forward only if he/she finish the current step.
- Trigger Zones: the event areas were always an important part of designing a mission. They will stay with us, but it will go a huge revision. The biggest one, I believe, is that the plugin will call an "embedded script" to process its test and outcome logic once it was fired. So the plugin will only handle the triggering part, but nothing else (almost).
If no script will be given, we will treat the trigger event as fulfilled, which will fire the "onSuccess" event.
There are many aspects and flags to the "trigger_zone" that might go away or move to the "embedded script" part, and some that we will retain for simplicity. - Communication Messages: I think that the ability to send communication to the simmer is important, the problem is how it will be done. If we will use X-Plane SDK, it means that messages will be printed and narrated. If we had our own narrator, that would have been a boon.
- Random: Will stay, and be expended, but probably after finishing skeleton implementation of the plugin.
- 2D Map.
- Widgets: Briefer/Inventory/Debug - TBD
Overall, the core experience should stay the same, the huge difference will be the way we implement it.
Until today, a mission should have only one file, the mission "data file". In the new implementation you will probably need to create one "data file" and many "scripts" to handle different aspects of the mission.
Other thoughts
There are many aspects when designing the Mission-X plugin, I hope that in the next iteration we will see a balance between pure XML driven based missions and pure SCRIPT based missions. I hope that the new implementation will allow a higher flexibility, with minimal code writing to achieve your designing goals.
One way to do it, is by creating snippets of code. If you want to read a DATAREF value, we can provide a simple snippet, and you will just have to fill in the missing information. That way, parts of code could be easily combine with other parts that we could not prepare as snippets.
Let me know your thoughts, you can send them directly to my e-mail.
I'll update with the progress once I'll give it some more thought.
Cheers
Saar