MKMoose

Cob has a 15% chance to drop nothing when broken. If you're curious, the most useful blocks for quickly pillaring up are generally: hay, because it breaks very quickly by hand (several times faster than soil), regular soil or strewn straw for general purposes (or packed dirt if you're playing with soil instability, though it breaks a bit slower), cob, only if you need to quickly get a lot of blocks in the early game, but it gets annoying due to the material loss, ladders - regular ladders are preferable, crude can work because it currently only needs attachment at the base, but rope ladders will not do for this specific purpose - for when you need to go up and down a few times (and they also break very nicely from the base).

Fair warning - I'm not certain if all of the following is going to work properly. The villagers are currently designed specifically as Nadiyan villagers, and last I checked, they seemed like they just weren't doing anything when spawned in artificially. Currently they have two generic variants which you can either get from creative or spawn with a command, and a set of predefined gender-job-name combinations which can only be spawned through commands. The command for it is as follows: /entity spawn villager-nadiya-male-generic-generic 1 where the code can also be replaced with any of these variants: The special villagers are especially liable to not behave as expected and you might (if there are problems with them) have to use the following command while looking at them right after they spawn (could try pausing the game to ensure you have the time for it) to remove their special behavior - that is my best guess for how to potentially fix them, at least, though I can't really guarantee that it won't break something else: /entity cmd l[] rmbh activitydriven

I'm not personally aware of any mods which would specifically allow to make the lower of the two chiselled blocks receive snow - if there is one, I'm out of ideas for search terms. If you're open to a different solution, if a bit overkill, consider checking out the VS Roofing Mod. It completely overhauls roof building, and does fully support proper snow coverage as far as I can tell. That said, I'm not sure it will be able to adequately recreate your chiselled shapes - preferably try it in a new creative world to see if you like it before thinking about replacing the roof on your main world.

Then my apologies for failing to deliberately clarify that I'm not just replying to your suggestion. This is among the most common ideas in the community, so I'm broadly speaking about the concept and giving some background in regards to how I believe it should be done from a design perspective and why some commonly-suggested ideas wouldn't work too well. Those design considerations are almost entirely absent from the explicit contents of your post, even if they were a factor in its writing. It's a fine suggestion, but I think it could easily be a net negative for the game if implemented carelessly or without certain other changes prior to or alongside its introduction. Your suggestion doesn't have as much to criticize as some other suggestions that I've seen, but also doesn't include any changes that would aim to allow cooling with ice to fit the game better. And it doesn't need to, just to be clear - it's my preference when I'm talking about game design, but it's nowhere near necessary for more casual suggestions. The main difference between my thoughts on the topic and common suggestions seems to be that, to me, cooling with ice is above all else a method of increasing the game's variety and depth in gameplay, whereas increasing shelf life is essentially incidental. Your idea as you've presented it appears to focus primarily on the thematic and historical inspirations as well as on increasing shelf life of foods - which is a fine direction to take, naturally, but not quite what I was going for. What I try to achieve is more or less to give the player distinct means to manage varied gameplay problems or allow different food preservation methods to shine in their own unique niches. The primary high-level distinction here is between: maintaining low temperature through cellars optionally with the use of ice, mainly in short-term and local storage, maintaining low moisture through granaries and drying, primarily in long-term storage or travel food, though, naturally, there's a lot of middle ground and combinations between the two. Ice especially could be particularly effective for certain items, but actually harmful for some produce. What I think is also important here is the cycle of tension and relief when preserving freshly obtained food, which currently isn't significantly emphasized in VS, in large part precisely because of cellars which allow even fresh meat to stay that way for a whole 6 days and then freshly-made meals for ~2 months. You could say that my post is actually focused on setting up cellars and food preservation in general in such a way that your suggestion would have the best chances to shine. ''it would also add something for the player to do/look forward to in winter.'' ''to make your first spring fruits last juuuust a little longer'' Let me be more explicit, then: I would find a simple implementation of ice cooling almost entirely useless on standard settings, and not much better even on much more difficult settings, even if the ice is fairly cheap. A regular cellar on standard settings easily preserves every type of nutrition for at least for as long as is necessary to get more of it, assuming your food choices don't include strictly suboptimal options, and you'd need to at least roughly double all spoilage rates for that to become noticeably patchy. While ice for food preservation could be an interesting addition, I just don't see myself using it in the current balance if the game doesn't change more significantly. ''to keep the temperature slightly lower aand increase the shelflife of foods slightly.'' I'm saying that it should be specifically effective for freshly obtained food prior to processing, and especially recently-killed animals, but less impactful for already-processed foods and certain shelf-stable foods. Having exactly the same multiplicative effect on the shelf life of already shelf-stable foods is largely pointless, not to mention in some aspects unrealistic. This way, cellars and especially ice primarily take the role of short-term food preservation and allow more freedom and convenience in time management, instead of just being equally useful for all spoilable items in the game. ''and of course the ice would slowly melt so it wouldn't last all year long'' You've also mentioned icehouses, though, which were often used to preserve ice all year long. I'm not certain about the specific arrangement that would be ideal here - I don't think it's worth the hassle to specifically allow creating icehouses to then move ice into cellars. The main historical method seems to be to store ice in icehouses, then place the ice in or around containers when something needs to be cooled, so that is an option. Using it to cool the cellar with ice, closer to what you've described, seems like it was also done reasonably frequently and seems more practical in gameplay. Iceboxes proper are generally a 19th century thing, now that I've checked more precisely, so I probably wouldn't turn to those. Keep in mind that: A single player only needs a couple storage containers, a couple shelves, a couple barrels - you'd have to require an absurd number of ice blocks to make this not fit in the footprint of a standard cellar. Especially if the ice blocks can be placed on the floor, ceiling or walls, and I see no reason why they wouldn't. Even if a single cellar is not enough, making a second cellar is not difficult. Taking up space is a hassle more than it is a tradeoff.

