Passing parameters to VoiceAttack through the command line is not thread
safe. For RATSIGNALS coming in in rapid succession (either because,
well, several cases at once or when using an IRC bouncer, like I do) it
completely messes up the data.
see #51
You can directly pass default values instead of checking for “Not set”,
then setting a default. Sadly isn’t a thing for Booleans though :-/
Default values can’t contain tokens either … T.T
Also fixes #38 command queue parameter passing because VoiceAttack
profiles aren’t properly diff-able and that’s what I was working on.
Yay!
– `passedInteger` ≠ `passedInt` T.T
– Passed string variables are evluated, `|{` and `|}` are swallowed
… again. Needs to passed as String literal without going through
a variable.
A lot of people put there systems in caps lock for some reason. That
causes EDDI to pronounce it letter by letter. Converting to lower case
first prevents that.
On the flip side that might mean that e.g. “HIP 2342” might be
mispronounced; this should happen way less often than the above problem
though.
You can now just pass a ratsignal to VA (without it being announced) by
calling `RatAttack.getInfoFromRatsignal`, or choose to also have it
announced in TTS by calling `RatAttack.announceCaseFromRatsignal`.
**Breaks interface compatibility!** `RatAttack.getInfoFromRatsignal`
behaviour has changed.
Handling of a ratsignal will be delayed by 5s if a signal is currently
being handled. That way all signals will find their way into VoiceAttack
even if they hit simultaneously / shortly after each other.
To reduce possible confusion though the “open case?” prompt has been
removed from `RatAttack.getInfoFromRatsignal`.
**Breaks interface compatibility!**
Now resides in `Sounds\scripts` for upcoming profile package compatibility.
Techincally the `Apps` directory would be more appropriate; as soon as
a profile package has that directory though you have to restart
VoiceAttack without plugin support to import the package.
