1
0
mirror of https://github.com/vcmi/vcmi.git synced 2025-06-19 00:17:56 +02:00
Files
vcmi/docs/modders/Bonus_Format.md

108 lines
3.9 KiB
Markdown
Raw Normal View History

2024-07-16 20:29:20 +02:00
# Bonus Format
2023-09-01 12:11:35 +03:00
## Full format
2023-08-12 12:39:44 +03:00
All parameters but type are optional.
```json
2023-08-12 12:39:44 +03:00
{
2023-09-23 19:24:20 +03:00
// Type of the bonus. See Bonus Types for full list
2023-09-01 01:30:26 +03:00
"type": "BONUS_TYPE",
2023-09-23 19:24:20 +03:00
// Subtype of the bonus. Function depends on bonus type.
2023-09-01 01:30:26 +03:00
"subtype": 0,
2023-09-23 19:24:20 +03:00
// Value of the bonus. Function depends on bonus type.
2023-09-01 01:30:26 +03:00
"val" : 0,
2023-09-23 19:24:20 +03:00
// Describes how this bonus is accumulated with other bonuses of the same type
2023-09-01 01:30:26 +03:00
"valueType": "VALUE_TYPE",
2023-09-23 19:24:20 +03:00
// Additional info that bonus might need. Function depends on bonus type.
2023-09-01 01:30:26 +03:00
"addInfo" : 0, // or [1, 2, ...]
2023-08-12 12:39:44 +03:00
2023-09-23 19:24:20 +03:00
// How long this bonus should be active until removal.
// May use multiple triggers, in which case first event will remove this bonus
2023-09-01 01:30:26 +03:00
"duration" : "BONUS_DURATION", //or ["BONUS_DURATION1", "BONUS_DURATION2", ...]"
2023-09-23 19:24:20 +03:00
// How long this bonus should remain, in days or battle turns (depending on bonus duration)
2023-09-01 01:30:26 +03:00
"turns" : 0,
2023-08-12 12:39:44 +03:00
2023-09-23 19:24:20 +03:00
// TODO
"targetSourceType" : "SOURCE_TYPE",
2023-09-23 19:24:20 +03:00
// TODO
2023-09-01 01:30:26 +03:00
"sourceType" : "SOURCE_TYPE",
2023-09-23 19:24:20 +03:00
// TODO
2023-09-01 01:30:26 +03:00
"sourceID" : 0,
2023-09-23 19:24:20 +03:00
// TODO
2023-08-12 12:39:44 +03:00
"effectRange" : "EFFECT_RANGE",
2023-09-01 01:30:26 +03:00
Better support for Adela specialty (+new modding functionality for it) Fixes Adela specialty that was apparently broken back in #1518 and replaced with logic that was clearly not tested - it was neither functional, nor it was following H3 behavior. - `HAS_ANOTHER_BONUS_LIMITER` now accepts `null` in place of bonus type, for cases when limiting is needed by bonus source or bonus subtype. This allows Adela Bless specialty to always work, irregardless of which bonuses are provided by Bless. - Implemented `DIVIDE_STACK_LEVEL` updater that functions same as `TIMES_STACK_LEVEL`, but it divides bonus value, instead of multiplying it (to make Adela specialty weaker for high-tier units, as in H3) - Implemented `TIMES_HERO_LEVEL_DIVIDE_STACK_LEVEL` updater that combines two existing updaters, to implement `val * heroLevel / unitLevel` formula needed for Adela specialty - Removed deprecated `ARMY_MOVEMENT` updater. Its functionality has already been removed in 1.6.X releases, and it was remaining only as a placeholder - Updated modding documentation to account for these changes & to remove some TODO's Fixed regression from #777 that could led to either duplicated bonuses or to multiple application of updaters. It introduced double-recursion - node parents were gathered recursively, and then bonuses were also collected recursively within each parent. This created situation where updater could be applied different number of times. For example, hero bonus that is propagated to unit in combat could be selected directly, or via hero->combat unit chain, or via hero->garrison unit->combat unit chains, leading to different calls to updaters if updater handles garrison unit node type
2025-04-11 15:04:30 +03:00
// This sections allows to define 'limiter', which allows to limit bonus and only apply it under specific conditions
// Typical conditions are "affect only specific creature", or "affect only if target has another, specific bonus"
// See Bonus Limiters list below for full list of supported limiters
2023-09-01 01:30:26 +03:00
"limiters" : [
"PREDEFINED_LIMITER", optional_parameters (...), //whhich one is preferred?
{"type" : LIMITER_TYPE, "parameters" : [1,2,3]}
],
Better support for Adela specialty (+new modding functionality for it) Fixes Adela specialty that was apparently broken back in #1518 and replaced with logic that was clearly not tested - it was neither functional, nor it was following H3 behavior. - `HAS_ANOTHER_BONUS_LIMITER` now accepts `null` in place of bonus type, for cases when limiting is needed by bonus source or bonus subtype. This allows Adela Bless specialty to always work, irregardless of which bonuses are provided by Bless. - Implemented `DIVIDE_STACK_LEVEL` updater that functions same as `TIMES_STACK_LEVEL`, but it divides bonus value, instead of multiplying it (to make Adela specialty weaker for high-tier units, as in H3) - Implemented `TIMES_HERO_LEVEL_DIVIDE_STACK_LEVEL` updater that combines two existing updaters, to implement `val * heroLevel / unitLevel` formula needed for Adela specialty - Removed deprecated `ARMY_MOVEMENT` updater. Its functionality has already been removed in 1.6.X releases, and it was remaining only as a placeholder - Updated modding documentation to account for these changes & to remove some TODO's Fixed regression from #777 that could led to either duplicated bonuses or to multiple application of updaters. It introduced double-recursion - node parents were gathered recursively, and then bonuses were also collected recursively within each parent. This created situation where updater could be applied different number of times. For example, hero bonus that is propagated to unit in combat could be selected directly, or via hero->combat unit chain, or via hero->garrison unit->combat unit chains, leading to different calls to updaters if updater handles garrison unit node type
2025-04-11 15:04:30 +03:00
// Normally, only entities that are located "below" bonus source are affected by the bonus
// For example, bonus on creature will only affect creature itself,
// bonus on hero will affect hero itself and all its units, and player bonus will affect all objects owned by player
// Propagator allows bonus to affect "upwards" entities.
// For example, creature that has bonus with battle-wide propagator will affect all units in combat, and not just unit itself
// See Bonus Propagators list below for full list of supported propagators
2023-08-12 12:39:44 +03:00
"propagator" : ["PROPAGATOR_TYPE", optional_parameters (...)],
2023-09-23 19:24:20 +03:00
Better support for Adela specialty (+new modding functionality for it) Fixes Adela specialty that was apparently broken back in #1518 and replaced with logic that was clearly not tested - it was neither functional, nor it was following H3 behavior. - `HAS_ANOTHER_BONUS_LIMITER` now accepts `null` in place of bonus type, for cases when limiting is needed by bonus source or bonus subtype. This allows Adela Bless specialty to always work, irregardless of which bonuses are provided by Bless. - Implemented `DIVIDE_STACK_LEVEL` updater that functions same as `TIMES_STACK_LEVEL`, but it divides bonus value, instead of multiplying it (to make Adela specialty weaker for high-tier units, as in H3) - Implemented `TIMES_HERO_LEVEL_DIVIDE_STACK_LEVEL` updater that combines two existing updaters, to implement `val * heroLevel / unitLevel` formula needed for Adela specialty - Removed deprecated `ARMY_MOVEMENT` updater. Its functionality has already been removed in 1.6.X releases, and it was remaining only as a placeholder - Updated modding documentation to account for these changes & to remove some TODO's Fixed regression from #777 that could led to either duplicated bonuses or to multiple application of updaters. It introduced double-recursion - node parents were gathered recursively, and then bonuses were also collected recursively within each parent. This created situation where updater could be applied different number of times. For example, hero bonus that is propagated to unit in combat could be selected directly, or via hero->combat unit chain, or via hero->garrison unit->combat unit chains, leading to different calls to updaters if updater handles garrison unit node type
2025-04-11 15:04:30 +03:00
// Updaters allow to modify bonus depending on context.
// For example, it can be used to scale bonus based on hero or unit level
// See Bonus Updaters list below for full list of supported updaters
2023-09-01 01:30:26 +03:00
"updater" : {Bonus Updater},
2023-09-23 19:24:20 +03:00
Better support for Adela specialty (+new modding functionality for it) Fixes Adela specialty that was apparently broken back in #1518 and replaced with logic that was clearly not tested - it was neither functional, nor it was following H3 behavior. - `HAS_ANOTHER_BONUS_LIMITER` now accepts `null` in place of bonus type, for cases when limiting is needed by bonus source or bonus subtype. This allows Adela Bless specialty to always work, irregardless of which bonuses are provided by Bless. - Implemented `DIVIDE_STACK_LEVEL` updater that functions same as `TIMES_STACK_LEVEL`, but it divides bonus value, instead of multiplying it (to make Adela specialty weaker for high-tier units, as in H3) - Implemented `TIMES_HERO_LEVEL_DIVIDE_STACK_LEVEL` updater that combines two existing updaters, to implement `val * heroLevel / unitLevel` formula needed for Adela specialty - Removed deprecated `ARMY_MOVEMENT` updater. Its functionality has already been removed in 1.6.X releases, and it was remaining only as a placeholder - Updated modding documentation to account for these changes & to remove some TODO's Fixed regression from #777 that could led to either duplicated bonuses or to multiple application of updaters. It introduced double-recursion - node parents were gathered recursively, and then bonuses were also collected recursively within each parent. This created situation where updater could be applied different number of times. For example, hero bonus that is propagated to unit in combat could be selected directly, or via hero->combat unit chain, or via hero->garrison unit->combat unit chains, leading to different calls to updaters if updater handles garrison unit node type
2025-04-11 15:04:30 +03:00
// This is special type of propagator, that is only activated when bonus is being propagated upwards,
// using its propagator. It has no effect on bonuses without propagator
2023-08-12 12:39:44 +03:00
"propagationUpdater" : {Bonus Updater, but works during propagation},
2023-09-23 19:24:20 +03:00
// TODO
2023-08-12 12:39:44 +03:00
"description" : "",
2023-09-23 19:24:20 +03:00
Better support for Adela specialty (+new modding functionality for it) Fixes Adela specialty that was apparently broken back in #1518 and replaced with logic that was clearly not tested - it was neither functional, nor it was following H3 behavior. - `HAS_ANOTHER_BONUS_LIMITER` now accepts `null` in place of bonus type, for cases when limiting is needed by bonus source or bonus subtype. This allows Adela Bless specialty to always work, irregardless of which bonuses are provided by Bless. - Implemented `DIVIDE_STACK_LEVEL` updater that functions same as `TIMES_STACK_LEVEL`, but it divides bonus value, instead of multiplying it (to make Adela specialty weaker for high-tier units, as in H3) - Implemented `TIMES_HERO_LEVEL_DIVIDE_STACK_LEVEL` updater that combines two existing updaters, to implement `val * heroLevel / unitLevel` formula needed for Adela specialty - Removed deprecated `ARMY_MOVEMENT` updater. Its functionality has already been removed in 1.6.X releases, and it was remaining only as a placeholder - Updated modding documentation to account for these changes & to remove some TODO's Fixed regression from #777 that could led to either duplicated bonuses or to multiple application of updaters. It introduced double-recursion - node parents were gathered recursively, and then bonuses were also collected recursively within each parent. This created situation where updater could be applied different number of times. For example, hero bonus that is propagated to unit in combat could be selected directly, or via hero->combat unit chain, or via hero->garrison unit->combat unit chains, leading to different calls to updaters if updater handles garrison unit node type
2025-04-11 15:04:30 +03:00
// Stacking string allows to block stacking of bonuses from different entities
// For example, devils and archdevils (different entities) both have battle-wide debuff to luck
// Normally, having both such units in combat would result in bonus stacking, providing -2 debuff to luck in total
// If such behavior is undesired, both such unit must have same, non-empty stacking string
// String can contain any text, as long as it not empty and is same for both of such creatures
2023-08-12 12:39:44 +03:00
"stacking" : ""
}
```
2023-09-01 12:11:35 +03:00
## Supported bonus types
- [Bonus Duration Types](Bonus/Bonus_Duration_Types.md)
- [Bonus Sources](Bonus/Bonus_Sources.md)
- [Bonus Limiters](Bonus/Bonus_Limiters.md)
- [Bonus Types](Bonus/Bonus_Types.md)
- [Bonus Propagators](Bonus/Bonus_Propagators.md)
- [Bonus Updaters](Bonus/Bonus_Updaters.md)
- [Bonus Range Types](Bonus/Bonus_Range_Types.md)
- [Bonus Value Types](Bonus/Bonus_Value_Types.md)
2023-08-12 12:39:44 +03:00
## Subtype resolution
All string identifiers of items can be used in "subtype" field. This allows cross-referencing between the mods and make config file more readable.
2023-09-23 19:24:20 +03:00
See [Game Identifiers](Game_Identifiers.md) for full list of available identifiers
2023-08-12 12:39:44 +03:00
### Example
```json
2023-08-12 12:39:44 +03:00
"bonus" :
{
"type" : "HATE",
"subtype" : "creature.enchanter",
"val" : 50
}
```
This bonus makes creature do 50% more damage to Enchanters.