Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum Goto page 1, 2, 3, 4  Next
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Sat Nov 03, 2007 8:05 am   

[2.10] SLOWWWWWW
 
What in the world. You know I thought Cmud was supposed to be all about making things faster and better. But good lord I try and test this version and it's nothing but slow.

For example, in Cmud 1.34 I have an alias to inrift all of my herbs.

inriftall:

inr all plant1
inr all plant2
inr all plant3

....all the way to like plant 15 or whatever.


Well in 1.34 and even Zmud all those commands are sent in one swift sequence, but in 2.10 it's like forever just to send 15 commands! There is like a delay between each line and when it prints to the screen it looks like it's moving through mud trying to get to the MUD.

So I get on the MUD and try to do some things, get in some combat, get all afflicted, and I can't even move or type anything on the command line because it's so damn slow it is waiting to complete all of the curing sequences going on. I mean 1.34 it works fine but I just can't understand why there is such a big difference here. Like I said just sending multiple commands in a row like that is ridiculously slow. I was thinking maybe it was my OnPrompt event firing on every prompt but then I ran a couple of aliases like the one above and it is just slow period! If it is taking that long to go from one line to the next I guess I will just stick with 1.34 or just go back to Zmud and not worry about this multi-threading.

Also on Control+Q it took around 50 in 1.34 and in 2.10 it takes over 60 for the same exact package. What is the difference there?

I don't want to build a robot to go to MARS. I just want a client that will execute with speed and efficiency without error. Yes I know this is beta. :-) Again maybe someone can help me out here.
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Sat Nov 03, 2007 8:17 am   
 
Okay let me also add that it is only like this when I am connected and online. I can't figure out why. If I run that same alias I described above it's like normal and sends all the commands immediately so I am at a loss.

Here is the difference in the amount of time it took just to go through these commands. I simply added a local variable to store %secs before the first line and then after the last line I subtracted that from %secs.

Offline time...

inr all ash
inr all bayberry
inr all bellwort
inr all bloodroot
inr all cohosh
inr all ginseng
inr all goldenseal
inr all hawthorn
inr all kelp
inr all kola
inr all lobelia
inr all echinacea
inr all moss
inr all pear
inr all sileris
inr all skullcap
inr all elm
inr all valerian
inr all myrrh

76 ms


Online time...

inr all ash
inr all bayberry
inr all bellwort
inr all bloodroot
inr all cohosh
inr all ginseng
inr all goldenseal
inr all hawthorn
inr all kelp
inr all kola
inr all lobelia
inr all echinacea
inr all moss
inr all pear
inr all sileris
inr all skullcap
inr all elm
inr all valerian
inr all myrrh

686 ms
Reply with quote
Arde
Enchanter


Joined: 09 Sep 2007
Posts: 605

PostPosted: Sat Nov 03, 2007 10:37 am   
 
Yeah.. I've check Ctrl+Q while offline right after installation of 2.10

2.09: 1.8-1.9
2.10: 9.1-9.8

5 times slower
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sat Nov 03, 2007 2:59 pm   
 
I am also seeing a significant slowdown with 2.10. My tests of CTRL-Q showed it taking 2 times as long as 2.09. That ratio was reasonably constant between allocating memory and straight scrolling.

I did my tests on the first launch after a clean install, and a number of subseqent launches without testing anything else.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Sat Nov 03, 2007 4:49 pm   
 
I'm seeing 2.10 two times slower, like Vigilante, than 2.09 with Ctrl-Q on the untitled session. I didn't notice any difference when connecting though, and aliases that send commands to the mud work very fast for me. Do you have stuff that gets enabled when you connect and disabled when you disconnect?
Reply with quote
Arde
Enchanter


Joined: 09 Sep 2007
Posts: 605

PostPosted: Sat Nov 03, 2007 5:13 pm   
 
7 hours after my previous post.
2.10: 3.3-3.8 Confused
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Nov 03, 2007 5:18 pm   
 
Did everyone do a fresh install, or install over the previous version? I'm not seeing any slowdown on my computer at all, so I'm not sure what's causing it. My Ctrl-Q speed in 2.10 is the same as in 2.09. This is in CMUDPro...maybe there is a difference between CMUDPro and regular CMUD?
Reply with quote
Arde
Enchanter


Joined: 09 Sep 2007
Posts: 605

PostPosted: Sat Nov 03, 2007 5:30 pm   
 
I made uninstall first, after that install CMUD in the same directory
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sat Nov 03, 2007 5:33 pm   
 
