Free CMUD System

by Catarin

Back to Mechanic's Corner.

Desitrus2009-01-25 11:37:59
QUOTE (Sadhyra @ Jan 23 2009, 02:27 PM) <{POST_SNAPBACK}>
Sigh, I think I'm doing something wrong. I keep breaking every system I try or something. Sparred a few times with Catarin's and every single spar ended in a system loop of some sort. Against Esano, I was spamming focus mind/body, while against Melville and Yuriko, I got slit-locked and the system then paused itself and any attempt I made to cure manually made cmud yell at me. sad.gif After those spars, it continued to spam green outside of arena and clearing variables didn't stop it. Had to restart cmud (not sure yet how to clear queues). Anything obvious I'm doing wrong to get this result?


That's duplicate variables, fo sho.
Unknown2009-01-25 13:35:23
Not seeing any duplicate variables. Because of the various crash/reconnects the log wasn't saved, so I'll spar some monks and get another version of the log.

Hypochondria seems to really upset the system as well, understandably.

Hallucinations also didn't seem to register (been running through totems as well as sparring to test it all >_>).

All in all, this looks like a very nice and well organized setup.
Kante2009-01-25 19:58:50
Yes, it sometimes gets stuck in loops. The main loops I get stuck in are monk grappling writhes, and if you run out of a potion while hunting/doing whatever, God help you.

YOU ARE OUT OF FIRE AUTO-SIP SHUT DOWN
SIP FIRE
YOU ARE OUT OF FIRE AUTO-SIP SHUT DOWN
SIP FIRE
YOU ARE OUT OF FIRE AUTO-SIP SHUT DOWN
SIP FIRE

Then you have to pause the system and run around like a chicken with your head cut off till you find a keg.

All in all, the system works pretty, well though. Just a few MINOR issues.
Catarin2009-01-25 20:19:07
QUOTE (Kante @ Jan 25 2009, 12:58 PM) <{POST_SNAPBACK}>
Yes, it sometimes gets stuck in loops. The main loops I get stuck in are monk grappling writhes, and if you run out of a potion while hunting/doing whatever, God help you.

YOU ARE OUT OF FIRE AUTO-SIP SHUT DOWN
SIP FIRE
YOU ARE OUT OF FIRE AUTO-SIP SHUT DOWN
SIP FIRE
YOU ARE OUT OF FIRE AUTO-SIP SHUT DOWN
SIP FIRE

Then you have to pause the system and run around like a chicken with your head cut off till you find a keg.

All in all, the system works pretty, well though. Just a few MINOR issues.



That's not really a loop. It's a "hey, you should take care of this" every couple of seconds. You can always just pause it. When I think of loops I think of the system uncontrollably executing a process for no reason.

What do you mean with the monk grappling writhes? Is it writhing when it shouldn't? Someone else reported that the alias to remove the grapple affliction had gone missing entirely form their package. Is that what you mean? It never gets cleared and so just keeps trying?

Some more specifics, even if you don't have logs (though logs would be nice) would be very, very helpful. The fact that's it a free system doesn't mean bugs are just an "oh well" situation.

To test the grapple thing, just type "grapple". Then give me a log of what happens after that. You can post it here. It shouldn't be that long.
Kante2009-01-25 20:27:00
I do not have a log, but I CAN tell you what happened.

Every time that I've sparred Yukio, he will wind up using a Kata with a grapple. It would send me into a loop of trying to writhe out of the grapple, even when the grapple was finished, thus leaving me on the ground writhing and stripping me of my balance so I can't diagnose or even stand up.

I looked through the help files for the situation and just turned grapple writhing off. Also, the first time I got stuck in that loop, he killed me in the arena, and when I came out of the arena, I was still stuck in the loop.

I paused the system and unpaused it, and it kept going. I had to restart Cmud to get thing working again.

All in all, I like the system, though.

If you need a log though, I am sure I can acquire one later on today. smile.gif
Catarin2009-01-25 20:29:36
QUOTE (Kante @ Jan 25 2009, 01:27 PM) <{POST_SNAPBACK}>
I do not have a log, but I CAN tell you what happened.

Every time that I've sparred Yukio, he will wind up using a Kata with a grapple. It would send me into a loop of trying to writhe out of the grapple, even when the grapple was finished, thus leaving me on the ground writhing and stripping me of my balance so I can't diagnose or even stand up.

