==Informationless introduction==

Currently, the animation system uses strings for animation and variant
names, and I'm thinking of using names for other things as well:  handle
points ("hand", "handle", "stand") and sequence points ("attack", "hit").
I'm not 100% decided, but I think it would probably be best to use strings
in scripts as well rather than ID numbers (like slice lookup codes) since
that requires name editors, new lumps, enums for special names, id->string
tables for those enums, plotscr.hsd constants, hsi export code, and maybe
another script like misc/sl_lookup.py to keep it all in sync. Which is a
lot more complexity than just using strings!

So you would write something like
  play animation(sl, $0="walk")

Also, I was looking through my code for Carcere Vicis, which uses a
preprocessor to spit out HamsterSpeak code, which let me write stuff like:
   say($"as you drink the", item, $"your whole body starts to tingle")
(This expands to $NS="as you drink the", etc, where NS is a 'new string'
Just making it easy to write string constants solves one of the biggest
problem with plotstrings.


I think we should add special syntax which is like $...="..." but doesn't
require manually specifying a string ID:
-it returns the ID number for a special immutable string, which can be
passed to other string commands
-the engine assigns a string ID >= 100, so that it doesn't clash with
manually allocated string IDs. It searches existing strings >= 100 for one
with the desired value, and otherwise increases the number of strings,
creating a new one. Strings are not garbage collected. No GC is not a
problem, because you can't create more strings than exist in your script
source code
-the string can't be modified, as that would break other uses of the same
ID. Passing to any script command doing so is an error.
-strings >= 100 are saved in saves, just like other strings
-the actual ID assigned to a particular string constant varies between
different plays, but you will never hardcode an ID >= 100 into your scripts
-maybe it shouldn't be displayable with showstringat, etc. This isn't
necessary, but the intention is to use these as literals, not full-blown
plotstrings. Maybe we should just allow all that, though?

Call these plotstring literals. This is a temporary solution until we have
real string literals; they will become obsolete.
Therefore we can't just use "..." syntax; they're very different.

As I mentioned before, I want to have a way to expand embed codes in
strings immediately, and allow you to use names of local variables too. The
syntax I'm leaning towards is to prefix the string with $, like
  msg := $"${hp}"
It's not the easiest to type, but the relationship to $-prefixed embed
codes seems good. But there are many other options, like python 3's
f"${hp}". Any other suggestions?

If we're using $"..." for that, then it can't be used for plotstring

We could use something like $="..." or $?"..." or $$"..." to indicate the
similarity to $...="...". But the close similarity of these to $"..." seems
So maybe something different, like ?"...".

Also, we should add $== as a shorthand for stringcompare. stringcompare is
horribly verbose.
Also, if hspeak sees you write something like
  if(str == $?="")
then it can throw an error and tell you to use $== instead. Note that
comparing two plotstring literals with == will work, but comparing a
plotscripting literal to a mutable plotstring won't!
Ohrrpgce mailing list

Reply via email to