Word Wrap (with colour)

Posted by Maior on Wed 14 Jan 2004 03:56 PM — 4 posts, 14,533 views.

United Kingdom #0
Ok, this is actually technically a SMAUGWiz question, but, from everything ive found so far, apart from "linguistic subtleties", SW and SMAUG are essentially the same, so here goes.

In sending blocks of text to the descriptor, ie mostly in the case of descs, mob/room/obj, or note text, it autowraps at about 80 characters. This is fine on its own, however, the 80 characters INCLUDES "colour strings" ie "&[", "&x" and the like, that wont actually be seen as such by the end user, but stripped and used to control the colour of words. By including such things in the "wrap limit", in cases where colour is used, the wrapping APPEARS to be incorrect, because some lines seem much shorter and the like, as and where colour is used. I searched through the code of the sendtext, sendcolor and similar functions, and the descriptor functions that they call, but found nothing pertaining to where or how they did the wrapping, in order to somehow modify to exclude colour strings from the count. Thus, if anyone could point me towards where to look or what to change, or if one were to exist (though i -think- i made a fairly thorough search), i would be most grateful.

Thanks in advance
Canada #1
I beleive that it is infact not the output function that does the wrapping, but the OLC editor code. I know that it wraps to 80 characters. I assume that your using OLC building. If so, then you can do a simple test if this is the case by manually editing one of your areas, and putting a room description that is longer than 80 character, because as far as I know, no where else confines the output to 80. If it is in fact the edit, what you want to do is look at your particular edit code in build.c, looking for either 79 or 80( I think my old version mught have used 75...). If it using strlen, then you can use the following in its place, this will skip color characters.
int strlen_color (char *argument)
{
    char  *str;
    unsigned int    i, length;

    str = argument;
    if (argument == NULL)
        return 0;

    for (length=i=0; i < strlen (argument); ++i)
    {
        if ((str [i] != '&') && (str [i] != '^'))
            ++length;
        if ((str [i] == '&') || (str [i] == '^'))
          {
            if ((str[i] == '&') && (str[i+1] == '&'))
                length=2+length;
            else if ((str[i] == '^') && (str[i+1] == '^'))
                length=2+length;
            else
                --length;
          }
    }
    return length;
}


I can think of several stock editor replacements that you may also want to look at, should this method prove unsuccessful.
Amended on Wed 14 Jan 2004 04:22 PM by Greven
United Kingdom #2
Actually, something i sort of overlooked when i wrote the original post is that my dynamic description code that im working on would also require something similar, being based around the idea of having flags, similar to the way colour flags work, along the lines of:

The trees stand tall above you. [SEASON=AUTUMN][Their bare branches reach into the grey sky as if stretching to escape this place.] A track leads off to the west

Building isnt really my thing, so forgive the cliches ;) Then, if season = autumn, when the desc is shown, the text in brackets is displayed, and if season isnt, well, the text isnt. The only way that really came to mind to display this without the aforementioned problem of screwy wrapping was a similar something that would fix the colour problem. However, seeing how the desc code is far from finished, the function you provided is of great use, thankyou
Canada #3
Glad that helped, you could look into the way that MXP for for how to parse something like that out.