Feature Enable users to bypass the CLI command queue

zarqon

Well-known member
I've wished from time to time that I could check my inventory or the name of a monster or skill while another script was running. Or, I wanted to quickly visit one of the wikis using the "wiki" or "ashwiki" commands.

These commands do not hit the server and would not interfere with the current script's execution. Further, I am already able to do this during my login script -- mafia doesn't add commands to the queue while running the login script, but executes them immediately. I have taken advantage of this quite a few times -- even with commands that do hit the server -- so I know it works.

However, once I have a long script running, I need to abort the script to type in this command, and restarting the script may be undesirable (loss of data or somesuch). It's a hassle.

I'd like a command prefix, perhaps "rush" or "now" (or "sudo" hahaha) that makes the command execute immediately, bypassing the queue.

For example: "now inv star" while autoadventuring in the Hole or "now monsteref bee" if coding handling for bees while running a routine or "now ash last_monster()" during an automated combat.

This makes implementation both simpler and more powerful than my previous idea of immediately executing certain server-hit-less CLI commands. Mafia doesn't need to have any knowledge of whether a certain command hits the server or not -- the power to screw yourself up by running multiple commands simultaneously is in the hands of the user. Fortunately, this feature would likely only be abused by those who know how to get themselves out of whatever trouble they encounter.
 

Veracity

Developer
Staff member
I think it would be fine to have any commands that do not make server requests to not be queued. Among other things, this would allow people to set the "stop now" preference I added to my MMG script and have it notice the change and stop execution. :)
 

zarqon

Well-known member
That would be a step towards great awesomeness. Ideally you could do it with any command, to allow the greater flexibility of using ASH (I use those "itemref", "prefref", etc aliases practically every day).

EDIT: skipping the queue may not always be desirable. Maybe you want to see how many midget clownfish you got after a day's seafaring, but you couldn't queue up an "inv" check since it would execute immediately.
 
Last edited:

Theraze

Active member
If we're doing non-hit things as immediate, print should work immediately as well... change that to a council or something else and you should be good though. Long as they don't skip steps... maybe run it as an ash script, since it probably won't parse through part of your ash script to decide if it's possible or not. So
ash item_amount($item[midget clownfish])
in the gCLI tab should just return your inventory amount when farming is done...
 

xKiv

Active member
I would think that this should be a modifier on the CLI command (something like we already have "try; actual command here" with different keyword substituted for try).
I wouldn't recommend defaulting to skipping the queue for anything, unless it's for everything. That way are confused users.
Especially if the (non)enqueuing would depend on whether the command would *really* hit the servers (anything that can use cached results).
 

jasonharper

Developer
There are NO CLI commands that are guaranteed not to hit the server, other than 'cls' and 'abort' which are already handled specially. The presence of aliases makes that impossible to determine prior to executing the command line.
 

Winterbay

Active member
There are NO CLI commands that are guaranteed not to hit the server, other than 'cls' and 'abort' which are already handled specially. The presence of aliases makes that impossible to determine prior to executing the command line.

Would it then make sense to have a special keyword for it (now! or something) and run anything behind that keyword verbatim ignoring all potential aliases and make that keyword a reserved word that cannot be aliased? Or would that not work?
 

jasonharper

Developer
Sure, a special keyword like that could be implemented fairly easily. I personally consider it a disaster waiting to happen, because people are simply NOT going to think through all the consequences of executing commands immediately (and would probably end up recommending it to other users in horribly inappropriate cases, as used to happen with "update data").
 

zarqon

Well-known member
It would be a huge boon for debugging or script research during routine script execution however, particularly with things like "wiki" "ashwiki" "help" and "ashref" -- and those other reference aliases.

It could lead to disaster, as you say, but it would be power users bringing it on themselves and it would be their own fault. And they would probably know how to repair the damage and move on. The utility far outweighs the risk as far as I'm concerned. Leaving it undocumented is fine with me, too.
 
Top