08 Feb, 2009, Keberus wrote in the 1st comment:
Votes: 0
Okay, I have been working on getting NAWS to work in my mud, and at this point it does seem to, the only issue that I have is that it corrupts my input the first time I enter something after logging in.

Here's the code from comm.c read_from_buffer:
else if( memcmp( p, iac_sb_naws, strlen( ( const char * )iac_sb_naws ) ) == 0 )
{
unsigned char width, height; //should be split into four characters

int i_p = 4;

//width
width = p[i_p];
//height
height = p[i_p + 2];
process_naws( d, ( int )width, ( int )height );

memmove( p, &p[strlen( ( const char * )iac_sb_naws )],
strlen( ( const char * )( &p[strlen( ( const char * )iac_sb_naws )] ) ) + 1 );
p–;
}


Here's iac_sb_naws:
char iac_sb_naws[] = { IAC, SB, TELOPT_NAWS, '\0' };


I tried to mirror the code in comm.c after my MXP code which works fine. I put an option in the game to echo my input so I could see what it was recieving instead of just seeing 'huh!'. For an example, when I login to the game and type "who" this is what I get echo'ed back to me as my input

Quote
uwho3


Except the u has an upside down v accent above it.

Thanks in advance,
KeB
08 Feb, 2009, Tyche wrote in the 2nd comment:
Votes: 0
Assuming you negotiated NAWS correctly…(not shown)

One problem I see is the height and width are in network byte order (big endian shorts).
Use ntohs() to decode these.
Another is I don't see you process 255 correctly. If 255 occurs it's escaped.

Not shown also is whether SE is processed correctly.
08 Feb, 2009, Keberus wrote in the 3rd comment:
Votes: 0
Okay, for some more info here's my process_naws function:
void process_naws( DESCRIPTOR_DATA * d, int width, int height )
{
int oldheight = 0, oldwidth = 0;

if( !d )
{
bug( "process_naws: NULL d" );
return;
}
if( !d->character || !d->character->pcdata )
return;

if( !IS_SET( d->character->pcdata->flags, PCFLAG_VT102 ) )
return;

oldheight = d->character->pcdata->scrlines;
oldwidth = d->character->pcdata->scrcols;

if( height )
{
height = URANGE( 15, height, 99 );
d->character->pcdata->scrlines = height;
}

if( width )
{
width = URANGE( 80, width, 250 );
d->character->pcdata->scrcols = width;
}
if( ( oldwidth != d->character->pcdata->scrcols ) || ( oldheight != d->character->pcdata->scrlines ) )
{
turn_off_vt100( d->character );
// clear_old_vt100( d->character, oldheight, oldwidth );
draw_vt100( d->character );
}

return;
}


And here is send_naws which is the function that asks the terminal if it can use NAWS
void send_naws( DESCRIPTOR_DATA * d )
{
char iac_do_naws[] = { IAC, DO, TELOPT_NAWS, 0 };
write_to_descriptor( d, iac_do_naws, 0 );
}


Quote
One problem I see is the height and width are in network byte order (big endian shorts).
Use ntohs() to decode these.


So are you saying that I should change my read_from_buffer code to look like:
else if( memcmp( p, iac_sb_naws, strlen( ( const char * )iac_sb_naws ) ) == 0 )
{
short width, height; //should be split into four characters

int i_p = 4;

//width
width = ntohs( p[i_p] );
//height
height = ntohs( p[i_p + 2] );
process_naws( d, width, height );

memmove( p, &p[strlen( ( const char * )iac_sb_naws )],
strlen( ( const char * )( &p[strlen( ( const char * )iac_sb_naws )] ) ) + 1 );
p–;
}


Quote
Another is I don't see you process 255 correctly. If 255 occurs it's escaped.
Not shown also is whether SE is processed correctly.


So should I shift p forward one more time to fix the 255 thing or actually check against it?


Quote
Not shown also is whether SE is processed correctly.

What is the SE? And how would I check for/against it?


Btw, I was used emud and the Purple Dragon's Telnet Protocol snippet to come up with what I currently have.


Thanks again,
KeB
08 Feb, 2009, Scandum wrote in the 4th comment:
Votes: 0
Emud only grabs the first of the two bytes, so only screensizes within the range of 254x254 will work with this code, it's a hack job but works in 99.99% of the cases.

I think you'd need to use width = p[3] * 256 + p[4]; to get the correct width (I could be wrong). If p[3] or p[4] equal 255 it's doubled according to the standard, which is retarded, but so be it.

The error here is that you use: strlen( ( const char * )iac_sb_naws ), try using 9 instead because that's the typical length of the full sb naws negotiation.

draw_vt100( d->character );

Out of curiosity, is that emud's vt100 interface you're calling there?
09 Feb, 2009, Keberus wrote in the 5th comment:
Votes: 0
Quote
Out of curiosity, is that emud's vt100 interface you're calling there?


Yeah, thats what I initially tried to do, though I ended up re-writing it. I wanted to have a constant prompt, works pretty well now, even made it customizeable and people can have mxp in it. Though it does have some redrawing issues that need worked out.

Thanks,
KeB
09 Feb, 2009, Keberus wrote in the 6th comment:
Votes: 0
I tried using 9 every which way I could think of, with no luck.

As an aside, in emud, does the prompt get deleted and redrawn or just overwritten?

Thanks,
KeB
09 Feb, 2009, Scandum wrote in the 7th comment:
Votes: 0
You tried: memmove(p, &p[9], strlen( ( const char * )( &p[9]) )); ? Not too sure though since the code doesn't resemble emud's all that much, so the problem could be elsewhere.

Quote
As an aside, in emud, does the prompt get deleted and redrawn or just overwritten?

It keeps a copy in memory and overwrites the parts that gets changed, so if your hp goes from 412 to 312 it only changes the 4 into a 3. If you're just putting a mud prompt on the split line that routine might not work all that well since it has a variable length.
0.0/7