Anyone needing/wanting help with zMUD?

[Taziar]

That would be cool, I would like to see that

[Taziar]

Have an updated version of this script posted on my zMUD script post @ wotmudarchives.org forums in the zMUD section there.
edited 12/7/2015




Here is a version of an ON! script like Spyder was talking about in previous post. I have done some testing, but any feedback or ideas to make it better would be great. You need Markus's Map scripts installed as this script uses his find alias to reset your map location. This script will work for any side. You need colors turned on for this to work as the triggers to capture cross race names are ansi color triggers.

When fighting any number of cross race opponents type: on
Script will send a find command (look) to set current location, this will get current room name, room short name, and look for any colored names inside asterisk.
If there are no cross race names captured in 1 second from the on command when looking in the room it will not narrate.

You will then narrate ON! -short room name- PC names -room name-

Example Taziar narrates ' ON! -asaw- Spyder Griznak Tempest Fong -Road to Tarwin's Gap-

Code: Select all

#CLASS {narrateON}
#ALIAS on {
  #VAR CrossNameON {}
  #VAR onNameAll {}
  #VAR onNameEX {}
  #VAR RoomNameON {}
  #VAR RoomShortName {}
  #VAR RoomShortNameON {}
  #T+ narrateON|triggerON
  find
  #WAIT 1000
  OnNarrate
  }
#ALIAS OnNarrate {
  #VAR onNameEX %expandlist( @onNameAll, " ")
  #VAR RoomNameON %roomname( )
  #VAR RoomName %concat( "-", @RoomNameON, "-")
  #VAR RoomShortNameON %roomid( )
  #VAR RoomShortName %concat( "-", @RoomShortNameON, "-")
  #IF %numitems( @onNameALL) {narrate ON! @RoomShortName @onNameEX @RoomNameON}
  #T- narrateON|triggerON
  }
#VAR RoomShortNameON ()
#VAR RoomShortName {}
#VAR RoomNameON {}
#VAR RoomName {}
#VAR CrossNameON {}
#VAR onNameAll {}
#VAR onNameEX {}
#CLASS 0
#CLASS {narrateON|triggerON} {disable}
#TRIGGER {~*%e[31m&%wCrossNameON%e[0m~*} {#ADDITEM onNameAll @CrossNameON} "" {color}
#TRIGGER {~*%e[35m&%wCrossNameON%e[0m~*} {#ADDITEM onNameAll @CrossNameON} "" {color}
#TRIGGER {~*%e[36m&%wCrossNameON%e[0m~*} {#ADDITEM onNameAll @CrossNameON} "" {color}
#CLASS 0

[Jomin]

I had an idea a long while back when I was still actively Mudding instead of coding a client to extend a room name report to also include a 4 hex digit hash code that was generated from the room description in a predictable way. I developed a patch for TinTin++ to use that to find rooms very quickly - it was conceived to reduce the imprecision for things like roads where there are many rooms with the same name and to work with different clients with different maps or even map systems. The speed-up in TinTin++ came about from only having to check a small number of rooms for actual name and description matches instead of the whole map and I felt it was good enough for real time location from a unique room name and description pair - it is still around on the TinTin++ forum here and if ported into the current code would still be useful, IMHO.

Of the calculations:

Code: Select all

The value ...[is]... from the room descriptions for the map where
a non-null description is converted to an unsigned short (0 to HASH_SIZE-1)
hash value derived from the room description by taking the ASCII value of each
character, multiplying it by its position [starting from 1 for the first character] in the description and taking the
modulus HASH_SIZE of it added to the running total ... It is suggested that
when using a multi-line capture to gather room description text the end
of (all but the last) line string (2+NULL character) of "\n" is used - then it
can be displayed on screen with an #ECHO.

Edit: FYI Hash size was 2^16 i.e. values range from 0 to 63535 inclusive {= 'ffff'}.

The handling of end of lines is important for cross-client compatibility so that every different one works out the same value for the same, complete, multi-line room descriptions and from what I recall of my TinTin++ scripts I stored the room descriptions without a leading or a trailing end of line. If anyone wants to do something for their client can I suggest this as a common format for such things? For a test, the description I had stored for the "Caemlyn Central Square" was:

Code: Select all

You are in a large stone square, right in the middle of Caemlyn's outer
city. You see a wide boulevard to the north, and the path to the inner
city. There are a number of shops around you. The density of the population
is really quite incredible. It's almost impossible to relax as you are
being constantly bumped and jostled. From here you can really get a good
view of the outer city, and this just makes you appreciate the older inner
city all the more. A large banner hangs nearby, depicting a map of
Caemlyn's outer city.

