Scripts are embedded using MY-BASIC library. The main idea behind the scripting is to have a simple language yet powerful enough to write “pin point” logic. The benefits, is the ability to have flexibility on the logic that will take place.
How do we call scripts
To use a script in the plugin there are two stages:
- Stage 1: Load the script into the plugin and store it in memory. The name of the script is without the file extention.
Example:
File Name: "myscript.bas"
The plugin will load the file and store its name as: “myscript” without the extension. - Stage 2: Call the script from one of the mission elements.
When constructing a mission, there are special attributes for script names. The name that should be use, is the name of the file without the extension.
Example:
“myscript” and not “myscript.bas”.
If for some reason the script file name has more than one “.” (dot), then the plugin will use the string before the first dot.
Example:
File Name: “my.script.bas”
Will be stored as: “my” and "script.bas" will be ignored. - In Mission file we will call the script as follow:
Option 1: <task name="feel fuel" … base_on_script="myscript">
[*]Option 2: <task name="feel fuel" … base_on_script="myscript.func1">
Option 2 is preferable since you can easily define one script for the whole mission, and then just call the right function and pass the relevant seeded parameters you want, if you need.
Since scripting will become core usage in Mission-X v3, I want to share and suggest how I think we should use it, in order to not have too much clutter and hopefully be organized and effective.
- Option A: Create 1 file for each script call.
If we have 5 triggers based on script code, and one task that is based on script, then we need at least 6 different files.
If in triggers we implement “on_enter” and “on_leave” then we add another 10 files. Overall we will need to manage more than 15 files. That starts to sound like a clutter. - Option B: Create 1 file for all needed logic.
This might solve the clutter, but you will have to arrange the code so it will be readable and you could easily find your way around it.
How to do that:
Simplest way is to use the mechanism of functions. You define functions in “my-basic” script, each function has distinguished name, and when you define the script name in the mission file, you also add the function name to call, example: “myscript.trigger1_always” or “myscript.trigger1_entered”.
The plugin splits the script name, so the string on the left represnts the "script name" and the right side of the “.” (dot) represent the "function name". When the plugin calls the script “myscript”, it will seed the parameter mxFuncCall with “trigger1_always” or “trigger1_entered” or any name you will use.
This simple naming convention can easily solve the “clutter” of code inside a file, and the need for many script files. All you will have to do is to call the right function using the “mxFuncCall” seeded parameter. - Option C: This option is similar to Option B, but we still prefer to have few main script files, for example: “triggers.bas”, “tasks.bas”, “objectives.bas”, “goals.bas”, but in them we will handle the code, same as we do in Option B. We will create many short functions that will handle specific cases and call them.
You can pick one of the options above, I guess that option B is good for missions who are not heavy on script code, or do not have many objectives and tasks to finish them. Low complexity.
If you have a complex mission, you can transition to Option C.
My hope, is that a designer, in most cases, will use option B.
Next post will be on how to use the seeded parameters.