How to prevent input command echo with alias?
Re: How to prevent input command echo with alias?
Let's see if others have interest in this! As you can see there's already a multitude of options around this, adding more to the soup is gonna make things more complicated and difficult.
Re: How to prevent input command echo with alias?
Sounds good! Maybe it would be wise to rename the thread/feature to be a bit more self-explanatory - I'm really not sure I'm using the nomenclature either, so your thoughts are very much welcome. Perhaps something like:
Feature Request: Enhance the "Show the text you sent" preference to optionally "Only show outbound text"
Indeed, this could easily make the already-complicated behavior more confusing, and we'd have to be careful to ensure backward-compatibility. I'll try to elaborate on a feature proposal.
I propose we add a new check-box preference named Only show outbound text (open to naming suggestions) on the Input line preferences page, as a sub-preference indented below the Show the text you sent check-box preference. The effect of enabling/checking Outbound text only is that only text that is actually sent to the MUD will be shown, but where the showOnScreen flag in the send() and sendAll() commands is still honored.
The scenarios are as described below. Note that it is Scenario 2's existing behavior which this feature aims to modify - so Mudlet doesn't print multiple lines for a single command sent to the MUD. E.g., if I have an alias that simply changes sc to scan, then Mudlet today will print two lines: sc (the text I typed) and scan (the text that was sent to the MUD) - but with the new feature, it will only print one line: scan
SCENARIO 1
If Show the text you sent is disabled/unchecked, then Only show outbound text has no effect (even if it is still enabled/checked) - Mudlet still behaves as it does today. Note that this overrides the showOnScreen flag in the send() and sendAll(), and no text will be displayed even when showOnScreen is true. Here are the possible configurations for this scenario in the UI:
----
SCENARIO 2
If Show the text you sent is enabled/checked, and if Only show outbound text is disabled/unchecked, then Mudlet still behaves as it does today, where it shows both all input text you send via command line, as well as any additional text sent to the MUD via calls to send() and sendAll() (such that the showOnScreen flag is honored). Here is the configuration for this scenario in the UI:
----
SCENARIO 3
If both Show the text you sent and Only show outbound text are enabled/checked, then Mudlet now behaves differently - it will no longer always show you the input text that you entered via the command line, but only show the text that is sent on to the MUD. This includes any text that passes through Mudlet unmodified and onto the MUD, as well as any text sent via calls to send() and sendAll() (such that the showOnScreen flag is honored). Here is the configuration for this scenario in the UI:
Re: How to prevent input command echo with alias?
Kinda funny - I happened across this thread in which someone else tried to accomplish the same effect by simply putting a deleteLine() in his alias, so the echo of his input text would be gagged while the output of his call to send() would be displayed:
viewtopic.php?t=1707
Alas, it didn't seem to work (and still doesn't work today afaict) - from that thread:
It sounds useful, and it would negate the need for the Only show outbound text feature I proposed above.
Perhaps a feature request in that vein would be less confusing/invasive/complex. Perhaps a new function like deleteInputLine(), or maybe a new flag parameter for deleteLine(), which tells it to gag input lines.
viewtopic.php?t=1707
Alas, it didn't seem to work (and still doesn't work today afaict) - from that thread:
I agree
![Smile :)](./images/smilies/icon_e_smile.gif)
Perhaps a feature request in that vein would be less confusing/invasive/complex. Perhaps a new function like deleteInputLine(), or maybe a new flag parameter for deleteLine(), which tells it to gag input lines.
Re: How to prevent input command echo with alias?
It turns out there's an event named sysDataSendRequest which is called for every outbound command actually sent to the MUD!
I can almost get exactly the behavior I'm going for by disabling the Show the text you sent setting, and adding the script below to subscribe to that event and print it out![Smile :)](./images/smilies/icon_e_smile.gif)
The only thing that's a bit weird now is commands that I submit which don't result in outbound commands (e.g. if it merely sets a variable) don't provide any visual feedback - but I can address that by simply adding a call to echo() to display whatever's appropriate for the command.
I can almost get exactly the behavior I'm going for by disabling the Show the text you sent setting, and adding the script below to subscribe to that event and print it out
![Smile :)](./images/smilies/icon_e_smile.gif)
The only thing that's a bit weird now is commands that I submit which don't result in outbound commands (e.g. if it merely sets a variable) don't provide any visual feedback - but I can address that by simply adding a call to echo() to display whatever's appropriate for the command.
Code: Select all
function echoCommand(eventName, commandSent)
cecho("<yellow>" .. (commandSent or "") .. "\n");
end
registerAnonymousEventHandler("sysDataSendRequest", "echoCommand");
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: How to prevent input command echo with alias?
I take it a "sysDataSendRequest" event handler isn't an option here? After all that does intercept user / script generated output does it not? Otherwise this sounds that you'd want to look at (void) Host::sendData(QString cmd, bool wantPrint, bool dontExpandAliases)...
.... sorry, posted this without spotting the second pages of messages. Interestingly it revealed to me that there is a bit of a login credentials security matter!![Shocked :shock:](./images/smilies/icon_eek.gif)
.... sorry, posted this without spotting the second pages of messages. Interestingly it revealed to me that there is a bit of a login credentials security matter!
![Shocked :shock:](./images/smilies/icon_eek.gif)