On 31 August 2010 03:45, James Paige <[email protected]> wrote:
> 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.
OK, I guess the shorter, the easier to type.
> 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.
Good ideas - and I really think we should be displaying short
help/explanation strings at the bottom of the screen in many menus.
I'm planning to start doing that. But 40-character-wide screens is
pretty frustrating. I propose that we add a new default 6x6 or 6x8
font for use in places where space limits are tight. Maybe it should
be variable-width. For example, in NPC debug mode, where NPC reference
numbers are 24 pixels wide, where I had to manually draw each numeral
7 pixels apart to make them fit. There, I went off on another feature
proposal tangent. But if we had a new font editor, we could get
someone on the forums to create our new font.
> Also, we should find somethign to call these other than "tags" :)
> (curse me and my naming scheme follies!)
Er... text...marks? I've got nothing.
>> 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)
(In case I haven't explained it: the idea was that animation names can
be independent of the specific sprite set: multiple portraits could
have a "grimace" animation defined; it's like duck typing!)
OK, sounds practical. But I wonder whether the ID number should be an
index into the big global table of animation names (shared by all
spritesets of any sort), or refer to the n-th animation currently
defined for this spriteset. I'd prefer the first, since it might make
sense to sort animations, say alphabetically.
>> 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.
Very well, further brainstorming!
> 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)
I don't see a need to have a left margin for the first line, instead
just have the left margin not apply to the first line so you can type
however many spaces you want.
I suggest:
-When you start typing a new line, the right margin displays, as a
vertical line 10*number of lines pixels long (and displays as long as
the cursor is in that paragraph)
-When you hit the end of the line and wrap, the left margin displays,
starting at the 2nd line of the paragraph and going downwards
-Left and right margins are set automatically if there is a portrait
in the way, otherwise they are copied from the last paragraph
-Add keys for moving each margin left and right, like alt+1/2/3/4
-If there's a portrait overlapping the beginning of the line, maybe we
could automatically insert some spaces when you start typing, and you
can delete them if you want to.
>> 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.
I've never planned to have variable-resolution menus automatically
resize the window/screen when you entered them (unless we add some
setting to do so when windowed, which sounds like a good idea (PS: we
need config files!!)), but that they would indicate that they could be
resized in the normal way by showing an icon (temporarily?) in the
bottom corner. (Actually, I can't remember whether fbgfx support
resizing windows like that, but the other backends do.) To resize
while in fullscreen mode, I guess there could be some hotkey, or you'd
have to switch to windowed mode temporarily.
>> 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.
That sounds much better!
But what should do we do when exporting textboxes? Maybe show a guide
on the previous line? If we throw away indentation for the first line,
that can be fairly simple.
Taking the sample example box, and pretending that there is a portrait
obscuring the five right columns of the first paragraph (fixed width
font please), so we set a right margin:
--------------------------------------
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?
--------------------------------------
That could be exported as:
--------------------------------------
Textbox whatever
...other header stuff
--------------------------------------
*################################*****
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?
--------------------------------------
and stored internally as:
"""${IL1}${IR5}Mespar: Good day, friends. If you plan on climbing this
mountain, I must warn you that many monsters live here
${IL1}Bob: Ha! Monsters don't frighten us, right James?"""
But we won't be able to handle changing the margins in the middle of a
paragraph, for example past the end of a portrait. Maybe we've done
enough?
>> 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.
Definitely.
>> 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 :)
Just trying to recruit someone else to implement them ;)
> ---
> James
> _______________________________________________
> Ohrrpgce mailing list
> [email protected]
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
