@idosgames/core 0.5.0 → 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +76 -0
- package/dist/index.cjs +2 -2
- package/dist/index.d.cts +704 -16
- package/dist/index.d.ts +704 -16
- package/dist/index.js +2 -2
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -14,6 +14,82 @@ and this project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.ht
|
|
|
14
14
|
|
|
15
15
|
## [Unreleased]
|
|
16
16
|
|
|
17
|
+
## [0.6.0] - 2026-08-09
|
|
18
|
+
|
|
19
|
+
### Added
|
|
20
|
+
|
|
21
|
+
- **`client.tutorial` (`TutorialService`)** — onboarding flows: `getTutorialDefinitions`,
|
|
22
|
+
`getUserTutorialState`, `startFlow`, `reportStepShown`, `completeStep`,
|
|
23
|
+
`completeStepsBatch`, `skipStep`, `skipFlow`, `claimFlowReward`, `resetFlow`. Definitions
|
|
24
|
+
are cached like the rest of the title config.
|
|
25
|
+
- **Tutorial progress rides on every response.** A tutorial step is usually closed by an
|
|
26
|
+
ordinary game action (a purchase, a dice roll), not by a tutorial call — so the backend puts
|
|
27
|
+
an optional `TutorialProgress` block into the envelope of **any** response, the transport
|
|
28
|
+
lifts it out, and `UserData` merges it into the state. Subscribe to `tutorial:systemProgress`
|
|
29
|
+
instead of polling `getUserTutorialState`: the state is already fresh after any request, and
|
|
30
|
+
polling also skews the `ReportStepShown` funnel.
|
|
31
|
+
- `SegmentGate.Tutorial` (`TutorialGateCondition` / `TutorialGateMode`) — gate any module's
|
|
32
|
+
definitions on the player's onboarding progress.
|
|
33
|
+
- **`client.localization` (`LocalizationService`)** — `t(key, params)`, `has`, `locale`,
|
|
34
|
+
`fallbackLocale`, `locales`, `setLocale`, `getManifest`. Resolution is
|
|
35
|
+
**own table → fallback table → the key itself**, so a title whose config holds literal
|
|
36
|
+
display names ("Iron Sword") keeps working without migration: the literal is a key with no
|
|
37
|
+
translation. Plural forms come from `Intl.PluralRules` (suffixes `.one/.few/.many/.other`).
|
|
38
|
+
- Translation tables arrive **with the player state** — no separate load. `UserService` sends
|
|
39
|
+
the locale and the versions of the tables it already has and resolves what comes back
|
|
40
|
+
through the same source chain as the title config (storage → CDN → endpoint → stale copy),
|
|
41
|
+
with one deliberate difference: a failure here does **not** fail the login. No config means
|
|
42
|
+
nothing to play; no translations means the UI shows keys.
|
|
43
|
+
- `settings.locale` (`SettingsInput.locale`) — the starting locale, defaulting to the device
|
|
44
|
+
language. It is a **wish**, not a fact: the server folds it to what the title is actually
|
|
45
|
+
translated into (`pt-BR` → `pt` → `en`), and the answer is `client.localization.locale`.
|
|
46
|
+
- `TitlePublicConfigurationModel.Localization` — locale settings only. The tables are
|
|
47
|
+
delivered separately, one file per locale.
|
|
48
|
+
- `localization:changed` event (login, `setLocale`, new tables). `t()` is synchronous, so
|
|
49
|
+
already-rendered labels need this signal to repaint.
|
|
50
|
+
- `PostOptions.throttleKey` — override the throttle / in-flight-dedup key when one route
|
|
51
|
+
serves genuinely different requests back to back. Added for the localization tables: own and
|
|
52
|
+
fallback both go through `Localization/GetLocalizationTable`, and under the default key
|
|
53
|
+
(the endpoint) the second call would be dropped as a duplicate — the fallback table would
|
|
54
|
+
never arrive, silently, and only for players whose language is partially translated. The
|
|
55
|
+
throttle window still applies, just per key.
|
|
56
|
+
- **Batch claims** — `season.claimTierRewardsBatch(seasonChainID, tierNumbers)` and
|
|
57
|
+
`referral.claimInviteRewardsBatch(inviteRewardIDs)`. Season tiers in particular are reached
|
|
58
|
+
in batches: one token grant can raise a player through several at once. The merged
|
|
59
|
+
`Resources` is applied **once** from the top level; per-item `Data.Resources` is null by
|
|
60
|
+
contract so summing both cannot double count.
|
|
61
|
+
- **Multi-open ceilings** — `collection.openPack(collectionID, packTypeID, count?)`,
|
|
62
|
+
`collection.openCollectionChest(collectionID, chestID, count?)` and
|
|
63
|
+
`coopEvent.spin(chainID, groupID, count?)` open/spin `count` times in one atomic operation
|
|
64
|
+
(`count` defaults to 1, so existing calls are unaffected). Each roll sees the state left by
|
|
65
|
+
the previous one, so a repeat drop is correctly counted as a duplicate. The count is clamped
|
|
66
|
+
server-side; responses report what actually happened (`OpenedCount` + per-item `Packs` /
|
|
67
|
+
`Chests`, `RequestedSpins` / `SpinsUsed` / `Sectors`). Only spins that happen are charged —
|
|
68
|
+
a run stops at the spin that completes the object.
|
|
69
|
+
- Config for those ceilings: `LootboxDefinitions.Settings` (`LootboxGlobalSettings`) and
|
|
70
|
+
`LootboxDefinition.MaxOpenCount`, `CollectionDefinitions.Settings`
|
|
71
|
+
(`CollectionGlobalSettings`), `CollectionPackTypeDefinition.MaxOpenCount`,
|
|
72
|
+
`CollectionChestDefinition.MaxOpenCount`, `CoopBuildObjectsDefinition.MaxSpinsPerCall`.
|
|
73
|
+
- `FriendActionResponse.Target` (the other side's public profile) and `.Counters`
|
|
74
|
+
(`SocialCounters`) — a new friend can be shown without a second `getFriendsList()`.
|
|
75
|
+
- New events: `tutorial:definitionsLoaded` / `:userStateLoaded` / `:flowStarted` /
|
|
76
|
+
`:flowSkipped` / `:flowReset` / `:stepChanged` / `:stepsCompletedBatch` / `:rewardClaimed` /
|
|
77
|
+
`:systemProgress`, `localization:changed`, `season:tierRewardsBatchClaimed`,
|
|
78
|
+
`referral:inviteRewardsBatchClaimed`, `user:tutorialUpdated`.
|
|
79
|
+
|
|
80
|
+
### Notes
|
|
81
|
+
|
|
82
|
+
- Everything here is additive: the new `count` parameters default to `1`, the new response
|
|
83
|
+
fields are optional, and no existing signature changed.
|
|
84
|
+
- `TutorialStepPolicy.TimeoutSeconds` is carried in the schema but **not applied** — neither
|
|
85
|
+
the backend (it has no "N seconds passed" moment) nor `core` (it renders no UI) can enforce
|
|
86
|
+
it. Whoever draws the tutorial implements it, and only for `ClientAck` steps; on a step
|
|
87
|
+
waiting for a game event the backend rejects `completeStep`.
|
|
88
|
+
|
|
89
|
+
## [0.5.1] - 2026-08-05
|
|
90
|
+
|
|
91
|
+
Version-only republish of 0.5.0 — no source changes.
|
|
92
|
+
|
|
17
93
|
## [0.5.0] - 2026-08-04
|
|
18
94
|
|
|
19
95
|
### Added
|