I am using the regular version. Having seen this mentioned I did a CTRL-Q test with 2.09 and noted the times. Next I renamed the 1 folder of packages that I have been working with. I did an uninstall of 2.09 and then deleted everything else. 2.10 was installed to the same directory, which contained only the 1 directory of backed up files. My next step was to backup the default.pkg in case of troubles, and so I can verify timestamps. The first launch done by the installer included all the inital update steps, and import of sessions from zMud in the CMud sessions.db. I then pressed ESC at the sessions window I began a CTRL-Q test. I retested it enough times using launch , ESC, CTRL-Q to say that there is a general slowdown.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Nov 03, 2007 5:37 pm   
 
Hmm, nevermind, now I see the problem too. Maybe some sort of debugging is still enabled. I didn't see the slowdown when running my development version from Delphi, but when I downloaded and installed the released version, then I see the slowdown. I have no idea what changed to cause this, but at least I can reproduce it now.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sat Nov 03, 2007 5:44 pm   
 
Oh, doh!

OK, the problem with the Ctrl-Q test is that when I was doing the thread testing, I changed how the Ctrl-Q test works. In previous versions, it sent the entire Ctrl-Q buffer to the screen at once. In 2.10 it sends it line by line. That's why Ctrl-Q is slower in 2.10.

This doesn't explain the slowdown's originally reported by oldguy2, so I don't know what is wrong with his scripts. My guess is that he has some kind of other triggers or scripts that are running and slowing things down.

In any case, please do your speed testing in CMUD 2.10 using the %secs function and *not* with Ctrl-Q. I'll restore the previous Ctrl-Q procedure in the next update so that we can compare apples to apples.

So, please continue testing 2.10. It is *not* corrupted as far as I can tell. Sorry the Ctrl-Q thing was a red herring and caused all of this confusion.
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Sat Nov 03, 2007 6:39 pm   
 
Nothing else was running. Thats the time it took for CMUD to get from the first line to the last line of the commands in that alias. All I did was execute the alias offline, and then I logged in and did it online. I did use %secs as I stated and as you can see even if another script was running that is a ridiculous amount of time.

See I don't understand how it can be something I am doing. It's ONE alias! There is not even any complicated scripts in it. All it does is send about 20 lines of text in a row to the screen. I logged in hit that alias and recorded the time it took and logged out.

Again, if there is this much of a change between 1.34 and 2.0+ multi-threaded versions then CMUD just got worse not better. How can it jump from around 76 ms to over 686 ms just to send around 20 lines of text? The ONLY thing that would have been running is my OnPrompt event. I will disable that and try it again, but still I have the same OnPrompt event firing in 1.34 on every prompt and it didn't bother the speed at all. So what is the difference and why am I going from 76 to 686?
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sat Nov 03, 2007 6:50 pm   
 
When someone reports a bug that nobody else has seen (and since all the reports but yours refer to Ctrl+Q, that seems like a fair assumption), it's normally a safe bet that it's something that one person has done. That doesn't mean that it always is, but it's best to work from highest probability to lowest when suggesting causes of a problem.

So, with that said, by "nothing running" do you mean that your package was completely empty apart from this one alias, that you had disabled all other aliases and triggers, that you had disabled triggers using the gun icon on the command line, or what?

As an addendum, to your edited post (I wrote this post before you edited it, but forgot to click submit):

Quote:
Again, if there is this much of a change between 1.34 and 2.0+ multi-threaded versions then CMUD just got worse not better. How can it jump from around 76 ms to over 686 ms just to send around 20 lines of text? What is the difference and why am I going from 76 to 686?

These are all questions that we want to answer as well - and we certainly agree that it's going to be a sucky program if it responds like that for everyone. But so far, we haven't been able to reproduce the bug, which means Zugg can't fix it. So the only way it's going to get fixed is if there's more information about exactly what's causing the problem - since you're the only person who's experiencing the problem, only you can help.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Sat Nov 03, 2007 7:05 pm   
 
Zugg has the same exact package I am talking about from where I sent it the last time I posted here. I showed you the times above. I explained the problem. Why would a few scripts running cause that much of a delay? It's just like if you entered 20 short lines of text in the command line and hit enter. I don't care if I had 10 scripts running, it should not take almost 700ms to complete that task of sending those 20 short lines. I do not have this problem with 1.34 at all. ALL of my scripts execute this much SLOWER.

Another example is that I have a little script to sort all of my vials. It will loop through two different stringlists and send to put those vials into a pack in order and then it loops through those lists again and takes them out of the pack in order. In 1.34 it executes so fast I can barely see it going by on the screen because this is around 100 or so vials. In 2.10 it is like I am writing line by line out by hand onto the screen...

