On Sun, Aug 29, 2010 at 05:48:57PM +1200, Ralph Versteegen wrote:
> 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 :)
I like this plan. I think the short tags are not so bad. Consider this:
We could have a key-combo you could press which would pop up a list of
tags to insert with long name captions, so it wouldn't have to be
confusing.
Secondly, when editing a string, if your cursor is on a special tag, we
could display the long description of it in the bottom right corner of
the screen, or something like that.
Also, we should find somethign to call these other than "tags" :)
(curse me and my naming scheme follies!)
> 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.
That is cool.
> *** 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)
Very nice.
> *** 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)
This stuff is great.
I prefer ${ON#} and ${OFF#} for tags. (but it doesn't really matter if
we have that text-command-insert popup)
> *** 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)
Maybe animations should get both a name and a number. The name can be
used everywhere that it makes sense to use a name, and the number can be
used in whatever small number of places a name isn't practical (like
here)
> 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.
That is doable. People can learn.
> (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.
Pretend for a moment that we don't have to care about back-compat for
everybodies old text boxes. We would probably want to emulate what most
wordprocessors do. There could be a way to specify:
* left margin for the first line
* left margin for wrapped lines
* right margin
Seems to me that it would be okay to set this information on a
paragraph-by-paragraph basis (with newly added paragraphs automatically
copying from the paragraph above them)
> 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.
I am really wary of changing resolutions anywhere other than at startup.
I know it works fine when windowed, but havoc will be wrecked in
fullscreen on many systems, even if both resolutions are well supported.
On my laptop, all resolution changes are very slow, and they always
mangle the positions of most of my open windows on all virtual desktops
:(
Although I guess if a higher-resolution text editor is optional, then I
am cool with that. Or maybe if it just detects fullscreen and doesn't
attempt to switch itself in that case.
> 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.
Maybe rather than embedding the indent mark in the text, we could prefix
the line with
${I#} for indenting the first line
${IL#} for indenting the left wrapped lines
${IR#} for indenting the right wrapped lines.
> 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?"""
If James hits enter without thinking, that is his own dang fault, not
ours ;)
Of course, We can make line breaks visually indicated when editing, so
that sort of mistake will be easy to spot.
> 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?
Yeah, we might not need to bother.
> 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)
Thise all sound great.
> 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.
Thank you for sharing these ideas :)
---
James
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
