Simimi2007-05-08 02:27:51
Well, with the open-sourcing of MUSH client, and a group already working on trying to port it to native *nix this is a good time for mud clients. My current main question is, which client produces the faster code, in terms of being in combat, and your system not lagging, or lagging the least... Mush or Zmud?
-Assume the code has not been fine tuned.
-Assume the Mush client user is using Lua, and the Zmud user is not using the #WAIT operand.
-Assume the person is using triggers on/off, so they only have groups on that are for pvp, when pvp occurs.
What do you all think? Is there really a speed difference? I have heard some people say yes there are some speed differences (noticeable) and some say you wouldn't notice.
So, given all of the above, debate; for my personal amusement and knowledge, what you think.
If you so choose, add TinyFugue into this, but I am not sure that it has a timer function...
love,mimi
-Assume the code has not been fine tuned.
-Assume the Mush client user is using Lua, and the Zmud user is not using the #WAIT operand.
-Assume the person is using triggers on/off, so they only have groups on that are for pvp, when pvp occurs.
What do you all think? Is there really a speed difference? I have heard some people say yes there are some speed differences (noticeable) and some say you wouldn't notice.
So, given all of the above, debate; for my personal amusement and knowledge, what you think.
If you so choose, add TinyFugue into this, but I am not sure that it has a timer function...
love,mimi
Hazar2007-05-08 02:32:36
Also consider CMUD.
Simimi2007-05-08 02:36:16
Well I was not considering Cmud since I do not have it, but this is your alls discussion, so include it if you want. =P Some debating would be cool though >_>
love,mimi
love,mimi
Arundor2007-05-08 02:50:48
I don't know about CMUD, but MUSHClient is faster than zMUD.
For comparison, MUSHClient benchmarks: http://www.gammon.com.au/mushclient/benchmarks.htm
And zMUD benchmarks: http://www.zuggsoft.com/zmud/bench2.htm
For comparison, MUSHClient benchmarks: http://www.gammon.com.au/mushclient/benchmarks.htm
And zMUD benchmarks: http://www.zuggsoft.com/zmud/bench2.htm
Simimi2007-05-08 02:58:32
Well the Mush tests are hella old, but it looks like the Zmud tests are rathr dated as well. I guess the Mush assumes Lua then?
Arundor2007-05-08 06:31:24
The MUSHClient tests were in VBScript. Lua would likely be faster.
Unknown2007-05-08 11:15:51
MUSHclient is faster than zMUD, especially with Lua.
CMUD is faster than zMUD, though not quite as stable yet.
Coding in zMUD/CMUD is simpler, but not as robust as MUSHclient.
There are definitely things I love about each client, but I choose zMUD still for its GUI features and ease of maintenance. Distributing MUSHclient scripts can be a real pain in the .
CMUD is faster than zMUD, though not quite as stable yet.
Coding in zMUD/CMUD is simpler, but not as robust as MUSHclient.
There are definitely things I love about each client, but I choose zMUD still for its GUI features and ease of maintenance. Distributing MUSHclient scripts can be a real pain in the .
Unknown2007-05-08 13:30:20
From what I've heard, MUSH Client is indeed very fast. (Considering it is written in C++). That being said, the fact that it has a GUI will probably make it slower than TF. By sacrificing a GUI, I think TF gets a slight edge in speed. And from my experience, I have yet to find a client that runs and processes faster than TF. Although I have not tried MUSH Client yet, I'd also like to give it a whirl when it's successfully ported as it supports programming in Python.
Unknown2007-05-08 13:33:07
Oh sweet. I just discovered MUSH Client supports Ruby now. This now makes an object oriented system a possibility. Very tempted to switch over now.
Unknown2007-05-08 13:42:50
Holy smokes. So I just downloaded the recently released MUSHClient 4.07 and ran it under Wine. It is just as fast as TF. Now, if the speed keeps up with a full-written system loaded on top of it, I think I'll be switching to MUSHClient. Although I do miss the terminal interface that TF provides, being able to code in Ruby or Python may be worth it...
Unknown2007-05-08 14:13:36
MUSHClient definitely benchmarks faster. I personally still prefer to use zMUD, because (like Zarquan says) it's easier to edit, and my laptop is toward the higher end (dual core, 2gb ram) so I never notice a slowdown either way. The real reason is most likely that I'm just more comfortable with zMUD, I've been using it since I started text MUDs several years ago.
So, when it comes to benchmarks and tests, MUSClient is definitely faster, especially if you use Lua. However, I've never actually noticed a functional difference between the two in real-world (well, made-up RPG-world) scenarios.
So, when it comes to benchmarks and tests, MUSClient is definitely faster, especially if you use Lua. However, I've never actually noticed a functional difference between the two in real-world (well, made-up RPG-world) scenarios.
Simimi2007-05-08 17:05:22
Hmm this is all great info, thanks everyone! I just have a lot of trouble with the TF scripting, I may give it another go though at some point. I am slowly collecting data for making a system to keep me a live, and auto flee like the little sissy that I am.
Does TF have a timer ability, to time things, like angel attack or demesne timing?
Does TF have a timer ability, to time things, like angel attack or demesne timing?
Unknown2007-05-08 21:56:15
There's a couple ways to do timers in TF. For example:
/repeat -0:30 1 /echo Dinner's ready
This will echo "Dinner's ready" in 30 minutes.
Or, you can do:
/time %@
Which will return the raw system time in seconds, to the nearest microsecond. Just do something like:
The above will echo Tick Tock (a lot of times) until 3 seconds are up.
All of this information is very easily accessible in the TF documentation. All I did was:
/help repeat
/help ftime
/help while
And I had all the necessary information to come up with the above. TF has good documentation. Use it to your advantage.
/repeat -0:30 1 /echo Dinner's ready
This will echo "Dinner's ready" in 30 minutes.
Or, you can do:
/time %@
Which will return the raw system time in seconds, to the nearest microsecond. Just do something like:
CODE
/def timer = \\
    /let startTime=/time %@ %; \\
    /let currentTime=startTime %; \\
    /while (currentTime - startTime <= 3) \\
        /echo Tick Tock %; \\
        /let currentTime=/time %@  %; \\
    /done
    /let startTime=/time %@ %; \\
    /let currentTime=startTime %; \\
    /while (currentTime - startTime <= 3) \\
        /echo Tick Tock %; \\
        /let currentTime=/time %@  %; \\
    /done