So again what would cause this problem? Is a thread getting stuck? What is it? I would appreciate some sort of answer rather than a pointing finger. By the way, I first mentioned the Ctrl+Q so yes mine did mention it. I'm just sorry that is what everyone jumped on. I know some of you must have an OnPrompt even firing that contains other aliases and things. No one else has this problem at all??????
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sat Nov 03, 2007 7:15 pm   
 
Oldguy2, your original post mentions CTRL-Q, that is why a number of us tested that. It is a standard test that we all can do without your packages in front of us, and without connecting to a specific mud. Once Zugg found what was going on there we can move on to doing tests similar to the other you described.

For this particular test I used the untitled session. I created an alias with your list of commands and 2 other lines, making the contents of the alias
Code:
#VAR $t1 {%secs}
inr all ash
inr all bayberry
inr all bellwort
inr all bloodroot
inr all cohosh
inr all ginseng
inr all goldenseal
inr all hawthorn
inr all kelp
inr all kola
inr all lobelia
inr all echinacea
inr all moss
inr all pear
inr all sileris
inr all skullcap
inr all elm
inr all valerian
inr all myrrh
#SHOW (%secs-$t1)

This test showed me numbers in the range of 30ms each time I ran the alias.

Next I created a command input trigger
Code:
#ONINPUT {^inr *} {}
Now the alias would display times in the range of 60ms. This makes it a little closer to your original report of 76ms, but then system specifications and all that could cause a large difference. I haven't even come close to online testing yet. Also I have a number of other things to take care, and my normal barrage of import tests to see if any new bugs got exposed or created. If no one else finds anything first, then I will make every effort to revisit testing this.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sat Nov 03, 2007 7:48 pm   
 
I tried this both offline and on before my first post and got 30ms both times. I tried again just now just to make sure, and it's still the same.

Try creating a new session that connects to the same MUD and try running this alias with a fresh package loaded, offline and on. That'll help us determine if it's specific to your package - if you give the name, Zugg will be able to take a look with that package loaded and see if it's the culprit, too.

I'm sorry if you took my post to be some kind of insult - far from it, if anything I should be thanking you for taking the time to test and report bugs, and I am: thankyou for taking the time to report this very serious problem. Fact of the matter is that, given that nobody else has seen your problem, it's very likely that there's something specific about your setup that makes you suseptible to this problem and nobody else. Whether it's a setting that's not compiling because of a bug, something that was corrupted by an earlier beta version that this version is more sensitive to, or whatever, it's very likely to be something on your system that causes the problem. That's why I'm asking you to provide more information about how to cause the error.

You ask "what would cause this problem?" - the answer is we don't know. If we did, it wouldn't be a bug, it'd be an ex-bug. The whole idea of doing more testing is to find out the cause so that the bug can be reproduced and fixed.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Arde
Enchanter


Joined: 09 Sep 2007
Posts: 605

PostPosted: Sat Nov 03, 2007 8:22 pm   
 
First Vijilante script runs offline at 11ms and I did not notice any changes with additional command input trigger - the same 11ms
_________________
My personal bug|wish list:
-Wrong Priority when copy-paste setting
-1 prompt trigger for Mapper, Session and General Options, not 3 different!
-#SECTION can terminate threads
-Buttons can't start threads
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Sun Nov 04, 2007 1:10 am   
 
Okay...I am running Windows XP Professional with an AMD Athlon 64 3800+ CPU and 1 GB of RAM.

I got online a second ago and went through each class folder one by one disabling them and then ran the aforementioned alias each time. Each time the time dropped significantly around 50 ms or so. However, even after disabling ALL of the class folders, meaning EVERYTHING, and just having this TEST alias as the only thing not disabled, it still came up with a time of 200 ms to enter those few commands. This means I had absolutely NOTHING running. However, when I disable the all triggers by clicking the little gun that drops down to around 40 ms. Offline the time is 26 ms with everything disabled.

Therefore, I can't see how it is anything that I have done. It's just flat out slow as hell while connected. Also since none of those triggers are ONINPUT, why does disabling them decrease the time? Sorry but I am not a GURU here. Why would it loop through everything or whatever it is doing to add all of this time in just sending a few commands through an alias that has nothing to do with text being received but instead being transmitted.

