Zugg Software :: View topic

Magician Joined: 29 Nov 2005 Posts: 482

Predefined variable %lastcom;%lastcom2;%lastcom3 dont work at all it seems

I use this in many of my scripts at times to verify commands.

west;#ECHO %lastcom;#ECHO %lastcom2;#ECHO %lastcom3;

does nothing. at least for me. im checking other issues with predefined variables i have already sent you two bug reports on other more serious errors.

I even attempted to replace this with an ONINPUT trigger and it doesnt fire either. so now im wondering if some of the command functions we are used to have changed or arent working.

Posted: Wed Sep 20, 2006 6:51 pm

Confirmed both the %lastcom and #ONINPUT problems. Not sure what changed to break these, but they are on the bug list for the next version.

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

This drove me nuts for an hour or so and I just figured that my oninput triggers weren't passing syntax checking or something along those lines.

Posted: Thu Sep 21, 2006 9:01 pm

Found and fixed the issue with #ONINPUT. Turned out that it was the old parser that called the ProcessInputTriggers and the new parser didn't do that :) So, they really should not have been working in any version of CMUD. But they are fixed in 1.07.

For %lastcom it was a bit trickier. Like #ONINPUT, the %lastcom variables were being set in the old parser. In the new parser, I can set %lastcom to the last command *sent to the MUD*, but I cannot set it to the last script executed. In other words, if I enter:

hello world

and press Enter to send it to the MUD, then %lastcom will be set to "hello world". But if I execute a script on the command line, like:

#ALIAS test {hello world}

then the %lastcom remains uneffected because nothing was sent to the MUD. This is because of the new compiler. With the new parser/compiler, the main MUD window doesn't have access the the text of each individual script command like it did in zMUD.

It's the ; command separator that causes the issue. By trapping the text sent to the MUD, CMUD can handle something like this:

first;second

and can properly set %lastcom to "second". But if you entered:

#VAR a 123;#VAR b 456

then the command line has no way to tell that this is two commands and doesn't know whether executing this causes something to be sent to the MUD.

In summary, %lastcom, %lastcom2, %lastcom3 only return the commands last sent to the MUD. To get the full command line last entered, use %lastinput and %lastin2. I'll add this to the list of changes from zMUD to CMUD.

SubAdmin Joined: 18 Nov 2001 Posts: 5187

Actually I love that change. In zMud I found %lastcom to be nearly useless since it would change with every line of script executed. This is a definite improvement.

Posted: Fri Sep 22, 2006 7:32 pm

Here's a question for everyone about %lastcom:

Should %lastcom return the command that was typed, or the actual data sent to the MUD. This is different if you have an #ONINPUT trigger. For example, let's say I have something silly like:

#ONINPUT {test} {hello world}

and now I type "test" on the command line. Should %lastcom return "test" or should it return "hello world" (the actual text sent to the MUD)?

In zMUD, %lastcom would return "test", but I'm thinking that this might be wrong.

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I'm thinking that "test" would be the correct thing, actually. The #ONINPUT triggers don't stop the "test" from being sent to the MUD, at least not in my experience. In this example, however, since you're sending additional text inside the trigger (as opposed to doing some script function like setting a variable), maybe "test" should go in %lastcom2 instead.

The most likely use for the %lastcom variables is to re-try commands that fail, so you typically want to know what you typed and send that again (assuming it goes through the same parsing steps both times).

Posted: Fri Sep 22, 2006 8:56 pm

No, the #ONINPUT trigger *does* prevent "test" from being sent in this case. Any output from the #ONINPUT trigger replaces the original command text. So in the above example, "hello world" is sent to the MUD and "test" is *not* sent to the MUD.

Does this change your answer?

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

Isn't doing #oninput like you said above the same as #alias?

from what I understood doing #oninput {test} {hello world} would produce the following (using > as a prompt, orange as command literally sent to mud by zmud and brackets around command line text entered by the user)

[test]
> test
-Mud returns to test command being sent-
> hello world
-Mud returns response to hello world command being sent-

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

doing what you said where the text triggered is captured and not sent to the mud would be nothing more than an alias where you send test and the mud output is

[test]
> hello world
-mud response to hello world-

Posted: Fri Sep 22, 2006 10:31 pm

No, that's never how #ONINPUT has ever worked, even in zMUD. As I said, any output generated by the trigger *replaces* the original command text. The original command text is not sent. Try it in zMUD and you'll see.

Yes, the simplistic example that I gave is the same as an alias. But it doesn't use the full power of #ONINPUT triggers. That wasn't the point. The point was to decide whether %lastcom should have the text entered by the user, or the actual text sent to the MUD.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

Thinking about it, I get what you're saying.

#oninput {give (%w) (%d) credits} {give %2 credits to %1}

[give liria 50 credits]
give 50 credits to liria

SubAdmin Joined: 18 Nov 2001 Posts: 5187

I would personally like to see %lastcom, %lastcom2, and %lastcom3 only ever return texts actually sent to the mud from any source.

I feel that %lastinput and %lastin2 should reflect only user inputs. This would include text that was entered in the command line as well as macro calls. I know that last one would be awfully difficult; but the reason for it is that often a macro is called at a specific moment with a specific variable settings, this causes some commands to be issued and the variable subsequently changed. Simply using the macro script again will not produce the same result because the variables involved are changed, so knowing the actual commands that were issued can be very important. If the changes to %lastcom were made then all that would be needed is a way to note in %lastin that the source was a macro.

I have long been disappointed with the ability to work with the command history in zMud. In zMud only commands exist to interact with this because the %lastxxx function have been unreliable. I would actually like to see these become system functions and have more consistent names, %lastinput vs %lastin2 takes far too much thought...for everyone.

I would propose having:
%lastcom(number) as repesentative of commands actually sent to the mud, returning a simple text value.
%lastin(number) as representative of user inputs, returning a record variable with keys of Type and Input.

I would also suggest that the command history should have a hard cap at 1000 and no specific preference to set it. I can not personally imagine pressing up more then 100 times to find a command I want to reissue; and in the current world of cheap memory it makes sense to simply allocate a huge block right off the bat. Reducing memory reallocations does improve speed. That would make number in both suggestions above having a range of 1 to 1000.

Magician Joined: 29 Nov 2005 Posts: 482

lastcom = last command? wouldnt that imply that test would be the correct thing. I actually use this in many scenarios

While i in some degrees agree with vigilante in context my use for lastcom has often been replaced by using on input triggers

Lastcom = command text entered (Command history is the history of commands you type not that are sent) this all seems to work together.
lastin = last input the mud recieved (Text from scripts)

thats my opinion