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, Google, Bing, Majestic-12

Members: 0
Guests: 11
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
614
BenitoVirg
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » General Discussions » Mudprog arguments not being r...
Forum Rules | Mark all | Recent Posts

Mudprog arguments not being recognized properly
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Jan 30, 2006, 5:07 am
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

Since I applied the strip_cr bugfix my mob-/objprogs have encountered problems. The argument of commands like mpoload aren't recognized as a number, some emotes fail to work. This only applies to progs created after I introduced the bugfix. Removing the bugfix didn't help until I deleted the progs, reentered them and rebooted. So my question is, what may have caused this behaviour, and how may it be solved? The MUD is running under Linux if that matters.
       
Post is unread #2 Jan 30, 2006, 8:31 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

That doesn't sound like it was supposed to happen. Only things which call strip_cr should be complaining and I don't think the mudprog system needs to mess with it. The following are the only instances of strip_cr being used in the FUSS code:

[samson@boralis: ~/SmaugFUSS/src] grep strip_cr *
act_info.c: fixed = strip_cr( text );
build.c:char *strip_cr( char *str )
build.c: fprintf( fpout, "%s~\n", strip_cr( pMobIndex->long_descr ) );
build.c: fprintf( fpout, "%s~\n", strip_cr( pMobIndex->description ) );
build.c: mprog->arglist, strip_cr( mprog->comlist ) );
build.c: fprintf( fpout, "E\n%s~\n%s~\n", ed->keyword, strip_cr( ed->description ) );
build.c: mprog->arglist, strip_cr( mprog->comlist ) );
build.c: fprintf( fpout, "%s~\n", strip_cr( room->description ) );
build.c: fprintf( fpout, "%s~\n", strip_cr( xit->description ) );
build.c: fprintf( fpout, "%s~\n", strip_cr( xit->keyword ) );
build.c: fprintf( fpout, "E\n%s~\n%s~\n", ed->keyword, strip_cr( ed->description ) );
build.c: mprog->arglist, strip_cr( mprog->comlist ) );
mud.h:char *strip_cr args( ( char *str ) );


All but the use in act_info.c are for saving area file data.
       
Post is unread #3 Jan 30, 2006, 11:30 am
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

I've been testing a little, using SWRFuss1.2 downloaded from this site. For the test I create the following simple room prog:
>speech_prog test
mpoload 60
drop all

Running this produces the following bug message:

Log: [*****] BUG: Mpoload - Bad syntax, Room #100.

But then I fold the area and reboot. Voila, it works. Obviously it's supposed to work with no need of folding/rebooting, but it doesn't. It also appears that it doesn't have anything to do with strip_cr as such. In any case, since my codebase didn't have this error prior to me applying the SWRFuss bugfixes from the forum, and since SWRFuss1.2 itself has this error, it can be concluded that this is caused by some bugfix from Fuss.

If I succeed in tracking the source if this I will of course post it.
       
Post is unread #4 Jan 30, 2006, 12:05 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 this is most odd. The bug has now been verified as being in all of the FUSS packages as well as in AFKMud. I'm not sure exactly what happened or why but I'm on the hunt now. Damn bugs :P
       
Post is unread #5 Jan 30, 2006, 2:00 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

I have a possible solution that's been tested with 3 different mud clients so far: SimpleMU, Mudmagic, and Mushclient. It has also been tested via SecureCRT and a console session at the server's terminal. So I think it should work, but I'd like confirmation from anyone else using something like Zmud or Portal or whatever. I suspect it should be fine though.

Here's the change:
mud_prog.c, mprog_next_command

Locate:
   while( *pointer != '\n' && *pointer != '\0' )
      ++pointer;


Change to:
   while( *pointer != '\r' && *pointer != '\0' )
      ++pointer;


I think this had to do with the telnet protocol fixing that was done, though I honestly can't figure out why that should have mattered.
       
Post is unread #6 Jan 30, 2006, 2:20 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 so much for easy solutions. Damn this crap. The above fix works with progs entered via the OLC, but it falls apart on ones loaded from disk. What kind of BS is this anyway? Thing is, checking for both \n and \r does not work either and you end up with an even bigger mess. Stumped.
       
Post is unread #7 Jan 30, 2006, 3:05 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Alright. This little bastard is dead now. Tracked it down to a problem with user input after the tenlet patch was done. Seems someone at some point in time thought it would be cute to use the full \n\r to signify a newline in the copy_buffer code. Well that bit of stupidity has finally come back to haunt someone. That got changed to \r\n and began pissing off user input sent through the line editor. Anything done online via the OLC that used it would be affected but apparently the mudprog code is overly sensative to it. Go figure. Anyway, will have the fix posted shortly.
       
Pages:<< prev 1 next >>