I would like to share with you a test script that I use to test MY-BASIC embedded scripting. So far I am quite pleased with its integration and the support I receive from its creator. I also admit that I'm not fully used to the "basic" syntax since I usually write C/C++ code, so do not use this example as a "my-basic" language tutorial, in many cases I could strip the code from some e relevant parentheses or variable declaration, but the more I test it the more I find it easier to maintain.
Few words about MY-BASIC.
- Written by Paladin-T (I'm using his "git" name not his real one).
- Its syntax is based on basic which means it is readable and simple to write.
- Its variables are dynamic typed, which means you do not need to declare types of variables.
- Its an interpreter - it parses the code each execution, which means you should strive to have the shortest code path to optimize performance, and errors won't be known until the interpreter will reach the "offending" line of code.
- In Mission-X v3, MY-BASIC has been stripped down from few of its capabilities in order to have a smaller footprint and to eliminate nu-nessccery code complications. I have compiled it without: Classes, lambda, arrays and Unicode support. It just make sense to remove these features since we just need a simple scripting mechanism to allow a designer to make "logical" decisions.
Here is a snippet of code. You can click it to view a larger, more readable, image:
In this example, the main code is located at the end of the script and it calls relevant function ("def") to do some logic.
It is important to place the calling code at the end, since it needs to be aware of the code prior to the calling command.
This allow us to optimize code and assist in rooting out mistakes, since it easy to just comment out (using ' sign) the code that we believe is the root cause, and then try to fix it each run.
In the code image above, you can see I:
- highlighted function boundaries in "pinkish" color.
- Communication functions are colored in green. These are function I wrote to allow the script to "get/set/create" content from the plugin.
Each function starts with: "fn_some_name()".
Most functions return a "boolean" value representing success/failure and seed "mxError" that holds error message.. If mxError is empty, then probably there is no error.
The documentation will hold the list of functions, what value it directly return and which attributes it seeds as extended way to provide more information in just one function call.
- mxFuncCall: If you read my previous blogs, you should be aware that every time the plugin calls a script, it seeds the origin of the call. If you construct the script names like I suggested, then it will hold the function to call. That way it is easier the dispatch the call to the correct function.
mxFuncCall - holds the function that we want to call in the script.
The script I display here, holds relevant code for the test mission and also some code that is part of functionality test.
I hope you can see that the script code is quite readable, and in most cases self explanatory.
Until next update.
Have a great simming