which yielded a hex hash value of: ef35
which my scripts would have sent/received as "Caemlyn Central Square[ef35]"

[Yves]

I like this idea and have done something similar in my setup. You do have to be a little careful with how big the hashes are, though. Ideally, hashes are unique with a very low chance of collision. It's useful if I can type `go ef35` and it goes unambiguously to Caemlyn Central Square. If there are multiple rooms with the same hash, however, it loses some of its usefulness as a universal shortcut. With only 65536 possible hash codes and a mud of 30k+ rooms, the likelihood of collision is really high.

So you'll probably want to make the hash longer as a start. And, further, if it is computationally feasible maybe you could do something a la Git where they calculate super long SHA hashes but just shorten them whenever possible.

Code: Select all

> go ef35
| ef35 is ambiguous. Did you mean:
| ef35a73f24 - Tear Road
| ef35b431be - Caemlyn Central Square
> go ef35b
| Pathing to Caemlyn Central Square [ef35b]

[Taziar]

Thanks for posting all the weave trigger patterns folks, that is helping me with a script since I don't play much fc/mc. Now does anyone have the patterns for all the messages you get when you successfully channel these weaves?

[iria]

anyone have a spin timer for zmud? I think that is what its called,

so the bash goes----- and not:
-
-
-
-

[Yeri]

Link to a download is here: http://wotmudarchives.org/forum/viewtop ... f=8&t=2322

[meryk]

Hi was wondering if anyone has the target script that used to be around. was like ta, ta2, ta3 etc...

[Jomin]

I like this idea and have done something similar in my setup. You do have to be a little careful with how big the hashes are, though. Ideally, hashes are unique with a very low chance of collision. It's useful if I can type `go ef35` and it goes unambiguously to Caemlyn Central Square. If there are multiple rooms with the same hash, however, it loses some of its usefulness as a universal shortcut. With only 65536 possible hash codes and a mud of 30k+ rooms, the likelihood of collision is really high.

With around 30K+ of rooms that was what led me to 2^16-1 i.e. 65K codes; for WotMUD there ARE some clashes and usually that is down to them having the SAME description (for example: Wisdom Houses or the two adjacent rooms west of the Manor House east of Caemlyn, ONE of which has an aggro Scarecrow) - but when there IS a difference it is much faster in code/script to cross-check the room you are in with a *few* stored room descriptions than the WHOLE map's worth...

So you'll probably want to make the hash longer as a start. And, further, if it is computationally feasible maybe you could do something a la Git where they calculate super long SHA hashes but just shorten them whenever possible.

I'm not so sure of that, I felt that 4 HEX digits was a reasonable length to show in messages, e.g. "help me, under attack at 'The North Road{48F3}'", or remember if typing manually. I do see where you are going in terms of Git SHA hashes, but the algorithm I selected should be something that can be coded in most clients with scripting capabilities reasonably straightforwardly using just the native facilities to run reasonably quickly - I'm not sure that longer, more complex Hashes would do that.

FWIIW the example you offered could easily be redone thus:

Code: Select all

> go ef35
| ef35 is ambiguous. Did you mean:
| 1 - Tear Road
| 2 - Caemlyn Central Square
> go ef35 2
| Pathing to Caemlyn Central Square [ef35]

Indeed the patch I offered for TinTin++ uses a HASHSIZE size array of pointers to a linked list of integer room numbers (ending in a null pointer) so the list of rooms to present would be stable and just be an index into the list of numbers stored against the hash which is an index in the array of pointers. Actually the fact that, in that implementation, there is an array structure with HASHSIZE entries is a good reason to not let that value get too large, and a 16-bit integer seems reasonable from a coding point of view for most MUDs out there (apart, perhaps, for those with "wilderness" areas - I have a map from one Mud with around 2.2 Million rooms {the Mudlet saved map is 280MBytes and it takes around 4GByte to run a copy of Mudlet and load THAT in without swapping, but since that doesn't use room descriptions that is not a valid concern!})...!

[Yves]

Indeed, if you're not worried about the collisions then I agree your solution is the simpler (and thus superior for ensuring compatibility across many clients). My only concern is if/when that collision happens in the middle of PK. That situation should be rare enough and as long as you have a backup plan it should be fine.

Yves