Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Users Online
CommonCrawl, Yandex, Yahoo!

Members: 0
Guests: 6
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
612
Jacki72H
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » General Discussions » Edit_buffer combining lines?
Forum Rules | Mark all | Recent Posts

Edit_buffer combining lines?
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2 next >>
Post is unread #1 May 25, 2006, 6:33 am
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

I've been playing around with edit_buffer to not consider color codes when it checks against length. I worked most of the kinks out (Including a problem that was caused by copy_buffer when you saved), but now, I'm having a problem. For some reason, if your string has enough color codes to put it out of regular bounds (Longer than 80 chars), the string won't return, and the next string after will get added onto it. (This cycle will repeat until the input string is less than 80 chars, with or without codes)

The relevant code here MUST be this, I would think:

   if( edit->size + strlen( argument ) + 1 >= MAX_STRING_LENGTH - 1 )
      send_to_char( "Your buffer is full.\r\n", ch );
   else
   {
      if( strlen_color( argument ) > 79 )
      {
         strncpy( buf, argument, ( strlen_codes( argument ) + 79 ) );
         buf[strlen_codes( argument ) + 79] = '\0';
         send_to_char( "(Long line trimmed)\n\r> ", ch );
      }
      else
         strcpy( buf, argument );
      strcpy( edit->line[edit->on_line++], buf );
      if( edit->on_line > edit->numlines )
         edit->numlines++;
      if( edit->numlines > max_buf_lines )
      {
         edit->numlines = max_buf_lines;
         send_to_char( "Buffer full.\n\r", ch );
         save = TRUE;
      }
   }


"strlen_color" being my own variant which makes sure to count only VALID color codes. The one that comes with the color snippet is a bit on the trusting side. :smile:

Anyway, I really don't see where this is happening. It really doesn't make much sense that it would. Does anybody see something I don't?
       
Post is unread #2 May 25, 2006, 6:44 am   Last edited May 25, 2006, 6:45 am by Halcyon
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Oh, also, since I forgot. "strlen_codes" does about the exact opposite of what strlen_color does: It counts only colors codes in the string. The math you see there in regards to shortening the string is to ensure it isn't shortened unneccessarily. It adds the count of color codes to 79 before it cuts the line off, so a line 100 chars long that's only 82 after color codes are taken out isn't shortened to isn't going to get 16 chars munched that should still be there. (I don't think I did the math right on the last bit, but lol, you get the idea, I hope.)
       
Post is unread #3 May 31, 2006, 1:19 pm
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

<_< No one? Really?
       
Post is unread #4 May 31, 2006, 7:10 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

I've already got a stlen snippet installed that autowraps text by stripping color codes and counting characters. *shrug*
       
Post is unread #5 Jun 4, 2006, 8:45 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Well I'm not terribly good with C strings and am as stumped as you are about it. But I'm sure someone else will find this and go "hey...."
       
Post is unread #6 Jun 5, 2006, 6:43 am   Last edited Jun 5, 2006, 6:58 am by Remcon
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

I haven't gotten around to messing with it yet, In all honesty I've never had the need to use alot of color codes in a single line before lol.
But I'll check it out in a bit and see what I can fiqure out.
Ok, yea I guess we should fix it since if you actually choose to do a color code for each letter it changes
1> testing out the color deal in the editor etc, since i think we all want it to w
2> testing out the color deal in &
1 was with no color codes and 2 was with a color code for each letter
Now to see if theres a good and easy fix for this :)
While I don't feel like working up a whole fix for this lets take a look at this you showed
      if( strlen_color( argument ) > 79 )
      {
         strncpy( buf, argument, ( strlen_codes( argument ) + 79 ) );
         buf[strlen_codes( argument ) + 79] = '\0';
         send_to_char( "(Long line trimmed)\n\r> ", ch );
      }
      else
         strcpy( buf, argument );

Ok so first you use strlen_color to see if argument (without counting color codes) is above 79
If it is then you take and copy argument into buf using strlen_codes (assume that strlen_codes actually only counts the valid color codes) and adding 79 onto it? and then your setting buf[using the same max] = '\0'
Now don't get me wrong since I'm not exactly sure of all your changes here, at least in stock SmaugFUSS instead of the = '\0'; its doing = 0; so you might want to give that a try, if that doesn't work we would have to see your strlen_codes and strlen_color functions.
       
Post is unread #7 Jun 5, 2006, 7:09 am   Last edited Jun 5, 2006, 7:20 am by Remcon
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Well that seems simple enough for me
I did only slight modifications and ended up with this
1> testing out the color deal in the editor etc, since i think we all want it to w
2> testing out the color deal in the editor etc, since i think we all want it to w
1 with no color codes and 2 with color codes for each letter. Worked nicely no?
Although it's not done pretty heres all I did
      int normal = strlen( argument ); /* Normal string length */
      int nocolor = color_strlen( argument ); /* String length without color */
      int max = ( 79 + ( normal - nocolor ) );

      /* check it without the color in it */
      if( nocolor > 79 )
      {
         strncpy( buf, argument, max );
         buf[max] = 0;
         send_to_char( "(Long line trimmed)\r\n> ", ch );
      }
      else
         mudstrlcpy( buf, argument, MSL );

