Biter Revive

Any biter or worm (option) that dies will have a chance to revive back to life.

Includes a large selection of mod settings to control base revival chance and behaviours. To facilitating streamer integrations layered temporary settings can be applied as well via Remote Interface Calls or Factorio Commands.

Details =======

• Any unit or worm entity is available for revival with various mod settings allowing fine tuning of what's excluded by entity and force name. By default the mod settings are configured for the compilatron unit and the player force to be excluded. Worm's are one of the turret entity types that have the breath-air prototype flag.
• Revive chance is a scale based on configurable settings using a min and max evolution range for a min and max revive chance. This should allow any desired effect to be achieved.
• Multiple times a second the enemies awaiting reviving will be processed and up to the maximum revives done, controlled by the max revives per second mod setting. This process avoids excessive revives being done at a time, so limits UPS impact during excessive biter death periods.
• Revives have a random delay between configurable min and max seconds from 0 upwards. To avoid infinite revive/death loops a 0 second revive won't happen the moment the enemy dies, but instead a fraction of a second later.
• Enemies waiting their delay time to revive can have configurable text shown above them until they revive, i.e. snore, BRB, its just a flesh wound, etc.
• There is a mod setting to limit how many times the same unit can be revived. It defaults to unlimited. Its useful for cases of very high revive rate when you don't want the risk of near infinite revivals due to random chances.
• If a biter revive location is blocked by buildings after the enemy has died then the biter will revive in the nearest available location. This is to prevent griefing by building large walls or buildings over delayed revival biters.
• A revived biter will have its pre death attack command applied back to it if possible. Otherwise the revived biters will be controlled by Factorio as normal.
• When a worm revives (mod option) it will revive to the exact same position, pushing anything it can out of the way. Anything that can't be moved will be destroyed by the force of the worm returning.

Revive Chance Formula =====================

This is a special setting for when you want non linear revive chance growth in relation to evolution. When the default value of the setting is blank/empty then the simpler Chance of revive % per evolution % setting value will be used by the mod. When the formula setting is populated it will take priority over the simpler value setting.

The formula must be valid Lua written as suitable for use after the keyword return and will be run within the mod. The enemy's force evolution above the minimum runtime setting will be passed in as a Lua variable evo as a numeric value of the evolution percentage. So if the minimum is 70 (%) and the enemies force evo is 72 (%) the evo variable will have a value of 2.

Example of valid formula string: evo * 1.5

Modifiers (RCON) ==============

The modifiers concept is designed as a highly flexible way of applying setting values and modifiers to them. Modifiers apply for a limited duration and the mod supports multiple being active at one time and "stacking" with each other. When an enemy dies the mod evaluates all active modifier settings and the mod settings in a hierarchical manner to establish the correct current runtime settings.

Logic

Each modifier will include:

• Duration: how long in seconds the modifier will be active for.
• Settings: one or more settings that this modifier includes values for. These settings will correspond to the mod's settings. While the mod setting values are restricted in range, modifier setting values can be at any scale of the correct type (i.e. integer) and the final result will be clamped to between 0% and 100%. This is to allow unusual streamer requirements.
• Priority: this modifiers hierarchical state during the evaluation for current runtime settings. Types are: Enforced, Base, Add.

When the mod is evaluating modifiers and mod settings to identify the current runtime values it follows the below logic. It reviews all active modifiers for inclusion of the current setting.

1. If any have the Enforced priority then only these modifiers contribute to the runtime value of the setting. All other non Enforced priority modifiers and the mod setting are ignored for this. If multiple modifiers have Enforced priority then the widest value range will be used, i.e the lowest if the setting is a minimum and the largest if the setting is a maximum.
2. If any have the Base priority then these modifiers will set the base value of the setting, replacing the mod setting. Any Add priority modifiers will be applied on top of this. If multiple modifiers have Base priority then the widest value will be used, i.e the lowest if the setting is a minimum and the largest if the setting is a maximum.
3. If no modifier had Enforce or Base priority for this setting then the mod setting value will be used as the base value.
4. All modifiers with the Add priority will be added to the base value. If these are negative values then they will be deducted. This allows multiple Add modifiers to apply their cumulative effect.
5. The final value for evolution and revive chance settings will be clamped between 0% and 100%. With duration min/max settings being prevented going below 0 seconds.

Exceptions

2 settings are exceptions to the above evaluation logic: chanceFormula and delayText