Talk:Beer

I can’t find where the 6 days fermenting time come from. Neither in the def files nor in the changelogs. Is it from in game testing? (Can’t do that right now.) I feel like I’m missing something obvious here. Also there is conflicting information on how the game deals with adding wort in the middle of the fermenting process. While this page claims it resets the cycle, Fermenting barrel suggests it’s only prolonged.

Well, "6 days" was on the page before my first edit, so I didn't do it! ;D When you start a batch, the count-down on the barrel says "6 days left" - no idea where that number comes from. As for "adding", I observed it to reset, ~but~ it was early in the process (~5 days left?), so it's possible that both are (close to) true depending exactly when new wort is added. I'll do some checking. Albedo (talk) 21:23, 23 March 2022 (UTC)

A cautioning text about using Fahrenheit was added to Temperature.

Hey User:Albedo, thanks for the feedback about the temperatures. I actually think the game doesn't deal with Fahrenheit at all internally. If the temperature setting is set to Fahrenheit (or even Kelvin) the game will only switch what unit it displays and converts the Celsius values for the player. These values will be shown as whole numbers to the player in the GUIs, but same as with a lot of other values the game most certainly calculates with the unrounded values.

Also I just had a quick look in the game files and the Fermenting barrel has the following properties:

Class="CompProperties_TemperatureRuinable"
  <minSafeTemperature>-1</minSafeTemperature>
  <maxSafeTemperature>32</maxSafeTemperature>
  <progressPerDegreePerTick>0.00001</progressPerDegreePerTick>

This would suggest that the safe temperature range is -1 °C – 32 °C (30.2 °F – 89.6 °F). I guess the third property means that each tick per degree outside the safe temperature the spoiling increases by 0.00001 until it reaches 1 or something like that. But I can't confirm that right now. Do you know more about that or can test it?

My second best guess would be that the “progressPerDegreePerTick” actually means the progress of the brewing process. So the higher the temperature the faster the brewing but if it reaches a certain temperature it goes (immediately?) bad. I think this would even make more sense than my first theory but again I’ll have to test it in game.

The first paragraph is absolutely correct. All the conversions to F are on the front end and are fractional both in the math and because they're using C to set the thresholds rather than F.

As for the second part, it does seem to do as you say. Tick up at a rate defined by the difference between actual temperature and the safe temperature, and then ruin when it gets to 100% (1)

private void DoTicks(int ticks) {

   if (!this.Ruined)
   {
       float ambientTemperature = this.parent.AmbientTemperature;
       if (ambientTemperature > this.Props.maxSafeTemperature)
       {
           this.ruinedPercent += (ambientTemperature - this.Props.maxSafeTemperature) * this.Props.progressPerDegreePerTick * (float)ticks;
       }
       else if (ambientTemperature < this.Props.minSafeTemperature)
       {
           this.ruinedPercent -= (ambientTemperature - this.Props.minSafeTemperature) * this.Props.progressPerDegreePerTick * (float)ticks;
       }
       if (this.ruinedPercent >= 1f)
       {
           this.ruinedPercent = 1f;
           this.parent.BroadcastCompSignal("RuinedByTemperature");
           return;
       }
       if (this.ruinedPercent < 0f)
       {
           this.ruinedPercent = 0f;
       }
   }

}

"All the conversions to F are on the front end and are fractional both in the math and because they're using C to set the thresholds rather than F" - that's all well and good, but a player doesn't care about the "black box" of the code, only what's displayed - and the display for either temp is always in whole numbers. Please be careful about getting lost in the fine details and distinctions of game mechanics and the "Curse of Knowledge" of an advanced player, and remember that this Wiki is for players (esp new ones) as much as modders (if not more so!). With that in mind, making statements that include tenths of degrees is simply not serving the presumed mission of this wiki, which (imo) is first to explain "How to play the game", and only secondarily "How to mod the game".
If I am using F, is "30.2" safe at 30 or 31? THAT is what the wiki needs to communicate. Or, if it is indeed a (non-displayed) fraction and the cutpoint occurs between them, then that info is critical to those relying on Farenheit, and to mention that the exact fail point lies between those two displays and so to err on the safe side! (And if you want to mention, somewhere, that modders should always use C, that's great too!) Albedo (talk) 22:55, 22 March 2022 (UTC)

Ok, I think then we could just change Template:Temperature to round to the nearest whole number instead of to the tenths degree. You are probably right that this kind of precision is unnecessary, especially as there are 1.8 °F per 1 °C

And thanks Harakoni for the confirmation of my theory about the third property, although I am a bit sad that my second theory was that short lived ;)

