4 Commits

Author	SHA1	Message	Date
prosolis	d538f91cf7	Combat engine: pay off the N-body debt, and hire Pete ... N3 widened the combat *roster* from 1 to N but never widened the action model, the scaling model, or the test net to match. Building the hireable companion walked into all three. Only one of the four defects found was the companion's; the rest have been live in prod for every human party since N3. The party golden did not exist (§5) Solo combat is pinned exhaustively (7468 lines); the entire N-body layer had nothing. That is why a healer class that cannot heal shipped without a test going red. Adds party_characterization.golden (9 scenarios x 5 seeds, incl. weak and dying seats) and TestPartyCharacterization_OneSeatIsStillSolo, so the N-body path can never quietly stop being a superset of the balance corpus. Regenerate only on purpose: -update-party. No action could target another seat (§1) Every heal in the engine was self-scoped. A party cleric could not put one hit point on a friend. Adds turnActionEffect.AllyHeal/AllySeat, `!cast <spell> @user` and `--target @user` -- the latter has been advertised in !help and silently swallowed by parseCombatCast since SP2 ("reserved for SP3"). The auto picker uses it too (simPickAllyHeal), so away-players and engine-driven healers behave like competent ones. It will not raise the dead. Corpses kept buffing the boss (§2b) enemyActionsThisRound counted len(st.actors), dead included -- so a party that lost a member kept paying for them, and the survivor faced a boss still swinging at two-player cadence, alone. A death spiral with the arrow pointing the wrong way. Now counts livingActors(). Party golden moved deliberately for this. An engine-driven seat was a bool any command could clear (§3) autoDriveCombat drives a party by dispatching each seat's turn AS that seat, so a companion's own auto-played move arrived at beginCombatTurn looking like a player returning to the keyboard and cleared the latch that was moving him. He then stood in the fight doing nothing while the boss he had inflated killed everyone. ActorStatuses.EngineDriven is now a persisted seat property that no command clears, and the driver calls driveEngineSeat instead of impersonating. "The party" could be empty (§4) A solo expedition has no expedition_party rows, so asking the roster who was in the party answered "nobody" -- and every caller fell back to something plausible. That is how the companion got hired at level 1 for exactly the player the feature exists for. expeditionParty()/partyHumans() always include the owner. The companion himself (!expedition hire [class] / !expedition dismiss) Day 1, leader only, costs coins, role-fills the gap, globally exclusive. He is an NPC seat and must never become a player: no player_meta, no dnd_character, no inventory, no DM room -- mint him a player_meta row and ensureDnDCharacterForCombat will auto-build the news bot a real character, and he starts appearing in the graveyard and filing death notices about himself. Mail and seats are different sets: he fights, he does not get written to. Measured on millenia, n=750/arm. Before these fixes he was -28pp -- worse than no companion at all. After: solo 48.5% -> 63.9% clear (+15.3pp), with +28.0pp for trailing players and +2.0pp for leaders. Help, never a carry. The solo golden is byte-identical throughout: solo combat provably did not move, and the balance corpus is intact. Known gap: the companion cannot cast (castActionForSeat loads a sheet from the DB and he has none by design), so a hired Cleric is still just a bad fighter. Claude-Session: https://claude.ai/code/session_01J5SQZWoLmL3M3mw2XmHHdy	2026-07-11 12:39:01 -07:00
prosolis	d76c63be0c	Review follow-ups A + B: armed abilities survive the fight, supply pool serialized ... A. An armed ability lasted one round of a turn-based fight. buildZoneCombatants called applyArmedAbility, which applies an ability's mods *and* clears ArmedAbility and saves the sheet. The turn engine calls that builder again on every !attack / !cast / !consume, so round 1 fired the ability and disarmed the character, and every later round rebuilt them with none of its mods. A Berserker paid stamina for a single round of BerserkerRage / RageMeleeDmg / PhysicalResistRage / FrenzyDmgBonus. Every entry in dndActiveAbilities had the same shape. mods.BerserkerRage was not merely unread at close-out — by then it no longer existed. Split arming into its two halves: consumeArmedAbility(c) mutates: disarms, saves, returns the id. Once, at fight start. applyAbilityByID(c, id, mods) pure: no DB write, no disarm. Safe on every rebuild. (No ability's Apply writes to the character, so this really is pure.) armAbilityForFight(c, mods) consume + apply, for the auto-resolve callers that build and fight in one breath. buildZoneCombatants now takes the already-consumed id and re-applies it. The id rides on ActorStatuses.ArmedAbility, seeded per seat at fight start, so partyCombatantsForSession reproduces the ability every rebuild and the close-out can still see that a rage fired. The close-out itself: postCombatBookkeeping now carries grantCombatAchievements + persistDnDPostCombatSubclass, and all four close-outs route through it — runDungeonCombat, runZoneCombatRoster, finishCombatSession, finishPartyCombatSession. It fires on every terminal status, not just a win: a Berserker who rages and loses is still exhausted, which is what auto-resolve always did. Also: buildFightSeats and runZoneCombatRoster consumed the ability before the checks that could sit a seat out, so a downed member was disarmed for a fight they never joined. The refusals now run first. B. Six unlocked read-modify-writes against the shared supply pool. updateSupplies rewrites supplies_json wholesale, so a caller folding its delta onto an *Expedition it read earlier discards whatever landed in between. Handlers run one goroutine per event, so those writers genuinely interleave. All six now go through withExpeditionSupplies, which takes advExpeditionLock, re-reads the row, hands the closure the fresh copy and persists what it returns: nightRolloverBurn (forage + burn in one write), grantTwoWeeksCache, advanceToNextRegion's transit burn, campPitch, pitchAutopilotCamp, and the ambient pack-rat drain. expeditionCmdAccept's hand-rolled lock folds onto the same helper. expedition_sim.go is left alone: single-threaded, takes no locks. Known consequence, for the balance track: trySimAutoArm used to live inside the rebuild, so a simulated Fighter (second_wind) or Cleric (healing_word) re-armed and re-spent a resource every round of every elite/boss fight. expedition-sim drives those through the turn engine, so every prior expedition-sim corpus overstates those two classes. Re-baseline after this, not before. Claude-Session: https://claude.ai/code/session_017mEwUmmS7aQTP2NQXj6rUa	2026-07-10 08:01:51 -07:00
prosolis	1f211564d9	Review fixes: party close-out, member soft-lock, supply race, elite loot, season crown ... Five bugs found reviewing n1-restoration end to end. beginCombatTurn settles any phase the engine owes before reading whose turn it is. That settle can end the fight — and the old code then answered "you're not in a fight" and returned. The terminal status was already persisted, so nothing ever paid the party out: no XP, no loot, no death recorded, no run teardown. The reaper cannot recover it either, because listExpiredCombatSessions filters on status='active'. Close the fight out there, the way the !fight start path and the reaper already do. A party member was permanently soft-locked when their leader extracted and never resumed. seatedExpeditionFor (the guard) spans 'extracting'; expeditionForMember (what !expedition leave resolved through) saw only 'active'. So the member was refused any new adventure by the guard and told "No active expedition" by the command the guard points them at, with nothing sweeping stale rows and only the leader able to clear one. Resolve the exit through the same lookup as the gate. updateSupplies overwrites supplies_json wholesale, and expeditionCmdAccept folded a member's packs onto a snapshot read before the coin debit, unlocked. Handlers run one goroutine per event, so two invitees accepting genuinely interleave and one member's packs vanish. advUserLock cannot help — it is keyed by sender, so racing members take different mutexes. Add advExpeditionLock and re-read the pool under it. Closes accept-vs-accept; the six other updateSupplies callers still race and are written up separately. runHarvestInterrupt picked an elite enemy and elite narration off a local `elite` flag, then passed a hardcoded false as isElite to closeOutZoneWin. dropZoneLoot gates masterwork on isBoss||isElite, so beating an elite interrupt skipped the masterwork roll and took standard treasure weight — while the same elite fought via !zone paid out correctly. arenaSeasonRollover marked its job complete even when recordArenaSeasonTitle failed, and JobCompleted short-circuits every later run for that quarter, so a transient SQLite BUSY lost the crown forever. Defer completion on failure; the insert is ON CONFLICT DO NOTHING against PRIMARY KEY (season, kind) and a past season's data is frozen, so the retry is safe. Also: drop dead partySurvivors, collapse the zoneCombatRoster alias into fightRoster, route partyCasualtyLine through joinNames, fold four copies of the expedition column projection into expeditionSelectCols, stop replyDM sending a blank DM, and correct two doc comments describing a path that no longer exists. Deliberately not fixed, with reasons, in gogobee_code_review_followups.md — most notably that both turn-based close-outs skip grantCombatAchievements and persistDnDPostCombatSubclass, which the auto-resolve paths run.	2026-07-10 07:20:14 -07:00
prosolis	1928f75c19	N3/P6b: a party you can actually ask someone to join ... !expedition invite / accept / decline / party / leave. The invitee buys their own loadout and it pools -- a party is a shared burden, not a free ride. The plan said invites close "before the first walk". That is not a window, it is a race: autoRunMinExpeditionAge leaves a fresh expedition alone for thirty minutes and then the autopilot starts walking it, and the leader's own !expedition run can beat it there. Thirty minutes is not enough to ask a friend who is asleep. So two changes to what the plan specified: - The window is all of Day 1, not the first step. Supplies burn at the night rollover, so a companion who arrives three rooms in pays and receives exactly what one who arrived at the gate does. - An unanswered invite pins the autopilot: loadExpeditionsForAutoRun skips any expedition somebody has been asked to join. The leader must not be dragged into a boss room while their friend reads the DM. Bounded by expeditionInviteTTL (2h) in the query itself, so a forgotten invite costs an afternoon, not the expedition. New table expedition_invite. Absent == nobody was asked, which is true of every expedition predating N3 -- nothing to backfill, same reading that let expedition_party and roster_size ship without one. Details worth keeping: - Outstanding invites count against expeditionPartyMax. Otherwise a leader asks four people and three accept. - Pooling raises Current *and* Max. supplyDepletion reads the ratio, so folding in only Current would read as the party suddenly starving. - A member's supplies stay in the pool when they !leave. They were spent on the expedition, not lent to it; clawing them back would let someone starve the party on their way out. - assertNotAdventuring guards expeditions and rosters but not bare zone runs, so accept checks getActiveZoneRun itself -- startExpedition does. - A party is not a taxi: zoneOpenToLevel gates the invitee on the same tier rule !expedition start applies to the leader. - releaseParty now clears invites too, or someone could accept onto a corpse. - expeditionCmdStatus and the bare `!expedition` switched to activeExpeditionFor, and a member typing `!expedition go 2` is told the leader picks the path instead of falling through to `start` and being told "2" is an unknown zone. Combat still seats one player -- handleFightCmd is P6c. go test ./... green, golden byte-identical.	2026-07-09 22:30:11 -07:00