Content: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Background: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Pattern: Blank Waves Notes Sharp Wood Rockface Leather Honey Vertical Triangles
Welcome to TerraFirmaCraft Forums

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

  • Announcements

    • Dries007

      ATTENTION Forum Database Breach   03/04/2019

      There has been a breach of our database. Please make sure you change your password (use a password manager, like Lastpass).
      If you used this password anywhere else, change that too! The passwords themselves are stored hashed, but may old accounts still had old, insecure (by today's standards) hashes from back when they where created. This means they can be "cracked" more easily. Other leaked information includes: email, IP, account name.
      I'm trying my best to find out more and keep everyone up to date. Discord (http://invite.gg/TerraFirmaCraft) is the best option for up to date news and questions. I'm sorry for this, but the damage has been done. All I can do is try to make sure it doesn't happen again.
    • Claycorp

      This forum is now READ ONLY!   01/20/2020

      As of this post and forever into the future this forum has been put into READ ONLY MODE. There will be no new posts! A replacement is coming SoonTM . If you wish to stay up-to-date on whats going on or post your content. Please use the Discord or Sub-Reddit until the new forums are running.

      Any questions or comments can be directed to Claycorp on either platform.
LarsonPacific

[Solved] Food Decay Russian Roulette

25 posts in this topic

Have you read, understood, and followed all of the rules listed in large text at the top of the support forum? (Yes/No): Yes

TFC Version #: [1.7.10]TerraFirmaCraft-0.79.28.908.jar
Forge Version #: v10.13.4.1558

SSP/SMP (SinglePlayer/MultiPlayer):  Issue only affects busy SMP servers
 
Have you deleted your config files or are using default configs and are still able to reproduce this bug? (Yes/No): Yes
 
Do you have any mods other than Forge and TFC installed? (Yes/No): No

Description: 

 

There was a change in a recent version of TFC, where decay NBT data was fixed to store four decimal places of decay, rather than two, to make sure that food ticks properly. After doing some calculations based on the TFC source, it indeed looks like most food in most climates, especially in the early stages of decay, was only receiving ticks occasionally when the conditions were extreme enough, making most all food everywhere last an artificially long time. So,first of all, nice catch on an obscure bug :)

 

Fixing this, however, has created an unfortunate issue regarding the decayProtection mechanic, which now acts as a sort of russian roulette decay routine of sorts, for players logging back on to busier 24x7 multiplayer servers after several hours absence. The current default decayProtectionDays is 24 in game days, which can put up to 552 in-game-hour ticks of quasi-nerfed decay on a returning players food after several real-life hours. Now that the underlying decay mechanic is working properly and food is decaying faster, if a player logs back in after 7 real-life hours in most habitable climates while the server clock is still ticking, most all of their food will disappear seconds after it starts ticking. However, if they wait an extra few hours, they will take only 24 in-game-hour ticks of regular decay on their food due to the decayProtection mechanic kicking in; only a small amount of decay occurs. Understandably, this has frustrated many players on the server whose food in their perception, is randomly disappearing.

 

Since 24 in-game days equates to somewhere around 9 real hours, players might log off to go to bed one day, and whether or not they have all the food they just farmed in TFC when they log on in the morning, may be solely determinant upon how long it took to get their morning latte. Bad traffic and slow barista? No problem, your food will be good. Speedy service and clear roads? Sorry pal, everything in your fridge is gonna be gone. That is to say, it's now a true russian roulette, whereas before with broken decay, there was hardly any decay at all, on anything, ever... so no problem. Which is equally not okay.

 

To my understanding, the decayProtection mechanic is there to help with the issue of people logging off for a while on a server so they aren't losing all their food upon return, but also inhibit other players from exploiting that functionality and making an unloaded chunk fridge. Given that, I think that since the underlying decay mechanic has been fixed making most food in most places decay much, much faster, the decayProtectionDays default value should be revisited and reduced significantly to be in line with what currently observed decay rates have now become. To achieve the objectives the decayProtection mechanic sets out to accomplish, and after a reasonable amount of mathematical modelling, a default setting of decayProtectionDays ~6 (~2 real-life hours) seems more suitable to help reduce this russian roulette effect, yet still inhibit people from using unloaded chunk refrigeration.

 

