27 Dec, 2008, David Haley wrote in the 21st comment:
Votes: 0
Err… ok. There's a difference between characters printed to screen, and characters put into a buffer. You are writing those characters – INCLUDING the color codes – into the openb buffer. It doesn't matter at all if there is a function anywhere else that does anything whatsoever to any string. You are writing more characters than the buffer contains, and that's pretty much the end of the story. One suggestion I might make would be to read up a bit on how strings work in C: there's a big difference between buffer sizes, visible characters, etc. If anything, it seems like you need to read up on how null characters terminate strings and all that.

The short story is that a string in C is just a sequence of characters terminated by a null character. That sequence has to live in memory somewhere: some kind of buffer is used to store the string. Obviously, you need to have enough buffer space to store each character of the string. Writing too many characters is what's known as buffer overflow, and that causes all kinds of bad things to happen.
27 Dec, 2008, David Haley wrote in the 22nd comment:
Votes: 0
Igabod said:
[p.s] and my "something like that" was cause I couldn't remember if it was -=+ or -+= or +=- the order doesn't matter at all, just the number of characters.

Well, yes, except that you didn't actually show what you were writing into the buffer, exactly. You removed certain characters, even though, as Kayle said, everything matters.
27 Dec, 2008, Kayle wrote in the 23rd comment:
Votes: 0
DavidHaley said:
Igabod said:
[p.s] and my "something like that" was cause I couldn't remember if it was -=+ or -+= or +=- the order doesn't matter at all, just the number of characters.

Well, yes, except that you didn't actually show what you were writing into the buffer, exactly. You removed certain characters, even though, as Kayle said, everything matters.


It's like it's magic or something.
27 Dec, 2008, Igabod wrote in the 24th comment:
Votes: 0
First of all, I am listening here, I'm rebutting with what I believe to be true and when and if I'm proven wrong I accept that and learn from it. I do not talk big, I don't know where you're getting that from but whatever, that's not important.

I've never implied that you guys don't know what you're talking about or that I'm better than any of you in any way. I freely admit that I'm not very skilled at this and am still learning. I don't know why you're getting upset with me for trying to explain why I'm doing things the way I am. I'm just trying to give all the information I have about the subject at hand.

You've informed me now that what I thought was wrong and I accept that as true in most cases. However I still think there is something in my code that handles this problem because everywhere I've used color in buffers would have alignment problems if it wasn't, yet I have no problems like that anywhere. I'm afraid that if I do make those 5's into 16's though that it will create problems cause the openb and closeb are close to the end of the screen already and if I were to just add 9 more spaces kingdoms wouldn't fit on the who screen.

If someone can tell me why this is a problem even though it's not visible I'll gladly learn from it and fix the problems. Please don't mistake me as an arrogant ass who refuses to admit when he's wrong or learn from his mistakes. I think I've made it quite clear since I've been here that I respect all of you who have helped me and am willing to learn.
27 Dec, 2008, David Haley wrote in the 25th comment:
Votes: 0
Make a very simple hello world program, have a buffer of size 5, write 10 "a" characters into it, run the program through valgrind, watch it complain. And hey, it might even crash if the buffer overflows into the wrong thing.

The size of a buffer has nothing to do with the size of the string. As I said, a string is a sequence of characters terminated by a zero. A buffer could be of size 1 billion, and a string in that buffer might still only be 2 characters long.
27 Dec, 2008, Igabod wrote in the 26th comment:
Votes: 0
DavidHaley said:
Err… ok. There's a difference between characters printed to screen, and characters put into a buffer. You are writing those characters – INCLUDING the color codes – into the openb buffer. It doesn't matter at all if there is a function anywhere else that does anything whatsoever to any string. You are writing more characters than the buffer contains, and that's pretty much the end of the story. One suggestion I might make would be to read up a bit on how strings work in C: there's a big difference between buffer sizes, visible characters, etc. If anything, it seems like you need to read up on how null characters terminate strings and all that.

The short story is that a string in C is just a sequence of characters terminated by a null character. That sequence has to live in memory somewhere: some kind of buffer is used to store the string. Obviously, you need to have enough buffer space to store each character of the string. Writing too many characters is what's known as buffer overflow, and that causes all kinds of bad things to happen.


Ok, so you're saying that it's going past the buffer size allotment already so me changing the buffer size to say 10 won't make any visible difference on the who screen?

