Internal World Variables

It would be nice if there was an option to make the variables save automatically with the World file, instead of a message popping up when I'm closing the World.

In case of a system crash, I'd like the latest variables available to me (I assumed this would be when I last clicked save, but found out it was only when the world closed and i clicked yes to saving the world variables).

That is a global option (File -> Global Preferences -> Closing).

Check 'offer to save world if only variables have changed'.

For the world in question you might want to check 'save world automatically on close'.

Finally you could make a timer that fires every 5 minutes, and does a (in a script):

world.save ""

That would save the world (including variables) repeatedly so they don't get lost on a crash.

I think the distinction here is that while you can set it up to automatically save the variables and world with a timer as you said, the save menu item and save button do not save the variables along with the world. I have tried and it most definitely does not. This seems a bit odd, since you have the option of saving them when you close the program, but it seems to be implied that they are not always saved with the world file, even when closing the client. As with several other things the help files fails to clearly describe what the client does/does not do in such cases.

Nice to know that a simple timer can solve this. The possibility that they may not be saved with a world.save is one thing that has prevented me from trying a few script ideas.

It may also be useful if some sort of array style variable was supported with the clients internal variables. There are serious limits to what kind of permanent information you can store in them and faking it tends, as Magnum pointed out, to seriously slow down the client. An array would be easier and less costly to access and create than 20 variables named Items1, Items2, Items3, etc. You can get around it using file access in a script, but that opens a different can of worms. lol

Hmm. Another thought... zmud and a few others allow a %name% syntax in triggers. The idea being to preform some task when the trigger goes off, but also store the contents of that wildcard for later use outside the main trigger. Someone can of course write a script to do someting like:

sub Saveit (nm, out, wildcards)
world.setvariable "Whatever", wildcards(1)
end sub

However if this is all you are doing it is seriously redundant considering the client already has the value, but not where you intended to put it. This would also make life easier for anyone used to having such a feature who may decide to ditch your buggy competition's client in favor of MUSHclient. lol

Saving the world file ( File -> Save, pressing the Save icon, or doing a world.save ) will all save all aspects to the world, as you would expect, including variables.

I hate to contradict you, but I just tested it with a new variable, did a save, closed the world, reloaded it, and the variable was there.

The only distinction with variables is that you can set an option in global preferences to not consider changing a variable to be a change to the world. This is so that scripts which use variables for "work" purposes don't have to save a world which is otherwise unchanged. However, if you *do* save the world, the variables are saved too.




I think you mean:

world.setvariable "Whatever", nm

I can't see much point in a %name% variable. zMUD lets you do scripting "inline", whereas MUSHclient puts scripting into the script file. If you are in the situation where the script needs to remember the name of the trigger that called it, just save the "trigger name" argument, as in the example above.

As for arrays, interesting idea. You could look at what someone else did, and do an ODBC interface, so you can actually store data in a database. This is a nice extension to MUSHclient, as a database is fast, can store large amounts of data, and is automatically saved, so you don't need to worry about saving variables.

When i use world.save("") (in JScript), it opens the file dialog, as a "Save As", instead of just saving it automatically as the normal filename with no dialog box. Any way to fix this?

Oops, an earlier change caused this bug.

You are the first to notice.

I have added this as bug #459.

As a workaround, I suggest finding the full pathname of your world file and putting that in. eg.

world.save ("c:\\mushclient\\myworld.mcl");

>I hate to contradict you, but I just tested it with a new
>variable, did a save, closed the world, reloaded it, and
>the variable was there.

Ok.. I hadn't noticed if it save the variables, just that it continued to insist that they had changed, even after forcing a save from the menu.

>I can't see much point in a %name% variable. zMUD lets you
>do scripting "inline", whereas MUSHclient puts scripting
>into the script file. If you are in the situation where the
>script needs to remember the name of the trigger that
>called it, just save the "trigger name" argument, as in the
>example above.

Something got lost in the translation here. lol By %name% I meant any variable. EX:

'You see a fuzzy bunny.'

Would yield a trigger like:

You see %s(mob)

