KoreanWaffles

Remember when you could put an eyeball on literally anything and it would be funny?

I'm here for my bi-monthly meme post

I've done the math before. Skip to the end for a tl;dr. Cooking food returns 50% of the missing freshness of the food. For example, if you have a raw meat (spoils in 6 days) and then cook it after 3 days (50% freshness) have passed, cooking will return 50% of the missing freshness which is 1.5 days (25%), giving it a new freshness of 75%. A cooked meat spoils in 10 days, so it will spoil in 7.5 days, giving a total spoilage time of 10.5 days. However, let's say you cook it at the very last second at 0% freshness or after 6 days have passed, then it will return 50% freshness, giving the cooked meat 5 more days of spoilage, yielding a total spoilage of 11 days. So it's best to cook a meat as late as possible, or right before you plan to eat or cook it in a crockpot. However, let's look at monster meat, which has a raw spoilage time of 6 days, and a cooked spoilage time of 15 days. If you cook it immediately, then the monster meat will last 15 days. However, if you cook it at the last possible moment (after 6 days), then it will become a cooked monster meat at 50% freshness which will spoil in 7.5 more days, totaling 13.5 days of spoilage. This means it's best to cook monster meat as soon as possible to prolong spoilage. So how can we tell when is the best time to cook foods? Spoilage rate can be modeled by the following formula where d = amount of days passed r = raw spoilage time c = cooked spoilage time Basically, it adds the amount of days that have passed, the percent freshness converted to days of the cooked food, and adds the bonus %50 missing freshness converted to days by cooking the food. After doing some algebra, we get that the overall spoilage time is always equal to the cooked spoilage time when c = 2*r. When c > 2*r, (such as in the case of monster meat) the overall spoilage time will be maximized when the food is cooked as soon as possible. When c < 2*r, the overall spoilage time will be maximized when the food is cooked as late as possible. This makes intuitive sense since you're returning half the missing spoilage, so the rate at which the food spoils when cooked should be half that of it's raw spoilage rate to even itself out. tl;dr The best time to cook food to maximize its overall spoilage time depends on the the cooked spoilage time and the raw spoilage time. When the cooked spoilage time is more than twice the raw spoilage time, cook it as soon as possible. When the cooked spoilage time is less than twice the raw spoilage time, cook it as late as possible. If the cooked spoilage time is equal to twice the raw spoilage time, it doesn't matter when you cook it. Here's a table of all the foods that have cooked spoilage times greater than or equal to twice their raw spoilage times.

