Feature - Implemented enable after-adventure script after manual adventuring

[AlbinoRhino]

OK. Do we care if this script is called in the Relay Browser? I'm thinking "no", since I think its main use will be doing things to satisfy goals - and goals are only applicable for automated adventuring. You will be able to see what items you find in the relay browser and decide exactly what to do with them at the time, via the helpful "use" links, if you have those enabled.

I added the preference, but it's a no-op. I'm going to close this and if somebody comes up with a use for an after-adventure script after manual adventuring, they can open a new Feature Request for it.

Could this please be enabled for the relay browser as well ? I have a script which prints various information to the cli for me based on what I'm doing at the time, which I currently have included in a mood, which means it prints its messages before adventuring. I usually play in the relay browser with the cli running in the chat pane. The situation is that often the messages from a single adventure are more than the chat pane can contain and I find myself constantly scrolling upwards to read the messages my script has printed for me. It would be great if I could have this script run after battle and therefore have the information it prints be the last thing printed to the browser cli.

 

[Gnocchi Masala]

I don't know if it would be appropriate to use the same hook for relay and non-relay but I would really like some script hook to automate various administrivia in relay browsing please.

 

[Theraze]

Can't you just turn relayRunsAfterAdventureScript to true?

 

[lostcalpolydude]

Can't you just turn relayRunsAfterAdventureScript to true?

Yes, that should work (marked Implemented). Unless it isn't working for some reason, in which case this would actually be a bug.

 

[Veracity]

I have the setting, but we don't use it yet.

Reopening.

 

[Veracity]

Try Revision 10800.

 

[AlbinoRhino]

It appears to be running the script after the "win/loses initiative" messages appears, unless it's a non-combat adventure.

 

[Veracity]

Doesn't do that for me. I guess I will investigate more.

 

[AlbinoRhino]

Doesn't do that for me. I guess I will investigate more.

I am attaching the session log for the character which I tested it on. Inever got any errors or debug logs. The character had the same script included in its mood for the first 3-5 adventures, before I remembered to remove it from the mood. Could that have screwed something up ? For the rest of the adventures, the script was only running as an after-battle script.

EDIT: Looking over this session log, I notice that the script first ran when the charpane override script was checking for updates. ??

 

[Veracity]

Well, I keyed to run when the charpane tells us that we've used an adventure. That is the identical trigger that we used to use, back when the betweenBattleScript was run after battles in the Relay Browser.

What I see is this:

- I tell KoLmafia to adventure somewhere.
- It starts the fight
- The charpane does not refresh
- If I force it to refresh, the "adventures left" does not change.
- I finish the fight
- The charpane refreshes, and the "adventures left" changes.
- That triggers the afterAdventureScript to run.

Apparently, when YOU execute in the Relay Browser, the charpane updates after the first round of the fight starts - the "won/lost initiative" round - and, unlike for me, KoL has already decremented the "adventures left" counter. That is bizarre.

Revision 10801 will not run the afterAdventureScript if it thinks you are still in a fight. That should stop it from executing in the middle of battle - although I am puzzled as to why it thinks it needs to run it there.

Actually, I am not puzzled. It was also triggering if you have started a battle. I am puzzled as to why it was not triggering for me.

 

[AlbinoRhino]

Could it possibly be because of the cli running in the chat pane ? I am sure that the charpane refreshes much more often when the cli is running in the browser, although I am not sure what triggers each refresh.

 

[Veracity]

I don't know. As I said, even when I forced a refresh, it did not force my script to run - and, looking at the code, I don't understand that.

I think the current code will work for you. Try it and report back, please.

 

[AlbinoRhino]

Will do. I should be able to download it in about 35 minutes. Thanks for all of your awesomeness !

 

[AlbinoRhino]

It's now working as expected. I did get a debug log the first time that mana burning occurred. I kept adventuring until mana burning had run twice more and the unexpected error did not recur. I don't know if the debug log is actually related to this issue or not but I will attach it here. Otherwise, everything worked perfectly.

Thanks again for all your efforts !

 

[Gnocchi Masala]

Thanks for that Veracity.
When I went to Preferences to turn it on I was surprised to see that I could also turn on the betweenBattleScript in relay. The Miscellaneous ASH features wiki page just says bBS will not fire from the relay browser. Do we have a wiki updater person/team? Yes i will do this if someone advises me.
The first time aAS ran I got two debugs and one successful run:

1 frat boy defeated; 972 down, 28 left.
Unexpected error, debug log printed.
afterAdventureScript
Unexpected error, debug log printed.
betweenBattleScript
Calling Universal Recovery for type=HP, amount=0
Calling Universal Recovery for type=MP, amount=0

Subsequently aAs seems to be running twice:

1 frat boy defeated; 973 down, 27 left.
afterAdventureScript
afterAdventureScript
betweenBattleScript
Calling Universal Recovery for type=HP, amount=0
Casting Laugh It Off 2 times...

My aAS and bBS each just contain a single print statement to show when they run.
Despite reporting 2 Debug logs only one was created.
View attachment DEBUG_20120317.txt

 

[AlbinoRhino]

So...I've gotten the debug_log a couple more times since my last post. The most recent is attached. I notice that after the debug that the scripts menu doesn't list any of my scripts past the name of my afterAdventureScript. Clicking "Refresh menu" does not restore the list.

 

[Veracity]

Whoa. Yes, indeed: it appears that we refresh the script menu any time we execute a script via an implicit "call" command: via the CLI, from the Script menu, a betweenBattle script, an afterAdventureScript. Probably not a consult script, a counter script, or a recovery script, since those have to be ASH scripts. But the other ones I mentioned go through the CLI.

This is a result of the Script MRU list: it wants to rebuild the script menu every single time a script is run so it can reorder it. The code as present will do this even if you don't have the MRU list activated. It does this by clearing the menu and re-adding the current set of files and directories

That is a lot of file system activity. It is also repeatedly manipulating and rebuilding an active UI control - the Script Menu - from a different thread than the one which otherwise handles inputs from it - the Swing thread.

I see two kinds of stack traces in the ones presented:

- We are "adding" an entry to the list at a particular index, which is too big, it seems
- A Null Pointer Exception construction the menu

This is a can of worms.

I think it is highly unlikely that even those who want to use a Script MRU list really want their afterAdventure and betweenBattle scripts to be listed there; presumably, they want the scripts that they have manually executed. But, I'm not going to touch that.

What I will do is make the script menu rebuild after command execution ONLY if you are operating with a Script MRU list, so those of us who don't use it will not have the performance drag and potential for bad interactions with the Swing thread that I mentioned above.

 

[Veracity]

Revision 10804

 

[fronobulax]

Good catch. Thanks.

 

[Gnocchi Masala]

Thanks Veracity, I'm no longer seeing the debugs but I'm still getting two invocations of the aAS after combats in the relay browser ... non-combats and automated adventuring only trigger once.
Added AAS to the Miscellaneous ASH Features wiki page. I could use some words (or a pointer to said words) to describe exactly when AAS fires.