As opposed to 'You see *'. This allows people using zmud to set a variable without having to do it in the script itself.
In the above case it would be a (s)tring as opposed to %d or %w, which are numbers and words respectively. In my previous example you have to create a script to set a variable, even if you don't want to do anything with the result at that specific moment. There is no functional difference in inlining a script and using MUSHclients method, but it is redundant to have the client retrieve a value in a trigger and then have to use a script command to store it. In this respect zmud does have a small advantage imho. Of course if you do not give it a (name) part then you still have to deal with it in a script, but at least you know that it had to be a number, word or string and not a false match on what is simply a very similar line.

>As for arrays, interesting idea. You could look at what
>someone else did, and do an ODBC interface...

True. To a certain extent it is generally preferred to not rely on something that may not be installed/working on someone elses machine, especially if you are considering sharing a script with other people. The odds of picking a database type that does not come preinstalled on most peoples computers is significantly higher and less easilly corrected than choosing the wrong script. Also.. I was under the impression that direct access to ODBC is not really possible and you need a server object running to do it. This complicates things even more, since it forces someone to install another program on their computer. The only free one I am aware of is MySQL and, while i don't remember the precise reason at the moment, I concluded it was more of a hassle than a benefit to install it.

Frankly I have enough trouble trying to figure out why something like this:



refuses to work despite 'for each' saying it deals with 'Name of an object collection or --array--' and 'split' insisting that it creates an --array-- based on the expression it is given. With the glitches in vbscript I really don't need to complicate things by getting a database interface to work. ;) lol

Wish I could figure out the reason the above code fails though.. I could shorten one of my script to less than 4 lines if I could get it to work. Of course the zmud version of a similar script also bugged oddly and made what should have been 3 lines into 6 in order to fix it, so yah just can't win. lol

You can do that in MUSHclient like this:


Trigger: You see *
Send: %1
Send to: Variable (label is name)
Label: mobname




You have a minor coding bug there. You mean "for each b in a" - a is the array, not data. It should read like this:


dim a, b
a = split(data," ",-1,1)
for each b in a
...do stuff...
next


I tried that in immediate mode and it worked. :)



There are other posts here about accessing ODBC via scripting. I think that would work, eg. to an Access database, without needing a server. However I have tried MySQL and it works very well (and is free).

If you want to be more specific about alphas or numbers use a regular expression in the matching part and use the appropriate regular expression.

>Trigger: You see *
>Send: %1
>Send to: Variable (label is name)
>Label: mobname

Hmm. Yes, but this won't -

Trigger: You see *
Send: follow %1
Send to: ??? (Oops...)
Label: mobname

You see the problem, you can't send it to more than one place, so you can't A) perform an immediate action and store it at the same time without scripting. and B) this was a simple example and thus doesn't take into account multiple variables in the trigger string and the need to differentiate what 'kind' they are. Of course scripting it is not that big a problem, since things like the status line do not 'as far as I am aware' act as self updating trigger (or maybe it is more like a timer...) in MUSHclient. In zmud they do and thus you can create a status line like:

#setstatus, You are carrying %ston stones and %sor sorcen *
(not sure of the exact syntax..)

and create a single trigger that does nothing more than:

Trigger: You are carrying %d(ston) and %d(sor) *
Send: nothing

Since MUSHclient's status line probably doesn't work this way it isn't as helpful to be able to use a simple trigger without a script. However, you could create a timer to update it the status, in which case it is still nice to do without the extra script code, which does nothing functionally different that Sendto: Variable, save allowing multiple variables and send a command.

It is not necessary to have such function with scripting, but it does provide the means to do without scripts in some cases, such as with following the bunny. In which case you could later use an alias to attack or spellcast on it without needing to enter the name. You can send a more than one variable to the mud in a trigger/alias it is sort of odd that you can only set one at a time and then only if you don't plan to also execute a command using that trigger.

>You have a minor coding bug there. You mean "for each b in >a" - a is the array, not data. It should read like this:

>dim a, b
>a = split(data," ",-1,1)
>for each b in a
> ...do stuff...
>next

>I tried that in immediate mode and it worked. :)

Trust me to type from memory...

The original test code got deleted, but it was more like the following:


The 4th wildcard contained something like '1d 8h 43m 6s' or '33m 5s', etc. depending on the actual time to reboot. I ended up using a slightly more complex 'for 1 to ubound(sMatch)' loop instead. Could be I did mess up the way you suggest though, but I was fairly sure that I hadn't made such a dumb mistake. :p

