Feature - Implemented last_result or integer return value

[bordemstirs]

For things like eat, drink, use_skill, it would be nice if ASH was provided some way to find out, in the case of a failure, -why- it failed.
Changing the result type to string would be icky, integer seems easiest to change, but would require knowing what the errors mean, but something like last_result() could give back the CLI string printed (like "Selected target is too low level.") and would allow scripters to see what's going wrong when something goes wrong.

 

[Fluxxdog]

I have to ask how necessary this is. If it fails, it return a false and the CLI is printing out a message to begin with. Furthermore, depending on the code, if it's just eat(1,whatever,) it's supposed to stop the script right there (though I'm not sure if it acts similar to an abort() as I keep traps in place for that). If it's an if(eat(1,whatever)), you already have your trap in place for catching a failure.

As far as returning an integer instead of a boolean, usually if it comes off without a hitch, it'd return zero, which is easy enough to manipulate in to a true, such as !to_boolean(value).

If a string did get used, similar to integers, successes could just return an empty string ("") which again could be translated to a boolean, like (value=="").

I suppose a couple examples of how this could be useful might be needed. I doubt they want to start introducing error codes in to ASH. What did you have in mind?

 

[bordemstirs]

it's supposed to stop the script right there

I would never want a script to simply stop because an eat or drink failed. If I had an error and maybe a brief reasoning behind the error, the script could figure out a way around it.

Yes, the messages are printed to the CLI, but in script, that's not very helpful. It would require human intervention.

I doubt they want to start introducing error codes in to ASH. What did you have in mind?

Error codes is why I'd suggest a last_result() instead. It works for failures and non-failures, and just returns whatever the last thing posted to the gCLI is. Which is more than enough information for any script author to manipulate to his bidding, and should be pretty easy to add (assuming all output to the gCLI goes through one common function at some point.)
I could see myself using this in quite a few places, but the reason it came up tonight was because someone using my chatbot was getting the plain "You can't get a buff right now" message and was confused. use_skill fails for any reason, the bot only knows that it failed. It'd be nice to be able to have it automatically inform the player why (in this case, it was a hobopolis buff) so they don't try again (knowing full well that they only have 2 songs and aren't in battle).
Of course, being able to apply this to other things would be quite nice as well.

 

[Fluxxdog]

I would never want a script to simply stop because an eat or drink failed. If I had an error and maybe a brief reasoning behind the error, the script could figure out a way around it.

Yes, the messages are printed to the CLI, but in script, that's not very helpful. It would require human intervention.


Error codes is why I'd suggest a last_result() instead. It works for failures and non-failures, and just returns whatever the last thing posted to the gCLI is. Which is more than enough information for any script author to manipulate to his bidding, and should be pretty easy to add (assuming all output to the gCLI goes through one common function at some point.)

OK, last_result is a bad description. last_error() would be more appropriate. What you'd be wanting would be something like:

if(!eat(1,hi mein)) switch(last_error()){
case "Not enough fullness": eat_something_smaller(); break;
case "Too low level": eat_something_simpler(); break;
case "Don't have any": buy(1,hi mein); eat_again();
default: abort("Not even I know what's wrong");

...so if it failed to eat, to could adjust.

I could see myself using this in quite a few places, but the reason it came up tonight was because someone using my chatbot was getting the plain "You can't get a buff right now" message and was confused. use_skill fails for any reason, the bot only knows that it failed. It'd be nice to be able to have it automatically inform the player why (in this case, it was a hobopolis buff) so they don't try again (knowing full well that they only have 2 songs and aren't in battle).

In this case, you might be better off using a visit_url() version which (IIRC) gives the reason somebody couldn't be buffed. mafia will just give a true/false (for now), KoL gives a string. Something to think about.

 

[bordemstirs]

Using visit_url for any action that might fail would essentially mean ditching -all- of ASHs built in functions, and a lot of navigating through raw HTML. I could do it, yes, but it just seems icky.

As for the name, last_result() or last_error() doesn't really matter what you call it, though asking for the last_error() when the last function was a success means either A) last_error() would return a "success" message, awkward; or B) more careful coding of the piece that loads the function with its value.

 

[Fluxxdog]

Using visit_url for any action that might fail would essentially mean ditching -all- of ASHs built in functions, and a lot of navigating through raw HTML. I could do it, yes, but it just seems icky.

Well, for the skills, the only ash function you'd be ditching would be use_skill(), and in exchange, you'd be getting the actual KoL "failure" message. It may be "icky", but I've found these solutions give me a much more elegant code in the end.

Case in point, with the choice adventures for the Spooky Forest being broken, I need a way to loop things until I
1: sell my bar skin(s)
2: get 1 sapling
3: exit the choice adventure
This led me to a way to manipulate all the choices for the Spooky Forest depending on my needs, with the choice for the sapling being made by looping a check for choice.php and hitting visit_url with an integer:

choice(504,4-to_int(!possess_item("spooky sapling"))-to_int(possess_item("bar skin"))-to_int(have_item("bar skin")==1));

Other choices are set up so I don't go anywhere near that choice adventure if I already have a sapling.

Sometimes icky leads to pretty. This is where we make an analogy with manure and flowers, but you get the idea ^^

 

[bordemstirs]

Yes, but in that case, you only use manure to get the flowers because you don't have the option to buy them already potted.

I have to use the less-than-elegant visit_url() to record my excess songs at the end of my day, but use_skill() already exists -and- mafia already is aware of why it fails and handles the error.
It would be quite nice (and surely in other situations as well) to be able to get the gCLI output from a given action and use it in ASH.

 

[Fluxxdog]

Point. We don't have a lot of options when it comes to why things failed. In most cases, we can determine why (or prevent the failure altogether). But with use_skill(int,skill,string), we'd have no way to pinpoint the failure against the other person if it's simply "Too many songs already active" other than using a visit_url("skills.php?")

 

[bordemstirs]

we'd have no way to pinpoint the failure against the other person if it's simply "Too many songs already active" other than using a visit_url("skills.php?")

Do you mean as is, or even if my request was implemented? I'm not sure I understand what you're getting at. Mafia prints to the gCLI something unique for each error that KoL vanilla gives in this case.

 

[Veracity]

That "last error string" thing is unique to UseSkillRequest. near as I can tell.
It's not a bad idea, but it's a wide-ranging feature request...

 

[holatuwol]

So add functions named last_item_message() and last_skill_message() that return UseItemRequest.lastUpdate and UseSkillRequest.lastUpdate?

 

[Fluxxdog]

So now we can do error trapping with something like:

if(!use_skill(1,foo)) switch(last_skill_message()){
case "No such skill": ...

Sounds like a win ^^