Decay and the passage of time.

[kevingranade]

Here's a simple system for implementing terrain decay over time. Each terrain type gets assigned a half-life and one or more decay products. Each time we load a submap, we have a last loaded timestamp, using this we can calculate the passage of time, and using that a weighted probability of the half-life occurring for each tile. Decayed tiles will be modified in-place to be the new type. Ideally the comparison will yield when the decay happened, and we can re-roll with the new terrain half-life for additional decay. This can apply to item decay as well. Probably not good for crops, as we want that to be more deterministic. Fire of course is still a problem.

Examples: Terrain, half-life, product Asphalt, 1 year, cracked asphalt cracked asphalt, 1 month, weedy asphalt Wall (exterior), 1 year, vine-covered wall Wall (exterior), 1 year, crumbling wall Wall (interior), 3 months, moldy wall Meat, 6 hours, rotten meat rotten meat, 2 days, pile of filth pile of filth, 1 week, nothing

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[i2amroy]

I think I might want my interior walls to last a lot longer then 3 months (assuming my roof still works), but I could see this working fairly well. Question though, how/would this work with modifiers? Originally I thought we could just factor it into the end half-life rolls, but that could lead to weird things where if you manage to get food into a refrigerator right before it goes bad it magically gets a much longer lifetime (despite having sat on the hot pavement for a few days first).

[kevingranade]

While an item is on-map, and therefore more subject to changes in condition, we can use a much finer-grained system to track spoilage, e.g. make a half-life expiry roll each turn. So it has one effective half-life while on the sidewalk, potentially another while in inventory, and then another when in a powered refrigerator. If per-turn checks add too much load, we can maybe have multiple lists of items and round-robin through them, e.g. 10 lists and each is processed once a minute. Basically the age

• decay time system we use right now simply doesn't work if we're going to do things to manipulate decay rate.

The proposed system doesn't kick in until the map tile containing the item in question is unloaded, at which point we set the timestamp on the submap, and run the proposed expiry system on it the next time it is loaded.

There are additional nuances possible, such as stepping through the weather history since the submap was unloaded in order to apply different rates based on temperature, or in the case of a refrigerator, determining powered and unpowered spans, and treating those spans separately. Obviously this can get quite complicated if power input is intermittent and especially if there is some kind of power buffer, then you need to calculate charge rates and discharge rates based on whatever your power source is, and determine when the system runs out of power so you can apply the effects of it being unpowered properly. Unfortunately food spoilage with an intermittently powered refrigerator is both one of the more complex use cases as well as one of the ones we care about the most :P

All that having been said, item decay is a side issue, it might use this system, it might not. For terrain aging, I don't think there is going to be much to modify it (while the submap is unloaded in particular), so I'm not sure it's an issue. A potential side effect is assuming the player does some amount of maintenance when in their home base, so any time they spend there doesn't count toward decay.

On Tue, Nov 5, 2013 at 10:30 AM, Christian Buskirk <notifications@github.com

wrote:

I think I might want my interior walls to last a lot longer then 3 months (assuming my roof still works), but I could see this working fairly well. Question though, how/would this work with modifiers? Originally I thought we could just factor it into the end half-life rolls, but that could lead to weird things where if you manage to get food into a refrigerator right before it goes bad it magically gets a much longer lifetime (despite having sat on the hot pavement for a few days first).

— Reply to this email directly or view it on GitHubhttps://github.com/CleverRaven/Cataclysm-DDA/issues/4162#issuecomment-27788059 .

[VampyreLord]

Walls shouldn't be deteriorating this fast.

[i2amroy]

Walls shouldn't be deteriorating this fast.

Agreed. Roof lifetimes are in the 15-50 year range, depending on the type of roof (wood around 14-20 years, clay/metal 50-150 years). Wall lifetimes are even longer then this, and tend to be in the 50-100 year range, with well built walls/roof combinations sometimes holding back the elements for a couple of hundred years before collapsing.

[uzername]

I'm getting bored after 3-4 days of ingame time and you are talking about years.

[i2amroy]

Play more then one game on the same world. :P

That said I'm certainly not going to condone "speeding up" the decay of the world just because some players are impatient. If we're going to do something like this, we're going to do it realistically.

[kevingranade]

I'm not lobbying for using those numbers, that was just some examples to illustrate how the system works.

[Rivet-the-Zombie]

This would be AWESOME with some tweaks applied to the numbers.

Even better would be if a few game-years in, we'd start seeing trees growing out of cracks in the road and such.

Google 'Pripyat, Ukraine' for some great photos of a decaying urban environment that's slowly being reclaimed by nature.

[illi-kun]

This issue was closed as it appears inactive.

Reducing open issues to those which are (or will) be actively worked upon helps us focus our efforts. This issue has not been deleted - it still appears in searches and if it contains relevant information you are encouraged to continue to link to it.

If this issue was a bug

It should be reopened if it can be reproduced in the current build. You can obtain the most recent copy here. Please check there is not a more recent report of this bug before doing so. If no more recent report exists you should continue the discussion in this issue.

If this was a feature request

If the consensus was that the idea was good you could consider submitting an implementation via a PR. If you want to comment further please do so here as opposed to opening a new issue. Before posting check nobody has already made the same point and consider whether your comments are likely to lead to an implementation. If you have doubts about either consider instead voting for the issue

If you want to work on this issue

Then either assign it to yourself or if you are unable to do so claim it via adding a comment. Please don't assign others or make a general request for action.