onExit/onAbort

[Veracity]

Experimenting with my MMG script, I've noticed that I sometimes want to abort its execution. When I do that, all the fancy statistics I print out on normal exit don't get printed.

I can envision having a couple of functions that would be invoked whenever ASH terminates a script, normally or abnormally.

void onExit();

called whenever a script terminates without error, either by running off the end of main() (or the end of the script, if you have no main() and are executing top-level statements), or by using the "exit" command.

void onAbort();

called whenever a script terminates prematurely, either because the user said to stop, the script said to abort, or a runtime error happens.

Questions:

- do we need both?
- obviously no recursion: if you get an error while executing one of these functions, no call to onAbort().
- should these be fixed-named functions (like main()), or should there be a way to declare that such-and-such a function is your "onAbort function", say?

How would people use this kind of feature? What do you think?

 

[Bale]

I think that this would be an interesting and useful feature so that a script could have tidy abort handling.

Allowing a user to declare an onAbort function has an advantage in that the user would be able to declare a function as his onAbort function even though that function is also used in the script, but I think that it would hurt readability. Anyway, if the onAbort function calls this other function, then you get the best of both worlds.

Here's a related issue. I've found that if I use the "stop after" button, then the script will abort the adventure() command, but immediately start executing commands that follow that command. This is frequently bad since I might not want those commands to be executed unless the adventure executes according to the conditions set in my script. This has caused me trouble at some point. Should the "stop after" button lead to switching to the onAbort() function, onExit() function or simply continuing the script as it does now.

 

[mredge73]

Great Idea
Really great idea

onAbort() would be awesome in combating the "blame Jick" errors.
I would just have it restart my script.

Better, is if it was a string function where it could return you the error as a string. That way I can restart the script if when the error is "blame Jick" or do something else if it is not.

if (contains_text(onAbort(),"blame Jick"))
cli_execute("call AdventureSomemore.ash");

Something like this would be pretty sweet!

 

[Catch-22]

This is awesome Veracity. I've already talked about something like this (here).

Questions:

- do we need both?
- obviously no recursion: if you get an error while executing one of these functions, no call to onAbort().
- should these be fixed-named functions (like main()), or should there be a way to declare that such-and-such a function is your "onAbort function", say?

Answers:

- I think it would be nice to have both, but just one could be tooled for both purposes.
- Makes sense.
- I think it should be a reserved/fixed name function.

Just a thought, I think there should also be a timeout. So your abort function can't get stuck in an endless loop or stuck taking too long. Either the timeout is some hard coded value provided we know what it is, or we can set the timeout value in the function (we know roughly how long it would take to perform such and such a task and we can set a timeout value based on that).

 

[Alhifar]

Is this still being considered?
It would give me reason to actually work on the average ML statistics in slime.ash, currently most people don't even know they are there because the adventure to fight Mother causes an abort.

 

[dj_d]

My only concern is that the user should be able to supercede the script; if the user really wants the script to stop, it should do so immediately. Perhaps a second ESC means "stop now dammit".

 

[Catch-22]

My only concern is that the user should be able to supercede the script; if the user really wants the script to stop, it should do so immediately. Perhaps a second ESC means "stop now dammit".

KoLmafia used to have similar "stop eventually" and "stop now" functionality. If you were in the middle of a combat, the stop button used to finish that combat off for you and then stop. Now it just stops and lets you finish the combat manually, not sure why but it's been that way for a while now and I never bothered questioning it.

 

[lostcalpolydude]

KoLmafia used to have similar "stop eventually" and "stop now" functionality. If you were in the middle of a combat, the stop button used to finish that combat off for you and then stop. Now it just stops and lets you finish the combat manually, not sure why but it's been that way for a while now and I never bothered questioning it.

I'm not quite sure what you're referring to, but in the GUI there's two separate buttons: one for stopping immediately, and one for finishing the fight before stopping.