decay.decaytickrate Server Command

Can anyone explain how exactly this works? Can it be used to slow down or possibly turn off decay? Thanks in advance.

Id bet that if you set decay.decaytickrate to 0 it would turn decay off. Careful though, id also bet that decay.decaytickrate 1 isnt the default setting. I know env.timescale 1 makes time go like 10x faster than it should be!

Decay is in the game for a good reason. It destroys old and unused buildings so that the server doesn’t lag horribly.

Does anyone know the default value for this field? I have struggled to find solid information on the subject. I understand that decay is a good thing, but for a very inactive server…it would be nice to have control over it.

it will be configurable in next version of Rust++ tonight

I am looking forward to it.

is a new version of RUST being pushed out tonight?

within the hour

I tried putting decay.decaytickrate 0 in my server.cfg and it severely lags my server. Also need help on this.

Anybody else have any ideas for removing this or turning it off?

Set to 0.000001 and your decay rate will be > 2 months. Experiment with smaller values if you want a shorter decay. Hopefully, we will get the vale defined by Facepuch at some point. Correlated to seconds or hours perhaps?

Slightly old thread, but I’ll share my little knowledge.

I suggest also setting decay.deploy_maxhealth_sec to a really high value alongside lowering decay.decaytickrate. I personally don’t understand the tickrate setting, but lowering it somehow slows decay. The maxhealth setting is either the amount of seconds something starts to decay or it is a backup to ensure something decays if the tickrate doesn’t work. I have yet to figure that out.

Anyways, the default maxhealth setting is 43200 seconds (12 hours) which happens to be the default shack decay time. I don’t know how it gets figured into other structures. I have my server’s tickrate at 50 and maxhealth at 500000, which is 5.787 days, and I’m getting reports from players that they can log off from weekend to weekend without anything decaying.

My current theory is that the tickrate somehow gets factored in with the maxhealth to determine the actual rate of decay for something.

thank you for the post…

i was searching but always same vague answers…
i put your settings and hope it will be ok…

do you know does it slower decay for spike walls? as that is biggest issue really…

I have still been playing with the decay rate commands on my server and I have come up with this theory about the decay.decaytickrate server command. I believe the interval you set here is relative in seconds as to when decay will start since an object has last been “touched/healed/opened/etc”. The lower I set the tickrate, as long as it’s a whole number, the faster things will decay for me since they were last touched. I do not understand why putting less than a whole number would slow down the tickrate here, but it does. I have my decay.decaytickrate set to “3600” on my server or one hour. Things start to decay after one hour since they were last touched and countdown to minimum health at the interval I set for decay.deploy_maxhealth. If anyone else knows more about these two commands I’d like to hear it.

The default decay rate is somewhere around .06677790 around that somewhere. I was playing around with It on my server.

I think you’re thinking about the old env.timescale setting, which was removed. The default value for decay.decaytickrate is 300.

I think decay.decaytickrate is the amount of health removed when a tick comes up.

and settings decay.deploy_maxhealth_sec to higher value gives more health to structures.

So the lower the decaytickrate the longer structure will stay up.

Yeah I don’t get it, I don’t want to play with it to much in fear that people’s stuff will start disappearing.

I’m guessing here and these are just my thoughts.
Changing “decay.decaytickrate” to a number like 1 causes severe lag, now why is that I wonder. Is it possible that this command is responsible for some sort of “decay countdown timer” or “activity check”? Decreasing this number you decrease the total time on the “countdown clock”. So how is it by increasing(300 to 3000) this “clock” causes no lag and causes decay faster while decreasing(300 to 30) this number causes lag and slows decay time in which items start to decay?(by reports from people). One would assume that “tickrate” is time so increasing this number would extend the time on the “clock” in which the first “decay damage” would take place but it doesn’t, does it? What it probably is, 300 is seconds so after the decay timer has hit 0 the item takes “X” amount of damage every 300 seconds. 300 seconds = 5mins so is it possible?

Does “decay.deploy_maxhealth_sec” control time? I mean the default number perfectly breaks down to 12hrs for a shelter which is the shortest decay time for a structure so is it a coincidence? You see the “maxhealth” which you’d think it would deal with hit points but then you also see “sec” which you’d think deals with seconds.

After all this thinking my final theory is:
“decay.deploy_maxhealth_sec” Deals in time in which decay starts based on health. (Health X Time = Decay Rate)
“decay.decaytickrate” The “pause” duration between “activity checks” for a “decay damage timer” in which when an item takes its’ next damage from decay. So a low number increases “activity checks” which also increases lag and decay. Since it is responsible for lag I’m going to say that this command, “clock” or “checker” is always active regardless if decay is active or not but rather it does “0” damage when decay is not ready yet and does “X” amount of decay damage when decay is ready.

We all know what the default settings do so what we need is someone with a server to keep the default “decay.deploy_maxhealth_sec” and change “decay.decaytickrate” to “150” (half of 300) and build a shelter since we all know shelters are 12hrs making it 24hrs because of “150” (300 = 12hrs, 150 = x2, 12hrs X 2 = 24hrs). So at 24hrs after placing and leaving the Shelter it should just start taking damage. This way we know that it does indeed change time in which items start to decay or that my theory is correct.

Figured it out. So decay.decaytickrate is in seconds. Ex: Set it to “50” and it will take 50 seconds for the next damage tick to happen.

decay.deploy_maxhealth_sec is how much damage your structures (not attached to or on foundations) will take when a tick happens.

The decay.deploy_maxhealth_sec damage ratio is weird though so I pinpointed it and did the math for you. 1 damage exactly is “18750”
4 DMG/Tick = “4687.5”
3 DMG/Tick = “6,250”
2 DMG/Tick = “9375”
1 DMG/Tick = “18,750”
.75 DMG/Tick = “37,500”
.50 DMG/Tick = “56,250”
.25 DMg/Tick - “75,000”

decay.decaytickrate “60” = 1 tick/min
decay.deploy_maxhealth_sec “18750” = 1 DMG/Tick

Large Spike Wall Max HP = 1500
Lets assume you set your settings to the ones I stated above.
1500HP taken down by 1 HP every minute = complete breakdown in 25 hours.

Similarly 1500HP taken down by 2 HP every 30 seconds = breakdown in 6.25 hours.

Hope this helps!

–==1337 Haxxorz==–

I don’t know how any of these theories can be correct… Maybe someone can make sense of this. I changed my settings to the following:

decay.decaytickrate 60
decay.deploy_maxhealth_sec 500000

My structures decayed completely in 60 hours. My spiked barricades are still intact.

Now I have tried the following but the result is still the same…

decay.decaytickrate 600
decay.deploy_maxhealth_sec 75000

It’s as if the settings aren’t taking. Yet after setting them, I reboot, and double check in console to see if the values are what they should be.