{"action":"created","issue":{"url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/12805","labels_url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/12805/labels{/name}","comments_url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/12805/comments","events_url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/12805/events","html_url":"https://github.com/CleverRaven/Cataclysm-DDA/issues/12805","id":91798874,"number":12805,"title":"Monster upgrades rework plan","user":{"login":"drbig","id":1252899,"avatar_url":"https://avatars.githubusercontent.com/u/1252899?v=3","gravatar_id":"","url":"https://api.github.com/users/drbig","html_url":"https://github.com/drbig","followers_url":"https://api.github.com/users/drbig/followers","following_url":"https://api.github.com/users/drbig/following{/other_user}","gists_url":"https://api.github.com/users/drbig/gists{/gist_id}","starred_url":"https://api.github.com/users/drbig/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/drbig/subscriptions","organizations_url":"https://api.github.com/users/drbig/orgs","repos_url":"https://api.github.com/users/drbig/repos","events_url":"https://api.github.com/users/drbig/events{/privacy}","received_events_url":"https://api.github.com/users/drbig/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/labels/Enhancement","name":"Enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/labels/Suggestion%20(Discuss)","name":"Suggestion (Discuss)","color":"FF3399"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":18,"created_at":"2015-06-29T13:07:10Z","updated_at":"2015-07-11T22:21:11Z","closed_at":null,"body":"So I was planning to start with how things are now *yadda yadda*. I'll just write down my idea of how it should look like logic- and implementation-wise. Didn't want to pollute #12313 though that issue is obviously relevant.\r\n\r\n - Upgradable monsters get a boolean `upgrades` property. This is the one-and-only property that clearly defines if a monster can upgrade or not.\r\n - If a monster has `upgrades = true` then it also has to (and this will be checked on load) have exactly:\r\n  - Either `upgrades_into` or `upgrades_group` (same functionality as now)\r\n  - Either `upgrades_half_life` or `upgrades_chance` (same functionality as now)\r\n  - `upgrades_period` - which specifies a time-span in days\r\n - Monsters can upgrade only *once* per `upgrades_period`, missed windows don't stack up. The only delay to monster upgrades is the starting season offset which guarantees that upgrade windows always start at the same time the player started. Also this means additional property on monsters to keep track of whether it has mutated already in the current period. (periods are continuous, e.g.: with `upgrade_period` of 14 days, Z upgraded on day 7, the upgraded Z didn't upgrade between 14 - 28 days, but it did on day 32, next windows is 42 - 56).\r\n - Monsters have a chance to stop upgrading once and for all (`upgrades = false` then). My current idea here is that if a monster passed upgrade chance check it will have 70/30 chance to either actually upgrade or stop upgrading.\r\n - There are only two ways to trigger monster update: the special attack and on load\r\n   - The special attack obeys once per period rule, but can't be turned off and the upgrade_period is not tweakable by the player\r\n   - The on load upgrade can be turned off and `upgrades_period` is tweakable by the player. The `MONSTER_UPGRADE_SCALE` works like this: values 0.01 - 0.99 make monsters upgrade (much) more often; values 1.01 - 100.00 make monsters upgrade (much) less often; 0.00 turns off on load upgrades completely; 1.00 means the default `upgrade_period`. This means we can call it \"Monster upgrade scale\" and actually have it work like that, e.g. 2.00 means on average it will take monsters twice as much time to fully upgrade (it should also make it simple for the player to scale this season length-wise; 2x longer season = 2.00 upgrade delay).\r\n\r\nThe above is obviously open for discussion and tweaking. The main goal is to have the monster upgrades smooth and sane code- and logic-wise.\r\n\r\n<bountysource-plugin>\r\n---\r\nWant to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/23302336-monster-upgrades-rework-plan?utm_campaign=plugin&utm_content=tracker%2F146201&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F146201&utm_medium=issues&utm_source=github).\r\n</bountysource-plugin>"},"comment":{"url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/comments/120665836","html_url":"https://github.com/CleverRaven/Cataclysm-DDA/issues/12805#issuecomment-120665836","issue_url":"https://api.github.com/repos/CleverRaven/Cataclysm-DDA/issues/12805","id":120665836,"user":{"login":"i2amroy","id":4275617,"avatar_url":"https://avatars.githubusercontent.com/u/4275617?v=3","gravatar_id":"","url":"https://api.github.com/users/i2amroy","html_url":"https://github.com/i2amroy","followers_url":"https://api.github.com/users/i2amroy/followers","following_url":"https://api.github.com/users/i2amroy/following{/other_user}","gists_url":"https://api.github.com/users/i2amroy/gists{/gist_id}","starred_url":"https://api.github.com/users/i2amroy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/i2amroy/subscriptions","organizations_url":"https://api.github.com/users/i2amroy/orgs","repos_url":"https://api.github.com/users/i2amroy/repos","events_url":"https://api.github.com/users/i2amroy/events{/privacy}","received_events_url":"https://api.github.com/users/i2amroy/received_events","type":"User","site_admin":false},"created_at":"2015-07-11T22:21:11Z","updated_at":"2015-07-11T22:21:11Z","body":"Keeping it just the basic rng seems like it might work best. An exponential seems like you might end up with \"chunky\" upgrades, where it seems the vast majority of zombies upgrade every 14 days or so, instead of a smoother distribution.\r\n\r\nAs for failure to upgrade chance, why not just put a ```\"stoppage_percent\":X``` into the JSON? Then you just have to add two bools (which in a bitfield would be just 2 bits) to each monster. The first checks if a monster has already done it's failure chance, and the second one says if it passed or not. On loading a monster for the first time you roll a single percentage roll and if they fail then they don't upgrade anymore. If they pass they keep trying to upgrade until they eventually pass, which resets them so the next time they load they have to check for upgrade failure again. Simple, and more configurable percentage wise then a \"only gets 5 upgrade roll chances\" or something similar."}}