Releases: teamsamoyed/TeamfightManager2Mod
Releases · teamsamoyed/TeamfightManager2Mod
Release list
0.5.6
Document the 0.5.4 API additions Describe what the stable API gained in 0.5.4, in game-version terms rather than internal contract levels. A modder already knows which game version their players are on; the contract level was a second version axis that only ever restated the same fact, and the reference now marks each addition with the version that introduced it. Damage and shields: deal_damage now runs the game's full attack pipeline, so it applies resistances and crit, records damage statistics, awards kill and assist credit, procs items and buffs, and shows the damage number. This is the one change that reaches already-built modules, so the page says so explicitly and points at deal_damage_raw for anyone who wanted the old unmitigated subtraction. Shields get their own grant/clear calls, because a shield is an absorb layer rather than a buff and putting shield numbers in a BuffV1 quietly did nothing. Items: document the callback set in full rather than the previous one-line summary, including on_base_attack, on_assist, on_dead, on_cc, the upgrade carry-over pair, the attack type and crit flag now carried by on_attack and on_damaged, and the ally skill hits that on_skill_hit previously never reported. Also clarify a long-standing confusion: the entity argument is the owner's own champion, and the killed entity is now a separate argument. Item builds: add StableItemBuildHook, which is how a mod gets its own items actually built by the AI. The old category selection could only ever pick base-game items. Champions: add lane_prior, so a new champion is not read as equally playable in all five lanes until it accumulates match history. Compatibility: state plainly that building against the newest SDK is always safe in both directions, and document requires = N as the rare opt-in for a mod that would be inert on an older game and wants an update prompt instead. Also refresh the classic reference, whose passive and item signatures moved with the same change, and note that the new surfaces have no classic equivalent.
0.5.5
Document the 0.5.4 API additions Describe what the stable API gained in 0.5.4, in game-version terms rather than internal contract levels. A modder already knows which game version their players are on; the contract level was a second version axis that only ever restated the same fact, and the reference now marks each addition with the version that introduced it. Damage and shields: deal_damage now runs the game's full attack pipeline, so it applies resistances and crit, records damage statistics, awards kill and assist credit, procs items and buffs, and shows the damage number. This is the one change that reaches already-built modules, so the page says so explicitly and points at deal_damage_raw for anyone who wanted the old unmitigated subtraction. Shields get their own grant/clear calls, because a shield is an absorb layer rather than a buff and putting shield numbers in a BuffV1 quietly did nothing. Items: document the callback set in full rather than the previous one-line summary, including on_base_attack, on_assist, on_dead, on_cc, the upgrade carry-over pair, the attack type and crit flag now carried by on_attack and on_damaged, and the ally skill hits that on_skill_hit previously never reported. Also clarify a long-standing confusion: the entity argument is the owner's own champion, and the killed entity is now a separate argument. Item builds: add StableItemBuildHook, which is how a mod gets its own items actually built by the AI. The old category selection could only ever pick base-game items. Champions: add lane_prior, so a new champion is not read as equally playable in all five lanes until it accumulates match history. Compatibility: state plainly that building against the newest SDK is always safe in both directions, and document requires = N as the rare opt-in for a mod that would be inert on an older game and wants an update prompt instead. Also refresh the classic reference, whose passive and item signatures moved with the same change, and note that the new surfaces have no classic equivalent.
0.5.4
Document multi-platform support for stable native mods Stable mods can run on Windows, macOS and Linux, because the SDK is plain Rust source rather than the classic path's pre-compiled Windows rlibs. Explain how platform support is decided: it is derived from the module binaries in the package (.dll / .so / .dylib), with nothing to declare in mod.mod_info, so a package can never advertise a platform whose binary is missing. Data-only mods have no platform at all. Make clear that the modder builds each platform themselves. Compilation is portable but linking is not: a .dylib needs a Mac because Apple's SDK cannot be redistributed, and a .so needs Linux or a cross-linker the modder installs. Supporting Windows only is a normal outcome. Also cover shipping several binaries in one Workshop item, the diagnostic players see on an unsupported platform, per-platform SDK locations, the lib-prefix rename when installing a .so/.dylib, and the Runs on: line the uploader adds. Correct the upload skip list, which omitted target/ and the Cargo manifests.
0.5.3
Document multi-platform support for stable native mods Stable mods can run on Windows, macOS and Linux, because the SDK is plain Rust source rather than the classic path's pre-compiled Windows rlibs. Explain how platform support is decided: it is derived from the module binaries in the package (.dll / .so / .dylib), with nothing to declare in mod.mod_info, so a package can never advertise a platform whose binary is missing. Data-only mods have no platform at all. Make clear that the modder builds each platform themselves. Compilation is portable but linking is not: a .dylib needs a Mac because Apple's SDK cannot be redistributed, and a .so needs Linux or a cross-linker the modder installs. Supporting Windows only is a normal outcome. Also cover shipping several binaries in one Workshop item, the diagnostic players see on an unsupported platform, per-platform SDK locations, the lib-prefix rename when installing a .so/.dylib, and the Runs on: line the uploader adds. Correct the upload skip list, which omitted target/ and the Cargo manifests.
0.5.2
0.5.1
0.5.0_hotfix2
Document existing champion rework support
0.5.0_hotfix
Document existing champion rework support