Aliases work almost exactly like triggers, but respond to your input, not text from the mud itself. Otherwise they behave exactly the same. As for scripts... In the version you are using there is only one option, a primary script. This script holds all code for performing different tasks. Later versions added a 'plugin' system, which basically combines all timers, triggers and aliases needed for a specific task into a file, along with all the script needed to make it work. This means that using such plugins one person can create one to keep track of gate locations and then anyone can use it for that mud, or with a few changes, with any mud that uses a similar system. Even more recent versions use 'inlined' scripts. This means that if all you need to do is have an alias disable a trigger, you can place the code needed to make it work in the trigger itself. Also, as old as yours is, most of the postings about triggers, aliases and timers won't make any sense anyway. All files used by Mushclient are now XML based, so if someone posts an alias example, they will probably post it as XML, so users of the newest versions can simply cut-and-paste it directly into the client.
As for the scripts themselves. Aliases and triggers use three storage places for the information they return. The first one contains the name of the trigger or alias that calls the script, the second always contains the entire line which the trigger or alias matched, the last one contains a list of "wildcards". In other words if you have an alias like:
match="k * *"
name="killit"
script="killstuff"
Then if you typed 'k kobold knife', the containers would be:
1st. = "killit"
2nd. = "k kobold knife"
3rd. = array {kobold, knife}
In the script itself (assuming you use VBScript), this would look like:
sub killstuff(name, output, wildcards)
note name
note output
note wildcards(1)
note wildcards(2)
end sub
The above would basically just display each item the sub recieved like so:
killit
k kobold knife
kobold
knife
If you look in the example files or other peoples, you may notice different names. For instance: (tName, output, wilds). This is because the name is just a label, to make it easy for you to tell what each of them should contain, you can call them anything you like, just as long as the name makes sense to you and you provide the right number of them.
Timers are a bit different. A timer is not matching a line and it cannot return values, so it only needs the first 'container' in order to pass the name to your script. Also, if you have a special function you create, then 'you' determine what it needs. For example, maybe you want to take two numbers and multiply them, then return the result:
function multip(num1, num2) 'A bit silly, but it is an example. ;)
multip = num1 * num2
end function
In this case you tell it you are going to give it two values, so it only works if you use two values. This confuses some people new to Mushclient, since they assume that because triggers and aliases require name, output and wildcards, everything else must too. Those are however only needed though when Mushclient calls scripts, not when you call your own script from inside itself. As another example, I have one plugin that takes your current HP and maximum, calculates the % you have of the max and determines a color to use when displaying your condition. The code is roughly like this:
sub showcondition(name, output, wilds)
current = wilds(1)
max = wilds(2)
percent = current/max
color = 120 * percent
brightness = 100 + (150 * percent)
newcolor = getcolor(color, brightness)
colournote newcolor, "black", "HHHHH"
end sub
function getcolor(hue, lum)
sat = 255
...Do stuff to figure out what color this is...
getcolor = newcolor
end function
The code for it is not exactly like above and getcolor actually calls a second function to do other things. The point is getcolor can be used in "any" place I need it and getcolor itself, in the real version, needs to do the same math three different times. It is easier to have it call a second function three times, instead of copying the twenty lines of math equations for each and every time it needs them.
The best way to learn is probably to look at stuff other people have created. If you can find a book on Basic is may help some too, since that will have examples of how to make certain things happen. VBScript is probably the most understandable of the choices in any case. If you got a book on Java, Perl or Python (the later two require installing other programs to use), then you still end up trying to figure out not only what all the commands mean, but also trying to figure out why some stuff won't work like the book claims. This will still happen with VBScript, but at least he commands in Basic make some sense. VBScript was designed for running stuff on web pages, so some things work a bit different when used in Mushclient or not at all. For the most part, once you get the hang of how and why Mushclient calls scripts and sends information to and from them, the rest is not hard to get the hang of.
The "Help files for scripting version 5.6", you meantion in the other thread is not going to provide examples. It is basically like a dictionary, you look up a command and it tells you what things is accepts and *maybe* gives you a mostly useless example of the basic use. Occationally their examples are more confusing than helpful, but it is still useful to have, for the same reason the a dictionary is useful. If you have a general idea what you are looking for or just want to check to make sure you remember how to use some command, it is very handy. For real examples, you are better off looking at stuff other people have already created for Mushclient.
As for starting with the example files (from your other post). Those are to help provide a 'simple' starting point. If you do use one, make a copy under a new name, like 'myscript.vbs'. **Never** use the original file. If you ever install a new version of Mushclient, it will write new example files (possibly with new examples in them) right over top of the ones already there. So, always use your own name for the one you plan to keep.
Now.. There are several ways to deal with your gate locations.
1. Use script functions to open your text file, then read it all in and display it.
2. Hand code all the gates in, so the script doesn't need to read it from a file.
3. Upgrade to a newer version and use a plugin that does the same as #2.
4. Upgrade to a newer version and make a system that lets you enter new gates and stores them.
All these have advantages. In the case of the first, you are using the same text file to display the information as you already have. However, Mushclient needs to waste time retrieving this information at least once each time you open the world. The sceond one is the easiest and you don't need to upgrade. However, I did that myself initially and now every time I need to add new information to the script, I have to hunt through 10 pages of stuff to find the place I need to edit it. However, reloading the changes is simpler and can even be set up to happen automatically. The third option means you have to upgrade, but you can put all the stuff for your gates in one seperate file. When you change it, you only need to look through 'that' file for where to make the changes. This is a lot easier. However, plugins must be manually reinstalled to make the changes usable.
The last option is probably the best. While it means upgrading to a version of Mushclient that supports plugins, you can use aliases in Mushclient to add to or change the gates and as long as the 'state' file for your plugin isn't lost, the information will be both permanent and available the moment you make a change, no need to reload. However, the programming needed to make it all work is a bit more complicated. I would however be happy to help out, if you can provide some idea as to what exactly you are keeping in the list of locations you need it to show. I have already made something similar for myself that shows me some 30+ places on the mud I play and lets you move quickly to and from any of them. If anything a mages 'gate' or teleport spell is bound to be easier to manage. ;) lol |
![[Go to top]](/images/gototop.gif){kind=small}
top