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 ➜ General ➜ Should multiple aliases be processed for one line?
Should multiple aliases be processed for one line?

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

Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Thu 03 Apr 2003 07:01 AM (UTC)
Message
I am in the process of fixing up the way aliases work, with a view to letting them execute commands (eg. other aliases) without having to call a script.

However when I look at the alias handling code it seems that they currently behave in a way that is rather bizarre, and I hope no-one is using this behaviour. :P

In early versions of MUSHclient, multi-alias matches simply replaced individual words. eg.

foo => bar
eat => drink

Now if you typed "foo eat" it would send "bar drink" - both would match and both would substitute.

However in current versions it appears that whilst it still multi-matches, it takes the output from the previous alias, and reprocesses that, in an undefined order, which I personally think is pretty useless.

eg.

foo => bar
bar => sausage

Now if you type "foo" it becomes "bar", then it matches "bar" and it becomes "sausage". However, and this is the important bit, because the evaluation order is undefined it might do this:

You type "foo", it becomes "bar", but because it looked for "bar" *before* "foo" it does *not* become "sausage".

I hope no-one is relying on this behaviour, and would be pleased to get some feedback about how you think aliases should work, if multiple matches are likely on one line.

If no-one expects multi alias matches on one line, then I will simplify the code, and then add the option to "send to" "execute" along the same lines as triggers currently do.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,791 posts)  Bio
Date Reply #1 on Thu 03 Apr 2003 07:31 PM (UTC)

Amended on Thu 03 Apr 2003 07:32 PM (UTC) by Shadowfyr

Message
Umm.. Multiple matches on a single line is not what I would have expected.. But then I haven't so far tried anything where such a conflict is possible. My assumption was that like triggers, a 'normal' alias would 'assume' start of line for any match. That is doesn't is a bit of a concern, since imho I would prefer to avoid such things 'unless' I specifically use a regexp to perform such a mid-line substitution. I at least say, 'simplify away'. However, since rexexp still need to work, you may not be able to simplify it completely or you will break that.
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #2 on Thu 03 Apr 2003 09:56 PM (UTC)
Message
I would prefer aliases not be matched on what is sent via the "send" box or via "World.Send", by default.

There are some cases where an alias is identical to a mud command. The purpose of the alias is simply to grab the argument and store it in an alias. For example:

Alias: punch *
Send punch %1
Script: Stores Wild to variable.

If "punch" were grabbed again as an alias, I would go into an infitite loop. Although I could change the alias to something other than the same word it is sending (like "pnch", this is not practical for some plugins where I want to set a variable and want to maintain ease of use).

I would therefor suggest one alias should only call another if it is explicity declared through an option on the alias configuration screen.

Now, in specific relation to what you are talking about:

If a person wants two different strings to match on a command they enter, and have them execute different aliases, then, well, they should have two different regular expression aliases. For example:

Alias: foo
reg.exp = Yes
Send: eat

Alias: bar
reg.exp = Yes
Send: sausage

...would send "eat sausage".

Alias: sust
execute output = Yes (Send to alias matching engine)
Send: foo bar[ENTER]drink water

...would send "eat sausage[ENTER]drink water"

In an ideal world, "foo" would be executed before "bar" because it appears first in the string. You execute aliases according to their order in the 'send string', reading from left to right.

Command Stacking:

Command box: "w;w;pwl;bs guard"

"w": alias? No: Send it.
"w": alias? No: Send it.
"pwl": alias? Yes, exectute (including sending from script).
"bs guard" alias? Yes, execute (including sending from script).

Somehow, MUSHclient is capable of queueing commands. It does it when it's busy executing a script, and receives a command from the interface. (For example, ShadowFyr's script that opened a webpage took some time, and if he typed new commands they would be queued while the script executes). Command stacking should simply break up the commands, in the order they are entered, and use the same queue.

This all seems straight forward to me. ...or have I missed something along the way here?
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,158 posts)  Bio   Forum Administrator
Date Reply #3 on Thu 03 Apr 2003 10:13 PM (UTC)
Message
I didn't mean that an alias would re-match itself, so that the example of "punch *" going into a loop wouldn't happen.

I also didn't mean an alias would match what was sent to the world, rather that this might happen:

alias 1:

match: attack *
send: kick %1

alias 2:

match: kick *
send: cast lightning %1

Thus in this hypothetical case, if the aliases matched in the order 1, 2 (which is not guaranteed at present), typing:

attack kobold

would result in

cast lightning kobold

being sent to the MUD.

However because the match order is not guaranteed I am hoping no-one is actually relying on this present behaviour.

As for your comments on command stacking, the new behaviour would work the way you describe, in fact it basically acts as if each command was typed separately into the command box, and thus they are executed individually and sent in the correct order, excepting three things:

1. The stacked command goes into the command history, not the unstacked equivalent.

