So I checked my source archives, and this bug was present in v2.00 - since 2014. So, from what I can see, I wrote it like this because... well, I don't know. Presumably, the effect is to be able to say "I don't know what to do with this variable, so ... let SDT handle it." But that's a useless thing to say or do, because, well, how is DialogueActions supposed to know whether a variable value should just be set in the local scope?
About scopes
There are 4 scopes. I've used the terms "local scope" and "global scope" before when explaining local and global variables, so I'll try to use the same terms here. There is a local scope, a global scope, a system scope (to refer to the "system variable" I named earlier) and a save scope. This is from the perspective of DialogueActions; if you were writing a dialogue, you'd tend to talk more about local, global and "da scope".
The local scope consists of variables defined in initial_settings. The local scope is stored in g.dialogueControl.advancedController._dialogueDataStore.
The global scope consists of variables that have been created via [DEFINEGLOBALS_...] and related triggers. They exist in DialogueActions - variableManager.globalVariables to be precise.
The system or mod variable scope are all variables that don't really "exist" but are defined as special keywords for DA to hook on. That's stuff like da.breathPercentage or mt.cuminmouth. These exist in DA's variableManager.registeredVariablesSet and variableManager.registeredVariablesGet
The save scope are the variables stored in a savefile. Those'll be in some SharedObjects folder in your filesystem.
When using SETVAR or the set line-attribute
When you write to a variable, normally, the variable and value are stored in local scope. DialogueActions may interfere; if the variable resides in system scope, the variable will not be set in the local scope.
This is where the bug is at the moment; this doesn't happen in cases where the function called doesn't return a value. If the variable doesn't exist in system scope but does exist in global scope, and the variable is currently linked, any writes will be copied over to the variable in global scope - thus affecting both local and global scope.
When inserting via asterisks
I'm gonna ignore the so-called "Substitutions" (YOU/YOUR/ME/MY/FINISHES) in this section.
Without DialogueActions, the variable is inserted from local scope if found. With DialogueActions, the requested variable is split up based on spaces. Then each variable is checked to see if it contains operators (if so, that's an error ... somehow ... probably to stop my-variable from blowing things up). Then it goes into something I call a "StringQuation" which tries to treat the whole thing as a expression. Result is that you can do crap like *4 + 3*. Anyway, if a variable in a StringQuation is not found in system scope, it will try the local scope. That's important - insertions go system scope first, then local scope.
When using the check line-attribute
When using the check line-attribute, the
local scope goes first. This because... I don't know... ... The best reason I can come up with is "to try and break the minimum possible". I don't plan on changing this because DialogPatch also changes the check mechanism. DialogPatch v4 should work with future DA versions.
Anyway, I have fixed the check line-attribute so that it properly identifies if a variable exists in system scope or not - see
Pim_gd / SDTDialogueActions / commit / d25a8a30b3a1 — Bitbucket.
Here's a build to play with.