so i guess my big question is.... how can i improve what im doing to make it run faster and smoother. Also anyone got advice on how i can find a better way to queue commands for fog (which slows things so you can only enter a command every 1.5sec)

Ok, Im rewriting my whole system. This thing is HUGE. And I doubt its the fastest way it could be. This is how it works...

I have a prompt trigger that runs on every prompt.. which calls an alias that does the following functions...

1. Check health/mana and sip accordingly.
2. Looks at poisons, and cures them using herb/smoke/potion.
3. Checks for defences and puts them up if needed.

Any curing system is event driven. If you want to make this easy for yourself, then first create an onPrompt event. Then create a new onPrompt event handler for each of your curing and defense checks. Basically modularize your system. The only thing you need in your prompt trigger is #raiseevent onPrompt. The good thing about this is that you can give each of those event handlers an ID and you can enable and disable them as needed. That way the code isn't being checked every prompt unless it needs to be. For example, there is no need to be checking for poisons unless you are actually attacked. There is no need to check defenses unless you have one stripped or need to put them up.

You create one or more Event objects named nameofevent. This is done either with the #EVENT command (like the #TRIGGER command) or in the Package Editor by specifying type Event instead of Trigger or Alias or something else. Inside the nameofevent you put in the code you want to be executed when the named event is raised.

A trigger (usually a trigger) fires and executes "#RAISEEVENT nameofevent". This will cause all events named nameofevent to be executed, in order by priority. You can add parameters to #RAISEEVENT -- "#RAISEVENT nameofevent 100" will cause nameofevent to be executed with %1 equal to 100.

The advantage of doing this is that you can separate different actions into different bits of code. Rather than having half a dozen triggers firing on your prompt (each one parsing the line from the mud, over and over), you can have just one trigger parse the prompt and fire #RAISEEVENT. If you ever change your prompt, you only need to modify the one trigger. Meanwhile, each individual event can do its own thing when it 'hears' that the event has been raised. Each event can be turned on or off with #T+ and #T-, like a trigger or alias. And you can write the code for each action (checking health, poisons, etc.) can be written in a separate event. You can have as many parameters in #RAISEEVENT as you need for your events.

Another way to handle this kind of thing is to your actions be Expression Triggers, which fire when a variable changes.

ok, i think i need to study this more. i dont understand how this is any better or different to just putting an alias in the prompt trigger, which contains the code. an event just seems to be the same as an alias so im not sure how moving the code from the alias into an event would change the speed of anything or make it work better. i already have an alias to perform each important action which are called as needed, just like i would with an event.

i think im just missing the point. read your posts multiple times, guess im gettin to old to understnad these things nowadays.

You can certainly do it all in a single alias. The advantages of doing it as several events are (1) you can turn pieces of it on or off separately; (2) you can design it piece by piece, testing each piece separately without the danger of messing up all the rest of the alias code; (3) it makes it easy to add new pieces, simply by adding a new event; (4) it gives you practice with Cmud events. Basically, the efficiencies are mostly in the ability to write and modify the code. Since you already have working code, it's not a great advantage to convert it all to events. So for your purposes, it is probably not worth it, unless you want to play with events.

so i guess my big question is.... how can i improve what im doing to make it run faster and smoother.

I just thought I would mention it since you stated the above. It will make life much easier on you in the long run. You can do it in aliases I suppose except that you're going to be running all of the code (your scripts contained in your alias) every single prompt when it isn't even necessary.

The receiving of your prompt is the event you are using to enact curing. Just like when you click a button on a webpage you have an onClick event happen. In CMUD the event would be an onPrompt event which gets raised every time you receive a prompt. That's why you put #raiseevent onPrompt in your prompt trigger code. Then you just create new event handlers for each curing process and give them each a specific ID. They all handle the onPrompt event.

Because of the priority numbers for each of these event handlers, each of these will execute in the correct order. You can, however, change the priority of any of these event handlers to make them execute in a different order. Anyway, now I could create other triggers to enable and disable each of them, such as lets pretend PrintOne is poison curing so in all triggers that give a poison affliction, I would put #T+ PrintOne. When the onTest event fires, only the ones I have enabled will execute. For the purpose of curing, you can put in the code for it to disable itself if you are no longer afflicted with anything specific to that curing process. So if PrintOne is code to cure poisons, then in the code I could put if afflicted with poisons then do my cures else #T- PrintOne. Now this code will no longer be executing when receiving a prompt but the other two will be until I disable them. If this were all smashed into an alias it would execute every prompt regardless.

Rahab mentioned many of the advantages of doing it this way. If you think about curing, you can do many things at once. You can smoke, eat, and drink at the same time. So you could have a SmokeCure, EatCure, and DrinkCure event handlers. You can break down your entire curing system into individual curing processes. Then when you need to change something, you only have to go to that specific event handler and change the code and not worry about anything else. You could also create MistCure and then disable all other event handlers so only MistCure is running since while in mists you can only do something every second or so.

Oh here is what it looks like when I run the test:

This is a test.
ONE
TWO
THREE

If I want PrintTwo to execute before PrintOne, all I had to do was change the priority of it. Then it executes first.

This is a test.
TWO
ONE
THREE

If I disable PrintThree, only the code in one and two execute.

This is a test.
ONE
TWO

If I disable them all, then obviously no code will be executing.

This is a test.

Oh look I got hit with a print one affliction, I better enable that so it executes when I get the next prompt #T+ PrintOne...

This is a test.
ONE

This make any sense?

Last edited by oldguy2 on Fri Jun 10, 2011 1:37 am; edited 1 time in total

hmmm, im not sure i get what you mean (sorry for my ignorance). Not used event for anything other the connect commands etc.

So would I put in my prompt #raiseevent onPrompt, then for each trigger i would call the event?

... eg if i get afflicted by yarl, it would then call the onprompt event and run my curing script?

do you have an example. i dont quite get how this works.

thanks!!

Sort of... You could create a new event handler for the onPrompt event and give it an ID like YarlCure for example. In the trigger that gives the affliction and sets yarl = 1 you would also put #T+ YarlCure so it executes when receiving the prompt. The trigger that gives the affliction doesn't call the event, it would just enable YarlCure so it gets called when the prompt is received.

A really basic example of what YarlCure code would look like is the following:

Code:

#if (@yarl) {do something to cure yarl} {#T- YarlCure}

This means that YarlCure will keep executing until yarl is cured (yarl = 0) and then disable itself on the prompt after. Then when you get afflicted with Yarl again you just enable YarlCure again and let it work.