I'm not sure a default "rounding" will work - sometimes the Farenheit "trigger" point is above a whole-number value (so rounding down is accurate), and sometimes the opposite - no? (And I'm not trying to be difficult, just productive - if the template transposes a failpoint in Celsius to "X degrees Farenheit", it'd be nice if that were an accurate value.) :/ Albedo (talk) 23:09, 22 March 2022 (UTC)

Afterthought - Since Celsius is the default, and if(?!) Farenheit is inaccurate/unreliable as integers-only, perhaps a mouse-hover pop-up over the Celsius value? (If possible to code.) It's Euro-centric, but if the game mechanic itself is then that might be the most useful/accurate approach, and let the player decide if rounding up/down is the "safest" value - mebbe?Albedo (talk) 23:43, 22 March 2022 (UTC)

Rounding it introduces issue that would be annoying to implement. Not every threshold is clean, and its not just a code curiosity. If the wiki says something happens at 30F, and your screen says its 30F, and it doesn't happen, that is confusing. If it says it happens at 30.2 F and its readily apparent that your display is rounding, then its becomes fairly self evident that you could be below the threshold and the display is whats causing the issue.

Even having the editor pick which to display as the "safe" doesn't really help because then someone looking for the inverse information (e.g. exactly where it become unsafe) is still misled.

"Misled" would be that one or the other appears absolute when it's not, so I think what we need, then, is to make it clear, to somewhere/somehow spell it out (perhaps repeatedly, as SOP?), that the situation is as it is - the game threshholds are based on Celsius integers, and Farenheit (and Kelvin) are going to be slaves to those values, and so (usually) non-intergral values. Then we can keep the current template as is (and proceed to confirm any/all currently listed "observed" Farenheit values). (Edit: If all agree, go ahead and reverse my recent "undo" on this article, np, agreed here.) Albedo (talk) 02:19, 23 March 2022 (UTC)

Yeah there is definitely an issue with observed values as you say. Where we can get the exact numbers theres far less of an issue.

I'm also in agreement, but I'll leave User:Ickputzdirwech to make any reversion just in case they have anything else to add.

Copy that. @ Ick - go ahead and (re)revert/edit as you feel approp (you've been doing good work from everything I've seen). I just added an explanation/disclaimer/caution under the intro for Temperature (along w/ some other useful info). I actually paused and did the math, and I have to confess I pro'ly over-reacted - it's just not that significant since Farenheit is almost twice as sensitive as Celsius, so even a half degree rounding from °C to °F is going to be reduced to a tiny hiccup in accuracy. I guess it's more for in case someone notices that things are not perfectly smooth in °F, more pro forma than a cause for real concern. I'm good w/ closing/resolving this once Ick' replies. Albedo (talk) 05:22, 23 March 2022 (UTC)

Thanks for the text on Temperature @Albedo and thanks to both of you for the good discussion! The only thing I want to add is that the game rounds pretty much all the values it shows the player. Temperature is only a special case because in C the values are usually integers already so the error is only resulting from the unit conversion. But as you pointed out it’s quite small anyway. Also it’s nearly impossible to control the temperature of a room to the nearest °C anyway. It therefore won’t make much of a difference for a player if the target temperature is a tiny bit off. Although I always like precision.

Anyway I’ll rerevert to the use of the temperature template now and correct the values with what I found in the game files. Thanks again!

Infoboxes merged

There appear to be two diff info boxes (there certainly are 2 diff colors, and perhaps 2 diff styles/templates?). Either way, the upper one is far too wide (and the red is a bit garish, but that's a quibble). Above my wiki-fu to troubleshoot.Albedo (talk) 21:45, 15 March 2022 (UTC)

There are two infoboxes right now. While the food/drug part is still defined with the old infobox system, the weapon stats are already in the new infobox. I'm currently working on switching pages to the new infobox and the food items are the next thing on my list.