GameSlayve Keystone Party — v1.13.18

A Major Foundation & Reliability Update

Version 1.13.18 represents one of the largest development milestones for Keystone Party so far.

A substantial amount of this release has been devoted to something that isn't always visible in screenshots: making the systems underneath Keystone Party trustworthy enough to build the rest of the addon on top of them.

Combat tracking has been extensively rebuilt and hardened. Activity history and character snapshots have continued to mature. Multiplayer data sharing has been expanded. The journal has received numerous presentation improvements. And the growing GameSlayve addon family is beginning to take shape inside Keystone Party.

This release brings Keystone Party considerably closer to the original goal:

Your personal World of Warcraft adventure journal.

⚔️ Combat Lab — Major Reliability Overhaul

Combat Lab received one of its largest development passes to date.

The combat engine now treats individual combat encounters as finalized, immutable pull records rather than relying primarily on mutable running totals.

Each finalized pull can preserve:

• Damage
• DPS
• Healing
• HPS
• Damage Taken
• DTPS
• Interrupts
• Dispels
• Deaths
• Combat duration
• Capture source
• Recovery state
• Confidence information
• Blizzard comparison/reference information

Final activity totals can then be reconstructed directly from the finalized pull ledger.

This provides a much stronger foundation for Mythic+, dungeons, raids, Delves, PvP, and future activity analysis.

Pull Ledger Reconciliation

At the end of an activity, Combat Lab now audits and rebuilds its final totals from the finalized pull ledger.

This helps prevent:

• adjacent pulls contaminating one another
• stale combat information affecting final totals
• incomplete mutable counters becoming permanent history
• duplicate pull finalization
• late callbacks modifying an already finalized activity

The final ledger and final activity totals can now be compared directly for integrity.

🧠 Smarter Blizzard Combat Meter Handling

Blizzard's combat meter information is useful, but its CURRENT data does not always reset at exactly the moment Keystone Party needs it to.

Combat Lab can now recognize suspicious CURRENT-session information instead of blindly accepting it.

When appropriate, Combat Lab can recover pull-local information using Blizzard Overall boundary differences.

This recovery system now covers:

• Damage
• Healing
• Damage Taken
• Interrupts
• Dispels

This was successfully exercised during live Mythic+ testing, including a case where Blizzard CURRENT contained a dramatically longer duration than the actual Combat Lab pull.

Instead of allowing that stale session to corrupt the journal, Combat Lab detected it and recovered the pull from safer boundary evidence.

⏱️ Improved Combat Timing

Combat duration is now tied much more closely to the actual combat boundary.

Combat begins with the real combat-start boundary and ends when combat actually ends.

The additional settling time required to safely read Blizzard's meter is no longer treated as combat duration.

This improves the accuracy of derived:

• DPS
• HPS
• DTPS
• pull duration

Provider-reported rates are still retained where useful for diagnostics, while Combat Lab can normalize historical rates against the accepted combat duration.

🔗 Chain-Pull Protection

Fast consecutive pulls received additional protection.

If a new combat begins while the previous encounter is still inside Combat Lab's short meter-settling window, the previous pull can be finalized from evidence captured while that pull was actually active.

This prevents the newly started pull from contaminating the previous pull.

Additional development diagnostics were added specifically to identify when this CHAIN_FROZEN recovery path occurs naturally during gameplay.

🛟 Recovered Combat Ownership

Combat Lab now handles cases where Keystone Party takes ownership of an activity after combat has already begun.

Rather than pretending it observed combat that occurred before it was active, the resulting pull can be explicitly identified as recovered/partial.

This preserves useful information without silently presenting incomplete information as a perfect capture.

🛡️ Activity & Finalization Safety

Numerous lifecycle protections have been added around activity tracking.

Combat Lab now has stronger safeguards against:

• duplicate activity starts
• stale activity ownership
• duplicate finalization
• finalization while combat is active
• finalization during pending meter settlement
• callbacks belonging to an older activity
• callbacks belonging to an older pull
• repeated completion signals
• stale summary requests

Activity ownership and pull generations are tracked more carefully so delayed events cannot accidentally modify the wrong run.

💀 Death Tracking Improvements

Deaths are tracked within the active activity and attributed to the appropriate pull.

Pull-local death totals are preserved in the finalized ledger alongside the other combat statistics.

✋ Interrupt & Dispel Isolation

Interrupt and dispel tracking received additional work during this development cycle.

Combat Lab now maintains pull-boundary evidence for these utility statistics and can recover them from Blizzard Overall data when CURRENT information is determined to be stale.

Importantly, zero is treated as valid evidence when the underlying boundary information is available.