Note that with self updating status and the ability to treat variables as something other than strings the code would have been more like:

Which is significantly shorter and nearly identical to what I used in the zmud version. Though I have found that things like 'if CInt(left(sGrab, b-1)) > 30 then' often cause odd errors in vbscript... Seems a variable it ok, but in some cases imbedding a function inside of a command causes it to generate errors... Bloody annoying. Obviously if this was not the case, then I could also eliminate the need to put the contents of the split into a variable. This sort of bug also appears in zmud's scripting in a quite a few places.

Note: In both cases a timer calls Rttt every minute, but in this modified version it does not build the string, but just decrements variables.

Anyway.. Maybe I will try again with something else (or maybe rewrite what I am using), but for now it is a bit of a null issue, since what I am using works, even if it is slightly more complex than it really needed to be. ;)

Nick: Regarding the save file prompt, I concur. I will hit the save icon, click the disconnect icon, then click the "x" close window icon, and will be prompted to save updated variables, despite not receiving any output from the MUD in between those actions. I do not run any script on world close or disconnect. (Only on world open).

Shadowfyr: I see this line: "for each sGrab in sMatch", but I do not see you defining 'sGrab' before that statement, which would lead me to assume that 'sGrab' is Empty. In other words, you may as well be putting: "for each Empty in sMatch"...

I know you are giving a simple example, however in the example you *can* do that. You can make two triggers:


You see *


Provided they send to different places you are allowed to do that. Set them both "keep evaluating" and they will both be executed, thus you can set a variable, and do a response without scripting.

As for automatic status lines, I agree it sounds nice. However this is a bit of a design thing. I think the automated status lines might save a bit of scripting, at the expense of being a bit more complicated to understand. At least with scripts it is "procedural" so you know that things only happen because you tell them to, not because some trigger somewhere updated a variable that then automatically updates the status line. However both methods are quite workable. :)

Ok. First to magnum: ;)

The 'for each sGrab in sMatch' command works exactly the same as the following for x to y loop:

dim sMatch
sMatch(1) = "a"
sMatch(2) = "b"
sMatch(3) = "c"

It basically takes each element of the array and automatically tranfers it into the variable you provide, in this case sGrab, providing a really nice short cut when it works. The problem I was having had to do with the fact that it didn't seem to want to recognize my newly created array, but I may have just done something really stupid. ;)



To Gammon:
Gah... I have enough triggers without duplicates (of which you can't tell one from another without editing all of them). lol

However the ability to specify types would still be nice. As it is you can use regular expressions to make sure that a line 'contains' something, but unless you then use the full output in a script to pull out that bit you can't both 'make sure it is a number' and 'pass it to a script'. Well, you can test it after it gets there, but the point is to avoid false alarms in the first place. ;) Auto variable setting would be nice in some cases, but the ability to tell the trigger to accept only a number or one word could be useful in some cases. From a purely ease of use view it is hard to tell what exactly the trigger does/doesn't do based one something like 'abc * abc * abc *', especially if you do use more than one identical trigger to set variables. It can get confusing trying to figure out which one is which. Being able to place the variable in the trigger may not be 'necessary' but visually it is a lot easier to understand.

As for the status thing, using a timer that trips every minute and uses world.setstatus would have exactly the same effect as an auto trigger, but the trigger(s) needed to grab values would still end up being fairly complex. Also, even with the auto update, it was necessary to decrement the time, so it really didn't do anything more than eliminate a single line from a script I had to have anyway. I don't think it is a major issue, but it was a good example of how having the variables in a single trigger can sometimes be far less of a hassle than the 'gludges' you need to accomplish the same thing with MUSHclient. And multiple triggers is a very inelegant cludge imho. ;) "Hmm. Square wheels don't work.. I got it, octagonal!!" lol

As a minor side note... One major problem with both the systems in MUSHclient is that you can define 'optional' content, but not optional wildcards. One reason I had to do the complicated chop job to get days, hours, minutes and seconds was that the content could have any or all of those things. The only way to make them optional is currently to make at least 14 triggers to match every possible combination. This may be possible, but definitely not efficient, never mind having to slog through an additional 14 triggers, besides whatever you already have, when you need to edit one.