The above will echo Tick Tock (a lot of times) until 3 seconds are up.
All of this information is very easily accessible in the TF documentation. All I did was:
/help repeat
/help ftime
/help while
And I had all the necessary information to come up with the above. TF has good documentation. Use it to your advantage.
Simimi2007-05-09 04:01:50
Hmm... true TF -does- have good documentation... I actually really like tintin++ a lot. I wonder if it would work for a Lusternia system. I guess the thing to do now would be to just try them all and see how they work for me. Though, wish MUSH going to *nix soon (I hope), it may be down to two, since I am not in windows too often.
As far as TF goes, it is pretty easy to find things when you go into it knowing what you are looking for, my issue is I do not understand TF scripting language, and usually do not mentally see how A=B. Like speedwalking? Would you just nest a huge list of directions in with a wait function for each one? The HORROR!
love,mimi
EDIT: So no one has noticed any real ingame slowdown based on client? Like, deaths from client-lag are not really a prevelent issue?
EDIT2: Bah! I have been meaning to ask this for a while. Which is the better practice...
In MUSH- putting as much as possible in the external script file? OR Having a trigger line for an affliction, and putting the if statements and such in the box below the trigger line?
In ZMUD- same as above, externally loading script (can you?) OR having the triggers evaluate everything in their own little space as to what the trigger responds to.
As far as TF goes, it is pretty easy to find things when you go into it knowing what you are looking for, my issue is I do not understand TF scripting language, and usually do not mentally see how A=B. Like speedwalking? Would you just nest a huge list of directions in with a wait function for each one? The HORROR!
love,mimi
EDIT: So no one has noticed any real ingame slowdown based on client? Like, deaths from client-lag are not really a prevelent issue?
EDIT2: Bah! I have been meaning to ask this for a while. Which is the better practice...
In MUSH- putting as much as possible in the external script file? OR Having a trigger line for an affliction, and putting the if statements and such in the box below the trigger line?
In ZMUD- same as above, externally loading script (can you?) OR having the triggers evaluate everything in their own little space as to what the trigger responds to.
Unknown2007-05-09 13:05:31
In MUSHclient, I would recommend putting your functions in an external script file and calling those functions from your triggers/aliases. It's just easier to maintain, in my opinion. It makes no real speed difference either way, since MUSHclient compiles all the script code together as one piece.
In zMUD, you can't have an external script running dynamically. I develop my scripts as text files and then import them into my settings, which I highly recommend for purposes of backup and maintenance.
Lag in zMUD has gotten me killed several times, but I still find it difficult to switch to another client due to lack of free time for reimplementing all the stuff I've built in zMUD over the last couple years. (Stupid GA/EOR trigger bug.)
In zMUD, you can't have an external script running dynamically. I develop my scripts as text files and then import them into my settings, which I highly recommend for purposes of backup and maintenance.
Lag in zMUD has gotten me killed several times, but I still find it difficult to switch to another client due to lack of free time for reimplementing all the stuff I've built in zMUD over the last couple years. (Stupid GA/EOR trigger bug.)
Unknown2007-05-09 15:33:31
Mimi, a speedwalking is very easy, and it doesn't come close to being a HORROR. Try to stick to the DRY principle - Don't Repeat Yourself. Hardcoding a Nested set of directions with wait functions every time is inefficient. Be a little more abstract. Do something like this:
So if you do /speedwalk path_nexus, it will automatically walk in the direction specified in the variable path_nexus.
The only thing I don't like about TF is that it's library is not very powerful. I found myself re-inventing the wheel a number of times simply because TF's language doesn't support the common functions you see in programming languages today.
CODE
# Assume the function /timer will pause for "args" seconds.
# Also note that I just made this function on the fly. Theoretically it should work, but there may be some conflict between the speedwalk and timer functions. I haven't tested it.
/set path_nexus=s w w w e n d w s n n e w nw se nw
/def speedwalk = \\
    /if ( {#} == 1) \\
        /let path=%%{%{1}} %; \\
        /while ( {path} !~ "") \\
            /send $(/pop path) %; \\
            /timer 0.5 %; \\
        /done %; \\
    /endif
# Also note that I just made this function on the fly. Theoretically it should work, but there may be some conflict between the speedwalk and timer functions. I haven't tested it.
/set path_nexus=s w w w e n d w s n n e w nw se nw
/def speedwalk = \\
    /if ( {#} == 1) \\
        /let path=%%{%{1}} %; \\
        /while ( {path} !~ "") \\
            /send $(/pop path) %; \\
            /timer 0.5 %; \\
        /done %; \\
    /endif
So if you do /speedwalk path_nexus, it will automatically walk in the direction specified in the variable path_nexus.
The only thing I don't like about TF is that it's library is not very powerful. I found myself re-inventing the wheel a number of times simply because TF's language doesn't support the common functions you see in programming languages today.
Simimi2007-05-09 22:03:20
I agree with the lack of power with TF bakakaba. Well, thanks so much for everything, Hopefully I will have something to post for critique soon enough!
love,mimi
love,mimi