Zugg Software :: View topic - [3.16b] "Not enough quota is available to process this command."

Beginner Joined: 02 May 2010 Posts: 14

I get this on occasion when I try to execute this trigger:

<trigger priority="12480" id="2239">
<pattern>^You are:$</pattern>
<value> #VA affliction.ablaze 0
#VA affliction.addiction 0
#VA affliction.aeon 0
#VA affliction.agoraphobia 0
#VA affliction.anorexia 0
#VA affliction.asthma 0
#VA affliction.baldness 0
#VA affliction.bbile 0
#VA affliction.berserk 0
#VA affliction.berserking 0
#VA affliction.bloodcurse 0
#VA affliction.bloodeff 0
#VA affliction.bloodpoison 0
#VA affliction.blurryvision 0
#VA affliction.bodyodor 0
#VA affliction.claustrophobia 0
#VA affliction.clumsiness 0
#VA affliction.confusion 0
#VA affliction.darkshade 0
#VA affliction.deadening 0
#VA affliction.dementia 0
#VA affliction.disfigured 0
#VA affliction.dissonance 0
#VA affliction.dizziness 0
#VA affliction.earthrot 0
#VA affliction.eating 0
#VA affliction.epilepsy 0
#VA affliction.fearcom 0
#VA affliction.fearcommit 0
#VA affliction.frozen 0
#VA affliction.generosity 0
#VA affliction.haemophilia 0
#VA affliction.hallucinations 0
#VA affliction.hatred 0
#VA affliction.headbroke 0
#VA affliction.headmangled 0
#VA affliction.heartflutter 0
#VA affliction.heartpunch 0
#VA affliction.hellsight 0
#VA affliction.hubris 0
#VA affliction.hypersomnia 0
#VA affliction.hypochondria 0
#VA affliction.idiocy 0
#VA affliction.impatience 0
#VA affliction.indifference 0
#VA affliction.justice 0
#VA affliction.laasymptomatic 0
#VA affliction.labroke 0
#VA affliction.lamangled 0
#VA affliction.lethargy 0
#VA affliction.limpveins 0
#VA affliction.llasymptomatic 0
#VA affliction.llbroke 0
#VA affliction.llmangled 0
#VA affliction.loneliness 0
#VA affliction.lovers 0
#VA affliction.masochism 0
#VA affliction.mayeat 0
#VA affliction.mercy 0
#VA affliction.pacified 0
#VA affliction.pacifism 0
#VA affliction.paralysis 0
#VA affliction.paranoia 0
#VA affliction.peace 0
#VA affliction.phlegm 0
#VA affliction.plodding 0
#VA affliction.pride 0
#VA affliction.prone 0
#VA affliction.raasymptomatic 0
#VA affliction.rabroke 0
#VA affliction.ramangled 0
#VA affliction.rank 0
#VA affliction.recklesnessaff 0
#VA affliction.recklessness 0
#VA affliction.rlasymptomatic 0
#VA affliction.rlbroke 0
#VA affliction.rlmangled 0
#VA affliction.sadness 0
#VA affliction.selarnia 0
#VA affliction.selfpity 0
#VA affliction.self-pity 0
#VA affliction.selfpityaff 0
#VA affliction.sensitivity 0
#VA affliction.shivering 0
#VA affliction.shyness 0
#VA affliction.slickness 0
#VA affliction.spinalrip 0
#VA affliction.stunned 0
#VA affliction.stupidity 0
#VA affliction.stuttering 0
#VA affliction.sunlight 0
#VA affliction.thinblood 0
#VA affliction.throatrip 0
#VA affliction.throatslash 0
#VA affliction.torsasymptomatic 0
#VA affliction.torsoasymptomatic 0
#VA affliction.torsomangled 0
#VA affliction.unhappy 0
#VA affliction.vertigo 0
#VA affliction.vomiting 0
#VA affliction.weariness 0
#VA affliction.ybile 0

</value>
</trigger>

Ideas?

Beginner Joined: 02 May 2010 Posts: 14

I've also discovered that cMUD can run this trigger just fine when I first load it up, and for a while, it's only after time that it starts to lock it up. Memory leak somewhere, maybe?

Posted: Sun May 02, 2010 3:28 pm

For starters, simplify your script with:

#LOOPDB affliction {#ADDKEY affliction %i 0}

That is, unless you have one or two elements that cannot be reset to 0... in that case, I implore you to take those out and just leave afflictions in it.

Not sure what the error responds to, but that is a LOT of commands to be firing in one script. See if the change helps, though...

Charneus

Beginner Joined: 02 May 2010 Posts: 14

Changed to the #LOOPDB, we'll see what holds up there.

I've also had a general slowness with cMUD when I enabel buttons (and I have a ton of them) -- is this because I'm using databses to store variables or a side effect of the buttons themselves? I'm running Vista on a quadcore 2.4 GHz \ 3 GB build. I shouldn't have any power issues.

Posted: Sun May 02, 2010 11:41 pm

Its likely due to CMUD having to recalculate the wordwrap on x lines of scrollback buffer.

Posted: Mon May 03, 2010 5:06 pm

I would need to see the exact crash dump from the original error message to help more with this. Can you paste the stack dump into [code] tags within this forum post the next time it happens?

My best guess is that you have a caption on a button that is too large for Windows to handle.

Beginner Joined: 02 May 2010 Posts: 14

I have all my buttons in class folders, and in an attempt to figure out my speed issues, I've had them off (through #T+ and #T-). When this is crashing, I don't have anything open. The longest button I have is 180 pixels wide by 12 high and the caption is 'Random Parrying OFF'.

