OK, I am working on the Zone editor again, and those little things
keep annoying me. Today it's the difficulty of highlighting one letter
in a string of text. And no quick fix is going to satisfy me, it's
about time to go all the way!
This was last discussed in "SVN: james/2552 Text box import/export now
has better...".
Basically, the plan is to use textual tags like the current ${H#}
ones. There was some debate about whether to translate to a more
compact format before passing a string to printstr, but I reject that
because parsing tags in printstr is easy, and actually much faster.
Another idea was to use a more compact binary format in certain file
formats, because most of our text fields have severly limited length.
We can easily decide to do that later.
Here's a list of proposed tags. I've split them up into groups, each
to be processed in a different place. Unfortunately many of the
obvious letters are taken. Alternative suggestions very welcome
(frankly mine suck) maybe we should go with a more verbose three
letter scheme. Also, maybe it would be a good idea to distinguish the
current tags from all the others because they require use of
expandstring, say, by switching to %{X#}? The bigger benefit would be
freeing up letters :)
*** Embedded text options (text slices (they don't currently work in
text slices), many in-game strings, expandstring command)
*** processed by embedtext
${C#} = Hero name at caterpillar slot #
${P#} = Hero name at party slot #
${H#} = Name of hero ID #
${V#} = Global Plotscript Variable ID #
${S#} = Insert String Variable with ID #
In addition, ${V#} will eventually be able to embed any typed global
variable, obsoleting ${S#} for strings. Most types would only have
printable representations suitable for debugging, though.
*** Text options
*** processed by printstr
${F#} - switch to font #
${K#} - set foreground kolour to #. -1 to return to default
${KB#} - set background colour.
If the font is paletted, these changes colours 1 and 2 respectively.
If the font is 1-bit (unpaletted) two layer, the background colour is
the colour of the shadow/edge.
${KP#} - use palette # (for paletted fonts). -1 to return to default
${KP#} - flicker each printed letter between the colours from palette
#, Angband-style! (for unpaletted fonts)
*** Text slice options
*** processed by DrawTextSlice, necessary state stored in the slice
data. Note some of this is currently handled by drawsay
${W#} - pause for # ticks
${WK} - wait for keypress, while displaying a little down arrow
animation that would probably be adjustable somewhere in General Game
Settings
${SC#} - slow text: wait # ticks between each non-whitespace letter (0
to resume normal text). Note: maybe we need to support fractional
ticks or milliseconds here
${SL#} - slow text: wait # ticks between each line (0 to resume normal text)
${ST#} - set tag # on, for use by scripts waiting for a certain point
to be reached - alternatively ${ON#}, ${OFF#}
${SR#} - scroll the text up # lines, hiding the top # lines (more
details on modes of scrolling below)
${F#} - play sound effect #
(all text options also available)
*** Textbox options
*** processed by drawsay or its replacement
${PR#} - change the portrait picture to #
${PA#} - play portrait animation #, when that is implemented. Actually
I'm not sure about this one, because I wasn't planning on assigning
numbers to animations, but always referring to them by name.
"${AN"grimace"}" is a bit much.
(all text slice options also available)
Of course, the unpredictable length of text full of tags needs to be
addressed. The textbox editor (actually, all of this applies to text
slices too, so the editor should be shared) should wrap text as you
enter it, and it should be re-wrapped when you view with/without tags
visible, and in-game. Now, the big problems are left and right
margins/indentation (for example, when avoiding a portrait). I don't
see any way around making the textbox editor automatically wrap text
around the portrait, like a WYSIWYG document editor. Unfortunately
users who hit the enter key are going to ruin everything. They might
have to be reeducated.
(Left) indentation is even trickier. It could be automatically
recognised when the user adds extra spaces, and respected.
We'd need some visual cues, just some simple vertical lines to show
that there are automatically placed margins.
Trickiest of all would be a non-portrait-related right margin. So I'm
not even going to try; it'd need some margin placement mode.
It could also help if the textbox editor supported running at higher
resolutions so that lines full of tags could be way over the edge of
the box.
Examples, supposing for a moment that these were newly created
textboxes in a new textbox editor which wraps automatically as you
type.
--------------------------------------
Mespar: Good day, friends. If you plan
on climbing this mountain, I must
warn you that many monsters live here
Bob: Ha! Monsters don't frighten us,
right James?
--------------------------------------
Could be stored as
"""Mespar: Good day, friends. If you plan ${I1}on climbing this
mountain, I must warn you that many monsters live here
Bob: Ha! Monsters don't frighten us, ${I1}right James?"""
Suggestions for better notation than ${I#} welcome as always. If we
picked that, I wouldn't show it in the textbox editor, even showing
all other tags.
On the other hand, if James hit enter without thinking, that last line
might look like this:
"""Bob: Ha! Monsters don't frighten us,
right James?"""
I propose that each textbox should have a "text wrap compatibility
mode" option, which prevents lines that become over-long due to
embedding of the current tags from wrapping. Or do you think that
making such a change would not break anything, so that's pointless?
There are several related textbox features that I'll note here for
completeness (or maybe just to annoy anyone who want to read this
whole thing):
-Default "slow text" option: no delays/# ticks per character/# ticks
per line (Global setting). For maximum compatibility, maybe we also
need a fourth option that doesn't wait between the first two lines.
Someone might be depending on that?
-"Don't show choicebox until text finishes displaying" (per textbox)
-Trim text to size of textbox, scrolling as need (global and
overrideable per-box)
-Text scrolling: jump instantly, or scroll smoothly at rate of # ticks
per line (global setting)
-Text sound: replace the current sound effect option with one which
allows per-box, per-line, or per-character (looping while characters
are printing) (global and overrideable per-box)
Oh, and this reminds me of another idea: an in-game textbox debug
mode. Fixing/reporting typos is currently somewhat tedious: you have
to note down enough context to search for. Debug mode would show you
the ID number of the current box, and preferably let you edit the box,
and then export as text.
OK, that's all. Now, back to coding.
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
