Zugg Software :: View topic

Wanderer Joined: 14 Oct 2009 Posts: 57

Ive been having problems in that CMUD with scripts... isnt as fast as cmud without scripts. now i know running triggers will slow it down... but it is VERY noticeable. any way to improve this?

I do have hundreds and hundreds of triggers + alias. would disabling some improve speed? or wont that matter?

thanks

(edit - my pc shouldnt be the cause of the slowdown... 2gig ram intel core2 quad Q666)

Wizard Joined: 26 Mar 2008 Posts: 1547

If they're not being used, then yes, they should be disabled. Having triggers that only activate when certain variables "turn them on" are still there in the background, checking against possible trigger lines, even if only to come to the conclusion that because A equals 0, they can't do anything. Having triggers that turn them on and off as appropriate will certainly help you immensely.

Wanderer Joined: 14 Oct 2009 Posts: 57

would alias's effect speed? i assume not as thier not checking anything? so i can leave them all enabled right?

thanks for your reply

Wizard Joined: 26 Mar 2008 Posts: 1547

I don't know enough to comment on that. I'm sure some GURU will offer more tips as well. Check back often and you should see something of a response. Everything should require some sort of overhead I imagine, but I'm not certain to what extent. Just out of curiosity. How many triggers, aliases and variables are we talking about here?

Wanderer Joined: 14 Oct 2009 Posts: 57

no idea how to check exactly how many alias/triggers. but its a lot. the pkg file comes to 2 meg

ive been writing this system over about 5 years. works EXTREMELY well on the mud i play. i just wanna get that further edge.

have disabled a LOT of triggers. hopefully will managed to disable a a lot more. i must have disabled 20% so far with no marked improvement

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Do you send commands to the game in a manner similar to typing them in the command line? For example:

#if (@item = "dagger") {look dagger}

The part in bold would be sent to the game, but before it gets sent it is evaluated to see if "look" is an alias name. If you have a lot of aliases, you can shut down this extra evaluation by using #SEND or #SENDRAW. If your command is plain text, use #SENDRAW; if your command requires script code or needs to reference a variable to put together the command to send, use #SEND.

Wanderer Joined: 14 Oct 2009 Posts: 57

ok, im starting to see a noteable speed increase now. thanks for that to you both! any further ideas? ive disabled almost asmuch as I can and ive added #send/#sendraw to my alias where possible

Wizard Joined: 26 Mar 2008 Posts: 1547

Adding #send and #sendraw to your triggers would help too, I imagine. But I got nothing else for you. Glad to know it's working better for you.

Posted: Mon Mar 22, 2010 4:56 pm

You could also start looking at your specific trigger patterns. Some trigger patterns are slower than others, but we'd need to see your exact triggers to help more with that kind of optimization.

You can look for triggers that are firing more often than you'd expect by opening the Script Debugger. You can turn on the "Show all scripts" message to see everytime one of your scripts is called.

Wanderer Joined: 14 Oct 2009 Posts: 57

when looking at the debugger are the numbers to the left the time it takes to execute? i thought cmud could multithread...so it wouldnt be as much of an issue?

Posted: Tue Mar 23, 2010 6:21 am

Yep, the numbers are the relative timestamps between lines. CMUD is multithreaded, but you need to remember that anything that requires updating the user interface can only be done by Windows in the main thread, so in many cases the synchronization required for that kills the performance boost. And unless you are using a lot of multiple threads via #waits or #signals or specific #thread calls, every thread is always going to wait for the next line from the MUD together. There isn't any way to process multiple lines from the MUD simultaneously without causing a lot of scripting problems.