Bug - Fixed Casting skills on other targets doesn't work

H

heeheehee

Developer
Staff member
This is pretty easy to reproduce:
Code: 
> cast madrigal on monsooncrafter

Casting The Moxious Madrigal on monsooncrafter 1 times...
You acquire an effect: The Moxious Madrigal (duration: 10 Adventures)
The Moxious Madrigal was successfully cast.

> my_name

Returned: heeheehee

I'll take a look at the code in a bit.
 
H

heeheehee

Developer
Staff member
Got a debug log for a slightly different request:
Code: 
> cast polka on monsooncrafter

Casting The Polka of Plenty on monsooncrafter 1 times...
class net.sourceforge.kolmafia.request.UseSkillRequest
Connecting to skills.php...

Requesting: http://www.kingdomofloathing.com/skills.php?action=Skillz.&whichskill=6006&bufftimes=1&specificplayer=[B][COLOR="#FF0000"]354981[/COLOR][/B]
3 request properties
Field: Cookie = [appserver=www8; PHPSESSID=l8c2jg9eu0q4aj70hn3rfckra4]
Field: User-Agent = [KoLmafia v16.3]
Field: Content-Type = [application/x-www-form-urlencoded]

Retrieving server reply...

...
Well, ain't that dandy. (#354981 is Heeheehee's player ID, not MonsoonCrafter's)

That does suggest the problem has to do with session.ChatManager#getPlayerId, which in turn is simple enough it suggests the problem is in session.ChatManager#registerPlayerId
 
Last edited:
lostcalpolydude

lostcalpolydude

Developer
Staff member
There's chat.ChatManager (which seems to not be relevant here) and session.ContactManager (which has registerPlayerId), for anyone else looking at this.

getPlayerId just returns the player's name if their id hasn't already been stored previously, in this case. Some other case could have led to playerid being stored incorrectly for someone, but that would be easy for you to check with get_player_id( playername );
 
H

heeheehee

Developer
Staff member
Indeed.
Code: 
> get_player_id monsooncrafter

Returned: 1832792

Debugging seems to suggest that the form fields are all set correctly, up until the actual running of the request. I'm stumped.
 
Veracity

Veracity

Developer
Staff member
I've been looking at UseSkillRequest for another reason: I notice that if I have timed out and attempt to use a skill, it times in - which gives you a new password hash - but the data field doesn't seem to get constructed with the new password hash.

UseSkillRequest has a cache of request objects that it has previously used - one per skill - and when it reuses such an object, unless something changes in it (the target of the buff, for example), with will not rebuild the data string.

That's not exactly what you are reporting, but I'll bet it is the request object cache that is causing you an issue, too.

I am investigating further.
 
Veracity

Veracity

Developer
Staff member
What a can of worms. Yes, it is all about the "cached" UseSkillRequest objects. When we set up to cast a skill, get fetch the cached copy and modify the target as desired. But, there are any number of places which want to fetch the cached request in order to simply query it for things like "maximum possible casts given current MP" - and doing so will reset the cached request to have your own player ID as the target.

Revision 14225 makes all the "get a UseSkillRequest simply for querying, not to actually submit" places use getUnmodifiedInstance rather than getInstance.
 
You must log in or register to reply here.
Top