This is definitely a bug. I've seen this with some mods before. local function on_deploy(inst, position, deployer) local new_trap_starfish = SpawnPrefab("trap_starfish") if new_trap_starfish ~= nil then -- Dropped and deployed starfish traps shouldn't spawn in a reset state (or they'll bite the deployer). new_trap_starfish.AnimState:PlayAnimation("trap_idle") new_trap_starfish.components.mine:Spring() new_trap_starfish.Transform:SetPosition(position:Get()) new_trap_starfish.SoundEmitter:PlaySound("dontstarve/common/plant") end end There are two separate prefabs for Anenemy Traps, one is "dug_trap_starfish" and the other is "trap_starfish". The dug version is the inventory item, and the normal version is when it's planted. Anenemy Traps have a "deployable" component to them. Whenever a prefab is deployed, it needs its coordinates to be specified. This is usually done by getting the deployer's coordinates. However, if you look at the code above, deploying a "dug_trap_starfish" spawns a "trap_starfish" when deployed. Going back to the "deployable" component, the "dug_trap_starfish" will attempt to deploy itself at some coordinate. Since there is no coordinate specified, it defaults to the coordinate (0, 0). A simple fix to this bug would be to add inst:Remove() to the code, which would delete the "dug_trap_starfish" when deployed (which is what we want since it becomes a "trap_starfish" anyway).

This is definitely a bug. I've seen this with some mods before. local function on_deploy(inst, position, deployer) local new_trap_starfish = SpawnPrefab("trap_starfish") if new_trap_starfish ~= nil then -- Dropped and deployed starfish traps shouldn't spawn in a reset state (or they'll bite the deployer). new_trap_starfish.AnimState:PlayAnimation("trap_idle") new_trap_starfish.components.mine:Spring() new_trap_starfish.Transform:SetPosition(position:Get()) new_trap_starfish.SoundEmitter:PlaySound("dontstarve/common/plant") end end There are two separate prefabs for Anenemy Traps, one is "dug_trap_starfish" and the other is "trap_starfish". The dug version is the inventory item, and the normal version is when it's planted. Anenemy Traps have a "deployable" component to them. Whenever a prefab is deployed, it needs its coordinates to be specified. This is usually done by getting the deployer's coordinates. However, if you look at the code above, deploying a "dug_trap_starfish" spawns a "trap_starfish" when deployed. Going back to the "deployable" component, the "dug_trap_starfish" will attempt to deploy itself at some coordinate. Since there is no coordinate specified, it defaults to the coordinate (0, 0). A simple fix to this bug would be to add inst:Remove() to the code, which would delete the "dug_trap_starfish" when deployed (which is what we want since it becomes a "trap_starfish" anyway).

THEY'RE EVOLVING

Klei changed some of the land/ocean detection in the RoT beta. The edges of the land don't count as valid ground, so players can use the /rescue command when hugging the edge to cross small gaps in the caves. This also has several other implications that deal with land and ocean detection such as mobs swimming along the edge.

I am speed I AM SPEED

Consider your bug fixed.

ya'll ever just...

Burning items in your inventory was a thing in DST way back in early access. Klei didn't remove it because it was OP, but because it was an insane griefing tool. Aside from the fact that you could light something in your inventory and burn everything around you (including other players), you could actually give a flaming object to another player and they would start taking fire damage. There is in fact a DPS cap to fire damage: 120 damage per second. Why would Klei cap fire damage so high when the only practical application of a 120dps cap would be for fire farms and other fire related exploits? I have no idea. IMO, fire damage is the most underrated and overpowered mechanic in the game. Any character can abuse fire damage to stunlock enemies, not just Willow with fire immunity or a player wearing Scalemail. You actually don't need any sort of fire immunity. One of the best examples is using fire damage against a Spider Queen so she literally can't move.

@watermelen671 @fimmatek I edited out the cursor on the roof if anyone wants to use the Willow rework wallpaper.

Honestly, I think too many people view sanity through a black and white lens. Low sanity should be bad. High sanity should be good. Being insane is too meta, we should punish players for being insane all the time. Shadowy monsters attack the player when they're insane? Let's add more shadowy monsters to attack the player to make their life more difficult! It's a bit of an oversimplification, but it's the gist of what I'm getting. While I agree the sanity mechanic is a bit mundane in its current state, it's not necessary to be adding more shadow creatures to the game. Many players claim that insanity is a good thing, as it allows you to farm nightmare fuel. But really, what you want is to have sanity manipulation; the ability to control your sanity and slip in and out of insanity thresholds at will. You wouldn't want to be insane while fighting a boss such as Bee Queen, as the shadow creatures would then become a distraction. You wouldn't want to be insane while fighting Fuelweaver, or you'll get mind controlled. That's why the nightmare amulet and bone helmet are such valuable items. They allow you to easily feign insanity, and just as easily slip out of it. Maxwell is also an excellent character for this reason. His passive sanity regen allows him to stay topped off, but he can choose to go insane whenever he wants with his sanity puppets' max sanity penalties. I think any new changes to how sanity works should put an emphasis on sanity manipulation. There should be incentives to being both sane and insane. We shouldn't want to avoid insanity because it punishes it us, rather, we should want to avoid insanity because we'll be missing out on the benefits of being sane, and vice versa. The sanity obelisks in the Atrium are a good simple example. You need to be able to become both sane and insane to pass through all the different sanity obelisks to loot the chests and reach Fuelweaver. There should be more world interaction with sanity other than just shadow creatures attacking you when you're insane. We could fiddle around with loot mechanics. Bunnymen could be a potential candidate. They could deal bonus damage to insane players (when they're in their Beardlord form; actually, Beardlords are stronger in DS, but not in DST, probably because of Bunnymen armies/farms), but have their Beardlord loot buffed, so players are incentivized to risk the danger of killing Beardlords for the potential loot. As a final remark, there shouldn't be anything that's unintuitive, annoying, or otherwise frustrating for the player to deal with such as randomly being paralyzed from paranoia, freezing from going insane, or not being able to see shadow creatures when you're insane in the middle of winter because they camouflage with the background and snow tiles, thus forcing you to install a client mod that disables the insanity filter.