That being said, and I know you've had issues with IRE users in the past and lag. I use MudBot (a freeware tool developed by an Imperian player that works as a passthrough, and can house code, but most of us just use it for the realy handy mapper feature) a lot. Since connecting from cMUD straight to Aetolia instead of passing through MudBot and connecting through localhost, I've cut down on my lag a lot.

Is there a 'last crash' dump anywhere? If so, I can pull that file for you as this was ( I believe ) the last crash I had.

Posted: Tue May 04, 2010 3:15 am

The crash dump is only saved to a file if you clicked the Save button. So you might need to wait for it to happen again.

It's not the physical size of the button that would cause the problem. It's the length of the caption string itself. Although I'm pretty sure that was fixed a long time ago and that CMUD now truncates the caption if it gets too long. So that probably isn't the cause. Without the crash dump I won't be able to tell what the problem is since that Windows error message is so annoying generic.

I'm assuming you are not using a computer that actually has disk quotes enabled, so Windows is probably referring to some other system resource that it is running out of. But who knows what it really means by that.

The Microsoft help for this error says:

Beginner Joined: 02 May 2010 Posts: 14

Alright, I'll do both. It seemed to me like a memory issue, but unless the sidebar is lying to me (entirely possible) the most my RAM usage is getting is around 55% total, running usually Vista, cMUD, MudBot, and a media player such as Quintessential. I've since stopped using MudBot (which has eliminated about half of my speed related issues, removing all my buttons eliminated the other half). I'll try increasing the virtual memory in case that's an issue, but I'm pretty sure I have it set ridiculously high right now, as the system was built for video editing originally and has over 2 TB of disk space, so hard drive space and RAM shouldn't be an issue.

I *do* run an alarm every 1.5 seconds that calls my four healing functions, but I've been doing that since zMUD and never, ever had any issues. The only difference in the zMUD and cMUD versions is that I'm now using #SW instead of nested if statements and I'm using functions instead of aliases, so I don't think that would be the problem.

Posted: Tue May 04, 2010 10:03 pm

Getting the crash dump is more important than messing with your virtual memory. If it's a memory issue, increasing your virtual memory might just make the problem harder to reproduce rather than actually eliminating it. The Microsoft suggestion about the virtual memory is really just a generic "solution" that they use for a bunch of misc error messages like this. It really just means they have no idea what caused it.

It would also help to have the Script Debugger open to see what trigger was running when you get the crash, but that also slows things down and for something random and hard to reproduce like this, I can appreciate if you don't want to keep the debugger open all the time.

Let's start with the crash dump and then go from there depending upon what it says.

Btw, the speed issue with buttons is that if the button caption depends upon a variable and that variable changes it's value, then the button gets repainted, which can be slow. If the buttons are disabled, there shouldn't be a speed issue, so that might also be pointing to a problem to look into more.

Beginner Joined: 02 May 2010 Posts: 14

It's definately the trigger I posted above -- I could click continue application, make that thing fire, and it would do it again. If I disabled that trigger and did the same thing, I wouldn't crash.

As for the buttons, yea I realized it was the toggle variables that were causing the issue, hence why I just turned them all off. I never noticed it before because in zMUD I slowly added buttons so I was only increasing my lag a little bit each time, but with the cMUD system I've been scripting I added them at once and went 'whoa'.

I'll leave the virtual memory alone and leave cMUD open for a long time and see if I can reproduce this, though since I posted this, turned off buttons \ mudbot and switched to the #LOOPDB instead of a hundred #VA commands, I haven't had the issue. I can, however, undo all those changes and try to make it happen again if you'd like, so you can chase this down.

Posted: Tue May 04, 2010 10:32 pm

Am I correct in guessing that some of your toggle buttons were using the same variables that you are turning off in this trigger?

If you are willing, I'd definitely be interested in tracking this down if you can make it fail again.

Beginner Joined: 02 May 2010 Posts: 14

You are correct. I had toggle buttons that tracked afflictions, defenses, and 'cure states' which were the checks that go into herb eating, sipping, et al. This particular trigger handles all the afflictions (of which there are the greatest amount of buttons associated with) -- the skill is diagnose, and basically, when I did a diagnose, it would reset all my afflictions to false, and then repopulate based on what the diagnose skill found. I do it this way to eliminate illusions, so I'm not trying to cure things that aren't really there.

Posted: Wed May 05, 2010 11:22 pm

Ahh, ok. Well, I can certainly see where this script would cause a huge slowdown and it might be susceptible to crashes.

The way CMUD updates buttons is to make a list of variables that the button depends upon. If any of those variables change, then the button is updated. Now, CMUD has no way to distinguish between a change to a "key" of a database variable and the variable itself. In other words,

Wizard Joined: 22 Mar 2007 Posts: 2320

To reduce the excessive updating of the buttons, here is an idea:

Have your code modify a separate variable. Then, when the return from the diagnose skill is completed, copy this variable to the one that your buttons care about.

Actually, an even better solution is to have a separate variable for each button. As it is, if you change the "addiction" value, you cause the update of all 40 buttons. Much better to only update one button when you update one value.

Posted: Thu May 06, 2010 7:42 pm

Having a separate variable for each button is how CMUD is designed to work efficiently. That's why you can put them into class folders to organize them.

Beginner Joined: 02 May 2010 Posts: 14

Meh, I just wanted to organize all the variables, when I started building this I didn't even realize I was creatinve a database, then was like 'well, guess I'll go with it!'. Sorry I haven't gotten back to the other (original) issue. Work's been a real pain in the butt this week, but hopefully I can make it break this weekend.