Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ Internal World Variables

Internal World Variables

It is now over 60 days since the last post. This thread is closed.     Refresh page


Pages: 1 2  

Posted by Dave   Australia  (93 posts)  Bio
Date Wed 10 Apr 2002 07:50 AM (UTC)
Message
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).
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #1 on Wed 10 Apr 2002 09:59 AM (UTC)
Message
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #2 on Wed 10 Apr 2002 11:11 PM (UTC)
Message
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
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #3 on Thu 11 Apr 2002 02:06 AM (UTC)
Message
Quote:

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.


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.


Quote:

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


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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Dave   Australia  (93 posts)  Bio
Date Reply #4 on Thu 11 Apr 2002 02:16 AM (UTC)
Message
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?
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #5 on Thu 11 Apr 2002 03:29 AM (UTC)
Message
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");

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #6 on Thu 11 Apr 2002 09:37 PM (UTC)

Amended on Thu 11 Apr 2002 09:38 PM (UTC) by Shadowfyr

Message
>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:


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


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
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #7 on Fri 12 Apr 2002 12:15 AM (UTC)
Message
Quote:

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.


You can do that in MUSHclient like this:


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


Quote:

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


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



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.


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. :)

Quote:

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.


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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #8 on Fri 12 Apr 2002 10:25 PM (UTC)

Amended on Fri 12 Apr 2002 10:31 PM (UTC) by Shadowfyr

Message
>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:

sub SetReb (TrigName, Output, Wildcards)
  dim sGrab, sOut
  dim sMatch
  int tim
  tim = 0
  sMatch = split(wildcards(4),"; ",-1,1)
  for each sGrab in sMatch
    select case right(sGrab,1)
      case "d"
        tim = tim + 1440
      case "h"
        tim = tim + CInt(left(sGrab, b-1)) * 60
      case "m"
        tim = tim + CInt(left(sGrab, b-1))
      case "s"
        b = CInt(left(sGrab, b-1))
        if b > 30 then
          tim = tim + 1
        end if
    end select
  next
  world.setvariable "TTRB", CStr(tim)
  world.addtimer "RebootTimer", 0, 1, 0, "", 1, "RepReboot"
  world.enabletimer "RebootTimer", 1
  sOut = Rttt(tim)
  world.note "Reboot timer set."
  world.setstatus "Reboot is in " & sOut
end sub


function Rttt(tim)
  dim sRet, sOut
  int temp
  int temp2
  temp = tim
  if temp > 1440 then
    sOut = " 1d "
    temp = temp - 1440
  end if
  if temp >= 60 then
    temp2 = Int(temp/60)
    temp = temp - (temp2 * 60)
    sOut = sOut & CStr(temp2) & "h "
  end if
  sOut = sOut & temp & "m."
  Rttt = sOut
end function

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:

sub SetReb (TrigName, Output, Wildcards)
  dim sGrab, sMatch
  sMatch = split(wildcards(4)," ",-1,1)
  for each sGrab in sMatch
    select case right(sGrab,1)
      case "d"
        tday = 1
      case "h"
        thr = thr + CInt(left(sGrab, b-1))
      case "m"
        tmin = tmin + CInt(left(sGrab, b-1))
      case "s"
        if CInt(left(sGrab, b-1)) > 30 then
          tmin = tmin + 1
        end if
    end select
  next
  world.addtimer "RebootTimer", 0, 1, 0, "", 1, "RepReboot"
  world.enabletimer "RebootTimer", 1
end sub

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. ;)
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #9 on Fri 12 Apr 2002 11:33 PM (UTC)
Message
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"...

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #10 on Sat 13 Apr 2002 12:06 AM (UTC)
Message
Quote:

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.


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. :)

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #11 on Sat 13 Apr 2002 07:10 PM (UTC)

Amended on Sat 13 Apr 2002 07:14 PM (UTC) by Shadowfyr

Message
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"

for count = 1 to ubound(sMatch)
  sGrab = sMatch(count)
  ...do whatever...
next

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.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #12 on Sat 13 Apr 2002 09:16 PM (UTC)

Amended on Sat 13 Apr 2002 10:09 PM (UTC) by Nick Gammon

Message
Quote:

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.


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) ...


POSIX CHARACTER CLASSES
     Perl 5.6 (not yet released at the time of writing) is  going
     to  support  the POSIX notation for character classes, which
     uses names enclosed by  [:  and  :]   within  the  enclosing
     square brackets. PCRE supports this notation. For example,

       [01[:alpha:]%]

     matches "0", "1", any alphabetic character, or "%". The sup-
     ported class names are

       alnum    letters and digits
       alpha    letters
       ascii    character codes 0 - 127
       cntrl    control characters
       digit    decimal digits (same as \d)
       graph    printing characters, excluding space
       lower    lower case letters
       print    printing characters, including space
       punct    printing characters, excluding letters and digits
       space    white space (same as \s)
       upper    upper case letters
       word     "word" characters (same as \w)
       xdigit   hexadecimal digits

     The names "ascii" and "word" are  Perl  extensions.  Another
     Perl  extension is negation, which is indicated by a ^ char-
     acter after the colon. For example,

       [12[:^digit:]]


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.

Quote:

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.


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".

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #13 on Sat 13 Apr 2002 09:25 PM (UTC)

Amended on Sat 13 Apr 2002 10:08 PM (UTC) by Nick Gammon

Message
Quote:

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


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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #14 on Sun 14 Apr 2002 12:58 AM (UTC)
Message
[GOSSIP]: Magnum notices Nick Gammon subtly overlook his last posting.

Shadowfyr:

Sample output:

> 
uptime
Ages of Despair has been up for 9h 46m 58s.
The next reboot is scheduled for 19:05 CEST (GMT+1) on Sunday (in 15h 13m 2s).
> 
uptime
Ages of Despair has been up for 9h 47m.
The next reboot is scheduled for 19:05 CEST (GMT+1) on Sunday (in 15h 13m).
> 
uptime
Ages of Despair has been up for 9h 47m 2s.
The next reboot is scheduled for 19:05 CEST (GMT+1) on Sunday (in 15h 12m 58s).
> 

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).

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


60,540 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.