Zugg Software :: View topic

Wanderer Joined: 02 Sep 2005 Posts: 85

been wondering about the best way to go about things, and I've tried searching, didn't work.. anyways, two questions I'm curious about..

1) Streamlining multiple copies of one trigger having different values into one trigger with all values efficient for one single package that won't be shared? or should I keep them separate in case I may want to distribute?

2) dbvar vs var efficiency.. which is best for cmud atm? or is this dependent on the rig specs?

Posted: Sat Aug 21, 2010 3:00 am

In both cases, the answer is "it depends".

1. This really comes down to what your triggers are, how similar (or dissimilar) they are, and how good you at RegEx scripting. Since triggers (and trigger patterns are compiled) whether are separate or not does not make much of a difference. If they execute essentially the same code then you (c|sh)ould combine them but this requires you to have a good matching pattern to quickly and precisely determine whether you have a match or not. If you don't feel that comfortable with your RegEx / pattern matching skills you can maintain multiple triggers and have the trigger bodies call an alias so you're only writing / modifying that code once.

The bottom line is that is that it really boils down to the matching pattern and the code overlap between triggers.

2. Once again this is highly variable (pun intended). What data are you storing? Is it structured? Unstructured? How will you be accessing it? For example if you are keeping track of simple variables such HP, MP, XP or EquippedWeapon then simple variables will work just fine. You can use the "Use Default" option on variables like HP, MP etc since they don't need to be persisted across sessions and they are updated quite frequently. Now on the other and if you kept a very structured list of your equipped inventory or for all you character stats, then this type of data may make more sense for a db variable, since it's inherently structured. It also matters if you are going to access that variable in a gauge or button because CMUD updates buttons if the variable has been updated, but won't recognize this (in many cases) if you used a function call instead.

Your mileage will vary and most likely you'll end up using a combination of the two. Having said all that I typically don't have all the mega-variables some of hardcore folks do. For example 2000+ entry enemy lists are something I never maintained. Also with all of Zugg's optimizations (especially in the latest Beta line) it really doesn't make that much of a difference. That said I also don't play what I imagine to be hyper-kinetic muds that are very sensitive to time (that's the impression I get from Aardwolf and other IRE muds) so shaving milliseconds of the response time matters. Those are my thoughts on the matter, I'm sure others will chime in.

A few general speed tips. If you don't care what the value of a variable is when you are using CMUD offline, then simply check 'Use Default' to prevent constant background storing. Make liberal use of local variables. Have your trigger match patterns be as precise as possible. Updating local variables is much faster than updating regular variables. Only enable trigger packages on the windows that need them. Only enable specialty triggers when needed. For example if you have a group of triggers related to shops, it's fastest to have them in a disabled class that's only enabled by a trigger / event that detects you entered a shop.

My $0.02