I'm just spewing ideas out of my head right now, but here goes nothing:
Would it just be easier and simpler to create a new kind of textbox
with it's own set of data? And it would just sit along the old data in
the RPG file?
New games would hide the "Edit Textboxes" option in CUSTOM and only
show "Edit Game Text". Transition games would show both "Edit
Textboxes" and "Edit Game Text". Or perhaps a new top-level "Edit Game
Text" with "Edit Old Textboxes", "Edit Textboxes", "Edit Text
Strings", "Game Long Name", "Game About Line", etc. Maybe it's just me
but that General Game Data menu is a bit cluttered =)
And/or in the individual textbox settings, you choose either "Basic"
(old) or "Enhanced". Game/Custom would then load and save the
appropriate bits while preserving sanity and backwards compatibility.
"Basic" would show the old menu, "Enhanced" would show new options
like "Box Resizes to Text", etc etc. This would also allow you to add
new types of textboxes down the line, such as a "picture textbox" or
what have you.
On 2/15/07, Bob the Hamster <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 15, 2007 at 06:11:01PM -0500, Mike Caron 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.
>
> Backcompat for old text boxes will not be that easy. We can't assume
> that existing text-boxes will look the same when treated as a long
> wrapping string.
>
> ---
> Bob the Hamster
> _______________________________________________
> 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
