@rpgm-tools/neo-angband-core 0.10.0

package/dist/game/gear.d.ts

@@ -0,0 +1,408 @@
+/**
+ * The player's gear store: the world/UI-owned side of carried objects.
+ *
+ * The parity Player (player/player.ts) deliberately omits struct player's
+ * gear list, keeping only equipment[] as per-body-slot object HANDLES
+ * (0 = empty). This module owns the objects those handles point at: a
+ * handle -> GameObject store plus an ordered pack of non-equipped handles.
+ * It ports the equipment/carry substrate and the birth starting-kit from
+ * reference/src/obj-gear.c (slot_by_type, wield_slot, inven_carry) and
+ * reference/src/player-birth.c (wield_all, player_outfit) (Angband 4.2.6).
+ *
+ * LIVE vs DEFERRED (ledgered in parity/ledger/game-gear.yaml):
+ * - LIVE: slot_by_type (empty-preferring), wield_slot (full tval switch),
+ *   inven_carry's merge-or-add with quiver stack-mode routing, wield_all's
+ *   split-and-wear, player_outfit's start-item roll + prep + carry + wield
+ *   (birth_start_kit + eopts exclusion honoured), the real quiver subsystem
+ *   (object_is_in_quiver, preferred_quiver_slot, quiver_absorb_num,
+ *   calc_inventory's quiver assignment, pack_slots_used quiver accounting),
+ *   combine_pack + inven_can_stack_partial, and minus_ac armour damage,
+ *   pack_is_full / pack_is_overfull (the pack_size overflow enforcement itself,
+ *   pack_overflow, needs drop_near and so lives in game/obj-cmd.ts next to the
+ *   other obj-gear.c verbs that touch the floor).
+ * - DEFERRED: the display knowledge twin (obj->known) and equip_cnt UI
+ *   counter.  The pack-side inven[] listing is a derived view rather than the
+ *   source of truth: gear.pack keeps master-gear insertion order while
+ *   gear.inven reproduces calc_inventory's earlier_object ordering. Wielding DOES learn modifier runes
+ *   (obj-knowledge.c object_learn_on_wield); see obj/knowledge.ts.
+ */
+import type { Constants } from "../constants.js";
+import type { Rng } from "../rng.js";
+import type { ObjRegistry } from "../obj/bind.js";
+import type { GameObject } from "../obj/object.js";
+import type { PackTotalGear, StackLimits } from "../obj/object.js";
+import type { ObjectKind } from "../obj/types.js";
+import type { EarlierObjectOpts } from "../player/calcs.js";
+import type { Player } from "../player/player.js";
+import type { PlayerBody } from "../player/types.js";
+/**
+ * The player's live gear: every carried object by numeric handle, plus the
+ * ordered list of pack (non-equipped) handles. Equipped objects stay in
+ * `store` and are referenced by player.equipment[slot]; they are not in
+ * `pack`. Handles start at 1 so 0 can mean "empty" in equipment[].
+ */
+export interface Gear {
+    /** handle -> live object (both pack and equipped objects). */
+    store: Map<number, GameObject>;
+    /** The next handle to assign (always >= 1). */
+    next: number;
+    /**
+     * Ordered non-equipped handles: the port's stand-in for upstream's master
+     * gear list minus the equipment (upstream p->gear minus body slots). This is
+     * the raw storage ordering AND the pack listing; ammo/throwing handles that
+     * calc_inventory has routed into the quiver stay in this list (exactly as an
+     * upstream quiver object stays on p->gear) and are additionally referenced by
+     * `quiver` below - use objectIsInQuiver to tell them apart.
+     */
+    pack: number[];
+    /**
+     * upkeep->inven[]: computed, earlier_object-sorted non-quiver pack view.
+     * This is deliberately separate from `pack`, whose order is the master-gear
+     * ordering used by combine/split logic.  It is rebuilt, never persisted.
+     */
+    inven?: number[];
+    /**
+     * upkeep->quiver[z_info->quiver_size]: the COMPUTED quiver view, one handle
+     * per slot (0 = empty), filled by calcInventory. Optional so that a Gear built
+     * without it (e.g. a save-load reconstruction, before calcInventory runs)
+     * type-checks; it is a derived view and is rebuilt by calcInventory rather
+     * than persisted. Empty/absent means the pre-quiver behaviour (ammo behaves
+     * as a plain pack stack). Kept on Gear alongside `pack` (the inven view's
+     * home) rather than on Player, mirroring how the port already keeps the pack
+     * listing here while Player holds only equipment[] handles.
+     */
+    quiver?: number[];
+}
+/** A fresh, empty gear store (empty quiver; calcInventory sizes it). */
+export declare function newGear(): Gear;
+/** Store an object under a fresh handle and return it (no pack insertion). */
+export declare function gearAdd(gear: Gear, obj: GameObject): number;
+/** The object for a handle, or null (0 / unknown handle -> null). */
+export declare function gearGet(gear: Gear, handle: number): GameObject | null;
+/**
+ * object_split (obj-util.c): split `amt` items off `src` into a fresh copy,
+ * distributing wand/staff/rod charges, and reduce src by amt. Requires
+ * src.number > amt (upstream assert). Exported for the floor-pile module
+ * (floor_object_for_use splits floor stacks the same way).
+ */
+export declare function objectSplit(src: GameObject, amt: number): GameObject;
+/**
+ * wield_slot (obj-gear.c L341-367): the equipment slot an object of the
+ * given tval likes (an open slot preferred for rings), or -1 for a
+ * non-wearable tval.
+ *
+ * `equipment` (optional, defaults to all-empty) lets the empty-slot
+ * preference work; wieldObject/wieldAll pass the player's real equipment
+ * so a second ring lands in the free hand, matching upstream.
+ */
+export declare function wieldSlot(body: PlayerBody, tval: number, equipment?: readonly number[]): number;
+/**
+ * object_is_in_quiver (obj-gear.c L163-174): is the object referenced by
+ * `handle` currently held in one of the computed quiver slots? A zero handle
+ * (empty slot / no object) is never in the quiver.
+ */
+export declare function objectIsInQuiver(gear: Gear, handle: number): boolean;
+/**
+ * preferred_quiver_slot (obj-gear.c L1396-1427): the quiver slot an object's
+ * inscription asks for, or -1 when it is not quiver-appropriate or not
+ * inscribed with a matching @f/@v (fire / throw) key. The fire key depends on
+ * the keyset: 't' under rogue-like commands, else 'f'; the throw key is always
+ * 'v' (upstream hardwires these because cmd_lookup_key is in the UI layer).
+ */
+export declare function preferredQuiverSlot(obj: GameObject, rogueLike?: boolean): number;
+/** Optional message / naming hooks for minusAc. */
+export interface MinusAcEnv {
+    /** msg(): the "Your %s is damaged!" / "is unaffected!" lines. */
+    msg?: (text: string) => void;
+    /** object_desc(ODESC_BASE): the bare armour name; defaults to kind.name. */
+    describe?: (obj: GameObject) => string;
+    /** PU_BONUS trigger fired after a to_a decrement (calc_bonuses refresh). */
+    updateBonuses?: () => void;
+}
+/**
+ * minus_ac (obj-gear.c L376-438): acid has hit the player, so attempt to
+ * damage a piece of worn armour. Counts the armour slots, draws one at random
+ * with the exact upstream reverse one_in_(count--) scan, and (if that item can
+ * still lose armour) either reports it resists (EL_INFO_IGNORE on ELEM_ACID)
+ * or decrements its to_a and prints the damage message. Returns whether there
+ * was any effect (a piece was picked and had ac + to_a > 0), matching upstream
+ * so the caller can halve the elemental damage.
+ *
+ * The RNG draw order is preserved bit-for-bit: the forward count loop, then
+ * the reverse pick loop consuming one_in_(count--) per armour slot until it
+ * breaks. `obj->known->to_a = obj->to_a` (L425-426) is DEFERRED - the port has
+ * no per-object known twin (obj-knowledge #4.8); obj_k->to_a is 1 at birth so
+ * the real to_a is already the shown value.
+ */
+export declare function minusAc(player: Player, gear: Gear, rng: Rng, env?: MinusAcEnv): boolean;
+/**
+ * inven_carry (obj-gear.c L821-925): add an object to the gear. If a
+ * non-equipped stack is object_mergeable with the incoming object, object_absorb
+ * into it and return that stack's handle; otherwise store the object under a
+ * fresh gear handle and return it. The merge test uses OSTACK_QUIVER when the
+ * candidate stack is currently in the quiver (obj-gear.c L832-834) and
+ * OSTACK_PACK otherwise, so a quiver stack honours the stricter quiver caps.
+ *
+ * The subsequent calc_inventory (upstream's update_stuff after PU_INVEN) is a
+ * SEPARATE step here - callers run calcInventory when they want the quiver
+ * re-derived. inven_carry does not itself enforce pack_size upstream either:
+ * the command layer does (packOverflow, game/obj-cmd.ts).
+ */
+export interface InvenCarryResult {
+    handle: number;
+    /** true when the incoming object was absorbed into an existing stack. */
+    combining: boolean;
+}
+/** inven_carry plus the C `combining` bit needed by pickup awareness. */
+export declare function invenCarryResult(gear: Gear, obj: GameObject, limits: StackLimits): InvenCarryResult;
+export declare function invenCarry(gear: Gear, obj: GameObject, limits: StackLimits): number;
+/**
+ * pack_slots_used (obj-gear.c L257-296): the number of pack slots occupied.
+ * Equipped items don't count (they are absent from `pack`); ammo / throwing
+ * items assigned to the quiver aggregate by weighted count into quiver slots
+ * of quiver_slot_size, so a non-empty quiver frees up whole pack slots. When
+ * the quiver is empty this equals pack.length (every item is a pack slot).
+ */
+export declare function packSlotsUsed(gear: Gear, constants: Constants): number;
+/**
+ * pack_is_full (obj-gear.c L1328-1331): the pack holds exactly the maximum
+ * number of items.
+ */
+export declare function packIsFull(gear: Gear, constants: Constants): boolean;
+/**
+ * pack_is_overfull (obj-gear.c L1337-1340): the pack holds MORE than the
+ * maximum, so pack_overflow (game/obj-cmd.ts) will shed an item.
+ */
+export declare function packIsOverfull(gear: Gear, constants: Constants): boolean;
+/**
+ * quiver_absorb_num (obj-gear.c L649-744): how many of `obj` the quiver can
+ * take, and how many additional pack slots that costs. Reads the current
+ * computed quiver (gear.quiver) exactly as upstream reads p->upkeep->quiver.
+ * `nAddPack` is the number of extra pack slots the quiver may claim; the return
+ * carries the leftover (nAddPack minus the slots consumed) alongside nToQuiver.
+ */
+export declare function quiverAbsorbNum(gear: Gear, obj: GameObject, constants: Constants, nAddPack: number, rogueLike?: boolean): {
+    nToQuiver: number;
+    nAddPack: number;
+};
+/**
+ * inven_carry_num (obj-gear.c L749-780): how many of `obj` the gear can accept
+ * across quiver and pack. The quiver absorbs what it can first; then a free
+ * pack slot takes the rest, or the remainder squeezes into partially-full
+ * stackable pack slots.
+ */
+export declare function invenCarryNum(gear: Gear, obj: GameObject, constants: Constants): number;
+/**
+ * Hooks calc_inventory / combine_pack need beyond the gear: the keyset (for
+ * preferred_quiver_slot), the earlier_object tiebreak inputs (ammo_tval /
+ * object_value / awareness / browsability), and the reorder messages.
+ */
+export interface CalcInventoryOpts extends EarlierObjectOpts {
+    /** rogue_like_commands: the fire key preferred_quiver_slot looks for. */
+    rogueLike?: boolean;
+    /**
+     * character_dungeon: gates the "You re-arrange your quiver." / "You
+     * re-arrange your pack." notices (player-calcs.c:1174, :1224).
+     */
+    characterDungeon?: boolean;
+    /**
+     * object_is_equipped(p->body, old_pack[i]) (player-calcs.c:1227): an old pack
+     * entry that the player has since WORN must not count as a re-arrangement.
+     * calc_inventory has no player, so the caller supplies the predicate. Omit it
+     * and no old entry is treated as equipped, which can only over-report.
+     */
+    isEquipped?: (handle: number) => boolean;
+    /** msg(): the re-arrange / combine notices. */
+    msg?: (text: string) => void;
+}
+/**
+ * calc_inventory (player-calcs.c:1023-1238): rebuild gear.quiver and the
+ * separate sorted gear.inven listing.  `gear.pack` remains the raw master-gear
+ * order, so changing this derived view cannot destabilize combine/split logic.
+ * from the current non-equipped gear. First place inscribed items in their
+ * preferred slots (splitting a stack that overflows quiver_slot_size, with the
+ * excess going back to the pack), then fill the remaining slots in earlier_object
+ * order with ammo.  Then select each remaining non-quiver handle in
+ * earlier_object order, exactly as upstream fills upkeep->inven[].
+ *
+ * Split remainders are appended to gear.pack via object_split, exactly as
+ * upstream's gear_insert_end. `n_stack_split <= n_pack_remaining` guards splits
+ * so the pack can overflow by at most one slot, matching upstream.
+ */
+export declare function calcInventory(gear: Gear, constants: Constants, opts?: CalcInventoryOpts): void;
+/**
+ * combine_pack (obj-gear.c L1242-1323): sweep the gear from the back, merging
+ * each stack fully into an earlier compatible stack where possible, else moving
+ * items between stacks into two uneven stacks (inven_can_stack_partial). Runs
+ * calc_inventory afterward. Returns whether any full combine happened (upstream
+ * shows "You combine some items in your pack." and disables command repeat).
+ */
+export declare function combinePack(gear: Gear, constants: Constants, opts?: CalcInventoryOpts): boolean;
+/**
+ * object_copy_amt (obj-pile.c L743): a fresh copy of `src` holding `amt`
+ * items, with wand/staff charges and rod/activation timeouts scaled to the
+ * split (source unchanged). The AVERAGE charge time is deterministic.
+ */
+export declare function objectCopyAmt(src: GameObject, amt: number): GameObject;
+/**
+ * gear_to_label's label alphabet (obj-gear.c:446): a-z minus the roguelike
+ * cardinal-movement keys h/j/k/l, then A-Z. An equipment slot index and a pack
+ * LISTING index both index straight into it (L452, L465).
+ */
+export declare const GEAR_LABELS = "abcdefgimnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
+/**
+ * gear_to_label (obj-gear.c:443-469): the one-character label for a held object -
+ * an equipment slot letter, a quiver slot digit (I2D), or a pack listing letter.
+ * "" when the handle is not currently held, upstream's '\0'.
+ *
+ * THE LISTING, NOT THE STORAGE ORDER. Upstream's pack arm reads
+ * `p->upkeep->inven[]` (L462-466) - the earlier_object-sorted view calc_inventory
+ * builds and every inventory display walks - NOT the master gear list. The port
+ * had three copies of this function (game/project-obj.ts, game/obj-cmd.ts,
+ * game/known.ts) and all three read `gear.pack`, the raw storage order, because
+ * they were written while `gear.inven` was still an unbuilt stand-in. calcInventory
+ * has filled `inven` for some time, so every one of them was quoting a letter the
+ * pack listing disagreed with: pick up a scroll into raw slot 8 of a pack that
+ * sorts it fourth and the message says (i) while the item is at (e) and (i) holds
+ * whatever sorted eighth. Same defect class as #92, one layer further in - the
+ * listings were fixed and the MESSAGES about them were not.
+ *
+ * Deliberately reads `inven` with no fallback to `pack`. A wrong letter is worse
+ * than a missing one: it sends the player to another item, and no census can see
+ * it because the slot is filled (paraphrase-is-a-deviation). If `inven` is stale
+ * the caller has skipped upstream's PU_INVEN/update_stuff, which is a bug to fix
+ * at that caller - gear-label-freshness.test.ts asserts the invariant holds after
+ * every gear mutation the live session performs.
+ *
+ * `equipment` is optional because most callers hold a Gear and no Player; a pack
+ * or quiver handle is never in equipment[], so omitting it cannot mislabel one.
+ */
+export declare function gearToLabel(gear: Gear, handle: number, equipment?: readonly number[]): string;
+/**
+ * The p->gear view object_pack_total walks, built from the live gear.
+ *
+ * Upstream iterates all of p->gear and lets object_similar reject the equipped
+ * entries; the port's objectSimilar has the equipped test deferred (obj/object.ts
+ * module docs), so the view is built from the non-equipped handles instead. The
+ * resulting SET is the same, which is all object_pack_total reads.
+ */
+export declare function packTotalView(gear: Gear): PackTotalGear;
+/**
+ * Whether upstream suppresses the split-stack aggregate for this object.
+ *
+ * A charges count or "recharging" notice in the description belongs to ONE
+ * stack, so aggregating the number across stacks would contradict the notice
+ * printed beside it. Upstream repeats this test verbatim at every aggregate
+ * site - gear_object_for_use (obj-gear.c L550-556, L583-589), inven_carry
+ * (L899-901) and inven_drop (L1138-1140) - the last two of which also test
+ * object_is_equipped, which the callers here add because inven_carry does not.
+ */
+export declare function packTotalSuppressed(obj: GameObject): boolean;
+/** The detached result of gear_object_for_use. */
+export interface GearForUse {
+    /** The removed object (a split copy, or the excised original stack). */
+    obj: GameObject;
+    /** True when the whole stack was taken and its slot is now empty. */
+    noneLeft: boolean;
+}
+/**
+ * gear_object_for_use (obj-gear.c L524): remove `amt` items of the gear
+ * object referenced by `handle`, returning a detached object to hand off.
+ * When part of a stack is taken, the remainder stays under `handle` and a
+ * fresh split is returned (noneLeft=false); when the whole stack is taken,
+ * the original is excised (noneLeft=true). The total_weight upkeep and the
+ * knowledge twin are DEFERRED (see the module ledger).
+ */
+export declare function gearObjectForUse(gear: Gear, player: Player, handle: number, amt: number): GearForUse;
+/**
+ * Which upstream split a wield of a multi-item stack performs. The two C
+ * callers do OPPOSITE things and the difference is observable in the pack
+ * listing, so the caller must say which one it is:
+ *
+ * - "inven_wield" (obj-gear.c L947-968): `gear_object_for_use(p, obj, 1, ...)`
+ *   splits ONE item off; the split is linked into p->gear immediately after
+ *   the original (L961-963) and IT is what gets equipped. The original keeps
+ *   `number - 1` and stays in the pack AT ITS EXISTING LISTING POSITION.
+ * - "wield_all" (player-birth.c L484-491): `object_split(obj, number - 1)`
+ *   sends the remainder to a new object collected in `new_pile` and appended
+ *   to the END of the gear (pile_insert_end, L503); the ORIGINAL is equipped.
+ */
+export type WieldSplit = "inven_wield" | "wield_all";
+/**
+ * Wield the pack object with the given handle into its liked slot. If the
+ * stack has more than one item it is split, following `split` (see
+ * WieldSplit - the two upstream callers differ). Returns the filled slot, or
+ * -1 if the object cannot be wielded or the slot is already occupied. Read
+ * `player.equipment[slot]` for the handle that ended up worn: under
+ * "inven_wield" a split stack equips a FRESH handle, not `handle`.
+ *
+ * object_learn_on_wield runs the instant the item is worn (as in wield_all
+ * and inven_wield), so a worn item's modifier runes become known and its
+ * pval bonuses go live at once. The equip_cnt UI counter is DEFERRED.
+ *
+ * `intoSlot` is the slot ARGUMENT upstream's inven_wield takes
+ * (`void inven_wield(struct object *obj, int slot)`, obj-gear.c:931): the caller
+ * decides the destination and inven_wield never recomputes it. That matters for
+ * rings - do_cmd_wield asks "Replace which ring? " and then overwrites slot with
+ * `equipped_item_slot(player->body, equip_obj)` (cmd-obj.c:309), so re-deriving
+ * it here would silently discard the hand the player picked. Omit it to keep the
+ * wield_slot default (wield_all and every non-choosing caller).
+ */
+export declare function wieldObject(gear: Gear, player: Player, handle: number, env?: import("../obj/knowledge.js").RuneEnv, split?: WieldSplit, intoSlot?: number): number;
+/**
+ * wield_all (player-birth.c L462-507): try to wield everything wieldable in
+ * the pack. Scans a snapshot of the current pack handles (so the split-off
+ * remainders added during the pass are not re-scanned, matching upstream's
+ * deferred pile_insert_end), wielding each object whose liked slot is empty.
+ */
+export declare function wieldAll(gear: Gear, player: Player): void;
+/** Options for the birth starting kit. */
+export interface OutfitOptions {
+    /**
+     * birth_start_kit: with the full kit every start_item is granted; without it
+     * only a single food and a single light source. An explicit value overrides
+     * the option lookup; when omitted, it is read from `opt("birth_start_kit")`
+     * if `opt` is supplied, else defaults to true (player-birth.c L612).
+     */
+    startKit?: boolean;
+    /**
+     * OPT(p, name): the player's birth-option accessor, used to honour
+     * birth_start_kit (gap 1.6) and the per-start-item eopts birth-option
+     * exclusion (gap 1.8, player-birth.c L619-637). Absent = no options set,
+     * i.e. full kit and no exclusions (equivalent to upstream's defaults).
+     */
+    opt?: (name: string) => boolean;
+    /**
+     * object_flavor_aware(p, obj) (player-birth.c:650): the player starts AWARE of
+     * every kind in their own starting kit - a Warrior knows their Flask of Oil by
+     * name, not as "a Clear Flask".
+     *
+     * It is a callback rather than a direct call because awareness lives in the
+     * per-game FlavorKnowledge, which the session layer does not create until
+     * wireGame - and player_outfit runs before that (it has to: the starting gold
+     * deduction feeds the birth screens). The caller collects the kinds here and
+     * marks them aware the moment the store exists; see startGame.
+     */
+    onStartKind?: (kind: ObjectKind) => void;
+}
+/**
+ * player_outfit (player-birth.c L584-666): give the player their class
+ * starting equipment and wield everything wieldable.
+ *
+ * For each class start_item: roll the count in [min, max] via the project
+ * Rng (rand_range), look the kind up by tval/sval name, honour birth_start_kit
+ * (gap 1.6) and the eopts birth-option exclusion (gap 1.8), prep it with
+ * MINIMISE at level 0 (object_prep), set number and ORIGIN_BIRTH, carry it
+ * (invenCarry), and finally wield_all.
+ *
+ * wield_all learns each worn item's modifier runes (object_learn_on_wield);
+ * for a default class kit those items carry no modifiers, so obj_k stays
+ * empty at birth exactly as upstream.
+ *
+ * Each item is marked OBJ_NOTICE_ASSESSED (L652), the per-object half of the
+ * knowledge block that the port models on the live object, and reported through
+ * opts.onStartKind for object_flavor_aware (L650) - which the caller applies
+ * once the per-game awareness store exists (see OutfitOptions.onStartKind).
+ */
+export declare function outfitPlayer(gear: Gear, player: Player, reg: ObjRegistry, rng: Rng, constants: Constants, opts?: OutfitOptions): void;
+//# sourceMappingURL=gear.d.ts.map