This avoids confusing "no interrupts occurred" with "interrupt information was unavailable."

🩺 Combat Capture Health

Finalized Combat Lab activities now have a more meaningful capture-health concept.

Possible states include conditions such as:

• GOOD
• WARNING
• RECOVERED
• SUSPECT
• NO DATA

A run that required legitimate recovery is no longer automatically treated the same as a structurally corrupt run.

Likewise, disagreement with an external reference does not automatically invalidate a healthy Combat Lab ledger.

This distinction became particularly important during real Mythic+ testing.

📏 Independent Blizzard Reference Validation

Combat Lab maintains independent Blizzard evidence where available for comparison.

However, the addon no longer assumes that an external Blizzard reconstruction must be correct simply because it exists.

For Mythic+ activities, an independent reference that diverges excessively from the finalized Combat Lab ledger can now be rejected.

Rejected reference information is preserved for diagnostics rather than silently discarded.

The UI and audit tools now distinguish:

REJECTED

from an actual numeric value of:

0

This fixes an important diagnostic ambiguity discovered during testing.

🧪 Combat Lab Development Diagnostics

A substantial read-only diagnostic toolkit now exists for continued Combat Lab development.

Useful commands include:

/gslab debug on
/gslab debug off
/gslab debug
/gslab summary
/gslab report
/gslab pulls
/gslab audit
/gslab chaincheck
/gslab damage
/gslab inspect 1 1
/gslab healscan
/gslab bridge

These tools allow future combat problems to be investigated without rewriting the proven capture pipeline just to understand what happened.

Development diagnostics remain off by default during normal play.

🏰 Real Mythic+ Validation

Combat Lab's new architecture has now been exercised inside a real Mythic+ dungeon.

During testing, an eight-pull activity successfully produced a valid immutable ledger whose final Damage, Healing, and Damage Taken totals reconciled exactly with the finalized Combat Lab totals.

The same run also encountered stale Blizzard CURRENT data and successfully used the new recovery architecture.

That test provided real-world validation for several systems at once:

• immutable pull storage
• ledger reconciliation
• stale CURRENT detection
• Overall-boundary recovery
• interrupt recovery
• recovered-pull handling
• final summary generation
• multiplayer historical snapshot sharing

This was an important milestone for the new Combat Lab architecture.

📖 Mythic+ Journal Improvements

The Mythic+ Journal continues to mature as the central record of Keystone Party activities.

Combat information stored with runs now benefits from the new Combat Lab ledger and recovery architecture.

Several journal presentation issues have also been cleaned up.

Peak Pull information has received formatting improvements so pull number and duration information fit together more naturally instead of unnecessarily wrapping onto separate lines.

Historical records that do not contain newer pull-context metadata continue to degrade gracefully rather than inventing information that was never recorded.

📸 Character Snapshot Improvements

Keystone Party's Character Snapshot system has continued to evolve.

Snapshots can preserve information about the character at the time an activity occurred rather than simply showing what the character looks like today.

The broader snapshot architecture includes information such as:

• specialization
• item level
• health
• primary stat
• critical strike
• haste
• mastery
• versatility
• Mythic+ rating
• equipment and other supported historical information

The goal remains to make old journal entries genuine historical records of the character who completed them.

👥 Multiplayer Snapshot Sharing

The multiplayer snapshot architecture has received substantial development.

Compatible Keystone Party clients can exchange versioned character/activity snapshot information so journal records can contain richer information about party members who are also running compatible versions of Keystone Party.

The system includes safeguards for:

• snapshot ownership
• packet versioning
• capability detection
• chunked transfers
• reassembly
• acknowledgements
• activity matching
• participant attachment
• incomplete/partial historical information
• unmatched snapshot handling

Party members without compatible Keystone Party data continue to degrade gracefully rather than being populated with invented statistics.

🔍 Multiplayer Development Tools

Several diagnostic tools were created to help validate the snapshot transport system during real multiplayer testing.

These include local round-trip testing, party monitoring, cache inspection, version testing, and party connectivity diagnostics.

Examples include:

/gskpsnaptest
/gskpsnapmon
/gskpsharecache
/gskpversiontest
/gskpping

These are primarily development and troubleshooting tools rather than normal gameplay requirements.

🧍 Party Historical Records

Historical party information continues to expand.

Keystone Party can distinguish between more complete and partial historical participant snapshots when viewing previous activities.

This lays the groundwork for the larger planned participant-history system, where compatible Keystone Party users can eventually provide richer historical character and performance information alongside an activity.

🗂️ Activity History & Journal Foundation

Continued work has gone into making Keystone Party's activity history a consistent journal rather than a collection of unrelated trackers.