As to me not typing everything there, that's cause I thought those characters were being stripped and were therefore unimportant to the equation. I've been proven wrong though and won't do that in the future.
27 Dec, 2008, Kayle wrote in the 27th comment:
Votes: 0
Just because something magically works, doesn't mean it's right. 9 doesn't fit in 5. Giving them a size of 15 isn't going to change the way the screen displays. They're still only going to display what they contain. So unless you do something idiotic like change it from " {R-=+{W" to " {R-=+{W " It's not going to change the display any. The number in the brackets has nothing to do with how many spaces your game will display.
27 Dec, 2008, Igabod wrote in the 28th comment:
Votes: 0
Kayle said:
Just because something magically works, doesn't mean it's right. 9 doesn't fit in 5. Giving them a size of 15 isn't going to change the way the screen displays. They're still only going to display what they contain. So unless you do something idiotic like change it from " {R-=+{W" to " {R-=+{W " It's not going to change the display any. The number in the brackets has nothing to do with how many spaces your game will display.


Ok I wasn't aware of that. I know this makes me look kinda stupid to those of you who know different but I'm willing to look stupid in the pursuit of learning. Thank you for educating me. I'll change the buffer size to 10 (not 16 like sharmair said since it doesn't really need 16).
27 Dec, 2008, David Haley wrote in the 29th comment:
Votes: 0
else if (IS_CLASS(wch,CLASS_MONK))
{
strcpy(openb,"{c(O0o.{C");
strcpy(closeb,"{c.o0O){x ");
}

Please count the number of characters here, and then decide how large your buffer should be… or do the other thing that Sharmair suggested and be rid of these temporary buffers entirely.
27 Dec, 2008, Kayle wrote in the 30th comment:
Votes: 0
Igabod said:
Ok I wasn't aware of that. I know this makes me look kinda stupid to those of you who know different but I'm willing to look stupid in the pursuit of learning. Thank you for educating me. I'll change the buffer size to 10 (not 16 like sharmair said since it doesn't really need 16).


No, they really do need to be 16. Like David pointed out. (Sorry David, I didn't want to have magickz happen again. :P)
27 Dec, 2008, Tyche wrote in the 31st comment:
Votes: 0
27 Dec, 2008, Igabod wrote in the 32nd comment:
Votes: 0
I count 9 in the openb and 11 in the closeb (i think, kinda hard to count spaces) so I was off by one. I'll just change it to 16 to be sure though, in case I decide to add new classes in the future.
27 Dec, 2008, David Haley wrote in the 33rd comment:
Votes: 0
Remember what we said about null characters… and also, remember the second thing that Sharmair suggested about not using those buffers at all…
27 Dec, 2008, Igabod wrote in the 34th comment:
Votes: 0
yeah shar did give a good idea and I'll eventually do it that way, probably will do it that way tomorrow or the next day.
27 Dec, 2008, Sharmair wrote in the 35th comment:
Votes: 0
Igabod said:
yeah shar did give a good idea and I'll eventually do it that way, probably will do it that way tomorrow or the next day.

I gave it some more thought and came up with an even more efficient way to do it. As the strings you are
copying into kav are const and not changed while in kav, you can just do a simple assign to a pointer
instead of copying the strings (that are already in the code as literals - that is, they have memory assigned
to them in the code itself) into the buffer (that is MAX_STRING_LENGTH - not sure what low4 used, but
4096 is common in a lot of code bases and in any event is probably a whole lot longer then used here).
You would still replace everything I said in the last idea, and also the define of kav on line 17 (remove
old I mean) and add:
const char* kav = "{D….None….{x";

at about line 104.
And instead of the strcpy block I was talking about, use:
if(IS_CLASS(wch, CLASS_VAMPIRE))
kav = "{r<<-Vampire->>{x";
else if(IS_CLASS(wch, CLASS_WEREWOLF))
kav = "{y-+(Werewolf)+-{x";
else if(IS_CLASS(wch, CLASS_DEMON))
kav = " {R[-]Demon[-]{x";
else if(IS_CLASS(wch, CLASS_NINJA))
kav = " {m*+*Ninja*+*{x";
else if(IS_CLASS(wch, CLASS_DROW))
kav = "{b.o0 Drow 0o.{x";
else if(IS_CLASS(wch, CLASS_MONK))
kav = "{c(O0o.{CMonk{c.o0O){x ";
else if(IS_CLASS(wch, CLASS_HIGHLANDER))
kav = "{C-=Highlander=-{x";
else if(IS_CLASS(wch, CLASS_MOOGLE))
kav = " {Y-=+{WMoogle{Y+=-{x ";
20.0/35