Thoughts?

1

Share this post


Link to post
Share on other sites

As stated on the homepage announcements, there will be no further updates to TFC1 unless a major bug or crash is reported. You are more than welcome to change the config file on your server to what you feel is the correct value. That's why we added the config option in the first place. The default value that we chose was based on the assumption that the average player does not spend all of their time playing TFC. Let's assume that the average player has a normal life of work or school, and that they play TFC in their free time outside of the standard 9-5 hours of operation. I find would find it very surprising if the majority players were logging out before they go to bed, and then logging back in first thing in the morning less than 9 hours later. With the exception of weekends, it's much more likely that once a player logs out for the night, it'll be at a minimum of 12 if not 18 hours before they log in again.

0

Share this post


Link to post
Share on other sites

That is also assuming that the server is ticking 100% of the time. Sometimes there are periods where the server does not, such as when no players are on the server, which simply exacerbates the issue. Sometimes even after 14-20 hours later, a player will log in and get taxed with the ~280+ ticks required to kill all their food. Given that there is roughly a six real-life hour and an unknown server-tick time lapse roulette window during which this effect will be experienced, this issue is affecting the majority of regular players. Those who work 9-5, or go to school will often play before and after work, a testament to how good TFC is ;), and play at night, then again in the morning...

 

I don't expect a new release to change a default value, and understand that this issue is limited in scope to busier TFC servers. I also do not own the server, and cannot change the value myself, however, given the acknowledgement that this issue exists and will affect the aforementioned players, and that in such circumstances, server owners are encouraged to tune this particular value to suit their players' playing habits, then we can absolutely work with that. Thank you for your time :)

0

Share this post


Link to post
Share on other sites

I'd also just like to post a reminder that there are a plethora of preservation methods in TFC. I don't remember the exact math, but I believe it was that the majority of pickled food stored in vinegar will last for 11 real-life days of being loaded at 100% tick rate before the food disappears from decay. Alternatively, if players do not wish to store their food in liquid in barrels/large vessels, they can always log out with the food in their inventory to prevent the fact that if other players periodically load their base while they are offline, the decay is going to keep catching up on itself instead of using the protection system.

0

Share this post


Link to post
Share on other sites

Alternatively, if players do not wish to store their food in liquid in barrels/large vessels, they can always log out with the food in their inventory to prevent the fact that if other players periodically load their base while they are offline, the decay is going to keep catching up on itself instead of using the protection system.

 

Doesn't the decay play "catch-up" when you log in again?

If that is so then this isn't a guarantee (not that I'm saying you said it was!)...

0

Share this post


Link to post
Share on other sites

 Alternatively, if players do not wish to store their food in liquid in barrels/large vessels, they can always log out with the food in their inventory to prevent the fact that if other players periodically load their base while they are offline, the decay is going to keep catching up on itself instead of using the protection system.

 

Except that is exactly the problem. When they log back in now, the food in their inventory decays to nothing every time in most moderate to warmer climates if they get stuck in that ~200-575 in-game hour window; however, if they wait until after it, the decay protection system kicks in and they will take only 24 ticks of decay. It would make sense if returning players only took 24 (or even 72-96) ticks decay on inventory, but that's not how it works currently...

 

For preservation of food at their base, if someone is else playing at their base in their absence, I feel they should be harvesting and properly preserving food themselves to keep the stock fresh anyways... so I'm really not concerned with that aspect. If that's a problem, they need to find better people to play with  XD

0

Share this post


Link to post
Share on other sites

Doesn't the decay play "catch-up" when you log in again?

If that is so then this isn't a guarantee (not that I'm saying you said it was!)...

 

Yes, but only playing "catch-up" for the single longer period of time that the player is logged out is a lot better than it playing "catch-up" for the multiple shorter periods of time that players load the area when the player is logged out.

 

If the player is logged out for over 24 in-game days, then when they log back in the decay protection kicks in and they only get 1 day worth of decay on their food. If the player leaves their food at their base, and another player comes by and loads the chunk every 4 days, then they are going to get the full 24 days worth of decay on that food, because the protection system doesn't kick in.

1

Share this post


Link to post
Share on other sites

Thanks for that info - I've learnt something (again!)

0

Share this post


