New Content May 2026 IotM - Legendary Pasta Wand

[Magus_Prime]

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.

 

[Ryo_Sangnoir]

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

 

[VeeArr]

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.)

 

[Magus_Prime]

Here are the new cooked items and the recipes.

 

[Opassa]

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.

 

[Opassa]

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:

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.

 

[Opassa]

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:

        } 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.

 

[Ryo_Sangnoir]

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.

 

[Opassa]

I got something working, feel free to use this code if you want, I'm not confident enough to submit it as a pull request, but it works for me.

session/ResponseTextParser.java line 323 add:

        } else if (responseText.contains("How do you want to digest the legendary noodles?")) {
          AdventureResult item = ChoiceManager.lastItemUsed;
          if (item != null) {
            UseItemRequest.setLastItemUsed(item);
            UseItemRequest.parseConsumption(responseText, false);
            SpadingManager.processConsumeItem(item, responseText);
            UseItemRequest.clearLastItemUsed();
          }

request/UseItemRequest.java line 1419 add:

  if (!this.responseText.contains("How do you want to digest the legendary noodles?"))

I tested eating from the command line, "eat 1 Linguini Ubriacapa", it works properly. It gives "Unsupported choice adventure #1599", which is currently expected, so support for that choice adventure might need to be added.

When I run the following ash script:

    $item[Linguini Ubriacapa].eat(1);
    run_choice(5);

it crashes the script before the run_choice with "Unsupported choice adventure #1599". I assume that adding that adventure will fix this problem and let run_choice(5) do its work.

I also tested it with visit_url("inv_eat.php?pwd=" + my_hash() + "&which=f1&whichitem=12240"); and run_choice(5) after that succeeded. Which is probably good enough for scripting.

I tried eating it with Milk of Magnesium and Special Seasoning. The Milk of Magnesium message wasn't included in the choice.php response even though it added 5 adventures, so it wasn't able to parse that consumption out. I will bug report that to KoL developers. But the Special Seasoning worked correctly. And the number of Linguini Ubriacapa was also decremented properly. So it all seems to work.

Also, the result of choice 1599 should probably be reported to the CLI/Log.

Edit: fixed the code for bugs it introduced. My previous code caused bugs related to Mayam calendar and archaeologist's spade (and potentially other items) when scripting.