btc_rewards_artifact
Stores pending rewards and claim history for all players — artifact entry.
Entry Information
| Property | Value |
|---|---|
| Entry ID | btc_rewards_artifact |
| Type | Artifact |
| Color | Blue |
| Icon | mdi:gift-outline |
Fields
| Field | Type | Description |
|---|---|---|
artifactId | String | Unique artifact identifier for file storage |
Usage Example
- entry: btc_rewards_artifact
name: "Stores pending rewards and claim history for all players"
artifactId: ""
artifactId is a generated identity, not a file name. Changing it on an existing artifact
orphans the stored data — migrate and back up the asset first.
Persistence and cross-server behaviour
Writes are debounced: the queue is saved a few seconds after the last change, and always force-saved on unload, so a reload never drops a pending reward.
On a network, the storage is already shared, but each server keeps the queue in memory for
fast reads. Every save therefore publishes an invalidation on the Redis channel
rewards_invalidate, and the other servers reload that artifact on their next access — a
reward claimed on one server cannot be claimed again on another.
This requires the MySql Extension (which provides Redis). Without it the queue still works normally on a single server; no cross-server notification is sent.