loathers / grimoire Goto Github PK

I looked into this, but args left me stupified

Looprobot was trying to equip the poolcue and I think outfit.ts decided to put it on disembodied hand. This is a 2-handed weapon so theres some issue here with handedness or disembodied hand equips.

I have a draft PR to address this, but I feel like I probably did it wrong. What I'd like is to be able to assign a default value to a pref in such a way that it's not actually evaluated until Args.fill is called--the main use case is to prevent mallsearches in garbo before we do our big mallPrices("allitems") but I'm sure there are other use cases

I recently had to write the following admittedly-shitty function for garbo's upcoming outfit revamp:

export function validateGarbageFoldable(spec: OutfitSpec): void {
  const garbageItems = getFoldGroup($item`January's Garbage Tote`);
  for (const garbageItem of garbageItems) {
    if (
      Object.values(spec).some(
        (specEntry) =>
          specEntry === garbageItem || (Array.isArray(specEntry) && specEntry.includes(garbageItem))
      )
    ) {
      if (!have(garbageItem)) cliExecute(`fold ${garbageItem}`);
      break;
    }
  }
}

because calling Outfit.from was throwing errors when we don't have our foldable folded.

Garbo currently doesn't actually use grimoire's task-engine framework in most places, which is admittedly an us problem. phccs handles the issue by either folding the thing we want as part of our outfit function (as this does; phccs outfits are a lot more predictable and less dynamic than garbo ones) or as part of a prepare function for a task. It would be nice to have a system embedded directly into grimoire's outfit and/or task handling to do folding, sort of like how it has native modeable handling.

compileAutoattack has nothing in it that supports starting_macro or ActionDefaults and this is, as far as I can tell, undocumented. It also doesn't appear to have any analogues thereof.

I assume that this relates to an extremely annoying aspect of JavaScript and also TypeScript (typescript has a separate, extra-annoying part where it doesn't resolve it);

if I have a type type ExampleType = { foo?: string }, two very different objects could fulfill it: { foo: undefined }, and {} both fit that type because foo is an optional parameter. However, when we put an ExampleType into an object spreader, bad things happen:

const DEFAULT = { foo: "bar" };
const test = {};
return { ...DEFAULT, ...test}; // { foo: "bar" }

const DEFAULT = { foo: "bar" };
const test = { foo: undefined };
return {...DEFAULT, ...test} // {foo: undefined}

Because outfit.spec() populates the spec with a bunch of undefineds instead of leaving the entries truly blank, we can get some ugly behavior when using object spread syntax with it.

My attitude is that we should only add things to the spec object if they are truthy, and I'll put in a PR as such, but this is a sufficiently spicy issue that I'm making a github Issue for it beforehand, lest we need to modify things.

The moral of the story is some freecandy code went from looking like combatOutfit(outfit.spec()) to

combatOutfit(
  Object.fromEntries(Object.entries(outfit.spec()).filter(([, value]) => value))
);

Item, Items, Familiar, Familiars, Path, Effect, etc.

in garbo, we run it with garbo 100 for the number of adventures. To move over to grimoire args, we'd need to be able to replicate this behavior (e.g. having an argument that doesn't come in the form key=value)