And yea copy_buffer has to be adjusted to if you really want it to allow the full amount but thats simple enough.
This is what it put in the file for my test string (after I adjusted copy_buffer to handle longer then 100)
Text    testing out the color deal in the editor etc, since i think we all want it to w
&Rt&Ce&Rs&Ct&Ri&Cn&Rg &Co&Ru&Ct &Rt&Ch&Re &Cc&Ro&Cl&Ro&Cr &Rd&Ce&Ra&Cl &Ri&Cn &Rt&Ch&Re &Ce&Rd&Ci&Rt&Co&Rr &Ce&Rt&Cc&R, &Cs&Ri&Cn&Rc&Ce &Ri &Ct&Rh&Ci&Rn&Ck &Rw&Ce &Ra&Cl&Rl &Cw&Ra&Cn&Rt &Ci&Rt &Ct&Ro &Rw&C
~

Hope that info helps you out some :) Later.
       
Post is unread #8 Jun 7, 2006, 7:54 am
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Still didn't work, I'm afraid. It's still munching lines. :/

I don't think what you're looking at there is the issue, because it doesn't actually seem to catch that particular chunk. It never mentions anything about trimming a long line. That's what REALLY confuses me.
       
Post is unread #9 Jun 7, 2006, 8:06 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

All I can say is that mine seems to work great after the changes I did.
Before I edited it at 80 characters (including colors) it would cut the line short.
After I edited it at 80 characters (not including colors) it will cut the line short.

If thats not what your getting at whats the actual problem in a short and sweet deal? maybe some output from the mud to give us an idea of whats going on would help out some too.
       
Post is unread #10 Jun 7, 2006, 8:25 am
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Okay, well, let's take this as an example, because this is what one of the players brought to me as causing problems:

&x.&z         .                                                      . 
        .n                   .                 .                  n. 
  .   .dP                  dP                   9b                 9b.    . 
4    qXb         .       dX                     Xb       .        dXp     t 
dX.    9Xb      .dXb    __                         __    dXb.     dXP     .Xb 
9XXb._       _.dXXXXb dXXXXbo.                 .odXXXXb dXXXXb._       _.dXXP 
9XXXXXXXXXXXXXXXXXXXVXXXXXXXXOo.           .oOXXXXXXXXVXXXXXXXXXXXXXXXXXXXP 
  `9XXXXXXXXXXXXXXXXXXXXX'-   -`OOO8b   d8OOO'-   -`XXXXXXXXXXXXXXXXXXXXXP' 
     9XXXXXXXXXXXP' `9XX'   &r(&R0&r)&z    `98v8P'   &r(&R0&r)&z    `XXP' `9XXXXXXXXXXX 
        -------       9X.          .db|db.          .XP       ------ 
                        )b.  .dbo.dP'`v'`9b.odb.  .dX(


If you copy and paste all that, then spit it into the editor, you get this:

------------------
 1> .         .                                                      . 
 2>         .n                   .                 .                  n. 
 3>   .   .dP                  dP                   9b                 9b.    . 
 4> 4    qXb         .       dX                     Xb       .        dXp     t 
 5> dX.    9Xb      .dXb    __                         __    dXb.     dXP     .Xb 
 6> 9XXb._       _.dXXXXb dXXXXbo.                 .odXXXXb dXXXXb._       _.dXXP 
 7> 9XXXXXXXXXXXXXXXXXXXVXXXXXXXXOo.           .oOXXXXXXXXVXXXXXXXXXXXXXXXXXXXP 
 8>   `9XXXXXXXXXXXXXXXXXXXXX'-   -`OOO8b   d8OOO'-   -`XXXXXXXXXXXXXXXXXXXXXP' 
 9>      9XXXXXXXXXXXP' `9XX'   (0)    `98v8P'   (0)    `XXP' `9XXXXX        -------       9X.          .db|db.          .XP       ------ 
