Disruptor Immunity to Deadspace Suppression
Issue
The Purity disruptor was not activating its OnReveal ability when played into a Deadspace lane. Instead of removing debuffs from all cards (e.g., restoring Orinbrennic after being reduced to -4 by Porthos), the ability was being suppressed.
Logs confirmed the ability was blocked due to Deadspace.
Root Cause
The CardEffect base logic applied Deadspace suppression to all cards indiscriminately. There was no differentiation between standard cards and disruptors.
Per design rules:
- Disruptors cannot be nullified
- Deadspace suppresses abilities in its lane
- Disruptors must ignore suppression effects (including Deadspace and similar mechanics)
The system incorrectly treated disruptors as standard cards, preventing their abilities from resolving.
Resolution
Updated suppression checks so disruptors are excluded from Deadspace restrictions.
Updated Behavior
- Standard cards in Deadspace: abilities are suppressed
- Disruptors in Deadspace: abilities resolve normally
- Fully aligned with established immunity rules
Impact
- Purity correctly removes debuffs even when played into Deadspace
- All disruptors function properly in suppressed lanes
- Standard cards remain correctly restricted
- Behavior is consistent across all ability-nullifying effects
Verification
When a disruptor is played into Deadspace, the ability executes normally and applies board-wide effects as intended.
Deck Snapshot & Rival System Fixes
Issues Addressed
1. Deck Snapshots Not Saving
After a win, no snapshot was created. The system failed to locate a valid deck and aborted snapshot generation. This prevented proper shadow deck challenges and rival tracking.
2. Opponent Rival Profiles Showing Incorrect Player
When a player defeated an opponent, viewing that opponent’s profile showed an unrelated rival instead of the correct player.
3. Player Snapshot Rival Logic Incomplete
- Losing to a player snapshot did not add that snapshot owner as a rival
- Defeating a player snapshot did not remove that rival
Root Causes
Active Deck vs Match Deck Mismatch
The snapshot system referenced the “active deck” (deck builder selection), not the deck actually used in the match. These are separate states, and cloud sync could clear the active deck, causing snapshot creation to fail.
Invalid Snapshot ID Generation
When adding a player as a rival to an opponent, the system generated a random ID instead of using the real snapshot ID. This created rival entries pointing to non-existent snapshots.
Unimplemented Snapshot Rival Handling
Handlers for adding and removing player snapshot rivals were incomplete, leaving placeholder logic in place.
Resolutions
Match Deck Tracking
Introduced explicit tracking of the deck selected at match start.
Snapshot generation now:
- Uses the deck selected for the match
- Falls back to active deck if necessary
- Falls back to first valid deck if neither is available
This ensures snapshots always reflect the actual deck played.
Correct Snapshot ID Usage
Rival entries now reference the real snapshot ID generated at match end. Opponent profiles correctly resolve and display the appropriate player snapshot.
Full Player Snapshot Rival Support
Implemented complete handling for player snapshot rivals:
- Losing to a snapshot adds that snapshot owner as a rival
- Defeating a snapshot removes the rival
- Snapshot ID validation ensures safe removal
Cloud Sync Safeguards
Enhanced deck merge and reload logic to preserve active deck state and prevent “no active deck” conditions after sync operations.
Resulting System Behavior
Snapshot Flow
Deck selected → Match played → Win → Snapshot created from actual match deck → Snapshot stored with valid ID
Opponent Rival Flow
Player defeats opponent → Snapshot created → Snapshot ID assigned to rival entry → Opponent profile correctly displays the player
Player Snapshot Rival Flow
Player loses to snapshot → Snapshot owner added as rival
Player defeats snapshot → Rival removed
Benefits
- Snapshots reliably reflect the deck used in match
- Opponent profiles display correct rival data
- Player snapshot rivals function end-to-end
- Cloud sync no longer breaks deck state
- Multi-layer fallback prevents edge-case failures
- Improved logging supports diagnostics
Leaderboard & Profile Display System Overhaul
Problem
Leaderboard entries displayed names and cosmetics correctly, but profile popups showed default placeholders.
The system relied on CloudCode profile lookups that failed due to incomplete GUID-to-authID mapping. Additionally, leaderboard profile buttons were not reliably passing correct player identifiers.
There were also scalability concerns with linear searches across large leaderboard lists.
Solution
Transitioned to a metadata-first architecture.
Instead of resolving profile data through remote calls, the system now builds profile views directly from leaderboard metadata already returned by the service.
Improvements
Direct Metadata Rendering
Profile data is constructed directly from leaderboard metadata JSON. This eliminates dependency on external resolution for players already present in the leaderboard.
Metadata Caching
Introduced a dictionary-based cache for constant-time lookups. Metadata is stored when leaderboard entries load and retrieved instantly for profile popups.
Smart Fallback
If metadata is not present in cache, the system falls back to CloudCode resolution. For all visible leaderboard players, remote calls are no longer required.
Performance Impact
- Previous approach: Linear search per popup
- Current approach: Constant-time dictionary lookup
- Scales efficiently to thousands of players
- No increase in initial load cost
Results
- Leaderboard entries display correct names and cosmetics
- Profile popups load instantly for leaderboard players
- Opponents and live players resolve consistently
- Reduced CloudCode dependency
- System now scalable and robust1
