"refresh all" doesn't even go near the charpane, so I'm guessing there is nothing missing from the API that isn't also missing from the charpane.
That was true until they added the number of PVP fites remaining to the charpane. I have requested that be added to the API. But, since we don't parse it from there, anyway, since displaying it is opt-in, that's not a big concern.
I've thought about - and experimented with - doing this for years. The following code in GenericRequest determines if we generate a request for charpane.php:
Code:
if ( this instanceof RelayRequest )
{
this.containsUpdate = false;
}
else if ( effectCount != KoLConstants.activeEffects.size() || this.getAdventuresUsed() > 0 )
{
this.containsUpdate = true;
}
else
{
this.containsUpdate |= this.responseText.indexOf( "charpane.php" ) != -1;
}
if ( this.containsUpdate )
{
new CharPaneRequest().run();
RelayServer.updateStatus();
}
Note that we never look at the char pane after a RelayRequest; we assume that the browser will generate one, if KoL asked for it, and we will pull what we need from it.
Note that we will ask for the char pane if you've gained or lost an effect or we believe that the request might have consumed an adventure.
And finally, note that if KoL tells us that the char pane has changed, we will load it, just like the Browser would in such a case. (Which is why saying "oh, it's just Javascript and the Browser won't load it if you turn off Javascript" is a red herring; if you try to run vanilla KoL with Javascript disabled, you will not be happy, for that and many other reasons.)
The middle check is probably subsumed by the last one, because if you execute a request in the browser and KoL does not tell you the char pane has changed, it's pointless to fetch it again. I.e., any change in effects or adventures used will spur KoL to say "get the char pane".
We could probably skip refreshing the char pane just for gaining or losing effects, but tracking adventures is The Big Reason we look at the char pane. KoLmafia does not "count adventures", contrary to the impression of many many posts that I've seen over the years. KoLmafia looks at the char pane and detects that the adventure count has changed and then updates things that depend on that. THAT is something that is not going to change; if we start actually "counting adventures", every time KoL adds something new that uses an adventure - or doesn't use an adventure (a choice option that lets you skip the choice, for example), then, suddenly, counters break and screams of outrage arise from users until we add it to the code.
This request wants to skip requests after items are used. Fine. First, complete the refactoring of UseItemRequest to make sure that all updating of KoLmafia's internal state occurs when we are parsing the response text, rather than doing some of it when the request is submitted and, perhaps, rolling it back if it failed. I think UseItemRequest could stand a major refactoring. It is complicated by the fact that sometimes item usage comes back as a response to inv_use.php and sometimes as a redirect to inventory.php?action=message. And there are so many special cases for items, with special messages determining exactly what happened when you use them. Yes, we can detect "You gain an effect", and such. Perhaps we can detect "You gain (or lose) xxx HP (or MP)".
I think the most promising idea is to change the line in GenericRequest.processResponse() that calls "new CharPaneRequest().run()" to do an ApiRequest?what=status instead and just parse the JSON (using existing code) rather than the HTML text.