Link to post
Share on other sites

I've been testing modifying the decayProtectionDays variable in the config, even in single player, and it seems to have zero effect. Even modifying the FoodDecayMultiplier to 0 doesn't even stop decay. Steps to reproduce:

 

With debugMode enabled in the config file and TFC Options set to where food should never disappear (protectionDays 2, multiplier 0 even):

 

1. /gamemode c, give yourself a stack of cheese.

2. /gamemode s

3. Add a year to the clock with the button in the time tab or using /time command

4. Watch the cheese disappear

 

 Tested this at temps of ~10 -  ~45 degrees and a range of decayProtectionDays down to 2, with no mods but TFC, with same outcome. I know it's reading the config file, because changing debugMode worked as advertised. The decay options just seem to do nothing for some reason...

 

What twigged me onto this, I was playing on a server earlier and visited a stack of smoked dried cheese, in a vessel, that had been there longtime. Over the course of several minutes, watched it decay from 0.2% to gone at a temp of less than two degrees. This server also now has the decayProtectionDays variable set to 6; so there is no reason it should have done that. So I tested in singleplayer with no other mods except TFC and had the same results. Every once in a while, decay will randomly stop ticking on the stack, but 80% of the time, the stack of cheese just disappears, even with    I:decayProtectionDays=2 and  D:FoodDecayMultiplier=0; which in theory, should not only limit the decay ticks to 2 days, but should not tick decay at all to begin with...

 

If you could look into this, I would greatly appreciate it. :) Thanks,

 

Larson

0

Share this post


Link to post
Share on other sites

I don't think you're properly understanding how the mechanic works. The first important thing to note is that changing FoodDecayMultiplier to 0 will only affect brand new food that has absolutely no decay on it. Any food that had decay on it when you changed the config option will still decay.

 

The other thing is that if you want to check protectionDays, you need to do so in a matter that the chunk is unloaded  when time passes. If you want to do this in single player, you'll have to leave the new stack of cheese in a container that is not in spawn chunks and then go a far distance away to 100% guarantee that it becomes unloaded, then increase the time and wait for a few minutes to let the server catch up before going back and loading the chunk. On a server you can simply give yourself a stack of cheese and log out, then use the server console to advance the time and after waiting a few minutes to let the server catch up log back in.

 

You might also want to double check all of your configs, because I just tested it myself. Set FoodDecayMultiplier to 0 either by using the config menu, or editing the config file. Completely shut down and restart the game then start a brand new world and use creative mode to give yourself cheese. You can then go back to survival mode and use debugmode on the calendar with the 1 year button and absolutely no decay happens to the cheese.

0

Share this post


Link to post
Share on other sites

Okay, so I double checked my configs, and it turns out I was using an old config file, TFCOptions.cfg, instead of the newer TFCConfig.cfg.

 

That solved the issue with the FoodDecayMultiplier not working, of course. Thank you. :) However, the decayProtectionDays still does not work. I tried placing cheese in a chest in a new world, teleporting 10K away, exiting the world, opening the world, advancing a year, waiting 20 minutes, then going back to the chest, but as soon as the chunk loaded, the cheese would still rapidly decay to nothing.

 

I believe I may have figured out why, however.

 

The tickDecay method in TFC_Core.java starts by reading the decayTimer from NBT data on line 1124. When the "if" condition is met on line 1133 to apply decay protection, it calls Food.setDecayTimer to set the decayTimer to T-24.

 

This is where it looks like there may be a problem. The original variable as read from NBT data, decayTimer, is not then updated to reflect the new value of T-24. What happens then, is later on in the tickDecay method, the original decayTimer as read at the beginning of the method is incremented, and gets overwritten to NBT again using the original value on line 1180, instead of T-24. This would mean that the decayProtectionDays variable, actually never does anything at all, because decayTimer always gets overwritten later in the method using the original value + 1, which would completely explain the behavior I've been observing.

 

Adding the following line after line 1135, to update the decayTimer variable should fix it I think, so that the correct decayTimer value is written back later on: 

 

decayTimer = (int) (TFC_Time.getTotalHours() - 24);

 

Actually, just replacing line 1135 with that line would have the same effect I believe, since decayTimer is written back later anyways

 