Edit: Oh yeah and let me add to this. The same thing happens OFFLINE as well. When I said the time offline was 26 ms I meant that was with triggers disabled by clicking the little gun. When I unclick it and enable triggers the time shoots up 11ms to 37 ms. That's crazy. It shouldn't take but 2 ms to send 15 lines of small text.
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sun Nov 04, 2007 1:45 am   
 
To explain the difference between the gun icon and just having everything disabled, you need meerly count your total number of triggers. For some reason which I will get to, they all are getting looked at for the enabled state with each of those commands.

I am going to assume that your package can trace its origin to a .mud file. zMud used to have some weird preference options that are not accessible through the GUI in CMud. One of those was the Trigger on Commands, I am going to guess you had it on in zMud. This is of course no longer necessary with Command Input triggers. Enter at the command line
Code:
#SHOW %pref(TriggerCom,0)
If it displays a 1 then you had that on and your time should now be improved.

Next look at your total number of aliases, 'inr' has to be checked against all of them everytime. You can again improve your speed by changing your alias to use #SEND
Code:
#SEND {inr all cohosh}
#SEND {inr all ginseng}
#SEND {inr all goldenseal}
#SEND {inr all hawthorn}
Once that is done your aliases won't be checked.

Both of those improvements should have an effect in version 1.34 as well as 2.10. Neither comes any wheres near explaining the vast disparity you are seeing between online and offline usage. I would suggest making those changes to get the best basic speed gain, testing off line again, then going online and testing again. Once you see the large time enter at the command line
Code:
#THREAD
Assuming you are not in combat or anything else at the time you should see very little reported by #THREAD. Let us know what you find, because I can't replicate this any of my files which contain similar aliases and macros.
_________________
The only good questions are the ones we have never answered before.
Search the Forums

Last edited by Vijilante on Sun Nov 04, 2007 1:48 am; edited 2 times in total
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Sun Nov 04, 2007 1:46 am   
 
Same test in version 1.34. Everything is disabled but this one test alias.

Offline

31 ms

0 ms when triggers are disabled by clicking the gun



Online

31 ms

15 ms when triggers are disabled by clicking the gun

Oh and you assumed wrong. I created this package from scratch in 1.34. Also "inr" is not an alias. The line of text "inr all bloodroot" is just that...a line of text. The alias that I put all of these lines of text in is called TEST for this purpose.

Basically I could send 15 or 20 other lines of random text as well. I could send 20 lines of "This is a test" with the alias as well. It's a single alias that is sending 15 or 20 lines of text to the MUD. I really don't understand what you are talking about with this multiple aliases.

This is the same EXACT package by the way. So the question is, what has changed between 1.34 to 2.10 to make it this slow?

Also just to make sure you believe me. I entered your #SHOW %pref(TriggerCom,0) into the command line and the result was 0.

Edit: By the way, I just tested with your #send suggestion and in 1.34 both with and without the triggers being disabled by clicking the gun the time is 0 ms which is awesome. I just cannot understand what the problem is with 2.10 version and why it is so horribly slow both offline and super slow online. It's not my package. I also enabled all the class folders in 1.34 and did the same test and again the results are 0 ms and 0 ms...that is with everything in the package enabled meaning all triggers, aliases, variables, classes, and so on.
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Sun Nov 04, 2007 2:16 am   
 
Fang Xianfu wrote:
I tried this both offline and on before my first post and got 30ms both times. I tried again just now just to make sure, and it's still the same.

Try creating a new session that connects to the same MUD and try running this alias with a fresh package loaded, offline and on. That'll help us determine if it's specific to your package - if you give the name, Zugg will be able to take a look with that package loaded and see if it's the culprit, too.

I'm sorry if you took my post to be some kind of insult - far from it, if anything I should be thanking you for taking the time to test and report bugs, and I am: thankyou for taking the time to report this very serious problem. Fact of the matter is that, given that nobody else has seen your problem, it's very likely that there's something specific about your setup that makes you suseptible to this problem and nobody else. Whether it's a setting that's not compiling because of a bug, something that was corrupted by an earlier beta version that this version is more sensitive to, or whatever, it's very likely to be something on your system that causes the problem. That's why I'm asking you to provide more information about how to cause the error.

You ask "what would cause this problem?" - the answer is we don't know. If we did, it wouldn't be a bug, it'd be an ex-bug. The whole idea of doing more testing is to find out the cause so that the bug can be reproduced and fixed.


