Gammon Forum : SMAUG : Running the server : If Mud Progs dont work; SCREAM!; endif. =)

Register forum user name Search FAQ

Gammon Forum

Entire forum

SMAUG

Running the server

If Mud Progs dont work; SCREAM!; endif. =)

If Mud Progs dont work; SCREAM!; endif. =)

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3

Posted by

David Haley USA (3,881 posts)

Date

Reply #15 on Fri 06 Jul 2007 04:49 PM (UTC)

Message

OK. Try taking completely stock SmaugFUSS and see if you can reproduce this. That is, download the FUSS archive, change absolutely nothing, and see if this problem exists.

Chances are you changed something else, somewhere, in perhaps subtle ways, and maybe even forgot. (Happens to all of us!)

Oh, and you are remembering to make clean from time to time (e.g. after changing header files), right?

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by Samryn United Kingdom (60 posts) bio

Date Reply #16 on Sat 07 Jul 2007 01:54 AM (UTC)

Message

Ok so i've tried this and now im getting abit more of a major problem.

Here is what im getting when i type startup...


dreamer@dreams.slayn.net [~/SMAUG/src]# ./startup &
[1] 7587
'reamer@dreams.slayn.net [~/SMAUG/src]# Unknown option: `-
Usage: csh [ -bcdefilmnqstvVxX ] [ argument ... ].

So i decided to try and to a gdb to check it out... and this is what its came up with:


Fri Jul  6 18:48:06 2007 :: IMC: imcfread_word: EOF encountered on read.
Fri Jul  6 18:48:06 2007 :: IMC: IMC2 network data loaded. Autoconnect not set. IMC2 will need to be connected manually.
Fri Jul  6 18:48:06 2007 :: Day of Dreams ready on port 4000.

Program received signal SIGINT, Interrupt.
0x001697a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

(gdb) backtrace
#0  0x001697a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00242a0d in ___newselect_nocancel () from /lib/tls/libc.so.6
#2  0x080eaa06 in game_loop () at comm.c:953
#3  0x080e9cbe in main (argc=1, argv=0xbfef0e64) at comm.c:550

