Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, 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.
Entire forum
➜ PennMUSH
➜ Running the server
➜ Characters "freeze" after 100 commands
Characters "freeze" after 100 commands
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| Saxman
(2 posts) Bio
|
Date
| Sun 03 Aug 2003 01:03 PM (UTC) |
Message
| Just downloaded the latest compiled version for win32. Running XP pro ona P4, 2.2, with 512 meg. Seems to run just okay, but with 2 problems.
1) The service doesn't register as running in the services screen, even though the game is up and running.
2) Once a character has entered 100 commands, all output from that character is frozen. They can see what others are typing, but they can't type a thing. Logging out and back in resets it until they hit 100 commands again.
Any ideas?
Mark | Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #1 on Mon 04 Aug 2003 03:37 AM (UTC) |
Message
| There is some kind of "throttling" in PennMUSH to stop players entering hundreds of commands per second. This is a configuration thing. Perhaps the configuration is set too low. Stopping at exactly 100 sounds like you have hit it, and then it should allow 1 per second (say) until x seconds have elapsed. Try fiddling with the configuration. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Saxman
(2 posts) Bio
|
Date
| Reply #2 on Mon 04 Aug 2003 12:52 PM (UTC) |
Message
| I was hoping it was some config issue, but just to be clear. It's 100 commands no matter how fast you enter them. As a test, I entered a WHO command once every minute, and at 100 I was stopped from entering in anymore. I tried it once a sec, and was stopped at 100 commands, and going as fast as I could, 100 commands. So it doesn't seem to be rate related. It is however set at the 100 command. Here is a dump of the limits set on my mush with mush.ncf if that helps at all.
@config/list limits
Limits and other constants
max_dbref #0
max_attrs_per_obj 2048
max_logins 20
max_guests 0
idle_timeout
unconnected_idle_timeout
whisper_loudness 100
starting_quota 2000
starting_money 150
paycheck 50
guest_paycheck 0
max_pennies 100000
max_guest_pennies 1000
max_parents 20
mail_limit 300
max_depth 20
player_queue_limit 2000
queue_loss 63
queue_chunk 2
active_queue_chunk 1
function_recursion_limit 50
function_invocation_limit 2500
call_limit 5000
player_name_len 16
queue_entry_cpu_time 3000
chunk_migrate 500
active_chunk_migrate 200 | Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #3 on Mon 04 Aug 2003 08:59 PM (UTC) |
Message
| Hmm - so I am solving the right problem, can you say exactly which version you are using? The "latest" may be the 2nd latest if they have found and fixed the problem already. Once you say that I'll try myself and see what happens. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Somerled
(5 posts) Bio
|
Date
| Reply #4 on Tue 16 Nov 2004 02:34 AM (UTC) |
Message
|
Nick,
I'm having the same problem. . . it doesn't matter what telnet client I use, the PennMUSH on a Windows 2000 server just freezes after 100 commands of any sort are sent at any speed/rate.
Any other ideas?
Thank you,
Chris / Somerled
chris@kcmo.net
| Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #5 on Wed 17 Nov 2004 03:36 AM (UTC) |
Message
| To be able to answer this I really need to know exactly what version of PennMUSH you are using, and whether you compiled it yourself or downloaded a precompiled version. If you compiled it yourself did you use Cygwin or something else?
Sounds like its internal timer is not being reset. I think it allows 100 per second, however if it doesn't realise a second has elapsed, for some reason, then you might get that result. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Cash
USA (626 posts) Bio
|
Date
| Reply #6 on Wed 17 Nov 2004 04:03 AM (UTC) |
Message
| Maybe its a problem with windows? Perhaps a Service Pack 2 mixup? Or maybe they are entering the same command 100 times? I think SMAUG boots you if you do something like that....
Just a thought.... |
~Nick Cash
http://www.nick-cash.com | Top |
|
Posted by
| Somerled
(5 posts) Bio
|
Date
| Reply #7 on Wed 17 Nov 2004 04:09 AM (UTC) |
Message
|
Nick,
Actually, I did another test last night on this and it does not appear to consistently be 100 exactly. . . yet it does somehow seem related to a quantity of commands having been transmitted. It can be 3 minutes or 30 minutes, or even up to an hour, but eventually--seemingly at random--the server will begin ignoring transmitting commands, yet the player can still see what is happening in the world as the server text messages continue to flash by.
The version is PennMUSH version 1.7.7 patchlevel 16 [06/23/2003]. It is a precompiled binary, downloaded from http://ftp.pennmush.org/Win32Binaries/, running on a Windows 2000 server.
The problem occurs with all telnet clients that I've tried so far, so it does appear to be server-related. I have also tested access locally on the server (127.0.0.1) with a couple of telnet clients, and the same thing happens.
I'll send you my configuration files via e-mail.
Thank you,
Chris / Somerled
chris@kcmo.net
| Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #8 on Wed 17 Nov 2004 07:19 PM (UTC) |
Message
| So, really this binary is almost one and a half years old.
It is possible this problem was noticed and fixed in a subsequent release, not necessarily one that became a Win32 binary.
I think the best thing would be to download a more up-to-date binary, or simply install Cygwin and recompile from the latest stable source.
At least then, if there still is a problem we can use gdb to find why the long delay.
The problem with debugging precompiled versions is that it is hard to know exactly what options they used to compile it.
Your description of how it may take half an hour to happen seems to confirm my suggestion that the server does not realise that time has elapsed, and is thinking the 100 commands have been entered in the last second.
You could try changing player_queue_limit in mush.cnf, which seems to be moderately relevant, and is about the only number that is exactly 100, at least if changing that to 50 makes it stop after 50 you know roughly where the problem is.
However if that *is* the problem, and you make it very large, you are just deferring the problem, and the directive is there for a reason, anyway. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Gage
(1 post) Bio
|
Date
| Reply #9 on Sun 02 Jan 2005 10:14 PM (UTC) Amended on Sun 02 Jan 2005 10:23 PM (UTC) by Gage
|
Message
| I have the same problem as mentioned here. Running Win2k Pro. Using the 1.80 precompiled binary. I changed the player_queue_limit, and it didn't change that it stops at exactly 100 commands. I also tried editing Call_limit(only other thing in mush.cnf with a value of 100) and it didn't affect it either. Stops at exactly 100 commands as listed in WHO. | Top |
|
Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
Date
| Reply #10 on Mon 03 Jan 2005 04:34 AM (UTC) |
Message
| I think the problem here is something to do with time and the way it is getting it under Windows. It should clear its 100 count every second or so.
However this site is not really designed to support PennMUSH Win32 problems. I am pretty sure the last version I did for PennMUSH Win32 worked fine, but the Win32 versions are now being done by:
Noltar@Korongil <noltar@korongil.org>
I mention somewhere on this site that one reason I stopped supporting PennMUSH Win32 compiles was because it works so well under Cygwin these days.
To prove the point, I just downloaded the source version of 1.8.0 and compiled and ran it under Cygwin. This took the following 9 lines (one being just pressing Enter at the prompt):
tar xzf pennmush-1.8.0p0.tar.gz
cd pennmush
. Configure -d
(enter)
cp options.h.dist options.h
make
make install
cd game
./netmush
After the final line the game was running, and I connected with MUSHclient, and typed in hundreds of commands without it hanging. I tried that under NT 4, and also XP, without any problems.
My advice is, use Cygwin and compile it yourself. It is not a lot of work, and is more reliable. :)
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Somerled
(5 posts) Bio
|
Date
| Reply #11 on Mon 03 Jan 2005 04:46 AM (UTC) |
Message
|
Nick,
Thank you for posting that. . . I've been meaning to compile the
latest source for use on my Windows 2000 server but I just have
not yet taken the time out to look into this.
Your CygWin sample compile steps are greatly appreciated.
Thanks again,
Chris / Somerled
chris@kcmo.net
| Top |
|
Posted by
| Somerled
(5 posts) Bio
|
Date
| Reply #12 on Sat 15 Jan 2005 06:18 PM (UTC) |
Message
|
I have the latest 1.8.0 binary (now that's available for download), but I'm having problems getting my indb file to port from version 1.7.7 to 1.8.0.
When I compare the two text database files I'm noticing that--although they are similar in format--they are also significantly different.
For example, when the file gets to the point where the first room (#0) is defined, the 1.7.7 indb file looks like this:
!0
"Room Zero"
-1
1
-1
-1
-1
1
-1
0
0
0
0
]DESCRIBE^1^544
"You are in Room Zero. It's very dark here."
]OSUCCESS^1^32
"is briefly visible through the mist."
<
. . . but then, when you look at the new (1.8.0) indb file (which is created automatically at first run), the format of the file for room #0 looks like this:
!0
name "Room Zero"
location #-1
contents #1
exits #-1
next #-1
parent #-1
lockcount 0
owner #1
zone #-1
pennies 0
type 1
flags "LINK_OK"
powers ""
warnings ""
created 1105815427
modified 1105815427
attrcount 1
name "DESCRIBE"
owner #1
flags "no_command visual prefixmatch"
derefs 5
value "You are in Room Zero."
. . . so we all have a problem here, unless someone out there has built a conversion tool that reformats the strings from the old indb files to the new indb format.
No matter what I have done in my testing so far I have not yet been able to get a single indb file from 1.7.7 to run under 1.8, not even the included sample minimal.db file.
Does any one have any ideas? Please copy/past your comments to my e-mail account: chris@kcmo.net
Thank you,
Chris / Somerled
chris@kcmo.net
| Top |
|
Posted by
| Somerled
(5 posts) Bio
|
Date
| Reply #13 on Sat 15 Jan 2005 08:33 PM (UTC) |
Message
|
. . . nevermind, Noltar from PennMUSH walked me through fixing it, basically the solution was to:
(1) Open the indb/outdb file with a text editor that supports UNIX format saves (minus an extra carriage return character), TextPad is what he had me use, and just save the file in UNIX format instead of DOS
(2) Put the indb/outdb file under an earlier version of PennMUSH (I used 1.7.7p38), start the MUSH server, log in and issue a @dump command and then @shutdown
(3) Take that indb/outdb file, put it under 1.8.0 and it works fine
Many thanks to Noltar of PennMUSH!
Chris / Somerled
chris@kcmo.net
| Top |
|
Posted by
| Noltar
USA (3 posts) Bio
|
Date
| Reply #14 on Tue 22 Mar 2005 06:57 AM (UTC) |
Message
| I was just directed to this thread. Firstly, I would like to second Nick's opinion that the binaries aren't really necessary. While I personally don't actively support Cygwin compiles, I do fully endorse using MinGW + MSys to compile and run Pennmush on Windows. There is a README for the installation of MinGW/MSys and compilation of Pennmush in the Win32 directory of the Pennmush source.
As for the freezing issue particularly, I've only noticed this in the NT_TCP enabled binaries, not those using the BSD sockets instead. So that may be one alternative for some of those here who are still having issues.
Also, any Windows issues may be directed to pennmush-w32@pennmush.org. I'll see about getting www.pennmush.org updated so that it doesn't imply that Nick is the person to come to for full support. | 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.
35,469 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top