Here is the problem with your test. You are not doing it with multiple other classes and things in your package. Try doing the same test where all variables are somewhat equal. Just creating a new session with a single alias is not going to show the difference in speed issues when the package doesn't also contain 20 other class folders full of triggers, aliases, and variables. I really don't see the point of doing what you ask. If you look at my post above I get 0 ms for online and offline in 1.34 to execute the same alias! In both instances I have the same package, containing the same amount of class folders, triggers, and so on. You can say it is specific to my package but I cannot see how! I don't care if I had 500 class folders full of the same trigger and a couple other aliases and disabled them all and just ran this one TEST alias, what is going to be the difference? This is a speed issue and a serious one in my opinion. If everything is disabled how can it be my scripts causing the problem? None of them are running. I'm really not trying to argue here. I am just trying to point out that if all I had was a single alias that sent these 15 or 20 lines of text I am sure our results would be identical. It is when you add many other classes and triggers to the mix that the problem arises in a tremendous loss of speed in 2.10 that does not exist in 1.34. This is what I don't understand. I'm sorry I am not an expert programmer. This is just a hobby. I can only look at it from a common sense point of view and all things being equal 2.10 is a turtle compared to 1.34.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Sun Nov 04, 2007 3:50 am   
 
oldguy2, how fast is using #SEND in 2.10?
Reply with quote
Vijilante
SubAdmin


Joined: 18 Nov 2001
Posts: 5182

PostPosted: Sun Nov 04, 2007 3:53 am   
 
Since we can't replicate, even with are own very large packages of settings, and just in case it never quite connected for you before both Fang and I play on Achaea as well; we have to rely on you to make all the test. Doing the offline and untitled session test just establishes a baseline. A comparative test with 1.34 doesn't help to make a baseline.

Since you were kind enough to post your system specs, and did a similar baseline test we can move on. Eliminating possiblities from the cause of a problem helps. It may sound crazy, but even trying and eliminating ludicrous possibilties is helpful.

Towards that end:
Did you check #THREAD, as requested, to assure that no other script got hung?

Do you have alarms that might be active at any point in any of these tests, or before you have a chance to execute the alias online?

You mentioned trying #SEND with 1.34, did you try it with 2.10? What effect did it have?

Did you try filling the scrollback buffer prior to going online to make sure it is not a scrolling issue?

Did you turn off triggers prior to login, login manually with #CH and #PW, then test your alias to make sure no other script ever ran?

Did you try copying your package file, launching up the session, deleting all other settings in your package, then running the test alias? You can delete the one and rename the copy when your done, just make sure to get the filename right.

Does it take just as long if you execute the contents of the alias from the command line?

Does it take just as long if done from a macro instead of an alias?

How about an #ALARM, did you put the code into an expiring alarm to test it?

Final question...will you please try everything I just asked about and report back? Those are the kinds of tests I would be doing if I had this problem with my settings. I might not do them in that order; but I can't say which, if any, should be skipped without knowing the results of some of them.
_________________
The only good questions are the ones we have never answered before.
Search the Forums
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Sun Nov 04, 2007 4:00 am   
 
Vijilante wrote:
Next look at your total number of aliases, 'inr' has to be checked against all of them everytime. You can again improve your speed by changing your alias to use #SEND
Code:
#SEND {inr all cohosh}
#SEND {inr all ginseng}
#SEND {inr all goldenseal}
#SEND {inr all hawthorn}
Once that is done your aliases won't be checked.

What Vijilante meant by this is not related to whether or not you have an alias called 'inr'. It's the fact that when commands are sent to the mud (not using #SEND), there are a number of things that occur (I'm not too sure on the order though):
1. testing to see if the text to be sent matches any ONINPUT trigger (but you say that you have none).
2. testing to see if the first word matches the name of any enabled alias - that might mean two checks - one to see if it matches an alias, and another to see if the alias is enabled.

The reason disabling classes causes a speed improvement is probably down to less aliases being enabled that need to be checked against what is being sent to the mud. Not sure about why it gets better when disabling all triggers though, since an alias is not a trigger. Using #SEND bypasses #1 and #2 above, hence much faster. Anyway, it does look like you might have found one or two areas in which some optimizations need to be investigated by Zugg, but it would be useful it we can narrow them down more first.
Reply with quote
oldguy2
Wizard


Joined: 17 Jun 2006
Posts: 1201

PostPosted: Sun Nov 04, 2007 4:27 am   
 
Well I can answer you Seb right now that none of the above are true. I have no aliases that match those words and none of it matches an oninput trigger. I also disabled all class folders containing everything before going online.

I will reinstall 2.10 and check again, if I can keep people from trying to kill me 5 seconds after I log in. I guess I can go create a whole new character.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net