Zugg Software :: View topic

Magician Joined: 29 Nov 2005 Posts: 482

Zugg i had a question for you.

I realize some of my scripts use duplicate triggers. I PERSONALLY cut them out and combine them but it makes distributing standalone scripts a pain. The problem is that if they install both scripts that use that function then you end up processing a line multiple times and increasing lag. Will the script importation / package abilities allow it to check to see if there is a duplicate and either not parse one of them or not install one or what?

The only solution i personally have come up with is a manual solution of installing all shared functions to a shared class folder that way it will over write the existing one if its been updated but this also has its problems.

What happens for example when you do the following?

User installs
FORCE OPENER SCRIPT
[code]
#CLASS {MMSystem|Force Opener}
#ONINPUT {^(%t)$} {#VARIABLE lastDir %1} "" {notrig}
#TRIGGER {The (*) {is|are} closed.} {open @lastdir}
#TRIGGER {It's locked.} {unlock @lastdir;bash @lastdir}
#TRIGGER {A strange force blocks your passage.} {open @lastdir}
#CLASS 0
[code]

USER INSTALLS
AUTO FLEE/BS Script
[code]
#CLASS {MMSystem|fleebs} {enable}
#ALIAS fbs {
#VARIABLE backstab %1
#T+ {MMSystem|fleebs|commands}
#T+ {MMSystem|fleebs|fleechecks}
#CR
backstab %1
}
#VARIABLE lastdir {} {}
#VARIABLE emergencystop {490} {100}
#ONINPUT {^(%t)$} {#VARIABLE lastDir %1} "" {notrig}
#TRIGGER {You pant and gasp, trying to catch your breath.$} {#IF (@emergencystop>%mud.hp) {
#T- {MMsystem|fleebs|commands}
#T- {MMsystem|fleebs|fleechecks}
} {#NOOP}}
#TRIGGER {^You have (%d) hit points. A suggested wimpy setting would be %d~% of that, or ~[%d~].$} {#MATH emergencystop ((%1*25)/100)}
#CLASS 0
#CLASS {MMSystem|fleebs|commands} {disable}
#TRIGGER {You attempt to stab %1 in the back with *, but miss.$} {
flee %reversedir( @lastdir)
@lastdir
fbs @backstab
}
#TRIGGER {You stab %1 in the back with *.$} {
flee %reversedir( @lastdir)
@lastdir
fbs @backstab
}
#TRIGGER {Not while you are in combat.$} {
flee %reversedir( @lastdir)
@lastdir
fbs @backstab
}
#CLASS 0
#CLASS {MMSystem|fleebs|fleechecks} {disable}
#TRIGGER {A %1 is hurt and suspicious - you can't sneak behind {her|him|it}.$} {
#T- {MMsystem|fleebs|commands}
#T- {MMsystem|fleebs|fleechecks}
}
#TRIGGER {You aren't wielding a proper weapon.$} {
#T- {MMsystem|fleebs|commands}
#T- {MMsystem|fleebs|fleechecks}
}
#CLASS 0
[/code]

As you can see there are two oninput triggers now. Suggestions? thoughts? answers?

Posted: Tue May 16, 2006 7:27 pm

My suggestion will be to create one package that has all of your "common" functions in it. And then have your other packages use the common package. Eventually there will be a way to specify package "dependency", but to start with you'll just have to give instructions in the description to make sure people get both packages.

No, there is not a way to eliminate duplicates. In fact, it's important that a package is not allowed to do something severe to another package, like overwrite it. In general, your package cannot effect someone elses package.

One other feature that will eventually help you are events. You'll be able to set up an event and then respond to it in your different packages. For example, you would set up your #ONINPUT pattern as an event. Then each package just has an event handler for this. So there isn't any increased lag because the event just gets triggered once and then goes through the packages executing the different handlers for it. This is more efficient than having to match two identical trigger patterns. Won't be in the first beta, but that's the direction I'm going.

And, of course, since CMUD is faster, these concerns are less of an issue than with zMUD already.

Magician Joined: 29 Nov 2005 Posts: 482

Okay after thinking about this a bit more i wouldnt want it to combine it for ease of removal. If someone uninstalls something i dont want it to mess up whats already there.

Guess i will just rewrite a major amount of those components and split them into shared libraries. I was already doing this for variables and aliases as it stands.

Instead of having a root folder full of those things. I split them into shared and independent variables/aliases/triggers etc.
i.e.
VARIABLES|statusbar
Variables|bagcounter
etc. so removal would be easy in zmud.