I looked through the help files for the situation and just turned grapple writhing off. Also, the first time I got stuck in that loop, he killed me in the arena, and when I came out of the arena, I was still stuck in the loop.

I paused the system and unpaused it, and it kept going. I had to restart Cmud to get thing working again.

All in all, I like the system, though.

If you need a log though, I am sure I can acquire one later on today. smile.gif


Yes, it sounds like your "grappled" alias is missing. If you have a chance do a settings search for "grappled" and see if you have an alias by that name.
Desitrus2009-01-26 17:07:43
QUOTE (Kante @ Jan 25 2009, 02:27 PM) <{POST_SNAPBACK}>
I do not have a log, but I CAN tell you what happened.

Every time that I've sparred Yukio, he will wind up using a Kata with a grapple. It would send me into a loop of trying to writhe out of the grapple, even when the grapple was finished, thus leaving me on the ground writhing and stripping me of my balance so I can't diagnose or even stand up.

I looked through the help files for the situation and just turned grapple writhing off. Also, the first time I got stuck in that loop, he killed me in the arena, and when I came out of the arena, I was still stuck in the loop.

I paused the system and unpaused it, and it kept going. I had to restart Cmud to get thing working again.

All in all, I like the system, though.

If you need a log though, I am sure I can acquire one later on today. smile.gif


There is a bug in cmud that will actually delete your "grappled" alias which is the grapple delete. What I did was an input trigger for grappled, that way if my client EVER actually sends grappled to the client it repopulates the alias and uses it.
Catarin2009-01-26 18:48:12
QUOTE (Desitrus @ Jan 26 2009, 10:07 AM) <{POST_SNAPBACK}>
There is a bug in cmud that will actually delete your "grappled" alias which is the grapple delete. What I did was an input trigger for grappled, that way if my client EVER actually sends grappled to the client it repopulates the alias and uses it.


This should be fixed in the new version. I'm not sure *why* Cmud dislikes that particular alias but reworked things enough that it should play nicely moving forward.
Daganev2009-01-26 20:54:33
QUOTE (Catarin @ Jan 25 2009, 01:55 AM) <{POST_SNAPBACK}>
I'm doing some major work on the system in the next few days. While I have its guts exposed (so to speak) I'm looking for wish list items (try to be reasonable) that people would like to see. Things already added:

1. The ability to turn on a mode that will pause the system if lag spikes hit. You can adjust how many seconds of lag you will tolerate before this enables. And of course just not use it at all.

2. Using summer/tipheret when you have several 'burnable' entanglements. And can use it of course.

3. A toggle to enable floating alert windows on things you really don't want to miss.

4. A customized menu when you right click on the main cmud window. An easy way to configure the system, find help, etc. for those who like pointing and clicking.

5. Customizable colors for system messages.

6. Basic targetting system

7. Cleaned up the auto configuration processes to make it so you just have to click yes or no on many of the options instead of typing it in.

Major bugs fixed: stancing not working, sometimes applying health not working

The behind the scenes work is mainly to make the mechanics more resistant to duplicates and clean up some redundancies. So if you know of any bugs that you have not reported or have not been fixed, please do so now. Stancing, for example, has been broken for months and no one reported it! It's great that the parrying works so well but still...

I'm not going to be making a gui for general usage. So don't ask for that smile.gif I may release some code that adds some nifty items to the status window like dynamic affliction tracking (that you can click to cure) if people are interested. Anything else though..let me know.



Can you put in a general command que? (maybe you already have it and I just missed it)

But say you have a combat sequence you want to pull off, and you always do that sequence as soon as you get balance back. It would be nice to have a cue to add it to, and if it doesn't properly fire, then it waits and refires when it has the chance.
Desitrus2009-01-26 20:55:50
QUOTE (daganev @ Jan 26 2009, 02:54 PM) <{POST_SNAPBACK}>
Can you put in a general command que? (maybe you already have it and I just missed it)

But say you have a combat sequence you want to pull off, and you always do that sequence as soon as you get balance back. It would be nice to have a cue to add it to, and if it doesn't properly fire, then it waits and refires when it has the chance.


It doesn't refire, since it needs the lines for not firing if unsuccessful, but onb waits for full balance recovery (bal/eq/psi) before taking action.
Enero2009-01-26 21:24:20
While on the topic of stacking commands for system to fire...
I guess it wouldn't have many uses (save for the few that are making me ask this), but how hard would it be to make something like ONB, but make it clear to current cue and add the new command to it, or add the new command with a higher priority than others?
Catarin2009-01-26 21:26:56
QUOTE (Desitrus @ Jan 26 2009, 01:55 PM) <{POST_SNAPBACK}>
It doesn't refire, since it needs the lines for not firing if unsuccessful, but onb waits for full balance recovery (bal/eq/psi) before taking action.


