--- Mike Caron <[EMAIL PROTECTED]> wrote:
> On 2/15/07, S'orlok Reaves <[EMAIL PROTECTED]>
> wrote:
> >
> > > > Technically, this makes these features
> available
> > > to plotscripting strings, but to use them, you'd
> > > need to embed those characters directly into the
> > > plotscript file, which while doable, isn't very
> > > convenient. Or, you can use append ascii....
> More
> > > thought on this is required.
> >
> > You could always invent your own markup. Like,
> "\n"
> > for newline, then "\c5{some string} some other
> string"
> > to make "some string" be the fifth color, and
> "some
> > other string" be the default.
>
> I have every intention to support codes like this,
> but not until I
> rewrite the textbox code :)
>
> The reason is this:
>
> Textboxes are, essentially, 8 strings displayed on
> top of eachother.
> Each string is limited to 40 characters by the very
> format they're
> stored in, since long before any type of code was
> possible. This means
> that any code embedded in the textbox takes up
> display character
> space. In other words, lets say you have a textbox
> in which Bob talks.
> Bob is, of course, customizable, so you use a code
> to sub in his name:
>
> "${H_}: Hello there, my friends and such!"
>
> That is exactly 40 characters. If the default name
> is "Bob", then this
> means that it will only take up 38 characters,
> leaving two wasted!
> Conversely, if the name is "Pedrovich" (shh), the
> string balloons to a
> massive 44 characters, and part of it is cut off.
>
> The solution is word wrapping, but this is not
> possible due to the
> "seprate strings" analogy. If you were to combine it
> into a single
> string (gluing it together with \n), then you get a
> different problem:
>
> "Pedrovich: Hello there, my friends and\n
> such!\n
> This is a fine day, is it not?"
>
> Obviously, if that hard line break after "such" was
> removed, this
> would work properly. But, we can't assume it isn't a
> hard break,
> because there are situations where it is (I assume
> you can think of
> one yourself).
>
> What to do? Well, first off, kill the 8-strings
> paradigm, and make a
> textbox one big string. Then, change the editor so
> that the user can
> just type, and it word wraps for them, and inserts
> hard line breaks
> when they hit enter, instead of after every physical
> line. Then,
> everything works nicely.
>
> I'm considering various ways to do this, but I doubt
> I'll get anything
> substantial in time for U...
> --
> Mike Caron
> Final Fantasy Q
> http://finalfantasyq.com
> _______________________________________________
> ohrrpgce mailing list
> [email protected]
>
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
Ah, yes, I ran into that same problem when preparing
.SAY textboxes for display on a phone (which has a
tall, narrow screen.)
My solution was to substitute all text strings, and
then add in newlines at display-time. So, your example
becomes:
"Bob: Hello there, my friends and such!\nThis is a
fine day, is it not?"
and then:
"Pedrovich: Hello there, my friends and\n such!\nThis
is a fine day, is it not?"
I'm sure you'll find your own method, suitable for the
OHR, but here's my method, just for discussions' sake.
(-> SR
Basically, the algorithm goes:
Add each character, tracking the length of that line
so far.
When you find a space:
If the length is > the allowed length, search
backwards until you find a space. Create a newline
here.
If you don't find a space, hyphenate. Create a
newline.
____________________________________________________________________________________
Get your own web address.
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
_______________________________________________
ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
