Zugg Software :: Search

You would use the %format function

#HELP %format - to pull up the help file

Due to the indirect way they are referenced, exec forces things to evaluate/be parsed that otherwise wouldn't.

Personally, I would use a dbVar to handle storage, which means the local variables can ...

I tend to break stuff down and segment it to protect from corruption.
Compartmentalization.
It effectively serves as a backup of known good code as well

Any corruption that matters will only be ...

I have had to Would you be willing to share a copy of one of your mud packages? The whole thing, I mean, modulo any sensitive data. I'm curious what good cmud style looks like from your perspective, ...

Who told you that those things were bad?

There is nothing wrong with #EVENTs.
#SIGNAL is another threading command.

Enabling and disabling is also fine, so long as you aren't turning off variab ...

This outlier situation probably has more to do with whatever caused the corruption in the first place.
Variable definitions are usually very reliable.

#SECTION and threading, in general, is one of ...

I think it would only be using more in those high-stress situations.
Or maybe it uses more CPU processing instead.

As for the command stacking issue, you could always set a command queue for thos ...

More that the amount of RAM your system has can drastically affect the performance of laggy scripts.

Do you have a permanent prompt trigger?
Seems like you could do away with that unfortunate-loo ...

That also depends on your system.
Have you looked into using a dbVar?
With that, you could house all of your utility variables in one master variable...at root.

Typically I have it up for running till I finally give in to the windows update requests.
A week or three at a time.
It was a bit more frequent when creating and coding new scripts (several times a ...

It is possible, though I am unaware of the circumstances for such off the top of my head.

I know editing multiple rooms on the map simultaneously can mess up the creation of the next room, but that ...

My guess is that the class/folder you house the variable in is getting disabled somewhere.

This forces the next definition to resolve at the root because there is no active variable with the name. ...

I have seen settings become attached to the map before.

You need a clean export to Import properly, and if your settings are corrupt, well, you might not get it all.

This is why proper backup pr ...

You don't use the @ of the dbVar when going an #ADDKEY.
You also want to enclose your expression in parentheses.

I have never seen this issue myself.

Speculation... there is usually a master window of a given tabbed group (all the other windows are tabbed to it, and its position is usually relative to the mai ...

I take the boolean method one step further and do a test for any non null value, and since 0 is equivilent to null...:

#IF (@autosc) {autosc=0} {autosc=1}

There is a helper for this very thing built into CMUD.

If you make a new trigger via the settings editor, switch to the pattern tab and enter the raw text into the line marked Text.

But in this ...

It's a 2 state trigger, only numbering starts at 0.

State 0
Just resets the Variable

State 1
Is of type within, with a param of 1.
This means: check the next one line for this pattern before ...

Unfortunately, you cannot delete map rooms via script, only via the GUI.
It's possible the room is stacked under another room square.
You may be able to select it by turning on panels under view and ...

#TR {<(%d)H (%d)M (%d)V (%d)X (%d)~%D (%d):(%d):(%d)>} {#IF (%5>70) {weave fireball}} "" "prompt"

Should do it.

You need a stated trigger, something like this:

#TR {It contains:} {contents=""}
#COND {*} {
contents=%concat(@contents, %line)
#IF & ...

Try exporting your settings to XML and then import them to the new session.

You should simply be able to load in the map file of your choice.

Parenthesis() are only needed when passing arguments to a function, or when defining an equation to be tested against.

Which works for %exec as it is a function.

But not with #EXEC which is a co ...

#exec {#rep @howmanytimes {%item(@anything,@anythingListRowNum)}}

#rep @howmanytimes {#exec %item(@anything,@anythingListRowNum)}

I am thinking it might be the quote marks, try pulling those out.