Anyone got any ideas what this problem is now? =(

Samryn Medri

Posted by

David Haley USA (3,881 posts)

Date

Reply #17 on Sat 07 Jul 2007 02:00 AM (UTC)

Message

Those are actually two separate problems, and neither makes a lot of sense at first glance. :/

For the first, try doing csh --version and see what version of csh it's running.
Also, please paste the first line of the startup script; the one that starts with something like #!/bin/csh ...

For the second one, you might want to ask the SmaugFUSS forums; maybe somebody has seen it before. It might be something with the FUSS additions.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Meerclar USA (733 posts)

Date

Reply #18 on Sat 07 Jul 2007 08:50 PM (UTC)

Message

IMC has come up a number of times, you should be able to search for that exact error message here and find the solution you need. As for the other, yeah we need to see whats in your startup script.

Meerclar - Lord of Cats
Coder, Builder, and Tormenter of Mortals
Stormbringer: Rebirth
storm-bringer.org:4500
www.storm-bringer.org

Posted by

Samryn United Kingdom (60 posts)

Date

Reply #19 on Sat 07 Jul 2007 11:41 PM (UTC)

Message

I finally got a code to work, and then began implementing the changes i did to see where the bug appeared... and guess what? I've found the bugger!

There is a bug in SMAUG which causes telnet to not function the description right correctly... this function is copy_buffer.

Now the reason it causes the problem (as stated on: http://www.fussproject.org/index.php?a=topic&t=1098 ) is because it doesn't have \r. Now when you finally put \r into copy_buffer... it begins to cause the endif bug.

Now I'm sooo sorry for wasting your time. But surely there has to be another way to fix this? Because if I dont use \r the line isn't refreshed when using telnet, however if i do put \r into copy_buffer is causes mud_prog issues... anyone got any suggestions?

Samryn Medri

Posted by

David Haley USA (3,881 posts)

Date

Reply #20 on Sun 08 Jul 2007 12:24 AM (UTC)

Message

I guess the mudprog could internally wipe the \r, right? Or it could be programmed to just skip it as a character. I agree that this shouldn't be that huge of an issue...

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by Samryn United Kingdom (60 posts) bio

Date Reply #21 on Sun 08 Jul 2007 01:28 AM (UTC)

Message

Its just finding a solution now...
hmmm, I suppose I could try putting a boolean in? so like if its coming from a mud prog's point of view... it will change it to \n instead of \r\n?

The mudprog wont internally remove it, but i'm guessing it could somehow be programmed. Something like:


   buf[0] = '\0';
   for( x = 0; x < ch->editor->numlines; x++ )
   {
      mudstrlcpy( tmp, ch->editor->line[x], 100 );
      len = strlen( tmp );
      if( tmp && tmp[len - 1] == '~' )
         tmp[len - 1] = '\0';
      else
         if ( boolMudProg == TRUE )
            mudstrlcat( tmp, "\n", 100 );
         else
            mudstrlcat( tmp, "\r\n", 100 );
      smash_tilde( tmp );
      mudstrlcat( buf, tmp, MAX_STRING_LENGTH );
   }

However, i'm not sure if its the actual writing the prog which is causing the problem, or is it the reading of the prog what is? if you get?

Once I know that, I can begin doing the boolean in the read or write part of the prog... making it so when it uses the copy_buffer. Now would this work, or not?

Samryn Medri

Posted by

David Haley USA (3,881 posts)

Date

Reply #22 on Sun 08 Jul 2007 03:37 AM (UTC)

Message

I think you're over-solving the problem. If the problem is only that the presence of \r characters confuses the mudprog driver, then the driver should be fixed to just skip over them as it parses the string. I don't think it's necessary to mess with the buffer contents or do fancy things like detecting where input/output is going.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Zune (76 posts)

Date

Reply #23 on Sun 08 Jul 2007 10:09 PM (UTC)

Message

I've got nothing to help, but I just wanted to say good luck. I'm watching this one with high hopes!

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #24 on Tue 10 Jul 2007 09:34 PM (UTC)

Message

Quote:

Ok, heres one for you brainy bunch to work out...
I've noticed when ever a builder makes a new ifcheck prog such as:

...

it ends up coming up with a nice strange error...
Log: [*****] BUG: Mptransfer - No such location, Room #1200.
Log: [*****] BUG: Missing endif, Room #1200.

I can't reproduce this. Using stock Smaug FUSS 1.7, I can change progs without any problems.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Samryn United Kingdom (60 posts)

Date

Reply #25 on Thu 12 Jul 2007 12:04 AM (UTC)

Message

This is how you would create this bug nick:

go into build.c
locate: *copy_buffer

change:
mudstrlcat( tmp, "\n", 100 );

to:
mudstrlcat( tmp, "\r\n", 100 );

This change is to start a new line on telnet. However it begins causing issues with the mud progs.

Still haven't come up with a fix for this, and still looking for a way around it... any help be greatful.

Samryn Medri

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #26 on Thu 12 Jul 2007 01:43 AM (UTC)

Message

OK, there are so many MUD clients around, for Windows, Mac, Linux, why are you changing the MUD code, in a way that stops it working, rather than getting your builder to simply use a client that works properly?

In any case, I wouldn't change it in that spot. There are lots of places (eg. help files) where the carriage-return is probably not present.

I would change the output routines, that if it gets a newline, that is not preceded by a carriage-return, that it inserts one there.

Not, to stick a carriage return into the editing buffer.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Samryn United Kingdom (60 posts)

Date

Reply #27 on Fri 13 Jul 2007 08:13 PM (UTC)

Message

Hmmm so let me see if I'm understanding this correctly.

When Smaug is outputting the buffer, stick it on the end? So like, when its displaying room descriptions, notes, progs, etc... it will stick it on the end?

How would this be done though? as from what i can see, the description is just read and dumped into the players client. So wouldn't that mean seperating each line and sticking the carriage-return in?

Sorry if these seem dumb questions but thought i better ask to make sure i'm understanding correctly. Thanks again.

Samryn Medri

Posted by

David Haley USA (3,881 posts)

Date

Reply #28 on Fri 13 Jul 2007 08:16 PM (UTC)

Message

I think that Nick was suggesting that your builder should get a client that works properly, and can handle the various \r and \n codes etc., instead of messing with the code too much. :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Nick Gammon Australia (22,975 posts)

bio Forum Administrator

Date

Reply #29 on Fri 13 Jul 2007 09:20 PM (UTC)

Message

Yes, I *was* suggesting getting a proper client. I can understand a newbie not having a client, as they may be playing a MUD for the first time. But a builder?

Quote:

When Smaug is outputting the buffer, stick it on the end? So like, when its displaying room descriptions, notes, progs, etc... it will stick it on the end?

No, that won't work. For one thing, the sequence in \r\n, not \n\r, so putting \r at the end is the wrong place.

Also, some text in the output buffer will have multiple lines in it, particularly when read from help files, and also inside the code, it may generate multiple lines.

You would have to write a routine that inspected each buffer, and do something like this:

Is the current character a newline? (\n)
If so, was the previous character a carriage-return? (\r)
If not, insert a \r before the \n.
Move onto the next character

You would need to allow for the buffer becoming larger. This would also introduce a marginal speed decrease for everyone.

The MUD already does something like this to convert internal colour codes into ANSI codes, maybe you could find where it does that and modify that.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

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.

72,649 views.

This is page 2, subject is 3 pages long: 1 2 3

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )