Mudlet - Forum

Ah, I see ... So your script is sort of a highlighter trigger that doesnt highlight but adds popup menus?

The script object type is "speedmenu". By object type, I mean alias, trigger, button, etc.
A "speedmenu" is an option that appears in the right-click menu. The name appears in the list of options that show when I right click anywhere in the main output screen.

There are three 'pre-defined system variables' that can be used in the scripts associated with these speedmenus: %selword, %selline, and %selected.

The value of %selword, is always the 'word' (alphanumeric) that the mouse pointer was over at the time of the right click.
%selline matches the entire line that the mouse pointer was hovering over, while %selected matches the current selection. (I've never actually used %selected. I've only rarely used %selline, but %selword is really useful).

When I'm looking in a shop, if I see something I want to buy, I right-click the name of the item, select "Buy" from the menu that appears, and the command "buy <that item>" is sent to the mud.

The command in the script section of the speedmenu, is just "buy %selword".

Some more thoughts:

1) Ctrl+C for copying output text. Thus far it's linked to the input, which means that even if you highlight output text it still copies whatever is highlighted in the input.

2) Hide the cursor once you start typing and only bring it back once you move the mouse again. This is something from zMUD I miss.

3) Mudlet flashes for attention if new output is received while you're on a different window.

We may already be able to do this, but I request being able to load text files into the main window. Zmud:
#read name.txt raw
(The 'raw' parameter is telling zmud that I'm sending it raw mud output, with control codes etc)

If the log has saved ansi codes, then reading it in the main buffer like this will display everything exactly as it looked when it first happened. If I am loading a past log, I turn triggers off first. Or, if I am testing my scripts by simulating game output, I leave triggers on.

How about a command-line accessible means of inputting paths?
Such as zMud's: .s2wd4s2e(unl grate;op grate)s(close grate;lock grate)

And a command-line accessible means of repetition.
Such as zMud's: #3 buy fish;look <- buy fish x3, then look once
Another example: #10 (get lozenge crate;put lozenge box) <- repeat everything in parens x10

I tried to develop my own repeater, but ran into the following two problems:

1. ; command separator doesn't "lazy separate", if you get my meaning (could work-around by defining my own delimiter, I guess)
2. The alias "pre-emption" killed the repetition if I tried to repeat an alias (I'm lost as to a work-around for this one)

Interesting points. As I don't know enough about zmud, could you or other ZMud users elaborate a bit more about the path request?
The repeater is something that needs to be implemented within the alias unit itself. This is correct. I have to think about this for a while, but this seems to be useful.

zMud paths:

You can create an arbitrary path in the command-line by prefixing numbers, directions, and parenthesized commands with a dot.

ex1: .s2e -- sends s;e;e
ex2: .2s(unl door;op door)e(close door;lock door)n -- sends s;s;unl door;op door;e;close door;lock door;n

Paths can be also be saved with a name, ie: .astoria = .s4w3n2e6n3en
While that seems like a simple alias, zMud has one more trick up its sleeve. The "double-dot" prefix will reverse a path. So entering: ..astoria will result in the reverse dirs being sent to the mud. (And the double-dot notation works for arbitrary paths, but who would enter "..2s" to go 2n?)

The user can configure one-character nw/ne/se/sw or other dirs to aid the path parser.

And of course, it's all tied in to the auto-mapper.

I'm still trying to figure out what would be the advantage of having such a quick path parser because it's so easy to record complex paths & actions in Mudlet and then just recall them via a simple alias like "go BlackCave;start killing spree; go RedCave; kill monster etc.
Those recorded paths can be stored in tables. Reversing them is trivial. They can be serialized to hard disc, also.
For a simple record actions alias you'd simply make an alias to start the recording, provide a name for the recording and then stream the value of the variable "command" into a table until stop_recording is called or whatever.
Don't get me wrong. I'm not turning down the request, but I want to understand why it would be a good thing to have.

I see. I was only explaining zMud path features and not making a solid persuasive argument, though.

I've actually written a scripting engine in Ruby, and after much deliberation, decided to put zMud-style paths in. The deciding factor was I wanted to provide a system-level method of composing directional entries. And though I wanted to avoid the overused term, you effectively end up with a DSL for movement.

What can you grok faster in case you want to understand/edit your paths?

.s7w3sese2se
or:
s;w;w;w;w;w;w;w;s;s;s;e;s;e;s;s;e

And that's using simple substitution.
Imagine if you wanted to do something else script-worthy in that path alias?

send('s')
send('w')
send('w')
...

So my argument is making movement aliases easier to read and write for the scripter. That's all.

1. This DSL could be written completely in Lua. The current features should be sufficient for such a project.
The function expandAlias( "n;s;w ...." ) can be used for recursive alias expansion. The initial command is fully available via the variable "command" though the command will be split on the basis of the seperator char after entering the alias unit. The send() function bypasses the alias unit and sends the command directly to the underlying network layers. If you decide to make such a plugin for Mudlet, we'd be happy if you could share it as I believe that it a useful thing to have - and way too difficult for many users to make themselves.

2. You could also make a repeater like this if you work off the alias "#(\d+) (.*)" and change the seperator ";" to something else. But as you've already mentioned it would be better if such a repeater functionaliy would be built in the system itself. I have to think a bit more on this.