Soll2007-01-14 14:16:27
Well. So very appalled with it, that I've uninstalled it for now. Maybe I'll try it again some other day. If there's someone who's managed to get cMUD working well, I'd really appreciate talking to them.
Unknown2007-01-14 16:16:02
Even though CMUD has been released as a public version, it's still not ready for prime time, in my opinion. I'm slowly converting scripts, but I'm not going to do the .mud conversion. I write everything as text files and import them, which I find works much better and gives me more control over fixing the problems like you saw.
I recommend waiting until Zugg returns from his (very long) vacation and fixes more of these bugs before seriously using CMUD as your client. It has great potential for speed and features, but it's just not there yet.
I recommend waiting until Zugg returns from his (very long) vacation and fixes more of these bugs before seriously using CMUD as your client. It has great potential for speed and features, but it's just not there yet.
Laysus2007-01-14 16:18:21
Apparently it's wonderful if you use events. Unfortunately, I can't find anything on how to use them in the helps.
Edit: Anyone who can tell me how they're best used would be much much liked.
Edit: Anyone who can tell me how they're best used would be much much liked.
Unknown2007-01-14 17:51:41
The first thing I did was use it for my prompt, and it passes the health, mana, ego, power, and flags to anyone listening for the event. I can then write separate packages for fun things like recklessness detection (combine an OnDamage event with OnPrompt) or a separate package for updating gauges with the values.
Events allow you to decouple your processing from the location where the event is signaled, meaning you can turn things on and off more easily, like sipping allheale or focusing your mind, by disabling the class or package where the processing of that event is done.
Events allow you to decouple your processing from the location where the event is signaled, meaning you can turn things on and off more easily, like sipping allheale or focusing your mind, by disabling the class or package where the processing of that event is done.
Soll2007-01-14 18:12:28
The packages thing really threw me off, too. Whenever I went into the editor, I had to do a lot of fiddling to find what I wanted to change. It was just a really painful experience. I spent about 2 hours on it, and accomplished nothing other than getting extremely frustrated at it.
Unknown2007-01-15 04:19:17
Ok, I have another Cmud problem to gripe about/ask Zarquan if he knows how to fix:
I have an alias called pipes that enables the pipes class and then uses pipelist. The pipes class gags all the text recieved from pipelist, and uses that info to automatically fill and light my pipes if they aren't already. Now, if I call the pipes alias from the command line, it works just fine, no problems. However, if I call it from a trigger, it doesn't enable the pipes class, only sends pipelist. Here's the code for it:
#alias pipes {#t+ lusternia|healing|pipes;pipelist}
#trigger {^Your pipe has gone cold and dark.$} {#gag 2;pipes}
class pipes:
#trigger {%dh, %dm} {#t- pipes}
#trigger {^@coltsfoot * &%wpherb %s %d %s &%wpstatus$} {#gag;#if @pherb="empty" {outr coltsfoot;put coltsfoot in @coltsfoot;light @coltsfoot} {#if @pstatus="Unlit" {light @coltsfoot}}}
//same trigger above only for myrtle and faeleaf instead, and the #gag triggers for the rest of the stuff
I can't figure out why the pipes alias doesn't work right when called from the trigger, and it really makes no sense at all!
I have an alias called pipes that enables the pipes class and then uses pipelist. The pipes class gags all the text recieved from pipelist, and uses that info to automatically fill and light my pipes if they aren't already. Now, if I call the pipes alias from the command line, it works just fine, no problems. However, if I call it from a trigger, it doesn't enable the pipes class, only sends pipelist. Here's the code for it:
CODE
#alias pipes {#t+ lusternia|healing|pipes;pipelist}
#trigger {^Your pipe has gone cold and dark.$} {#gag 2;pipes}
class pipes:
#trigger {%dh, %dm} {#t- pipes}
#trigger {^@coltsfoot * &%wpherb %s %d %s &%wpstatus$} {#gag;#if @pherb="empty" {outr coltsfoot;put coltsfoot in @coltsfoot;light @coltsfoot} {#if @pstatus="Unlit" {light @coltsfoot}}}
//same trigger above only for myrtle and faeleaf instead, and the #gag triggers for the rest of the stuff
I can't figure out why the pipes alias doesn't work right when called from the trigger, and it really makes no sense at all!
Unknown2007-01-15 19:22:46
My guess is that your #t- pipes is disabling your alias with that same name. Also, your prompt trigger should use the nocr and prompt options.
Unknown2007-01-16 17:32:06
Actually, it wasn't disabling the alias. I'm pretty sure it was that whenever I got "Your pipe has gone cold and dark" I also got the prompt with it, which disabled the pipes class, although I'm not sure that should be happening, since Cmud makes everything run like #priority.
I ended up keeping track of how many pipes went dark via variable, and lighting all three of them when they all went out. The disadvantage to that is that if I only receive the trigger text once or twice, it won't light them, so I need to use the pipes alias at that point, but it's not something I'm expecting to happen often.
I ended up keeping track of how many pipes went dark via variable, and lighting all three of them when they all went out. The disadvantage to that is that if I only receive the trigger text once or twice, it won't light them, so I need to use the pipes alias at that point, but it's not something I'm expecting to happen often.
Unknown2007-01-16 22:04:52
The alias thing was just a guess. The prompt advice, however, was not a guess. You should use the nocr|prompt options in your trigger, and it'll fire more reliably:
CODE
#trigger {^%dh, %dm} {#t- pipes} "" {nocr|prompt}
Catarin2007-01-16 22:47:15
Enabling and disabling of things in Cmud is sketchy at the moment. Sometimes it works, often times it doesn't. There are a LOT of bugs which may or may not be crippling depending on your style of scripting.
Carrying over zmud scripts is especially painful since cmud is a lot more strict on how you write things. For example if you said #IF {@blah = 0} {do blah} in zmud, it would work. If you say it in cmud, it won't. You have to use () rather than {} though brackets still work well enough for just a plain true statement like #IF {@blah} {do blah}.
I'm using cmud exclusively now and it's generally fine. I'm pretty sure the only reason I can do that is that I rewrote my scripts for cmud rather than trying to convert from zmud. Support of switch statements along with a real need to update and rewrite anyway made that a not so painful task. It's definitely much faster and there's a lot of potential. But it's probably not worth the headache right now unless you're really interested in it.
Carrying over zmud scripts is especially painful since cmud is a lot more strict on how you write things. For example if you said #IF {@blah = 0} {do blah} in zmud, it would work. If you say it in cmud, it won't. You have to use () rather than {} though brackets still work well enough for just a plain true statement like #IF {@blah} {do blah}.
I'm using cmud exclusively now and it's generally fine. I'm pretty sure the only reason I can do that is that I rewrote my scripts for cmud rather than trying to convert from zmud. Support of switch statements along with a real need to update and rewrite anyway made that a not so painful task. It's definitely much faster and there's a lot of potential. But it's probably not worth the headache right now unless you're really interested in it.
Unknown2007-01-17 00:34:41
Yeah, I decided to go with the Palisade Combat System, I could eventually figure out my own way of doing most of the stuff that I want to, but I really don't have the time right now to build my own script and collect all the trigger messages and debug the script since my job has pretty long hours. If I tried, I'd probably end up with a partially finished script for several months. So, on switching to the PCS I also switched back to Zmud for the time being, mainly because I wasn't sure how well it would work with Cmud's changes.
Laysus2007-01-17 02:13:49
#if (condition) {action} is general good practice rather than #if {condition} {practice} anyway
My main problem with carrying my zmud scripts over will be the change between the boolean expressions (&& instead of &, || instead of |) as I didn't use AND and OR
My main problem with carrying my zmud scripts over will be the change between the boolean expressions (&& instead of &, || instead of |) as I didn't use AND and OR
Unknown2007-01-17 03:08:43
Oh, that reminds me of another problem I had with CMUD, for some reason, my #IF statements weren't working properly. I had an IF statement that triggered on prompt that checked herb balance AND aeon AND stund AND asleep AND...I think some other stuff, then IF it was all good, eat some herb to heal some affliction (whatever the queue says) problem I had was, it didn't seem to be checking herb balance. I never tested the rest, all I know is that I got dizziness from a mob, then it spam ate kombu for me. I went in and modified the kombu alias itself to check for herb balance and it worked after that. So, I think the AND part of the IF wasn't working. I also switched it to use &&, but that didn't fix it. Also, I enclosed the conditions in parenthesis (they weren't before) and that didn't work either. I don't have it in front of me, but it looked something like this once I tried both those:
#IF {(%numitems(@herbqueue)>0)Â Â && (@herbbalance=1) && (@aeoned=0) && (@stunned=0)} {do stuff}
CODE
#IF {(%numitems(@herbqueue)>0)Â Â && (@herbbalance=1) && (@aeoned=0) && (@stunned=0)} {do stuff}
Catarin2007-01-17 03:17:43
Try making it look like:
#IF (%numitems(@herbqueue) > 0 && @herbbalance && @aeoned = 0 && @stunned = 0) {do stuff}
Don't enclose the conditional statement (the one checking the different variables) in brackets, enclose in parenthesis
#IF (%numitems(@herbqueue) > 0 && @herbbalance && @aeoned = 0 && @stunned = 0) {do stuff}
Don't enclose the conditional statement (the one checking the different variables) in brackets, enclose in parenthesis
Elysiana2007-01-17 03:44:35
QUOTE(Daruin @ Jan 16 2007, 07:08 PM) 374271
Oh, that reminds me of another problem I had with CMUD, for some reason, my #IF statements weren't working properly. I had an IF statement that triggered on prompt that checked herb balance AND aeon AND stund AND asleep AND...I think some other stuff, then IF it was all good, eat some herb to heal some affliction (whatever the queue says) problem I had was, it didn't seem to be checking herb balance. I never tested the rest, all I know is that I got dizziness from a mob, then it spam ate kombu for me. I went in and modified the kombu alias itself to check for herb balance and it worked after that. So, I think the AND part of the IF wasn't working. I also switched it to use &&, but that didn't fix it. Also, I enclosed the conditions in parenthesis (they weren't before) and that didn't work either. I don't have it in front of me, but it looked something like this once I tried both those:
CODE
#IF {(%numitems(@herbqueue)>0)Â Â && (@herbbalance=1) && (@aeoned=0) && (@stunned=0)} {do stuff}
Also perhaps try using (@herbbalance==1), for instance. (@herbbalance=1) is poorly formed and won't work.
Catarin2007-01-17 04:00:09
Actually the single = will work in Cmud but it is still poorly formed.
Unknown2007-01-17 04:46:57
I never heard before that Zscript used the == operator
Elysiana2007-01-17 05:31:23
Just to clarify, "=" is assignment, and "==" is comparison (this is standard to C and assorted other programming languages). So if you say "(@var=value)", you're using an (invalid) assignment syntax, whereas "(@var==value)" is a valid comparison. "(var = value)" as the conditional of an if statement, at least in some of these languages, results in assigning when you mean to compare (and always evaluates to true).
Elysiana2007-01-18 04:28:30
QUOTE(Zarquan @ Jan 14 2007, 09:51 AM) 373251
The first thing I did was use it for my prompt, and it passes the health, mana, ego, power, and flags to anyone listening for the event. I can then write separate packages for fun things like recklessness detection (combine an OnDamage event with OnPrompt) or a separate package for updating gauges with the values.
Events allow you to decouple your processing from the location where the event is signaled, meaning you can turn things on and off more easily, like sipping allheale or focusing your mind, by disabling the class or package where the processing of that event is done.
Any chance of getting a description of the basic event syntax, or better yet a link to a reference on it?
Unknown2007-01-18 12:22:31
The expression in your #IF, Daruin, is enclosed in curly brackets instead of parentheses. As already mentioned above, that's what causes your strange results. Enclosing an expression in parentheses causes CMUD to evaluate it to a single value. Also, you should be able to use = or == for equivalence in CMUD or zMUD. There is no implicit variable assignment allowed in an expression as part of a command such as #IF, so both options work for comparing values.
Events are akin to aliases that don't stop on the first match and continue executing all matches. You create one with the #EVENT command and you fire it with the #RAISEEVENT command. You can pass values to the event as arguments. For example, to create a prompt command and have two events (in different classes, so you don't overwrite the first with the second and end up with just one event) that fire, you could try this:
You may notice that the second event doesn't care about the arguments. Maybe you have something that fires on a prompt just to disable a class or module, but you don't need the health and mana values. You can omit parameters starting at the end (i.e., you could match health and leave mana out, but you cannot match mana and leave health out, unless you switched the order in which you passed the arguments).
Hope that helps more than confuses!
Events are akin to aliases that don't stop on the first match and continue executing all matches. You create one with the #EVENT command and you fire it with the #RAISEEVENT command. You can pass values to the event as arguments. For example, to create a prompt command and have two events (in different classes, so you don't overwrite the first with the second and end up with just one event) that fire, you could try this:
CODE
#REGEX {^(\\d+)h\\, (\\d+)m} {#RAISEEVENT OnPrompt %1 %2} "" {nocr|prompt}
#CLASS ClassOne
#EVENT OnPrompt($health, $mana) {#SAY {Health is $health. Mana is $mana.}}
#CLASS 0
#CLASS ClassTwo
#EVENT OnPrompt {#SAY {Firing second event.}}
#CLASS 0
#CLASS ClassOne
#EVENT OnPrompt($health, $mana) {#SAY {Health is $health. Mana is $mana.}}
#CLASS 0
#CLASS ClassTwo
#EVENT OnPrompt {#SAY {Firing second event.}}
#CLASS 0
You may notice that the second event doesn't care about the arguments. Maybe you have something that fires on a prompt just to disable a class or module, but you don't need the health and mana values. You can omit parameters starting at the end (i.e., you could match health and leave mana out, but you cannot match mana and leave health out, unless you switched the order in which you passed the arguments).
Hope that helps more than confuses!