Maltiez got hired well before this blew up, and has faced a range of consequences including the first half of what you deem a "normal response". His mods are also entirely safe to use and include some of the most useful libraries on the modding scene, so taking them away from the community just to make a point is far from necessary and would arguably be counterproductive. They will still probably just fall out of use over time in favor of forks or replacements unless an active maintainer takes over. Ergo, your "normal response" is essentially fulfilled, while minimizing the undesirable impact that outright removing the mods would inadvertently have on the community. Ah, yes, arguing about definitions. My favorite. Regardless of definitions, if you look at actual damages and risks, the "anti-cheat" was at the very low end of malware where definitions become debatable, and at roughly the same level as a software bug. No hardware damage, no data corrupted or extracted, no backdoor for malicious actors, no ransom - none of the standard risks of trojans or malware in general. If it was malware proper, there wouldn't even be any discussion about this. Which specific definition for malware you use when trying to make a point is virtually irrelevant for anything besides legal purposes, because its exact intent, design, functionality and flaws were known as soon as the public learned where to look for the code - they're buried somewhere with the horse, but they are there for you to find if you just dig around.

As much as the idea is interesting and could be quite historically accurate, I'm not confident that it wouldn't be a net negative for gameplay. I think it could work, and that's at the bottom of the post. Cellars are already an extremely cheap and effective method of food preservation. From a design perspective, they are really quite boring - they work all the time, entirely free besides a low initial setup cost, for every single spoilable item in the game. Fruit? Cellar. Vegetables? Cellar. Grains? Cellar. Meat? Cellar. Dairy? Cellar. Hides and raw fat? Cellar. If cellars weren't in the game, food preservation could be difficult. But as it is, cellars largely trivialize food preservation and arguably make some other methods thereof largely useless, at least on standard world configuration. Especially the already-weak preservation methods like alcohol, pickled vegetables or cheese, since they (1) apply a large satiety debuff, (2) have an additional cost to process, and (3) don't always actually meaningfully extend the spoilage timer relative to the base time or to how frequently new food can be acquired, so as a result are mostly delegated to vanity. Cellars also have a flaw - they can't move. If you stay in a stable home, you will often not have to worry about food spoilage at all, but otherwise you are at a massive disadvantage. This is just one of the factors which makes nomadic lifestyles a pain, because you just end up with ~4x shorter spoil times (potentially more or less depending on climate) for pretty much everything. Cellars are very nice thematically, but purely for gameplay purposes they tend to just be one thing on the checklist that has to be ticked off relatively quickly on every single world which then provides ubiquitous, universal benefits. How do iceboxes tie into this? In terms of effectiveness, they are largely just a better cellar, and they inherit most of the cellar's benefits and flaws. If cellars already trivialize food preservation, then iceboxes just add on to that. If you wanted to preserve some of your food further than a cellar allows and had to choose between other, potentially costly food preservation methods which may also apply satiety debuffs, which have to be done separately for every food in the game, or a single, universal buff which just extends the spoil time of anything you put in the cellar even further, what reason besides vanity or maybe travel food is there to ever choose the former? There are also two other matters: Does the ice melt? If it doesn't, then you're just adding on to the checklist of things that eventually need to be done on every single world. If it does, then it can easily become a tedious chore when not balanced properly. How much does it take to acquire the ice in the first place? If it's difficult, then you may just end up rendering iceboxes useless due to excessive upkeep costs for too little benefit over a regular cellar (keep in mind, regular cellars already allow you to store apples or similar fruit and most vegetables for over a year, and grains for several years - increasing it further just doesn't provide a meaningful benefit). I've seen suggestions to use glacier ice for this, but that is nearly objectively a bad idea simply because you don't want to make people search for mountains or go to cold climates just to get ice. If it's relatively simple, then you've just made the already-ubiquitous cellars even better, and you've made nomadic playstyles even more disadvantaged. How I would go about this The main motivation here is that iceboxes need to be an interesting and useful preservation method, but they shouldn't overshadow other methods or compete with them in the exact same gameplay space. I think the best way to do this is just to make cellars and iceboxes less ubiquitous and less universal: Make cellars and iceboxes most useful for extending short spoilage times for freshly-obtained items prior to processing, primarily for live animals, meat, and probably a couple other item categories. This makes them in part a matter of convenience by allowing to organize time better instead of having to process everything quickly before it spoils, but generally requires other preservation methods for long-term food security. Reduce the effect of cellars on foods preserved in other ways and on intrinsically dry foods, and on some other foods where refrigeration is not necessary to keep them shelf-stable. This especially applies to grains which would be more intuitive to store in a granary and not in a cellar, but could also apply more or less to salted, sugared, pickled, fermented or sealed foods. This would also allow to implement drying as an alternative to cellars, not a multiplier, and it introduces a natural distinction between "homestead food" and "travel food". Keep in mind that this is entirely based on real food preservation. Introduce a way to obtain ice blocks for iceboxes from lake ice using a saw. Ensure that obtaining ice is restricted seasonally to winter, and likely do not allow using dirty glacier ice in iceboxes because it's just not a fun gameplay incentive. This may require revising the current snow and ice system. Make the icebox ice melt within less than a year, so that it functions as wintertime preparation for hotter months, not an upgrade that stays over multiple years.

Open the macro editor with Ctrl + M. Setup the macro: Select any macro slot. Assign whatever macro name you want, e.g. "IMM on". Assign any keybind you deem appropriate. Enter the command .cf immersivemousemode 1 in the "Commands" box. Press "Save". Repeat the same setup for a second macro to disable IMM with the .cf immersivemousemode 0 command. Not an ideal solution, but it's the best I can find.

Trees which are generated using the tree generator (i.e. created on world generation, grown from saplings, or placed with World Edit) are considered "grown", and they can spawn cicadas. As a general rule, the only logs which can't spawn cicadas are those manually placed by the player. Your options in this case - if you want to stay in the same area and keep the trees, but remove cicadas from that specific area, besides custom modded solutions - currently include replacing the logs from natural trees with artificially placed logs one-by-one (easier to do in creative, but you can also do so in survival using a saw), or just removing the trees and building artificial ones from scratch (will generally require you to get leaf blocks from creative as they are unobtainable in survival).

There are three notable solutions to this, currently: You can disable cicadas globally with the .insectconfig cicada off command (this is just a client-side tweak, so other players will hear them just fine). You can remove the trees from an area to get rid of them from that specific area - they should only spawn on naturally grown logs (keep in mind that this seems to also include fruit trees). The cicada's sound range is 16 blocks, so you will have to clear a bit more than just the immediate proximity if you want them to not spawn anywhere near. If you want the trees to stay but cicadas to be gone, it is possible to replace the logs from natural trees with artificially placed logs one-by-one (easier to do in creative, but you can also do so in survival using a saw), or just remove the trees and build artificial ones from scratch (will generally require you to get leaf blocks from creative as they are unobtainable in survival). Additionally, keep in mind that cicadas only spawn within specific conditions: climate: roughly in temperate and warm climates (10-22 °C average yearly temperature), in areas with low to average rainfall (yearly rainfall less than or equal 0.5, which includes "very rare", "rare", "uncommon" and a bit of "common"), current weather: in warm weather (22-33 °C current temperature), while it's not raining (current rainfall less than or equal 0.1). Anything other than this would likely require modding. I think Accessibility Tweaks includes options for modifying the volume of every single sound in the game individually, but for something more specific you'd probably need a custom mod.

In the case of shattering during quenching, the relevant code in CollectibleBehaviorQuenchable.IsGettingCooled() at CollectibleBehaviorQuenchable.cs:178-202 has an immediate client-side return, so it's only processed on the server. Seems to me you're correct on that. Most of VS is server-authoritative, and any discrepancies on the client are typically overridden when the client receives updating packets. There are some cases where client-side data could be incorrect, e.g. when it is modified but not marked as dirty, but those don't tend to cause any major issues because any attempt at interacting with them will just be rejected by the server (or more specifically, for example where the client sees a ghost block, the server might be informed that the player is trying to interact with an air block which is obviously ineffective). Most if not all interactions are, as far as I can tell, sent to the server purely as interactions (with no data about the result thereof) and processed from there, so the server's trust that the interactions are legitimate may be what a significant portion of cheats would exploit. The client processes most things itself to reduce latency in normal gameplay, but updates from the server are authoritative should any discrepancies arise. That said, the above is just what I've learned or made an educated guess on when working on some PRs. I'm certainly not an expert on the technical details of the client-server relationship, and there are probably some ways to get around things - the devs wouldn't be fixing packet editing exploits if there weren't any.

As far as I can tell this could be also partially caused by an issue where the cooling delay is not reset while the heated item is maintained at the same temperature, if I recall correctly. I'm pretty sure that this currently isn't reported on GitHub, though I think I've seen it on Discord. I'm gonna double-check and report it when I have some time, maybe open a PR if I can find a good fix [reported in #10038, and the fix was literally just changing "<" to "<="]. This means that if you keep the copper at the same temperature for a while - more likely to reach the maximum temperature when using brown coal - and then take it off the heat, you're kind of rolling dice for how long it will stay at this temperature until is starts cooling down. You might get close to the correct time which gives a decent grace period to pour everything, or you might get a short time and see the temperature dropping nearly immediately. Finishing heating with a hotter fuel is a pretty nice way to counteract this. Besides that, the only practical remedy seems to just be keeping a close eye on the crucible and putting it back in the fire as soon as it can't be poured anymore. Or if you're doing something like heating iron blooms, try to make sure you're taking them off the heat and processing as soon as they reach the maximum temperature instead of keeping them there for a while.

Take a look at my post above, if you will. With ladders, it is not impressive. But using stairs instead of ladders allows to achieve travel speeds close to double that of the elk (more or less depending on terrain). Still not greatly practical for long-distance travel due to how much time it takes to set it up, but it can be very nice for regularly visiting nearby traders or other points of interest if you place an elevated platform near home - making a mountain base with this in mind could be especially nice. My experiments place the glider's travel speed in most circumstances at most at ~20 blocks per second, or ~1200 blocks per minute, and that's assuming you're using stairs and not ladders - roughly thrice as fast as running and twice as fast as riding an elk. If you're actually able to do more then I would love to know how. But this! This is what I call absolutely stellar game design. Simple, intuitive, and immersive. Genuinely an amazing use of birds. One thing I'd be careful about is that flying in circles could be disorienting and annoying, so having a way to stay circling in a thermal without having to constantly rotate the camera could be very useful. Makes me think of simulating wind, though, and that could increase the complexity of the task greatly.

Now, this is very nice. Various craftable masks would be quite fine. Ritualistic or ceremonial clothing could be really cool as well. But it is really not what comes to mind when you say this: This reads like modern accessories or kemonomimi, not historically-accurate decorations and pelts or whatnot. I would expect armor with animal hides or horns or antlers attached to be added at least in a small capacity with the armor rework in 1.23, provided the devs have time for it. Not sure if that will work without armor - would be pretty cool if the same decorations could be used by themselves in some capacity as well, but we'll see.

Tried it with all four listed versions of playerlists, none of them tripped. Maltiez has said that it's intended to target the specific obfuscator used by the cheat client, but if it does have 20.8% short type names so is clearly very close to tripping then I have no idea how to explain this. Do we consider it possible that Anego used a more robust way to detect obfuscated code instead of using the exact same checks, or possibly just reduced the threshold for some reason? Could also try checking some other stuff like PlayerListCrashFix or PlayerListOriginalName just to be sure, or just directly ask one of the devs. You've said this at least nine times now, and yet... I don't see why any healthy management should settle on termination as the only correct response. And especially not immediate termination prior to proper investigation. While several components of this situation, for example Malt's initial reaction to hostility over the undisclosed code, leave much to be desired, the loudest part of this whole thing can easily be boiled down to negligence. No need to even downplay anything - just interpret it as anything other than a simplistic "code shouldn't have been there => malware => fire Maltiez". The "anti-cheat" seems to have had, as far as we currently know, an exactly 0% false positive rate at the time that it was added. When one false positive came up, Maltiez apparently contacted the mod's developer and convinced them to deobfuscate their code. Reportedly in part due to health issues, Maltiez then failed to remove the code or otherwise address new false positives when they came up. I'm not sure about "playerlist", but URL Radio (YT) released ~1.5 months ago and Caves N Caverns released almost exactly one month ago, which is relatively recent considering that the code was up for almost a year. This seems like it could be justifiably seen as an honest mistake and not punishable misconduct. So then, the primary concerns would be: uploading undisclosed, risky code to ModDB => ban from ModDB, and monitor code contributions more carefully, public behavior after the code was discovered, and inadvertently causing a controversy => remove from Discord, presumed internal reprimand, failure on the part of Anego to verify Malt's "anti-cheat" => the blame on Maltiez is lessened, negligence concerns shift partially to Anego (and they've very clearly and very quickly admitted that not checking exactly what Maltiez was doing there was a mistake). Certain lines were crossed, that much is clear - if they weren't, there would (probably) be no consequences at all - but I frankly don't see why termination should be the correct course of action. It probably wouldn't be a mistake, as long as it's done within extents permissible by law, but it doesn't seem nearly necessary to me. For what I care and know, Anego have made a decision which lies well within the expected process and standard industry practices. I do have some concerns about Anego's public communication about the matter, but I personally see no reason to distrust their decision.

It's a 0.4% chance - on average 0.032 copper spearheads per block, or one per 31.25 blocks. Assume 70 blocks, it's 2.24 copper spearheads on average, and an ~10.6% chance for getting none at all. Low but not terribly low as far as chances go.