Of course making it work as optional in the trigger.... I suppose you would need to do something like [*[h]] [*[m]], to mean get this if you see values in one of these places followed by the letter, but otherwise leave that wildcard blank. i.e. You still need to return 'all' possible wildcards, but with values only in those that matched. Hmm... Not even sure what the proper syntax would need to be. :p Well it is an idea, but implimenting it may be troublesome.

You can do a lot of type-checking in regular expressions. Here are some examples from the supplied documentation ...


The third use of backslash is for specifying generic character types:

\d any decimal digit
\D any character that is not a decimal digit
\s any whitespace character
\S any character that is not a whitespace character
\w any "word" character
\W any "non-word" character


For example, you can match on one or more digits (ie., a number) ...


(\d+)


The brackets make it get returned as a wildcard. What about a signed number?


([-+]?\d+)


The "?" is the "zero or one" qualifier, so you are looking for zero or one signs, followed by one or more digits.

You can also use Posix classes for much the same effect but a bit more readibility (maybe) ...



Next, you can use repetition to limit the number you are looking for, eg.


(\d{3})


The above would find exactly 3 digits.


(\d+{2,})


The above would find 2 or more digits.


(\d+{2,6})


The above would find 2 to 6 digits.



Strangely enough, you can make optional wildcards in regular expressions. I stumbled across this, which is either not documented, or is rather obscure ...

Try this out as an example:


Match: will eat (fish )?chips
Regular expression: checked


The above will match on:


Nick will eat fish chips
Nick will eat chips


By putting something optional inside round brackets, and then following it by "?" (zero or one qualifier) then you make the whole contents optional. And, as something in round brackets are returned as a wildcard, then you have an optional wildcard. Tada!

I used that idea recently in another post, where someone wanted to match on a "who" list that had optional words at the end. By using the optional wildcards idea you can have one trigger that matches on all sorts of optional words. Something like this, from memory ...


(.*) (pk )?(afk )?(admin )?


Provided you know the order (and as it is machine-generated the order ought to be predictable) then that will work.

Finally regular expressions let you do this *or* that. eg.


(newbie|admin)


That will make a wildcard that matches on the word "newbie" or the word "admin".

Recent versions of MUSHclient let you see the label in the trigger list (and sort by label). The idea here is that you give the labels meaningful names. Why not? eg.


match_on_the_bunny_with_the_rabbit
match_on_the_bunny_without_the_rabbit


You can drag the "label" column heading over to the left, so it is easier to read (eg. the left column) and then sort by label. That way you should be able to organise your triggers better.

[GOSSIP]: Magnum notices Nick Gammon subtly overlook his last posting.

Shadowfyr:

Sample output:

You could of course just match on something like this:

The next reboot is scheduled for * CEST (GMT+1) on * (in *).

...then have your script poke and prod at the third wildcard, and tear it apart as needed. Personally, I would find this more efficient that a trillion triggers. Seems to me, more triggers slow the client down, better to have fewer and have the script do the hard work. (Check out the "InStr" function).

Personally, I would prefer Nick not incorporate major features into the client, that would slow it down... I'm running on a P166, and I'm borderline now. I feel I've pushed the limit with my 120 mushclient variables, 170 triggers, 256 aliases.

(Those triggers have used 8.6 seconds in 1h20m connection time).

Your triggers have used 8.6 seconds out of 4800 seconds? or, 0.001792% CPU utilisation of a P166. Doesn't seem so bad to me ;)

...or use Nick's extensive documentation to build a single trigger. It COULD be done, and you would end up with the hours in one wild card, minutes in another, and seconds in the last...

Actually, Dave, for the most part, I've just been idle on the mud, so that may not be reflective of performce when I NEED performance... :)

The number of aliases seem to be what's pushing the line most. Once in a while my spell queue will mess up. I'll have it paused, but something in the game will trigger script to add more spells, and my variable list increases dramatically, since each spell in the queue requires about 4 variables in my script. It only takes about 5 spells in the queue, and I'll notice a dramatic slow down. 10 or more spells, and the stall is intollerable.

Also, i don't know if trigger time increases as more hits are made... If so, the example I posted was very innaccurate, since I was idling. When I am out fighting solo, the trigger fires go up dramatically, and in a party they go even higher... and that's when I need the client to be going as fast as it can, cause I'm often in danger. :)

Are you using MXP? MXP sets variables like roomname, hit points etc. Timers? Timers might set variables.

In the case of:

