30 Jan, 2009, Omega wrote in the 21st comment:
Votes: 0
Changing to (char) 162 worked beautifully. Its odd though, because in all the editors, it displays as 157. � which = very annoying.

Thanks for all the help!
02 Feb, 2009, Guest wrote in the 22nd comment:
Votes: 0
If someone wants to come up with a better "End of line" character than alt-157 I'm all ears. The tilde was used before that but using the tilde for an end of line marker makes it impossible to include it in a string.

And changing it to c++ won't solve anything because these are multi-line strings being read in that alt-157 is being used to mark. So the c++ file streams that use \n to mark end of line won't cut it.
02 Feb, 2009, David Haley wrote in the 23rd comment:
Votes: 0
What's wrong with using the null character?
02 Feb, 2009, Guest wrote in the 24th comment:
Votes: 0
Null characters don't tend to be stored in files the last time I checked. But if they are then I suppose that would work :)
02 Feb, 2009, David Haley wrote in the 25th comment:
Votes: 0
Well, you can write whatever you want to files. So null characters would work fine.

Or, pick any character you please, for that matter, and have some kind of escaping schema. Say, why not use backslashes as escapes… :wink: So, you could use $ to terminate lines or strings or whatever, and if you ever want a $ to literally appear, stick a backslash in front; if you want a backslash, use two in a row… etc.
03 Feb, 2009, quixadhal wrote in the 26th comment:
Votes: 0
If it's your own storage format (and not meant to be compatible with some external editor, etc), why use a delimiter character at all? You could simply use a format that makes it obvious, such as XML-style tags to contain the description (or whatever multi-line unit you're talking about). Or, you could write the number of lines with the key and just read that many lines from the file.

Quote
LongDesc 4
This is a long description.
It has a few lines of stupid text.
With hard returns.
To annoy you.
03 Feb, 2009, David Haley wrote in the 27th comment:
Votes: 0
XML-style tags make sense when you have units of content embedded in other units of content, e.g. for inventory or containers. Otherwise, it's basically the same thing as a line ending character – both require escaping of the special character, in any case.

Not sure if I like the number of lines idea though, although I don't have a good reason for that at the moment. :wink:
04 Feb, 2009, Kayle wrote in the 28th comment:
Votes: 0
Back to the original topic…

Marlin and I figured out what it was, and how to replicate it, and basically lcSocName isn't being cleared out, and so you have residual text from the previous social that was looked up. I came up with this attempt at fixing it. It works for MW, but I dunno about anywhere else.

Imc.c: imc_find_social
Find:
// lower-case the social name before asking the MUD
static char lcSocName[LGST];
for (int i = 0; i < LGST && sname[i] != '\0'; i++) {
lcSocName[i] = tolower(sname[i]);
}


And change it to:
// lower-case the social name before asking the MUD
static char lcSocName[LGST];
for (int i = 0; i < LGST; i++) {
if( sname[i] != '\0' )
lcSocName[i] = tolower(sname[i]);
else
lcSocName[i] = '\0';
}


And that will prevent the socials from seeming to disappear.

[Edit:] I'm sure there's a better way of handling this. But this way worked. >.>
04 Feb, 2009, Guest wrote in the 29th comment:
Votes: 0
Call me crazy, but can't it just be this?

for( i = 0; i < LGST && sname[i] != '\0'; i++ )
lcSocName[i] = tolower( sname[i] );
lcSocName[i] = '\0';
04 Feb, 2009, kiasyn wrote in the 30th comment:
Votes: 0
okay, you're crazy.
04 Feb, 2009, Guest wrote in the 31st comment:
Votes: 0
I knew that, but is what I posted right? :)
04 Feb, 2009, Keberus wrote in the 32nd comment:
Votes: 0
Samson said:
Call me crazy, but can't it just be this?

for( i = 0; i < LGST && sname[i] != '\0'; i++ )
lcSocName[i] = tolower( sname[i] );
lcSocName[i] = '\0';


Wouldn't you still need lcSocName, for the next few lines at least which are:
if( ( social = find_social( lcSocName, FALSE ) ) == NULL )
{
imc_printf( ch, "~YSocial ~W%s~Y does not exist on this mud.\r\n", sname );
return socname;
}


What about:
static char lcSocName[LGST];
lcSocName[0] = '\0';

for( int i = 0; i < LGST && sname[i] != '\0'; i++ )
{
lcSocName[i] = tolower( sname[i] );
}


That's usually how I handle my static bufs anyways.
04 Feb, 2009, Guest wrote in the 33rd comment:
Votes: 0
Yes, lcSocName is still used later, but
lcSocName[i] = '\0'
doesn't NULL the string. It only adds a NULL at the position i is currently at. This should eliminate the issue that Kayle was talking about.

I don't think setting the first character to NULL would fix it either. If the string isn't being dropped by going out of scope, changing the first char to a NULL still leaves the ones following it intact. Unless I'm not understanding something here.
04 Feb, 2009, Keberus wrote in the 34th comment:
Votes: 0
My bad, I read it wrong, I was thinking the problem was that the string needed to be NULLed before usage.
04 Feb, 2009, KaVir wrote in the 35th comment:
Votes: 0
Samson said:
Yes, lcSocName is still used later, but
lcSocName[i] = '\0'
doesn't NULL the string. It only adds a NULL at the position i is currently at.


Technically, it adds a NUL (null character), not a NULL (null pointer).
20.0/35