Register
Events
Popular
More
Post #1Can 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.
-
Decaytickrate does NOT slow down or speed up decay over time, it only changes the frequency at which the server checks and applies decay damage which is 'due'. It is essentially a setting for the 'resolution' of decay. The default is 300 (seconds, meaning check for decay every 5 minutes), which is fine for most servers. Highly populated servers with very numerous or large structures may benefit from a higher value such as 600 (10 minutes) or 900 (15 minutes).
Deploymaxhealthsec is only relevant to 'deployables', objects like barricades, spikes, furnaces, boxes, workbenches etc. This setting also only applies to those objects when they are NOT on/in foundationed, active buildings (buildings which are not decaying because they have had someone using them in the past 12hrs). In other words, it applies to deployables in abandoned buildings, or ones placed on the ground/rocks/etc.
The decay delay of buildings (the inactivity timer) is apparently 12hrs and cannot currently be changed by any settings or mods.
The decay RATE of buildings can be changed, but not by any game setting, you need to use a mod which was designed for this purpose.
Decay cannot be disabled by game settings (though setting a very high deploymaxhealthsec can be used on a vanilla server to stop people's spikes etc from decaying if you so wish), but there are mods which stop it entirely - see http://forum.rustoxide.com/threads/decay-control.2219/ (big update coming soon too). ;)
If you've set your decaytickrate lower, just change it back to 300. There's absolutely no benefit to you or your server by having it check more frequently, and it can impact performance (cause lag).
Edit: and if you're trying to change these server settings and have them persist, you should be putting them in your server.cfg file.
-
THANK YOU! This is very helpful and saves me a lot of time testing different decay rate settings. lol.
I don't understand how someone reported in this thread that their players can go one week without decay. Does increasing the tickrate (which as you said, increases the time between checks) extend the decay rate? ie. If you set the tickrate to something longer than the decay rate.
-
If that building (or one of its connected foundations) has a door or campfire on it, which is interacted with (opened/closed/lit/extinguished), that resets the inactivity timer (12hrs). Only after 12hrs of no interactivity on that buildings foundations, does decay *begin* to damage parts of that building.
If at standard decay settings (43200 deploy_maxhealth_sec and 300 decaytickrate), a Wood Storage Box (default 500hp) is theoretically taking 500hp/(43200/300) = 3.47hp damage every 5 minutes. If you then set the decaytickrate to 600, it will instead be 500/(43200/600) = 6.94hp damage every 10 minutes. If you make the decaytickrate 100, it will inflict 1.157hp damage every 100 seconds.
Over the course of an hour, the box will still take the exact same amount of damage, just in smaller/bigger chunks. I don't think I can explain the irrelevance of decaytickrate any more clearly.
If you set the decaytickrate to, for example, 99999999 (which equates to 3 years :p), then that may appear to work in preliminary testing, but it's asking for trouble - the server may perform 'catchup' decay either at server start before the config file is read, or when the setting is not enforced for a short period of time for whatever reason.. Essentially you're banking on nothing ever going wrong, which isn't usually a smart thing to do ;)
-
What's your response to the people claiming setting their tick rate to "0.00001" extends their decay to months.
-
I would prefer that as the default value.
-
I imagine setting the tick rate to such a fine value probably causes the "damage per tick" value to get divided so low that rounding errors would more often than not clip the value to zero, and as a result only a very small fraction of the intended damage gets applied. (e.g. after millions-billions of ticks finally add up to inflict a single point of damage)
-
There is a wiki entry with good explanation and formulas.
Agree x 1
Useful x 1
Disagree x 1
Winner x 2