The next reboot is scheduled for 19:05 CEST (GMT+1) on Sunday (in 15h 13m 2s).

using:

The next reboot is scheduled for * on * \(in (\d+)(d)?(\d+)(h)?(\d+)(m)?(\d+)(s)\)\.

If it only finds some of the matches does it still return the same number of wildcards or only the number found? And even assuming it did, the result would still be worse than what I already have, since the idea is to get the number values (if they exist), but not have to check to find out 'which' number it actually found. If everything in a () gets shoved into a wildcard and there is no way to 'fix' the number of them passed to the script, then it only makes things more complex rather than simpler. I just don't see any way to do it if the information you are retrieving is of a nature that you cannot easilly distinguish it from other items or you want to avoid the need to distinguish them at all. Fact that I find a bit annoying. ;)

Because of this I currently use:
The next reboot is scheduled for * on * (in *).

I would prefer a more efficient way, but it doesn't appear that one is possible. As for Magnum's comment about slowing down the client... I am not sure how placing a value into a variable instead of, or at the same time as, a wildcard would be significantly slower. Variables themselves do seem to create extra overhead when you have too many for some reason (you need to look into this), but the actual act of puting the value into a variable instead of the wildcards should be only the number of clock cycles used to preform a check to see if it is * or %, retrieve the name after the % if it is there and set a variable with that name. The code already has to do most of the things needed to make it work, just to corectly figure out what needs to be put in all the * locations. Frankly I am sort of surprised regular expressions in general (if not in this client) don't already have provisions for doing it, except that most places they are used is not in retrieval of values, but simply in identification of a match.

However... Assuming that what I indicated in my example is possible in general, i.e. (\d*), then it does solve some of the more general problems when you do know what is likely to be popping up and is definitely nice to know about.

Now as to the very last post about variable saving... Nope. It doesn't matter if MXP is active or not, it still insists that variables have not been saved.

I turned MXP off again on mine because my work around turned out to not work quite as well as I thought it did. lol Guess I will just have to try to convince the people that recently took over admin of the mud to make it MXP complient. ;) Not bloody likely though... However, even with it turned off it still does not recognize that the variables are saved.

A quick test with my earlier example reveals that the wildcards are returned even if empty. In other words, you would get 8 back. Mind you, if you are using regular expressions your example is a bit wrong in the early bit. It should be ...


The next reboot is scheduled for (.+) on (.+) \(in (\d+)(d)?(\d+)(h)?(\d+)(m)?(\d+)(s)?\)\.


(In other words the asterisks on their own won't work).

Now you are up to 10 wildcards which is pushing the limit a bit, however you don't really need the letters d, h, m and s returned, as they are fixed. Thus it could be:


The next reboot is scheduled for (.+) on (.+) \(in (\d+)d?(\d+)h?(\d+)m?(\d+)s?\)\.


That ought to work, then wildcard 3 is always the day number, wildcard 4 the hour number, wildcard 5 the minute number and wildcard 7 the second number. No fiddling required.

Yes, I do (and am probably famous on the mud for it) use a timer that fires once an hour:

[bs]: Magnum curses negative exp!

No MXP.

Can't really explain it then. Either a bug, or you are setting a variable somewhere without realising it. :)

Maybe a diff on the two world files would show what it was. Or, write a little script that exports all variables to a text file, then:

1. Run the script, giving file1
2. Do whatever you do, disconnect etc.
3. Run the script, giving file2
4. Compare the two files

On second thought, I should point out, my timer does not update (or even use) any mushclient variables, it simpy sends an output line to the mud, nothing fancy. (Doesn't even call script).

I'll consider your suggestion later... Don't feel like logging off now. :)

>The next reboot is scheduled for (.+) on (.+) \(in (\d+)d?(\d+)h?(\d+)m?(\d+)s?\)\.

Hmm. Nice to know it does pass the same number. Just checked the vbscript help I have and looks like should work (assuming the ?s will correctly ditch the letters). Makes things a bit simpler that way. I will try it and see.

As to the variable thing.. The only thing that would be setting variables is my timer. Most everything including scripting though is diabled/non-functional when the client is not actually online and since the timer only ticks every minute the odds of my always hitting close just after saveing and as it executes is extremely unlikely. I think it is definitely a bug.

I have added the saving problem as bug #462.