package/dist/game/gear.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"gear.d.ts","sourceRoot":"","sources":["../../src/game/gear.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AAEH,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,iBAAiB,CAAC;AAEjD,OAAO,KAAK,EAAE,GAAG,EAAE,MAAM,WAAW,CAAC;AACrC,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,gBAAgB,CAAC;AAElD,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAsBnD,OAAO,KAAK,EAAE,aAAa,EAAE,WAAW,EAAE,MAAM,kBAAkB,CAAC;AAEnE,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,iBAAiB,CAAC;AAIlD,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,oBAAoB,CAAC;AAC5D,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,qBAAqB,CAAC;AAClD,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,oBAAoB,CAAC;AAMrD;;;;;GAKG;AACH,MAAM,WAAW,IAAI;IACnB,8DAA8D;IAC9D,KAAK,EAAE,GAAG,CAAC,MAAM,EAAE,UAAU,CAAC,CAAC;IAC/B,+CAA+C;IAC/C,IAAI,EAAE,MAAM,CAAC;IACb;;;;;;;OAOG;IACH,IAAI,EAAE,MAAM,EAAE,CAAC;IACf;;;;OAIG;IACH,KAAK,CAAC,EAAE,MAAM,EAAE,CAAC;IACjB;;;;;;;;;OASG;IACH,MAAM,CAAC,EAAE,MAAM,EAAE,CAAC;CACnB;AAED,wEAAwE;AACxE,wBAAgB,OAAO,IAAI,IAAI,CAE9B;AAED,8EAA8E;AAC9E,wBAAgB,OAAO,CAAC,IAAI,EAAE,IAAI,EAAE,GAAG,EAAE,UAAU,GAAG,MAAM,CAK3D;AAED,qEAAqE;AACrE,wBAAgB,OAAO,CAAC,IAAI,EAAE,IAAI,EAAE,MAAM,EAAE,MAAM,GAAG,UAAU,GAAG,IAAI,CAErE;AA2BD;;;;;GAKG;AACH,wBAAgB,WAAW,CAAC,GAAG,EAAE,UAAU,EAAE,GAAG,EAAE,MAAM,GAAG,UAAU,CAQpE;AAwCD;;;;;;;;GAQG;AACH,wBAAgB,SAAS,CACvB,IAAI,EAAE,UAAU,EAChB,IAAI,EAAE,MAAM,EACZ,SAAS,CAAC,EAAE,SAAS,MAAM,EAAE,GAC5B,MAAM,CA4BR;AAMD;;;;GAIG;AACH,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,IAAI,EAAE,MAAM,EAAE,MAAM,GAAG,OAAO,CAGpE;AAED;;;;;;GAMG;AACH,wBAAgB,mBAAmB,CAAC,GAAG,EAAE,UAAU,EAAE,SAAS,UAAQ,GAAG,MAAM,CAiB9E;AAkBD,mDAAmD;AACnD,MAAM,WAAW,UAAU;IACzB,iEAAiE;IACjE,GAAG,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;IAC7B,4EAA4E;IAC5E,QAAQ,CAAC,EAAE,CAAC,GAAG,EAAE,UAAU,KAAK,MAAM,CAAC;IACvC,4EAA4E;IAC5E,aAAa,CAAC,EAAE,MAAM,IAAI,CAAC;CAC5B;AAED;;;;;;;;;;;;;;GAcG;AACH,wBAAgB,OAAO,CACrB,MAAM,EAAE,MAAM,EACd,IAAI,EAAE,IAAI,EACV,GAAG,EAAE,GAAG,EACR,GAAG,GAAE,UAAe,GACnB,OAAO,CA8CT;AAMD;;;;;;;;;;;;GAYG;AACH,MAAM,WAAW,gBAAgB;IAC/B,MAAM,EAAE,MAAM,CAAC;IACf,yEAAyE;IACzE,SAAS,EAAE,OAAO,CAAC;CACpB;AAED,yEAAyE;AACzE,wBAAgB,gBAAgB,CAC9B,IAAI,EAAE,IAAI,EACV,GAAG,EAAE,UAAU,EACf,MAAM,EAAE,WAAW,GAClB,gBAAgB,CAelB;AAED,wBAAgB,UAAU,CACxB,IAAI,EAAE,IAAI,EACV,GAAG,EAAE,UAAU,EACf,MAAM,EAAE,WAAW,GAClB,MAAM,CAER;AAMD;;;;;;GAMG;AACH,wBAAgB,aAAa,CAAC,IAAI,EAAE,IAAI,EAAE,SAAS,EAAE,SAAS,GAAG,MAAM,CAwBtE;AAED;;;GAGG;AACH,wBAAgB,UAAU,CAAC,IAAI,EAAE,IAAI,EAAE,SAAS,EAAE,SAAS,GAAG,OAAO,CAEpE;AAED;;;GAGG;AACH,wBAAgB,cAAc,CAAC,IAAI,EAAE,IAAI,EAAE,SAAS,EAAE,SAAS,GAAG,OAAO,CAExE;AAED;;;;;;GAMG;AACH,wBAAgB,eAAe,CAC7B,IAAI,EAAE,IAAI,EACV,GAAG,EAAE,UAAU,EACf,SAAS,EAAE,SAAS,EACpB,QAAQ,EAAE,MAAM,EAChB,SAAS,UAAQ,GAChB;IAAE,SAAS,EAAE,MAAM,CAAC;IAAC,QAAQ,EAAE,MAAM,CAAA;CAAE,CAiEzC;AAED;;;;;GAKG;AACH,wBAAgB,aAAa,CAC3B,IAAI,EAAE,IAAI,EACV,GAAG,EAAE,UAAU,EACf,SAAS,EAAE,SAAS,GACnB,MAAM,CAiCR;AAMD;;;;GAIG;AACH,MAAM,WAAW,iBAAkB,SAAQ,iBAAiB;IAC1D,yEAAyE;IACzE,SAAS,CAAC,EAAE,OAAO,CAAC;IACpB;;;OAGG;IACH,gBAAgB,CAAC,EAAE,OAAO,CAAC;IAC3B;;;;;OAKG;IACH,UAAU,CAAC,EAAE,CAAC,MAAM,EAAE,MAAM,KAAK,OAAO,CAAC;IACzC,+CAA+C;IAC/C,GAAG,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;CAC9B;AAYD;;;;;;;;;;;;;GAaG;AACH,wBAAgB,aAAa,CAC3B,IAAI,EAAE,IAAI,EACV,SAAS,EAAE,SAAS,EACpB,IAAI,GAAE,iBAAsB,GAC3B,IAAI,CAkIN;AAwCD;;;;;;GAMG;AACH,wBAAgB,WAAW,CACzB,IAAI,EAAE,IAAI,EACV,SAAS,EAAE,SAAS,EACpB,IAAI,GAAE,iBAAsB,GAC3B,OAAO,CA0CT;AAED;;;;GAIG;AACH,wBAAgB,aAAa,CAAC,GAAG,EAAE,UAAU,EAAE,GAAG,EAAE,MAAM,GAAG,UAAU,CAiBtE;AAED;;;;GAIG;AACH,eAAO,MAAM,WAAW,qDAAqD,CAAC;AAE9E;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,wBAAgB,WAAW,CACzB,IAAI,EAAE,IAAI,EACV,MAAM,EAAE,MAAM,EACd,SAAS,CAAC,EAAE,SAAS,MAAM,EAAE,GAC5B,MAAM,CAgBR;AAED;;;;;;;GAOG;AACH,wBAAgB,aAAa,CAAC,IAAI,EAAE,IAAI,GAAG,aAAa,CAevD;AAED;;;;;;;;;GASG;AACH,wBAAgB,mBAAmB,CAAC,GAAG,EAAE,UAAU,GAAG,OAAO,CAE5D;AAED,kDAAkD;AAClD,MAAM,WAAW,UAAU;IACzB,wEAAwE;IACxE,GAAG,EAAE,UAAU,CAAC;IAChB,qEAAqE;IACrE,QAAQ,EAAE,OAAO,CAAC;CACnB;AA2BD;;;;;;;GAOG;AACH,wBAAgB,gBAAgB,CAC9B,IAAI,EAAE,IAAI,EACV,MAAM,EAAE,MAAM,EACd,MAAM,EAAE,MAAM,EACd,GAAG,EAAE,MAAM,GACV,UAAU,CAeZ;AAMD;;;;;;;;;;;;GAYG;AACH,MAAM,MAAM,UAAU,GAAG,aAAa,GAAG,WAAW,CAAC;AAErD;;;;;;;;;;;;;;;;;;;GAmBG;AACH,wBAAgB,WAAW,CACzB,IAAI,EAAE,IAAI,EACV,MAAM,EAAE,MAAM,EACd,MAAM,EAAE,MAAM,EACd,GAAG,CAAC,EAAE,OAAO,qBAAqB,EAAE,OAAO,EAC3C,KAAK,GAAE,UAAwB,EAC/B,QAAQ,CAAC,EAAE,MAAM,GAChB,MAAM,CA0CR;AAED;;;;;GAKG;AACH,wBAAgB,QAAQ,CAAC,IAAI,EAAE,IAAI,EAAE,MAAM,EAAE,MAAM,GAAG,IAAI,CAazD;AAMD,0CAA0C;AAC1C,MAAM,WAAW,aAAa;IAC5B;;;;;OAKG;IACH,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB;;;;;OAKG;IACH,GAAG,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,OAAO,CAAC;IAChC;;;;;;;;;;OAUG;IACH,WAAW,CAAC,EAAE,CAAC,IAAI,EAAE,UAAU,KAAK,IAAI,CAAC;CAC1C;AA0BD;;;;;;;;;;;;;;;;;;GAkBG;AACH,wBAAgB,YAAY,CAC1B,IAAI,EAAE,IAAI,EACV,MAAM,EAAE,MAAM,EACd,GAAG,EAAE,WAAW,EAChB,GAAG,EAAE,GAAG,EACR,SAAS,EAAE,SAAS,EACpB,IAAI,GAAE,aAAkB,GACvB,IAAI,CA+EN"}