New Content 2022 Standard

[MCroft]

I think this is a cosmetic bug where things are working as expected.

I pulled something I did not have in storage and got two messages, of which the second could be safely suppressed.

> pull nd

[ND] requested, but none available.
[ND] requested, but it's not a Free Pull

 

[Veracity]

That's sort of problematical. It comes from how we parse the argument.

"nd" is an exact match for an item. So, we could just look it up, right? Except the pull command can take multiple arguments and will do fuzzy matching on the names. You could, in theory, list multiple items: some in storage and some on freepulls. As coded, we have this:

    if (inHardcore) {
      items = ItemFinder.getMatchingItemList(parameters, KoLConstants.freepulls);
    } else if (!inRonin) {
      items = ItemFinder.getMatchingItemList(parameters, KoLConstants.storage);
    } else {
      // See if in storage. If not, see if in freepulls.
      items = ItemFinder.getMatchingItemList(parameters, KoLConstants.storage);
      if (items.length == 0) {
        items = ItemFinder.getMatchingItemList(parameters, KoLConstants.freepulls);
      }
    }

We could/should use ItemFinder to parse the command parameters into a list of items and then iterate through them all and determine if they are on storage or freepulls and give an error (and remove from list) if an item is not available.

I guess that'd be a new method in ItemFInder - for correctness and testability.

Edit: Actually, if ItemFInder treated "storage" as "storage or freepulls" and "freepuls" as "only freepulls", we could simplify that into:

    } else if (inHardcore) {
      items = ItemFinder.getMatchingItemList(parameters, KoLConstants.freepulls);
    } else {
      items = ItemFinder.getMatchingItemList(parameters, KoLConstants.storage);
    }

and it will be more efficient and fix this glitch as well.

 

[Veracity]

I am fixing this and, whoa. Not that hard, but I'm also writing comprehensive tests for ItemFinder.getMatchingItemList, and it's a doozy.