2. If the first thing on the line is the scripting prefix, then command stacking is disabled.

3. If auto-say is active, command stacking is disabled.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #4 on Fri 04 Apr 2003 12:47 AM (UTC)

Amended on Fri 04 Apr 2003 01:46 AM (UTC) by Magnum

Message
Uhm, I'm tempted to abandoned this message, cause it's kinda non-sensical, but I'll leave it anyway. Waste of reading perhaps....

I'm sorry, but I don't see what particular problem you are addressing there. As far as I know, there is no existing method to call one alias from another, so I don't see any issue with backwards compatability.

As I stated, if calling one alias from another is to be implemented, then I suggest there should be a specific option per alias to declare on/off, and that the line is executed from left to right.

All other situations should be handlable by using regular expressions, and 'keep evaluating'.

Oh wait, perhaps I just figured out what you mean:

Do you mean that if alias "jkl" is called, and sends (for alias matching) "abc", then it's possible that "abc" would fail to match because "abc" precedes "jkl" on some internal list?

If so, the answer would simply be to re-run the alias matching engine clean, without contining from the point in the list where the initial alias was called. This should be fairly straigh forward:

Command box: sust

Alias: sust
Execute Output: [x] (Yes)
Send: eatfood[ENTER]drink

Alias: eatfood
Execute Output: [x]
Send: open backpack[ENTER]get food from backpack[ENTER]close backpack[ENTER]eat[ENTER]Emote Yum

Alias: eat
Send: eat food

So you send "sust" to alias matching routine. Alias found, execute it.

Since Execute Output is checked, you essentially just throw these lines to the command queue (as if they had been typed in).

Run through the rest of the alias list, but still working on THIS EXPRESSION ["sust"]. List complete, process queued commands:

Send "eatfood" to the alias matching routine. Alias found, execute it. (and so forth).

In the end, it would be like this:

sust                       - Alias, nothing echoed.
eatfood                    - Alias, nothing echoed.
open backpack              - Sent to Command Queue (by alias).
get food from backpack     - Sent to Command Queue (by alias).
close backpack             - Sent to Command Queue (by alias).
eat                        - Sent to Command Queue (by alias).
Emote Yum                  - Sent to Command Queue (by alias).

So, all the commands in the queue get executed in the proper order. Each command in the command queue will run through the alias engine as would any command from the command box. ("eat" will match and expand to "eat food" which would send immediately).

I guess there is a minor problem in that logic. If "eat" was an alias that had 'Execute Ouput' checked, then those new commands created by "eat" would appear after the line "Emote Yum" which would be out of order.

Bleh, why oh why did I have to contribute to this thread? LOL.
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Vaejor   (120 posts)  Bio
Date Reply #5 on Fri 04 Apr 2003 05:13 AM (UTC)
Message
What about priorities (aka 'seq' in the triggers list) for aliases?

Add ability to 'keep evaluating' aliases and you should cover all bases.

Also will add the ability to temporarily alter aliases by simply adding in a newer one at a higher seq level, etc.

Just an idea.
Top
Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #6 on Fri 04 Apr 2003 05:27 AM (UTC)
Message
I think these posts answer one question, no-one is using the alias re-match feature.

Quote:

Do you mean that if alias "jkl" is called, and sends (for alias matching) "abc", then it's possible that "abc" would fail to match because "abc" precedes "jkl" on some internal list?



Yes, that is what I mean, and why probably no-one is using it.

I am strongly tempted now to implement aliases like triggers, like you can "send to world", "send to notepad", and so on, which they already do partly using rather confusing check boxes.

Also a "keep evaluating" and sequence number would be handy for those cases where you want to, say, pick up a general case and send it to the notepad, but a more specific case and react in another way as well.

As for re-scanning, I plan that if you "send to execute", the send box is reparsed as an entirely new command which means, amongst other things, it would (potentially) re-match all existing aliases. Of course, you then have the possibility of a loop, but I have built in a maximum of 20 re-executions before it bails out.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #7 on Fri 04 Apr 2003 05:34 AM (UTC)
Message
Magnum, your elaborate example is indeed how I envisage it working, which I think you would agree is a lot more powerful, as you can, when writing alias A, use alias B without having to remember whether it is an alias or not.

Plus, an alias could drop into scripting, which gives you the power to send to the world (or output) as well. eg. the "send" text might be:

/ world.EnableTrigger "mytrigger", 1
world.Note "Trigger enabled"
world.Send "who"
world.DoAfter 5, "laughs"

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,158 posts)  Bio   Forum Administrator
Date Reply #8 on Sun 06 Apr 2003 06:28 AM (UTC)
Message
This version is now available for testing - let me know what you think. :)
- Nick Gammon

www.gammon.com.au, www.mushclient.com
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.

24,870 views.

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.

Home