Accuracy is usually more important when tracking and curing things, but speed is always an issue. My Achaean script is so slow in zMUD that I sometimes die just to my own lag, so yeah, speed matters.

Actually, that trick with aliases sounds useful. Though I think it makes sense mainly if you are heavily using plugins, since you can direct the alias to any language. Which brings up a question: what does that "afflicted *" alias do when it matches - calls a script, automatically sets a variable?

For right now, my aliases mostly call a script method. I still hadn't decided if I wanted to try and convert my scripts/triggers to plugins, so I figured that if I made most of it interface with aliases that I'd be able to more easily switch later.

I've found that Plugins can cause alot of problems and are harder to manipulate once in, I try and stay away from them now.

I just didn't like having to reload my plugins when I was actively developing and debugging them. It's also a bit of a pain to communicate between plugins and can get more complex when you try to mix and match languages. I'm sticking with script modules and XML include files for now (sort of like pseudo-plugins).

THe only reason I don't switch to MUSH is because it's inbuilt scripting functions and whatnot can't do the job to well on their own. ZMUD does that schtuff better. Also, why do people switch to MUSH for VB? ZMUD does VB and whatnot. I also have another problem with MUSH. Whenever I'd load plugins they wouldn't be edittable through the MUSH windows, only through the text thing, that erked me that theyw ouldn't both be open for my viewing in one source. Hrm, I also suppose having to learn an entire programming language versus something developed for this is another daunting task

All this bitching was posted so that people could clarify it for me

The reason people swtich from Zmud to Mushclient is for a faster system and one actually written in a real code instead of some half-assed one like Zmud. Also, I don't like Plugins, as others seem to agree, don't use them.

Exactly. What Ethelon said. Plugins generally aren't the best way to do things, as they're a pain to update and reload. zMUD's built-in scripting is weak compared to the likes of MUSHclient and its support of other languages is almost non-existent. Try making a source module that you can load into zMUD and call a subroutine from it. You'd have an easier time writing a COM library in C++ and linking that into zMUD.

Depending on your interest in coding, speed is certainly an issue. There's a huge speed difference between ZMud and MUSHclient. Faster means you can have more thorough and potent scripts.

Damn. Makes me feel like my system's worthless...

Or, get a better comp and run ZMUD.

I don't see the difference between reloading the main script and a plugin, it's just two extra clicks, but that's nothing considering that you don't update things THAT much. And as for updating plugins - I find it much easier to change the code that is well isolated than a huge script file. Most systems that I write I put into plugins first, even if I intend to move them to the main script later on, this is because doing it in a plugin allows me to isolate the script and all client stuff (triggers, aliases, etc) that go along with that script and reload them without affecting anything else. This also helps when a sudden bug pops up in the middle of a fight - if you've modularized your system well enough through plugins you can simply world.ReloadPlugin or world.EnablePlugin to get rid of the bug and you get to keep the rest of functionality. Of course, writing a combat system as a collection of plugins in anything other than Python is a real pain, since there's no easy way to exchange information and call procedures between plugins, but then again, ever since I learned Python I've never had an urge to use anything else, heh.

Personally, I wouldn't run Zmud even if someone paid me to do it. It's not even that it's slow, or has excesive visual clutter, or messed up my keyboard the first several times I tried it, my main problem with it is it's scripting language, which I find absolutely incomprehensible.

It's easy to script in

I don't use plugins, and I don't have all my script in one file. I have my main script file just include other files. I've even organized them into directories, based on IRE-common stuff and then stuff for each specific game. I tried the Python way of making world-Singleton objects to communicate between plugins, and it was painful enough that I wanted to have everything just share the same memory space instead.

Hmm, how was it painful?

It's simple to do simple things. It's darned near impossible to do anything beyond the basics. Try making multi-line triggers or setting up failsafes or anything else complex enough to require a real scripting language. zMUD falls short in the evaluation speed, and it's got almost nothing to do with PC speed. I can run zMUD on my dual P4 3.2GHz with 2GB RAM and it's still not faster than MUSHclient on a P3 866Mhz with 512MB RAM.

You're all looking deeper in this than necessary.

It's like getting 5GB RAM to play space invaders.

Unnecessary.

I'm a coding noob and I manage to fight as well as anybody. Right?

yes but you have skill.

If you gave your system to somebody else they would die many many times.

They are trying to make systems that overcome thier lack of skill.

It's more painful to script in Python, in my opinion, simply because I have to preface so many things with "world." to make them work. When you add in the fact that you have to pass in your world variable to every class you use, you now have to do "self.World." (or something similar, depending on what you call the member variable). I had to make use of complex metaclass instances and shuttle data back and forth between plugins with these complex methods. Just looking at the code gave me a headache and then trying to decide the behavior of each plugin and how to keep them separate was more than I wanted to do, at least until I know more about all the MUSHclient scripting.

Basically, the boundaries between plugins isn't always cut-and-dried. Sometimes you'd like to mark a defense down when you see an affliction, but do you want the afflictions plugin to know about your defenses? Do you duplicate triggers and use sequences to take care of it? Are your triggers included with the script in the plugin or do you just slap the triggers, aliases, and everything besides scripts into your main world settings file?

There are just so many options in MUSHclient that it can be confusing. It's flexible and powerful, but confusing just the same.