Alias command variable

[Zanthis]

I'm having an issue with aliases that might not be intended. First, from the Mudlet Wiki on the Alias Engine (emphasis mine):

The initial user command is being held in the Lua variable command. When this value changes within the alias unit processing chain, the initial user input that the aliases work on can be rewritten and changed in the process. Consequently, you can substitute the user input step by step - or alias by alias - without that anything happens as far as sending commands is being concerned unless you explicitly decide to do so.

The issue is found in the red text. If you change the value of command in an alias, that change DOES pass through to all later aliases. However, the value of command does NOT affect pattern matching. Pattern matching always uses the initial input command. For example:

Alias 1: Match: .*, Script: command = "A" .. command
Alias 2: Match: ^A, Script: echo("cmd = " .. command)
Alias 3: Match: .*, Script: echo("Result = " .. command)

If you enter the text "xyz", the output you get is: "Result = Axyz" because Alias 1 changes the value of command. But this doesn't cause Alias 2 to fire. If you enter "Abc" you get: "cmd = AAbc" and "Result = AAbc", so clearly command has the 'A' prefixed in alias 2.

Is this how it is supposed to work?

NOTE: How the aliases are arranged (nested or not) does not change this behavior.

[Jor'Mox]

From my own experience, it seems that what you are describing is the intended behavior. The command variable works exactly like the line variable does for triggers. It holds the initial value, but has no direct effect on what happens. Triggers and aliases alike are designed to work as filters as necessary, but they don't modify the text used for pattern matching.

[Zanthis]

That's really unfortunate. I don't really find this ideal for aliases at all.

[Jor'Mox]

While I haven't had the particular issues you are having, I find thinking of aliases as nothing more or less than triggers that act on the commands entered exactly how triggers act on output from the MUD really helps me to keep their limitations and possible uses in mind.

[Zanthis]

Sadly, for what I'm doing I basically need to ignore aliases and code an entire alias system in Lua just because of this. Which is frustrating because inserting "data = Lua->get_lua_string( lua_command_string );" above line 283 in AliasUnit.cpp (anywhere in that block) should solve this issue.

Basically the current behavior is something you duplicate in Lua very simply. Just set any global variable equal to command with a .* alias, and you can modify it throughout your other aliases without affecting pattern matching. Exactly the way command works now. But the behavior I want requires abandonment of aliases entirely, and a lot more coding to implement. So using the more advanced behavior, you can get the simpler version very easily. The reverse is not true.

Just noticed there isn't a pre-Alias event (with command set to the pending command). That would be really helpful too. Especially if changes to command affected alias matching. Actually, if nothing else, just making changes to command in that event affect pattern matching would allow me to make things work with the existing alias system.

[Jor'Mox]

Not to be rude, but your given example is obviously not what you are actually attempting to do, and lacking that information makes it impossible to actually assess if what you want to accomplish can be done using the current system. If all you are trying to do is use multiple aliases on a single line of entered text (such as what you described earlier for commands separated by a pipe) then there are methods available, though they may not be absolutely perfect for what you intend (as you also mentioned). If you are trying to do something different, then a real example would be very helpful, because no one wants to prepend an A onto every command they send, and then echo some info based on if there is in fact an A at the beginning of the command.

[Jor'Mox]

As a side note, there is also a much easier way to handle the | separator issue, using a simple alias in combination with good pattern matching etiquette for other aliases. Have one alias that matches anything with a | in it. Split the command using | as a delimiter, and pass the trimmed results through expandAlias. Then be certain to include beginning and end of line indicators, along with explicit patterns for what you want (no use of .*, which can almost always be avoided anyway) in other alias patterns so they can't accidentally match something with a | in it.

It would still pass the commands separately, but it would work in a fairly transparent manner.

[Zanthis]

Ok, this is all how the MUD works, so I don't have any control over this:

1) I need to process prefixes: * # and $ which when leading a string, cause special behavior. The whitespace rules for each of these prefixes are annoying different (for example, " $stand" doesn't work, but " #stand" does, "$ stand" works, but "# stand" doesn't). The * prefix can be combined with # and $
2) Within a string, | symbols separate commands, unless the string started with a *, in which case |'s do nothing
3) There are player defined MUD-side aliases which can translate into multiple commands
4) There is also a chat mode and an editor that affect how aliasing works
5) The ! and ^ commands cause command history replacement and substitution
6) Piped commands need to be sent to the MUD as a single string to ensure no network lag between piped commands

As a result of all of these issues, I need to:
1) Track command history on my end
2) Read all existing player aliases on login and capture new ones created during a session
3) Queue up all commands for use by my auto-mapper and command scheduler

Ideally, I would like for users of this package to be able to create their own aliases.

[Zanthis]

As a side note, there is also a much easier way to handle the | separator issue, using a simple alias in combination with good pattern matching etiquette for other aliases. Have one alias that matches anything with a | in it. Split the command using | as a delimiter, and pass the trimmed results through expandAlias. Then be certain to include beginning and end of line indicators, along with explicit patterns for what you want (no use of .*, which can almost always be avoided anyway) in other alias patterns so they can't accidentally match something with a | in it.

This, and removing command prefixes, is actually the reason a pre-alias event would be useful. I could strip prefixes, split on pipe commands if needed, and then recombine in the send event.

[Jor'Mox]

So, I get that the MUD has weird syntax issues that you need to take into account when writing scripts and such, but why do you need to process user commands in some similar manner in order to properly handle aliases? Normally, I would expect an alias to take the place of some long command, which in this case could be many commands at once, all strung together. Anything that doesn't directly match some alias pattern, I would expect to go straight to the MUD as is. Doing: alias1 | alias2 | alias3 seems really counter intuitive to me. Either I could execute each alias in turn, type the whole actual command out, or create a new alias that sent what I wanted, depending on how often I used it, and what sort of time constraints I was facing. Is there some reason to expect that end users are going to be upset if they can't combine aliases that way?

In short, I think I understand WHAT you are trying to do, I just don't understand WHY. As you have correctly pointed out, doing what you are suggesting is very complicated, in part due to the way that aliases are handled in Mudlet. Given the complexity of what you would need to do to the commands being sent, I don't see any alternative but to intercept them using the sysDataSendRequest event and the denyCurrentSend() and expandAlias() functions. It will likely be very convoluted and prone to problems when presented with unusual circumstances that you didn't think to include, but it should be workable. Alias processing is very fast, so you should be able to deconstruct the command, pass all necessary parts through aliases, reconstruct on the other side, and then send the final result before any additional commands can be sent. But I remain convinced that you are doing too much work for the task at hand.