Java isn't my native language though, so I may not be reading it right or be missing something...

0

Share this post


Link to post
Share on other sites

Just to confirm, you didn't place the cheese in a chest at the spawn of that world did you? Spawn chunks are always loaded so the decay protection system will never apply to food in them.

0

Share this post


Link to post
Share on other sites

No, I teleported to 0 144 10000, far, far away from spawn to make sure the chunk was unloaded, then teleported 10K away from it after placing the cheese in the chest, and then relogged to make double sure before advancing the time. Then waited 20 mins before returning.

0

Share this post


Link to post
Share on other sites

Does it make sense what I said, about line 1135 being changed to update the decayTimer variable instead of writing it back using Food.setDecayTimer?

0

Share this post


Link to post
Share on other sites

Ah. Thank you. I've been struggling to figure out why this wasn't working correctly. The way I'm reading it though you do need the line in 1135 to setDecayTimer to the corrected value for calculating the decay to cause to the food stack.

Edit: yeah I'm still not quite following the decayTimer variable logic. The decay code turns my brain inside out.

Edit2: ok I see your point about line 1135. I don't know if the corrected decayTimer or original value should be used for the getCacheTemp call on line 1180. I also don't quite get logic of setDecayTimer + 1 bit. I thought the timer was total world ticks + value which determines the next time it should calculate decay.

Edited by Bunsan
0

Share this post


Link to post
Share on other sites

Yeah the bug was introduced in This commit  Prior to this it was directly referencing the nbt tag value and not first assigning it to an int and referencing that. I still don't quite understand how the decayTimer + 1 works, but I know that is me not understanding.

0

Share this post


Link to post
Share on other sites

The decayTimer on the food increments by one each time the method is executed until it catches up to the current hour.

0

Share this post


Link to post
Share on other sites

I finally got a moment to look at the code myself, and I agree with what you are saying about line 1135. I'm completely swamped with school and life right now though, so it will be at least a week if not longer before an update is out fixing it. In fact, I would probably estimate that it won't be until the week of March 21st since that's the next time I have a break.

0

Share this post


Link to post
Share on other sites

Ok I've been going through this to try and understand what exactly it is doing, because some other bits just didn't sit right with me.

 

So I'll write out the logic as I'm reading it and hopefully I can be corrected or have it confirmed. This is the logic with the decayTimer fixed.

 

Now the one variable is protMulti. This variable if I under stand it offers protection from decay. It is 1 when the food has ticked within the last 24 in game hours. Its value is calculated for food that hasn't ticked for more than 24 in game hours. Its value approaches 0 as the time since last tick increases the protection limit. Just under the protection limit it is basically 0 and would essentially cancel decay. So I assume the point of this is to buffer the decay for food stacks that haven't ticked for a long time, but are under the limit.

 

