# Decay settings discussion

There seems to be a a lot of confusion around decay settings, so I thought I’d start a thread trying to get a discussion on it and hopefully some test to finalize this answer.

The two settings I’m talking about specifically will be:

decay.deploy_maxhealth_sec (default setting: 43200)
decay.decaytickrate (default setting: 300)

decay.deploy_maxhealth_sec
My current understanding on this and from what I’ve gathered is this is how long a deployable (shelters, spike walls, furnaces, storage, etc) not attached to a structure decay completely. From peoples testing of shelters it takes 12 real time hours at default settings to decay. The correct conclusion and theory then would be 43200 = seconds which would equate to 12 hours for deployable items to decay.

This means by turning this number HIGHER it will make deployables last longer in the environment.

decay.decaytickrate
There are two theories around this setting that is still to be fully understood and tested that seems to determine decay. Some individuals say turning the number lower slows decay while others say turning it higher slows decay. Let me explain both theories.

Theory 1:
If you want decay to take twice of normal you lower the tick rate. This would mean by lowering from 300 to 150 your decay would take twice as long on wood and metal structures. This theory and setting would suggest that tick rate is the amount of damage a structure takes per tick. How often the decay ticks would then be considered highly unknown and this setting is setting the decay damage to structures.

Theory 2:
Tickrate is how often the server calculates for a structure to take decay damage. So by increasing from 300 to 150 it would decay structures twice as fast. An example of 300 (assuming seconds not really sure) is every 5 minutes. Every 5 minutes decay will tick and all structures will take their hard coded decay dmg amount. At 150 tickrate each structure will take dmg every 2.5 minutes. This theory plays into servers experiencing severe lag when reducing this number down below 20-30. as that would make the tickrate calculate dmg on all structures on the server every half second! it’s almost like DDOSing yourself with decay.

I have ways to test this but currently do not have a test server to test to finally conclude the answer to these questions. If anyone has a spare server willing to test let me know. I’m sure the community wants to know this answer as well.

Good job guy, i tested that on my own server and i report the result on this thread this evening.

From what I understand over the past week of attempting a Reduced Decay Server, lowering decay.decaytickrate does NOT reduce the time required to decay a building. I went to the extreme end of the spectrum and set it to .00005 and it seems to have little effect on the time for a wood base to decay. It has had very few issues with lag on the server.

However, it does appear to be affecting how deployables are decayed. I’m still seeing some that have been untouched for way past the standard 12hrs.

Would love to know if there’s a way to slow decay for bases with or without mods.

Anymore insights on this?

@lastgon have you been able to test yet?

I don’t believe the tick rate affects how fast objects decay at all, simply the resolution (frequency) of the server’s decay checks. There’s your Theory 3

Anyhoo, as you know Nynh, my Decay Control mod allows you to disable decay entirely on a Rust server running the Oxide mod framework:

As does Caelin’s mod of a suspiciously derivative name

Each plugin has features the other does not - but I’m looking forward to my next update which will make the ~400 admins using my mod very happy

Sounds like I’ll be installing plugins later today then. Thanks for your help and your active development!

or you can just use a plugin on a moded server…

When I used this mod my decay seemed to increase even tho the dcsetting said it was off. Any thoughts?
Thanks Icon58

I once addressed this issue here and in my experience, it still works the same way. My apologies for the link due to laziness of not wanting to re-type.