Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ Programming
➜ General
➜ Excluding color tokens from buffer limit in SMAUG
Excluding color tokens from buffer limit in SMAUG
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| Xavious
(41 posts) Bio
|
Date
| Sun 21 Jun 2015 11:30 PM (UTC) Amended on Mon 22 Jun 2015 04:08 AM (UTC) by Nick Gammon
|
Message
| I know I'm like 20 years late to this party, but here I am none the less.
I've recently started dabbling with SWR FUSS through Cygwin. Nick's guides were immensely helpful for getting it all running.
Now I've begun the journey to learn how this archaic code base works. I have a reasonable amount of programming experience, but I've been pampered by loosely typed scripting languages and never dealt with this level of complexity. I always intended to get experience coding in C, but it just never happened.
What I'm trying to accomplish is prevent the buffer from counting color/background/formatting tokens towards the buffer limit. Currently if you write something with &W, &B, or any other token character, it uses them in the calculation. This can stunt the available size of output and cause lines to be misplaced if one line uses a significant amount of color. These tokens are not actually displayed to the screen either.
I've been exploring code files and I believe I am on the right track. I have been digging into "editor.c" and "comm.c" for awhile now. However, I'm having trouble isolating where the buffer operation is occurring.
I think it is somewhere around this function:
for( i = 0, k = 0; d->inbuf[i] != '\n' && d->inbuf[i] != '\r'; i++ )
{
if( k >= 254 )
{
write_to_descriptor( d, "Line too long.\n\r", 0 );
/*
* skip the rest of the line
*/
d->inbuf[i] = '\n';
d->inbuf[i + 1] = '\0';
break;
}
I have been toying with some ideas for how to approach this programming wise.
This is my initial idea in what I think is mostly C syntax, but mgith be off:
for(i = 0; i < strlen(string);i++)
{
if(string[i\] == "&")
{
if!(string[i + 1] == "W" || string[i + 1] == "B")
{
//Letter does not match color tokens, add to buffer
//This if would have a bunch of ORs for each letter, but is condensed for example
cur_buffer_size++;
}
else{
//Letter matches a token, increment to skip the next letter
i++;
}
}
}
This is my initial brain storm. I'm really inexperienced with C and tampering with SMAUG. I appreciate any advice, wisdom, or insights you wonderful people in the community can offer.
[EDIT] Forum codes fixed up. | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #1 on Mon 22 Jun 2015 04:10 AM (UTC) |
Message
|
Quote:
What I'm trying to accomplish is prevent the buffer from counting color/background/formatting tokens towards the buffer limit.
I'm not sure what you mean by this. If you can only put x characters into the buffer, surely you want the limit of x and not some other limit?
Are you referring to the size of a "tell" or something like that? |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Xavious
(41 posts) Bio
|
Date
| Reply #2 on Mon 22 Jun 2015 12:23 PM (UTC) |
Message
| When you enter a buffer in SWR, like when you are writing a character description, there are checks in place to limit line length and buffer length. I'd like to put in a check to prevent color tokens from being included in this calculation.
For instance I might set my description to something with a lot of color tokens in it like this:
&WA &Rred &WTwi'lek is standing here with a &Gm&gu&Rl&rt&zi&Y-&Oc&po&wl&ro&Rr&ge&Gd &Wshirt
When you look at my character what you actually see is:
A red Twi'lek is standing here with a multi-colored shirt
I'm not sure where it is in the code precisely, but these color tokens are included to calculate if the description exceeds the maximum size and also can cause premature carriage returns.
Is it a bad idea to try to modify this behavior? There could be some repercussions to trying to make this change that I have not considered. | Top |
|
Posted by
| Nick Gammon
Australia (23,133 posts) Bio
Forum Administrator |
Date
| Reply #3 on Mon 22 Jun 2015 08:24 PM (UTC) Amended on Mon 22 Jun 2015 08:25 PM (UTC) by Nick Gammon
|
Message
| I would want to know why that limit is there. For example, if your character description is stored in a struct as:
Then making sure that there are no more than 255 characters, colour codes or not, is eminently sensible. However if it is just to stop people have stupidly long descriptions, then you could do what you suggest. (Just make sure that wherever the results are stored can hold the extra length).
Also I would check places the descriptions are used, for example a WHO list, that might assume that they only need to allow for a small buffer for the description, for example, prior to sorting the names in the list. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Xavious
(41 posts) Bio
|
Date
| Reply #4 on Mon 22 Jun 2015 10:24 PM (UTC) |
Message
| Well that certainly makes sense. I appreciate the response Nick.
Perhaps I am trying to learn how to run before I have even learned how to crawl. I think I have a lot more work to do looking over code files and trying to figure out how things work before I can tackle this problem intelligently.
I don't even really know how this buffer is processed and saved in the character's pfile yet. I'll keep plugging along and hope I can garner some kind of grasp on the inner workings eventually. | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
15,539 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top