Example 1 Food older than the protection limit (default 480 in game hours =~ 8 real life hours without sleeping on server.

 

  • It would satisfy the DecayTimer less than the totalHours would get a protMult of 1.
  • It would have a timeDiff greater than the protection limit and so the decay timer would be set to totalHours - 24.
  • It then does the whole decay calculation with protMult of 1 (which drops it out of the formula).
  • The DecayTimer NBT tag on the food is set to the decayTimer + 1.
  • The next increment the timeDiff would be less than the protection limit and 24, so it would just keep the protMult of 1 and calculate decay.
  • It would then continue to increment until the decayTimer was greater than totalHours.

So in the end this food stack would take decay for 24 hours with protMult of 1 for every calculation.

 

Example 2 Food under the protection limit, using 400 hours.

 

  • It would satisfy the DecayTimer less than the totalHours would get a protMult of 1.
  • It would have a timeDiff less than the protection limit and so the decayTimer remains the same.
  • It satisfies the timeDiff greater than 24 though so it would recalculate the protMult to the appropriate value.
  • It then does the whole decay calculation, with the new protMult.
  • The DecayTimer NBT tag on the food is set to the decayTimer + 1.
  • It would keep incrementing slowly raising the protMult value until the timeDiff = 24 and it would keep the protMult of 1 and calculate decay.
  • It would then continue to increment until the decayTimer was greater than totalHours.

So in the end this stack would increment the food stack 376 times with a protMult that starts at 0.167 (1-(400/480)) and moves to 0.948 (1-(25/480)). It would then increment the other 24 hours at protMulti of 1.

 

Conclusion.

 

If you are just 1 in-game hour below the protection limit you get hit with substantially more decay than if you were over the limit. This does not make any sense to me for gameplay. The way that makes sense to me is to have a maximum time that decay can be calculated for in one go. This means that food decays for the correct number of hours since it last ticked up to a limit. Not taking food over the limit and artificially setting it to a much lower amount.  I really like the protMult variable (if it works as I think it works).

 

So my suggestion is this. line 1135 should be 

decayTimer = (int) ((TFC_Time.getTotalHours() - (TFCOptions.decayProtectionDays * 24) - 1));protMult = 1 - (timeDiff/(TFCOptions.decayProtectionDays * 24));

So this would set the decayTimer to one less than the protection limit. You could leave off the -1, but then protMult value calculation added in the next line would equal 0 and would make a pointless decay calculation.

 

So is my logic sound?

0

Share this post


Link to post
Share on other sites

In reply to Bunsan's post:

 

The decayProtection mechanic only helps on multiplayer servers, and is only there to help with the following situation:

 

1. Guy makes a few sandwiches and/or harvests a bunch of food.

2. Guy logs off on a Friday night and logs back on Monday morning; server time keeps ticking as other people play elsewhere in the world.

 

Without decay protection, if the temp where the food is stored is > 0 and the guy logs on where the temp is > 0, the food would be gone, which isn't really fair to the player; may as well call it Farmville 3, 'cause all you're going to be doing is harvesting food. XD

 

If the suggestion you posted were followed, the guy in the above example would also still lose all his food. This is because unless the temp is < 0, 24 game days of decay (the current default decayProtectionDays setting in TFCConfig.cfg), is still enough to destroy just about anything. Thus it would defeat the whole purpose of having the decayProtection mechanic to begin with. Changing the default decayProtectionDays so far low enough to where it would be fair to returning players, however, would make it easy for people to exploit the feature and use unloaded chunk refrigeration. A balance is required between making the decayProtectionDays long enough to inhibit abuse of the mechanic to preserve food, but short enough to minimize the lottery/roulette effect about which this thread was started.

 

So, since I don't think people should be penalized with max decay simply for having to sleep, work, or go to school, I think the mechanic should be left alone (other than being repaired ofc).

 

Changing the decayProtectionDays config on your server, as previously recommended by Kitty (I chose the number 6, though you may want to go slightly more, or less, depending on the playing habits of your players and what you feel is the average habitable climate; though personally, I wouldn't bother going over 12, however, as it will just increase lottery effect and most food decays by then anyways), combined with a functioning decayProtection mechanic, should make everyone on your multiplayer server happy :)

0

Share this post


Link to post
Share on other sites

Well mine is based on balancing my public modpack. Also this does effect SSP as well since even in SSP you'll have unloaded chunks.

I see your point about the decay, however we are both basing this on an assumption. Yours on the default year and mine on the 360 day year.

It seems (although I can't figure out where it occurs) that decay rate scales for year length. So 24 days in a 360 day year is the equivalent to about 2 days 6 days in a 96 day year.

So it would seem the days of protection should scale to year length.

Edit: Derp 4/5 of a month not 1/5. So equivalent to 6 days.

 

Edit: I don't mean the protection should scale to year length in code, just that you would want to scale it appropriately when changing your year length. Either way I know how I can fix it to do what I want.

Edited by Bunsan
0

Share this post


Link to post
Share on other sites

Just wanted to post an update so you guys know I haven't forgotten about this bug. I ended up spending all of my spring break moving to a new apartment, travelling for on-site interviews, and doing all the homework that was due either during spring break.. or the first day back (meanie professors). As soon as I have enough free time to implement the fix and fix the negative crop growth bug and then test and confirm everything there will be a bugfix release. I just don't know when that's going to happen.

 

Absolute worse case scenario, the update will be in the middle of May, since I have finals and then graduate in the first few weeks of May. Hopefully I'll be able to release it before then.

0

Share this post


Link to post
Share on other sites

Don't let it get in the way of your finals!

0

Share this post


Link to post
Share on other sites