10>         -------       9X.          .db|db.          .XP       ------ 
11>                         )b.  .dbo.dP'`v'`9b.odb.  .dX(
------------------


If you take a close look, you can see what it's doing: There on line 9, it's taking the contents of line nine, cutting it at 80 chars (Color codes included), and then it's adding line 10 to the end. Oddly enough, after doing so, it still adds line 10 normalling on its own.

Somewhere along the line, the 80 char limit is being enforced, but not very well. I'm not sure where, unfortunately.
       
Post is unread #11 Jun 7, 2006, 8:29 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Ty, and you are correct it did the same thing on mine. I'll see if i can fiqure it out in a bit :)
       
Post is unread #12 Jun 7, 2006, 9:50 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Ok, heres the thing first this isn't a stock issue it comes in when we expanded the lines to
handle color codes and be able to expand beyond the 80 limit.

To fix this you have to actually decide on a new limit (including color codes) and in mud.h find the EDITOR_DATA and for line where it has like char line[49] [81] and change the 81 for how long you wish to allow a line.
       
Post is unread #13 Jun 7, 2006, 9:56 am
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Since personaly I choose to allow up to MIL (MAX_INPUT_LENGTH) for a line using color I choose to use ( MIL + 1 ) in place of the 81
And it did indead fix the issue heres what it showed after i pasted that into the bio editor and typing /l after applying the fix
------------------
 1> .         .                                                      . 
 2>         .n                   .                 .                  n. 
 3>   .   .dP                  dP                   9b                 9b.    . 
 4> 4    qXb         .       dX                     Xb       .        dXp     t 
 5> dX.    9Xb      .dXb    __                         __    dXb.     dXP     .Xb 
 6> 9XXb._       _.dXXXXb dXXXXbo.                 .odXXXXb dXXXXb._       _.dXXP 
 7> 9XXXXXXXXXXXXXXXXXXXVXXXXXXXXOo.           .oOXXXXXXXXVXXXXXXXXXXXXXXXXXXXP 
 8>   `9XXXXXXXXXXXXXXXXXXXXX'-   -`OOO8b   d8OOO'-   -`XXXXXXXXXXXXXXXXXXXXXP' 
 9>      9XXXXXXXXXXXP' `9XX'   (0)    `98v8P'   (0)    `XXP' `9XXXXXXXXXXX 
10>         -------       9X.          .db|db.          .XP       ------ 
11>                         )b.  .dbo.dP'`v'`9b.odb.  .dX(
12>  
------------------
       
Post is unread #14 Jun 7, 2006, 1:57 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

You will also have to update start_editing where it deals with lines and putting stuff into them :) later.
       
Post is unread #15 Jun 7, 2006, 2:36 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Blah you know that edit_buffer doesn't acctually take into consideration quite a bit of stuff?
Stock smaug has a limit of 81 (max per line length in mud.h) and when inputting data it limits it to 79
The start_editing handles that limit correctly.
copy_buffer also handles that limit correctly. (It uses a 100 limit that I guess should also be put down to the correct limit)
edit_buffer parts that don't limit the data correctly.
when doing the replace part (/r) it doesn't limit it correctly.
when inserting new lines (/i) and it moves data around it doesn't limit it correctly.
when deleteing lines (/d) and it moves data around it doesn't limit it correctly.

The thing is that if you go over the 81 limit using one of those its going to wrap the next line onto it as well as put it on its own line.
then in start_editing if the line is longer then it limits it...it makes some wierd looking junk in it lol. (at least that was my experience in mine of course it was changed)
Just thought I'd give you all a heads up what I found so far :)
       
Post is unread #16 Jun 7, 2006, 2:38 pm
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Good stuff, appreciate it. I was actually getting ready to go look at the editor_data structure to see if I could find some clues there, just beat me to it. :p Thanks a lot. :smile:
       
Post is unread #17 Jun 7, 2006, 2:51 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

NP, btw No point in giving the lines up to MIL (MAX_INPUT_LENGTH) the code limits each line input to 254 in comm.c read_from_buffer and I found that you should likly have the line length under that to make it all correctly handle. Personaly I did a MLS (MAX_LINE_SIZE) define of 252 and used it in most places. The exception to that being the define for line in editor_data in mud.h which i changed the 81 to ( MLS + 2 ) to give it 2 extra just to give it a bit of extra room lol
       
Post is unread #18 Jun 7, 2006, 2:57 pm
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,868
JoinedJul 26, 2005

Come to think of it why does read_from_buffer in comm.c use this
      if( k >= 254 )
      {
         write_to_descriptor( d, "Line too long.\r\n", 0 );
         d->inbuf[i] = '\n';
         d->inbuf[i + 1] = '\0';
         break;
      }

Shouldn't MIL (MAX_INPUT_LENGTH) be used there instead or am I just missing the whole point? :) Just wondering lol.
       
Post is unread #19 Jun 12, 2006, 9:47 am
Go to the top of the page
Go to the bottom of the page

Noplex
Apprentice
GroupMembers
Posts62
JoinedAug 30, 2005

You could always multiply by 80 (standard number of characters per line, right?) by the number of lines for the buffer (in profile case that was 24) and bump the maximum input for the editor substate up so that you could allow full pastes from the telnet window. If the auto-wrapping code works properly it would wrap everything at 80 characters per line and do it properly. Realms of Despair does not do this and it has always irritated the hell out of me.
       
Post is unread #20 Jun 21, 2006, 5:42 pm
Go to the top of the page
Go to the bottom of the page

Halcyon
Magician
GroupMembers
Posts187
JoinedApr 12, 2005

Rofl, I hate to ask this, Remcon, but... I tried doing what you did, but I think I left something out, seem to have some stray issues with text just disappearing. :p I know this is kind of asking a lot, but can you give me all the EXACT changes you made?
       
Pages:<< prev 1, 2 next >>