Skip to content

Releases: teamsamoyed/TeamfightManager2Mod

0.5.6

Choose a tag to compare

@mdlb0122 mdlb0122 released this 20 Aug 02:00
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

Choose a tag to compare

@mdlb0122 mdlb0122 released this 12 Aug 03:03
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

Choose a tag to compare

@mdlb0122 mdlb0122 released this 05 Aug 02:12
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

Choose a tag to compare

@mdlb0122 mdlb0122 released this 29 Jul 12:20
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

Choose a tag to compare

@mdlb0122 mdlb0122 released this 22 Jul 00:30
Document Ban/Pick illustration packs

0.5.1

Choose a tag to compare

@mdlb0122 mdlb0122 released this 15 Jul 07:11
Document existing champion rework support

0.5.0_hotfix2

Choose a tag to compare

@mdlb0122 mdlb0122 released this 09 Jul 12:09
Document existing champion rework support

0.5.0_hotfix

Choose a tag to compare

@mdlb0122 mdlb0122 released this 08 Jul 13:00
Document existing champion rework support

0.5.0

Choose a tag to compare

@mdlb0122 mdlb0122 released this 08 Jul 04:38
Document existing champion rework support

0.4.14

Choose a tag to compare

@jwvg0425 jwvg0425 released this 25 Jun 01:53
Document existing champion rework support