And you can put anything that needs balance/eq but doesn't take it in onbn which will fire before the onb stuff does. So you could make an alias to put a series of things in onbn and onb and just use it each balance cycle.

But yeah, as Desi said, it can't refire without knowing what a successful line looks like. I suppose it could say if a certain balance isn't taken within x period of time it was unsuccessful and try again but I'm not sure why onb and onbn wouldn't suffice for balance type recovery stuff.
Daganev2009-01-26 21:27:11
QUOTE (Desitrus @ Jan 26 2009, 12:55 PM) <{POST_SNAPBACK}>
It doesn't refire, since it needs the lines for not firing if unsuccessful, but onb waits for full balance recovery (bal/eq/psi) before taking action.


Can you make a long cue with ONB?

Like, onb attack1, onb attack2, onb Win!!1!!
Catarin2009-01-26 21:32:00
QUOTE (daganev @ Jan 26 2009, 02:27 PM) <{POST_SNAPBACK}>
Can you make a long cue with ONB?

Like, onb attack1, onb attack2, onb Win!!1!!


Yes but remember each one will only fire after you get balance back. So you get full balance back once, the first item in the queue fires, next time, the second one fires. But you can put as much as you want in there and it will keep working through it until it's clear.
Daganev2009-01-26 21:40:33
meh, I'll have to find Thoros's old zmud code again. I remember he had a nice que set up that fired again if the first one didn't go through. Don't remember how he did it though. Maybe it just looked for the "fail" messages, but I remember it working great for bashing and broken arms.
Anisu2009-01-26 21:41:25
QUOTE (Enero @ Jan 26 2009, 10:24 PM) <{POST_SNAPBACK}>
While on the topic of stacking commands for system to fire...
I guess it wouldn't have many uses (save for the few that are making me ask this), but how hard would it be to make something like ONB, but make it clear to current cue and add the new command to it, or add the new command with a higher priority than others?

that should be quite easy to do, if nobody else helps you out I will make you an alias for those things when I have access to cmud (which will be 4 days I think)
Unknown2009-01-26 21:43:32
Auto-bashers are the work of the Devil, and His name be... well, you get the idea.

(Psst, there's someone in your own guild who makes these sorts of things and could probably help you out. No, it's not me!)
Daganev2009-01-27 00:18:08
So I just remembered what the "cue" that thoros had did. (may not have been thoros)

There is an alias "do" and then as a parameter you have the command. like (do diag) or (do attack1)

it then set a variable "lastcommand" or something similar. If you got a fail message (such as "you need balance" or , "you can't do that" etc., then it would add the @lastCommand when whatever that fail message was, got rectified.

So if your arm was broken, it would do the last command when you healed your arm, if you didn't have EQ it would do the lastcommand when you gained back EQ.

It might be nice to have something similar here if you are inclined to make one.

Obviously the system would break if you had an alias for DIAG which did "do diagnose", and then you also did an attack, and then manually did diagnose witout the DO alias infront. Not sure the way around that though.
Enero2009-01-27 09:38:52
Yeah, something similar to what was spinning around in my head though what I had in mind was instead of feeding it the same command again, in the case when you couldn't comeplete it the first time, it clears the current cue and gives another command instead.

For example, if I told it to scratch my belly ONB, but before ONB is matched my belly grumbles, the system clears ONB and feeds me instead, as it's pointness to scratch an empty belly. THEN, if I still want to scrach my belly, I put it ONB again. Yes, yes... I'm poetic, I know.



EDIT: After reading daganev's post again I think he's talking about apples while I'm talking about PINEapples. Still, we're both talking about queuing (?) commands.
Catarin2009-01-27 14:46:17
Well. The system already has a pretty robust queuing system to queue commands for all types of balances. What seems to be wanted is a way to say if a particular command was unable to fire due to x, it will try to fire again rather than just fire once and be done. While attempting to make something for every conceivable combination that migt prevent you from executing a balance command is not feasible in a general system it is feasible to say something like "If I have a command in this queue, then when it fires successfully, I should lose this type of balance. If I don't lose this type of balance then I know it wasn't successful and I should try it again."

I can do this but I'm not certain of the value added. I'll test it out.