The architecture increasingly treats Mythic+, dungeons, raids, Delves, PvP, and future activities as different views into a common historical system.

Activity records are increasingly being built around:

• activity identity
• character snapshot
• party snapshot
• combat snapshot
• peak performance
• activity result
• timestamps
• historical metadata

This shared foundation will make future journal expansion considerably easier.

🎨 Journal & UI Cleanup

Numerous smaller interface refinements have accumulated throughout the development cycle.

Work has included improvements to:

• activity-history presentation
• Mythic+ result formatting
• character information
• Combat Snapshot presentation
• Peak Pull presentation
• navigation behavior
• sidebar behavior
• panel positioning
• page organization
• consistent terminology
• historical-data fallbacks
• compact information layouts

The navigation/sidebar system has also continued moving toward a unified Keystone Party shell rather than every feature behaving like an unrelated window.

🎒 GameSlayve Suite Integration

Keystone Party is beginning to serve as the home for the wider GameSlayve addon family.

Infrastructure now exists for optional GameSlayve modules to appear inside the main Keystone Party navigation while remaining independently developed addons underneath.

This is intentionally being built as a presentation/integration layer rather than forcing every companion addon into Keystone Party's core engine.

🚧 Mount Match, Pet Match & PetWhistle

Three GameSlayve companion projects are currently being intentionally paused while Keystone Party approaches its next major milestone:

• Mount Match
• Pet Match
• PetWhistle

These projects have not been abandoned.

Their underlying development work remains intact.

Keystone Party now has a centralized module-release-status system that allows a feature to remain integrated while clearly identifying it as:

IN DEVELOPMENT

Development modules are visually distinguished from finished features and their normal GSKP launch path is blocked for the public release.

Players clicking one of these entries receive a development notice instead of being dropped into an unfinished feature.

This allows development to resume later without ripping out the integration work already completed.

🧱 Module Release-State Foundation

The new GameSlayve module architecture establishes a foundation for release states such as:

• AVAILABLE
• DEVELOPMENT

and provides room for additional states such as Beta or Disabled as the suite evolves.

This gives Keystone Party one central place to control how companion projects are presented to players.

⌨️ New /gskp Command

A long-overdue quality-of-life addition:

/gskp

now invokes Keystone Party's primary panel command.

The existing aliases remain available:

/gskey
/gskr

The command uses the existing panel toggle behavior, allowing the main Keystone Party window to be quickly opened or closed.

🧭 Navigation Improvements

Work on the shared navigation architecture continues.

GameSlayve companion features now participate in the same navigation framework used by Keystone Party pages, including support for module status, tooltips, icons, compact navigation, and future suite expansion.

The GameSlayve section remains visually separated from Keystone Party's primary journal and analysis tools so optional companion projects remain easy to identify.

🔧 Reliability & Regression Work

A large portion of v1.13.18 has involved fixing the kinds of problems that tend to appear only after systems begin interacting with one another.

This development cycle included work around:

• combat callbacks
• delayed capture
• stale provider information
• activity ownership
• duplicate finalization
• historical data compatibility
• partial snapshots
• UI formatting
• navigation state
• optional addon integration
• panel behavior
• data availability vs legitimate zero values
• diagnostic reporting
• recovery-state classification
• independent-reference rejection
• compatibility with older saved activity records

A major design goal throughout this work has been:

Preserve proven systems instead of repeatedly replacing them.

When a pipeline has demonstrated that it works, new safeguards are increasingly being built around it rather than rewriting the working portion.

🏗️ Building the Foundation for What Comes Next

Some of the most important work in v1.13.18 is architectural.

Combat Lab can become the shared combat authority for additional activity trackers instead of every tracker developing its own competing combat engine.

Character and multiplayer snapshots provide the beginnings of richer historical party records.

The activity journal provides a common destination for those records.

And the GameSlayve navigation architecture gives companion addons a path into the wider suite without forcing them to surrender their standalone design.

Those foundations matter because several larger systems are still planned.

Keystone Party is not at the end of development.

But we're getting much closer to the point where the foundation stops moving underneath everything being built on top of it.

❤️ Thank You for Testing Keystone Party

v1.13.18 has involved a tremendous amount of live testing, debugging, rebuilding, breaking things, fixing them again, and eventually proving that the new systems can survive actual gameplay.

There are still edge cases to find.

There are still unfinished features.

There are still pages that will grow.

But this release represents an important transition for Keystone Party:

from proving that the idea can work, toward finishing the product built around it.

GameSlayve Keystone Party v1.13.18

Your character.
Your party.
Your adventures.
Your history.

The journal is getting closer.