Feature - Implemented Make "refresh status" use api.php

[lostcalpolydude]

The main reason this seems like a good idea is that it gives mafia a way of figuring out your fullness (when it's inaccurate due to quantum tacos or other future weirdness that might come up) without the extra server hits of "refresh all".

A patch is attached. I looked to see if any other refresh commands could simply switch to api.php, but none of them were obvious enough. Maybe refreshing equipment, but I'm not so sure about that.

 

[Veracity]

We get a couple of things from the charpane that are not in api.h: whether your familiar is "well-fed", and Intrinsic Effects. I asked CDM for those a long time ago, with no response. (Looking at the outstanding issues list for kolproxy, I see that Eleron lists Intrinsic Effects as "waiting for api.php change", so I'm not the only one who noticed that.)

I think the "gear" and "equipment" refreshes could use api.php with no harm; it has your equipment, stickers, and fake hands, which is all that we get from the Equipment page, anyway.

 

[Veracity]

FWIW, I just submitted the following Bug Report:

I've been using charpane.php to update character status. It's tricky, in that there are both normal and compact forms, and it's full of HTML, but it has a most of the important stuff on it.

Recently, KoL made the "unfunniest update ever" to optionally include fullness on the charpane. Personally, I find it unfortunate that it is opt-in, since I'd like to be able to always update fullness from the charpane, but, whatever.

As it turns out, fullness is always in api.php. That is good. So, I'd like to switch over to using api.php for status updates.

Unfortunately, there are two things on the charpane that are NOT in api.php, and I therefore need to make two server hits, rather than one, to get a full status refresh. The missing data:

- The feasted state of your familiar - whether it is "well-fed" - is only on the charpane.
- Your current Intrinsic Effects are only on the charpane.

Please help me hit the server once, rather than twice. Please add "feasted" and "intrinsics" to api.php?what=status.

Thanks.

I debated on whether to submit a Bug Report - which has a chance of getting inserted onto CDM's official bug queue (where it will likely languish), or sending CMD a Kmail with the same request (where it will likely languish). I decided on the former, since CDM has way too much official work on his plate to do favors, I think. (After I submitted my slew of Anapestic Combat Bug Reports, Gemelli told me that I, personally, now had 10% of the bugs on his queue. I have yet to see any Anapestic fixes... )

 

[roippi]

We can commit this now, ya?

 

[Veracity]

Yes!

 

[Veracity]

Along similar lines, the "refresh" button on the green sidepane (swingui/panels/CompactSidePane.java) currently does a CharSheetRequest. That seems less useful than a charpane.php - or now an api.php - update, especially since I removed parsing effects from the charsheet.

		JPanel refreshPanel = new JPanel();
		refreshPanel.setOpaque( false );
		refreshPanel.add( new RequestButton( "Refresh Status", "refresh.gif", new CharSheetRequest() ) );

 

[Veracity]

And and and ... here's a radical idea. Replace ALL the places that KoLmafia internally submits a CharPaneRequest to, instead, do an ApiRequest. That will result in a lot less HTML parsing and Patterns and Matchers and such. It will be replaced with JSON parsing. That may or may not be faster, but it is completely insensitive to KoL changing the physical appearance of the charpane.

 

[Veracity]

OK. Revision 10672 uses api.php instead of charpane.php for most of the places KoLmafia tries calling it.

I decided not to use it as a substitute for the charpane for those times that KoL tells us to fetch the charpane. I think that can be made to work, but we do have a difference in how we interpret the results:

- charpanes are timestamped and when we process one, we interpret differences between current state and what we see on it as a delta and will log adventures being used, will call triggers on stats changing, and so on.
- api is interpreted as a snapshot of the current state and simply replaces old state with new state.

I changed the following things:

- The ASH "refresh_status" function
- The CLI "refresh status" and "refresh effects" commands
- The "Refresh Status" button on the green sidepane
- When Chat Manager thinks that somebody has given you a buff
- When you use a skill and we encounter lag and cannot tell if MP was consumed
- When you use a skill and KoL says you don't have enough MP

The first three are requests for a snapshot.
The skill usage failures indicate that we are confused about your current MP for an unknown reason
The Chat Manager, probably, should be treated as a delta. I may change that one back.

 

[roippi]

Very cool.

I think this may have introduced some eccentricities with familiar weight handling. I just started what I intend to be a serious run so I'll provide more info as time permits.

Edit1: equipping things that modify familiar weight seem to cause problems. Not sure of the direction of the problem yet.

Edit2: casting weight-modifying skills too.

Edit3: I was completely wrong. This commit did not cause the issue I was talking about, it had been around for a good number of revisions. I'll open a new bug report.