Shorlen2007-01-11 07:23:23
When a lot is happening, like when multiple people at attacking me, or I'm getting hit by a druidic meld while the druid is hitting me, my system shuts down. I can't even send commands at all, zMUD just locks up. Triggers start firing 5-10 seconds late, so I'm handling the warrior hit that happened three hits ago, etc...
My question is, is the problem primarily my slow computer, my trigger setup, zMUD being zMUD, the fact that I have 80 running processes open right now, or what? What is the first step to take to reduce all this lag? Are complete (match every line exactly) triggers faster or slower than ones that match a tiny unique phrase?
My question is, is the problem primarily my slow computer, my trigger setup, zMUD being zMUD, the fact that I have 80 running processes open right now, or what? What is the first step to take to reduce all this lag? Are complete (match every line exactly) triggers faster or slower than ones that match a tiny unique phrase?
Richter2007-01-11 08:15:09
I have/had the exact same problem, when I'd go bashing with a large group, my commands would hit after everyone had killed the thing, I couldn't input commands, it'd freeze ZMUD, etc. It got a bit better when I wiped my computer, and now I'm running 20 less processes at once. Though, I still think it's the tremendous amount of things happening at once in ZMUD (it captures pretty much everything into something, and there's so many triggers).
Mogg2007-01-11 08:19:19
It's a combination of the way zmud parses information and the speed of your PC. It would be a lot of re-coding, but I would recommend you switch to MM2k if you have a slower computer. Not quite zscript, but it definitely has an easy language to write in and is muuuuch faster than zmud.
Lysandus2007-01-11 08:19:21
During the recend raids of Mag on Water, as soon as Malicia moves, everything hangs up and by the time it returns, I either got 3/4 health left or dead.
Unknown2007-01-11 12:55:54
My zMUD has a ton of settings, but it manages to keep up as well as can be expected with all the spam. I'm not able to cure all the afflictions with five people attacking just me and get away, but I don't see delays in the commands being sent, and I can stay alive a surprisingly long time in such a situation.
- Disable triggers when not needed, such as diagnose lines, wounds messages, etc.
- Anchor your triggers, especially at the beginning (^blah). This speeds up trigger evaluation by quite a lot, in my experience.
- Optimize loops to run as few iterations as possible, even changing the logic around where applicable. For example, I used to loop on all possible herb afflictions in a priority list until I found a match with an affliction I actually had. Now, I loop over my afflictions until I find one that can be cured by an herb. The assumption (or hope) is that my number of current afflictions is less than all possible herb-cured afflictions.
- Reduce the nesting levels of alias or function calls, if applicable. Calling an alias from an alias from an alias... can be a very slow expansion, especially when it's an expanding tree calling multiple aliases at each level.
- Put loops or lengthy bits of code inside #PRIORITY blocks to ensure that zMUD finishes executing your script before moving on. Very important in more situations than you'd think.
Shorlen2007-01-11 13:57:22
When are the times you *don't* want to use priority? I was worried that it would make my system hang *more*, so I refrained from using it.
Rylan2007-01-11 14:44:50
I haven't used ZMUD in years, and even when I did, I can't say I really knew how to script/trigger on anything, but it does sound like you're hitting a performance peak somewhere, and i'ts probably a combination of all the things you have listed.
If you want performance, I'd recommend tintin++. Not as pretty as ZMUD as it's entirely console based, but ZMUD developed it's own commands from tintin's base years ago. It's very minimal and extremely fast. I'm working on a base free system for it, though it's probably still a month or so away from being ready for public consumption. Anyway, might be worth taking a peak: http://tintin.sf.net. Of course I also use Linux, so 90% of the external problems that you're having, are not issues for me anyway.
Hate to gloat, but it's good to be a nerd.
If you want performance, I'd recommend tintin++. Not as pretty as ZMUD as it's entirely console based, but ZMUD developed it's own commands from tintin's base years ago. It's very minimal and extremely fast. I'm working on a base free system for it, though it's probably still a month or so away from being ready for public consumption. Anyway, might be worth taking a peak: http://tintin.sf.net. Of course I also use Linux, so 90% of the external problems that you're having, are not issues for me anyway.
Hate to gloat, but it's good to be a nerd.
Unknown2007-01-11 15:15:00
This is one reason why I prefer MUSHclient to zMUD tremendously. I can put any amount of junk in my prompt trigger, make it call practically every script function I have, and I still don't notice any slowdown at all. I can introduce tons of redundant checks and focus on writing scripts that give optimal curing rather than optimal speed. Whereas it's really easy to make zMUD lag.
Shorlen2007-01-11 15:19:24
I'm a creature of habit - I could never switch clients.
Unknown2007-01-11 17:08:02
I will have to go with Zarquan. I have mostly used his systems in Lusternia (and in Achaea, for that matter), and the more recent versions of Palisade especially have caused no speed issues for me at all. I haven't even noticed a slow down, even in group fights. During dairuchi, I was running from Shamarah, Forren, Soll, and Vesar all at once, and managed to do well enough that they finally just gave up chasing me and went after someone else.
Granted, I do have a relatively fast computer (dual core, 2 gigs of ram), but disabling triggers when not needed, and anchoring the triggers which are needed can speed things up tremendously. Even in my own scripts and my attempts at writing systems it makes a difference.
Granted, I do have a relatively fast computer (dual core, 2 gigs of ram), but disabling triggers when not needed, and anchoring the triggers which are needed can speed things up tremendously. Even in my own scripts and my attempts at writing systems it makes a difference.
Laysus2007-01-11 17:23:38
Another important bit is that numerically intense operations and #if nests are generally quite slow. Where you can, use record vars as lookups instead.
And use permanent #alarms where possible (i.e. one that's always there and turned on and off with #t+/#t- as opposed to #alarm +4 {thing}), and avoid using #foralls and #loopdbs, even inside #priority statements.
And use permanent #alarms where possible (i.e. one that's always there and turned on and off with #t+/#t- as opposed to #alarm +4 {thing}), and avoid using #foralls and #loopdbs, even inside #priority statements.
Daganev2007-01-11 17:30:09
With all these theories I would justl ike to say , that if I look through listofferings too quickly, and spam it too fast, I lost my connection on Nexus entirely.
However, getting CMud should solve your problem.
However, getting CMud should solve your problem.
Unknown2007-01-11 18:11:45
Thanks, Laysus, for pointing out the tip about permanent alarms versus temporary ones. My system's reliability increased greatly when I did that myself a long time ago. I had forgotten about that one in my list.
As for #PRIORITY, it's really just a way to make zMUD stand up and act right. CMUD has obsoleted the use of #PRIORITY by just executing scripts the way they're supposed to be in the first place. Heh.
As for #PRIORITY, it's really just a way to make zMUD stand up and act right. CMUD has obsoleted the use of #PRIORITY by just executing scripts the way they're supposed to be in the first place. Heh.
Laysus2007-01-12 22:34:50
Yeah, #priority does improve things, I won't argue. But it still doesn't make things wonderful.
Unknown2007-01-13 05:23:57
Cmud seems to have a number of problems right now. Well for me the main one I saw was that #loopdb does not expand the commands used in it, but on the Zugg forums there were a number of complaints.
Acrune2007-01-13 07:32:11
I used to have that problem. I just closed trillian and firefox while playing (AIM too if I expected big fighting soon) until I got a new computer that can handle the system. Much easier then reprogramming.
Unknown2007-01-13 13:13:19
I haven't had a problem with #LOOPDB on CMUD, but if you want to execute something (like your %val from the other thread), you need to use #EXEC to force expansion of the command(s).
Forren2007-01-13 16:49:17
QUOTE(daganev @ Jan 11 2007, 12:30 PM) 372147
However, getting CMud should solve your problem.
It's too buggy right now.
Unknown2007-01-13 18:02:00
CMUD wont run on my computer. It crashes when I try to open it .
Unknown2007-01-14 03:05:46
If you're not running Windows XP, it'll do that to you.