New Content May 2026 IotM - Legendary Pasta Wand

Magus_Prime

Well-known member
I see that the skeleton to support this item just went in. One thing that I didn't see in the initial support is:
  • During breakfast, if Pastamastery is set to be cast, equip the wand before casting.
Thank you for your consideration.

P.S. If I missed this in browsing the code I apologize in advance.
 
That isn't necessary, because merely having it in the inventory is enough.

We do still need:
* new cooked items
* recipes
* prefs for when you eat the items
* support for the features when you eat the items, e.g. the new misc modifiers
 
Given the bonus utility of the level 11 thralls, it might be nice for mafia to at least estimate the current thrall's XP. (As far as I can tell from a cursory glance, only the level is tracked currently, presumably because the game doesn't actually display the XP anywhere.)
 
Another thing that needs to be handled is Special Seasoning. When I eat the legendary noodle dishes, it throws off the count of Special Seasoning, so then when I go to closet them it fails because it tries to closet more than I have in inventory.
 
I also just discovered that it's not registering mayo as being consumed when eating legendary noodle dishes. This wouldn't really be a big deal, except that it then prevents you from taking new mayo until you've eaten something. Using the mayo isn't doing anything special, it's just this:

use(1, $item[Mayozapine]);

So the flow goes:

use(1, $item[Mayodiol]);
eat(1, $item[Pesto alla Marziano]);
run_choice(...);
use(1, $item[Mayozapine]); // KoLmafia throws up an error instead of consuming mayozapine
eat(1, $item[cranberry cylinder]); // food is eaten without mayo

I don't have the error message today because it doesn't write the error to the log, it just gets output to the CLI only. It's something about "you can't take mayo right now because your mouth is already full of mayo". I'll try to get the exact error message tomorrow if that would be any help tracking this down.

I assume it has the same root cause as the special seasoning bug. It must be not parsing the eat as an eat because it involves a choice adventure.

Edit: I've researched in the code the root cause. It's line 1414 of UseItemRequest.java:

Java:
if (UseItemRequest.currentURL.startsWith("choice.php")) {
  return;
}

I would submit a pull request for this, but I'm not sure my solution would be the way it's desirable to be solved. I would approach this by making an exception if the "this.ItemUsed" is one of the legendary noodle dishes, don't return. Or maybe if "this.responseText" contains text specific to the legendary noodle choice. But hopefully this is enough digging to make it easy for someone else to write up a quick bug fix.
 
Last edited:
I've been debugging the eat requests on the noodles today. It turns out it's a lot more complicated than I thought. When you use a Loathing Idol Microphone or eat a legendary noodle dish, it calls inv_use.php or inv_eat.php. The response from KoL is a tiny page which sets the document url to choice.php?forceoption=0. This choice.php then loads the actual text, but by the time this has happened, it's lost track of the item that it's using. The actual result of eating/using needs to somehow be associated back to the inv_use.php or inv_eat.php request. The first thing I tried was adding code to the choice.php handler in ResponseTextParser.java line 323:

Java:
        } else if (location == "choice.php?forceoption=0") {
          AdventureResult item = UseItemRequest.getLastItemUsed();
          UseItemRequest.parseConsumption(responseText, false);
          SpadingManager.processConsumeItem(item, responseText);
        }

But if it calls that, it doesn't have an item assigned to UseItemRequest.getLastItemUsed(), which returns null, and then parseConsumption does nothing because the item was null. The microphone does get counts updated properly after you use it, but not until you actually make a choice. But eating legendary noodles needs to handle the first response text after it calls choice.php, because that's where all the consumption messages happen. I suspect the microphone was implemented to change counts after the choice instead of on forceoption=0 because it was much easier to implement that way, but that's not really an option for legendary noodles.
 
I think special-casing the noodles is the right move: this case where the choice adventure also contains the consumption results can't be particularly common. In processResults, before noting that we were redirected to a choice, handle the consumption in there.

For the most part, it returns because items-that-redirect-to-choices don't consume the item until the choice is dealt with, so there's no point running the standard process.
 
Back
Top