Feature - Implemented Update charpane in Ed when using /servant chat command
- Thread starter Ensiferum
- Start date
Yep. I have an "illiterate" character for that very reason.
I've been looking at this a bit.
Let's compare two /commands and see how they work in the Relay Browser and via KoLmafia's internal chat (and via gCLI).
1) /familiar
- Browser sends the message using lchat or mchat, as the user desires
- KoL sends back an Event - green - message which includes js(dojax(familiar.php...))
- Browser sends the URL to actually do the work
- KoL sends back an ajax response - little frame at top of window - which includes a charpane refresh.
KoLmafia sees the response to familiar.php and updates its model.
For an internal chat command - the user typed it into KoLmafia chat or the gCLI:
- KoLmafia sends the command via lchat
- KoL sends back the response with the javascript command in it
- KoLmafia process the response and calls ChatPoller.addSentEntry
- That method calls ChatPoller.executeAjaxCommand, which extracts the URL and submits it
When we get the response to familiar.php, we update our model
2) /servant
- Browser sends the message using lchat or mchat, as the user desires
- (KoL does the desired servant switch)
- KoL sends back an Event - green - message which says that it did it and includes a charpane refresh.
Currently, KoLmafia does not do anything special with the response and depends on seeing the charpane refresh to recognize the servant switch.
Since it is an event, it is sent through ChatManager.processEvent, where the html is stripped out and it is printed to the gCLI.
For an internal chat command - the user typed it into KoLmafia chat or the gCLI:
- KoLmafia sends the command via lchat
- (KoL does the desired servant switch)
- KoL sends back an Event - green - message which says that it did it and includes a charpane refresh.
Currently, KoLmafia does not do anything special with the response. I suppose it could see the charpane refresh - and turn it into an api.php request - except Ed servants are not yet in api.php, are they?
Since it is an event, it is sent through ChatManager.processEvent, where the html is stripped out and it is printed to the gCLI.
The key thing to note is that ChatManager.processEvent handles all green messages that KoL sends to chat, whether they are from the Browser via lchat or mchat or are a response to an internal lchat request.
If you look at that method, you see that we look for " has " and force an api.php refresh. Odd, eh? Well, that is detecting "xxx has played the Moxious Madrigal for you" or "xxx has fortified you with Astral Shell" events - other players buffing you - and refreshing api.php updates the effect list.
However, this is clearly the correct place to look for the "/servant" events.
I think that method needs a little reorganization: it does not look at the content of the message if the user asks to suppress events from being displayed, for example. That seems wrong: why would we not call api.php to refresh effects just because the user doesn't want to be told about getting buffed? Ditto for servant swaps.
I'm willing to try adjusting this method to detect /servant results, based on Darzil's saved messages above, but I'm not currently in Ed. I can still code it, but I can't test it. I was planning on being out of Ed for (at least) 5 runs, so it will be 10 or 15 days before I get back there. I look at this then, unless somebody currently in Ed wants to take a shot at it.
Revision 15751 recognizes the event generated by /servant and updates your servant immediately, whether or not a charpane refresh happens. (i.e., you can use /servant in the gCLI and it will now work.)
Tested, even, since I'm doing one more Ed run as a transition back to Seal Clubber so I can fight Wart Dinsey as that class.
Tested, even, since I'm doing one more Ed run as a transition back to Seal Clubber so I can fight Wart Dinsey as that class.