MKMoose

I'm still seeing the same OpenGL error in client-main.log - OpenGL is supposed to be deprecated on Mac, so maybe it's got something to do with that, although I thought it should still work here. Not sure if that's the actual cause of the crashes, but I can't find anything suspicious in the other logs, and without a proper crash log (which is apparently caused by some issue in the actual crash reporter) it's mostly shooting in the dark - it could also be something with your mouse, with your screen resolution, or a host of other things. Unfortunately, I don't think I'm familiar enough with Mac to do much more other than direct you to a seemingly related GitHub issue which mentions some of this, and a Discord thread which has at least two different builds of the game that maybe won't crash.

Aside from "because lore that hasn't been explained yet" [...] One thing that really frustrates me about the lore side of it is that, sure, there is technically a vague suggestion that there might be something that makes animals agitated which the Seraph isn't aware of, but at the same time their behavior is completely unaffected by temporal stability, storms and any of the related mechanics (not even by realistic weather, for that matter). This can make it seem like the lore explanation actually has nothing to do with the most important established lore and instead references something else, which could be basically anything that we know nothing about. I could see the vague one-sentence suggestion as remotely acceptable if it had any mechanical reinforcement. And that's not even mentioning how unlikely the average player is to find that lore in the first place, so as it stands the player has practically no reason to believe that the animals aren't just aggressive like that in the wild for no reason. Wolves and bears become saturated for some time after killing a target, including the player, making them stop seeking entities for a short amount of time (though they will still attack when the player comes too close, and they will chase when attacked). In many cases, though, whether the animal is aggressive or not matters less once the player has already died, especially if it happens to be just one of multiple wolves. And this still changes little about their typical behavior in the wild - finding a saturated animal is certainly not common enough to make me risk walking up to one to find out unless I'm specifically looking to kill it. I would personally be rather cautious about the benefits that status effects can bring to the game, because it can be pretty difficult to integrate them into an existing ecosystem - I wouldn't personally expect status effects to be anything more than a way of reimplementing and standardizing existing effects like hunger, freezing, alcohol or poisoning for at least one or two major updates. But that said, I couldn't agree more with the general idea.

Partially based on what Tyron has said in the June 2026 dev update, I would expect that we will only see these features in 1.23. Red Ram has also said that "container shapes and textures have been hugely revised and upgraded already for 1.23" (here on GitHub). I was unable to find any prereleases for minor versions, but release candidates have very much been a thing, even as recently as v1.21.6-rc.1. Version 1.21 overall had 6 RC releases over the course of 1.21.X.

I've looked at it, and it turns out that the tooltip for the duration bonus is misleading. It has to be treated as a multiplier and not a bonus (which is what it is under the hood, e.g. 150% duration multiplier rather than +150% bonus), or you can just subtract 100% from the value in the tooltip to get the actual bonus (e.g. +50% bonus when the tooltip says +150%). The baseline duration is two in-game hours. There is also one type of fuel that I'm gonna mention which has the temperature and duration properties for fuel in a forge, but doesn't meet the condition that allows it to actually be used there currently, and that is contaminated coal (found in high quantities in the refinery). Barring those caveats, it goes as follows: contaminated coal - 1.4 h duration, 500 °C - if it was actually usable, it could be used for tin and bismuth bronze even without bellows; also sufficient for forging brass, silver, molybdochalkos and of course all low melting point metals like bismuth, lignite - 2.4 h duration, 600 °C - suitable for copper and all types of bronze without bellows; can reach the tempering range without bellows; also sufficient for forging gold, electrum and cupronickel, bituminous coal - 3.0 h duration, 700 °C - highest temperature safe for tempering, i.e. an item left in the forge will not exceed maximum tempering temperature, anthracite - 4.0 h duration, 700 °C - honestly quite disappointing, anthracite is much rarer than black coal and has double its duration in the firepit, charcoal - 2.0 h duration, 750 °C - the first fuel which can handle iron without bellows (although it's not sufficient for welding an iron anvil), coke - 2.0 h duration, 800 °C - the highest temperature, but still doesn't allow quenching without bellows (probably a good design decision, but it certainly devalues coke). And keep in mind that all types of fuel (even contaminated coal, if it was usable) can actually reach the quenching temperature (albeit for contaminated coal it requires to use bellows a lot), so frankly I don't see much purpose for coke in vanilla forging. If you're curious, if only for the sake of your Improved Quenching mod, brown coal reaches at most 985.7 °C with bellows, whereas black coal and anthracite reach 1150 °C. The general formula is MaxTemperature * 1150 / 700.

The only significant use for it in the game is smelting pentlandite, most notably smelting it into cupronickel, which is otherwise unobtainable without coke and is necessary for Jonas tech. Besides that, coke is currently mostly useless. On a side note, realistically, one of the main drivers of coke use in metallurgy was that heavy labor and rapid deforestation involved with producing charcoal made it actually less practical and economical than coke in many regions. Coke also burns hotter than charcoal, which had significant impact on the development of more advanced blast furnaces in Europe. The main problem of coke in the game is that it only has one major use and for everything else it's just horribly inefficient, so if the required temperature threshold can be reached with other fuels, then it is virtually always better to use those other fuels and not coke. The exact numbers are very inconsistent and differ depending on whether you're using them in a firepit, forge or as block fuel in a cementation furnace or beehive kiln. I'd have to double-check the forge as that has changed in 1.22, but take the firepit: brown coal - 1100 °C, 77 s - can be converted into coke at a 2:1 ratio, black coal - 1200 °C, 84 s - can be converted into coke at a 4:3 ratio, coke - 1340 °C, 40 s - effectively 3.85x lower duration than brown coal and 2.8x lower duration than black coal - higher temperature really doesn't make up for this in most cases. The cementation furnace and beehive kiln are actually even more questionable, because there is virtually no difference between a coke block and any other coal block when used as fuel for them, so converting coal to coke before use ends up strictly net negative with absolutely zero benefit.

[Error] GLFW Exception: ErrorCode:VersionUnavailable Requested OpenGL version 4.3, got version 4.1 See if updating OpenGL fixes it. If that doesn't fix it, then it may be helpful to see other logs, especially the actual crash report (should also be in client-crash.log), and ideally also client-debug.log, server-main.log and server-debug.log as those are most likely to contain relevant information.

You can use bellows to raise the temperature of the forge above the default maximum for a given fuel type. Coke has the highest maximum of all fuel types at 800 °C (700 °C is the baseline, and you can see the bonus in the tooltip). Both of them are viable to make an iron anvil which requires at least 800 °C, although bellows will generally be easier to make and more broadly useful than coke.

ProspectTogether's chunk display is misleading (and has a few other known issues). Neither the ore generation mechanism nor the vanilla prospecting mechanics are meaningfully affected by chunks from the player's perspective, and they can be generally considered to change continuously throughout the world with no chunk boundaries. Only the node reading can tell you exactly whether there are any ores within a given range from the reading, but it just has a 6-block range by default (i.e. it tells you how many ore blocks are within a 13x13x13 cube centered around the reading). When the prospecting pick returns you a density reading, the result is roughly proportional to the chance at that location that the world generator uses to spawn a deposit. Even an "ultra rich" reading is not a guarantee that you will find a deposit under it (for some common ores like copper or sphalerite it is fairly close to being a guarantee, but even then you shouldn't strictly treat it as such). The permille (‰) number next to the descriptor is just a mathematical estimation which roughly tells you "if you dig out a huge area, it will on average have roughly this many ore blocks of this type as a permille of total rock blocks where the deposits can spawn" (e.g. 2‰ means 2 ore blocks per 1000 rock blocks). It's not even accurate, though, and has a couple bugs. The standard advice tends to just be "ignore the permille value". The qualitative descriptor (e.g. "very poor", "poor", "decent"...) is also not fully reliable, as some ores (borax among them) can never reach readings above a certain threshold, but it is entirely sufficient. For borax specifically, even "poor" tends to be more than enough to find a few deposits. The "minuscule" reading is not sufficient for almost anything. For most ores, it indicates a roughly ~0.2-5% of maximum possible density. There are some tricks that you can use for certain deposits which allow you to say that "if the reading for this deposit is at least this much, it means that there is almost certainly at least one deposit within the chunk", but it is not something that most players will ever find notably useful. You can also find some loose ore bits on the surface for some ores, indicating a deposit under them, which for borax can sometimes be a better way to find a deposit than prospecting. Two additional notes regarding the prospecting strategy, if you will: Sinking a shaft every 12 blocks is generally unnecessarily dense. Since deposits tend to have a couple blocks radius, you can detect most of them if you dig shafts every ~20-25 blocks, allowing you to cover a much greater area within a fraction of the time. Taking density readings closer than every ~100 blocks is usually unnecessary. The ore maps are fairly smooth, and it's rare to find hotspots that are so small as to squeeze in 100-block gaps. It is also unnecessary to search for the exact highest reading in a small area. Slightly denser can be fine in some cases, but taking a reading in every chunk is just more work for little to no benefit. The prospecting guide in the in-game handbook can tell you some of this information. If you're interested, there is a fairly decent prospecting guide and ore deposit table on the wiki. They are not in any way necessary to get a solid grasp of the mechanics, but they might help you out if you're running into issues.

While the idea certainly makes sense and could be interesting, I think it would have to be limited to a very small, carefully designed selection of items, and it might also make sense to make a quest with a trader into the only way to obtain these items (a bit like the the glider or the rickety translocator which can only be obtained for progressing the story). The point of having trader-exclusive items is to encourage interaction with the traders and create sinks for rusty gears, so giving players the ability to just learn the recipes and no longer rely on traders kind of defeats the whole purpose. The rusty gear sinks created by trader-exclusive can be a pretty important factor which improves the stability of multiplayer economies, so I would be doubly careful about letting players learn the recipes for them. I feel like this would be much better solved by just improving the traders in other ways. For example, imagine if you could: buy items from a long-term stock kept by the trader instead of a narrow rotating pool, interact with a simulated supply-and-demand system, where the available quantity and price of items changes dynamically based on factors like the current season, and is also affected by items that players buy and sell, build a cordial relationship with a trader by trading a few times and helping out with some specific requests, explore the world and talk with traders or pass maps around to connect suppliers with craftsmen, help a trader restore their workshop through some kind of quests, place a large order on specific items for a low price once you've helped out the trader, possibly also on the condition that you deliver some tools or resources that the trader needs to make it happen. Some related topics were discussed in this thread, if you're curious:

Gameplay-wise, frankly, I don't see much purpose. If you look at the current storage options assuming that you have a cellar: If you get your hands on apples, pears or breadfruit, they can sit in a cellar well over a year (orange, mango, lychee and pomegranate also stay fresh for over half a year). Even if all you have is common berries, you can make them into: pies, which will last over four months, or porridge, which will stay fresh for two months normally, or well over a year in a sealed crock. If you also have honey, jam lasts close to two years normally in a cellar, or virtually indefinitely (~15 years) in a sealed crock. Juicing and alcohol can be used to massively extend shelf life as well (and for cherry and lychee, juice is also the highest satiety per fruit return). The only situation on default settings where fruit preservation is not already quite easy is when you don't have access to a cellar, but that will almost always only last a short amount of time within which it's easy to keep fruit fresh without a cellar or supplement the diet with wild fruit. Of course, purely for the sake of variety and roleplaying and whatnot, or for the sake of high-difficulty playthroughs, it would be a perfectly fine addition. But balance-wise on standard settings, meh. Personally, I've never even made jam, because it never seemed particularly useful for anything. Sure, it lasts a long time and it has very good satiety compared to raw fruit, but it's inefficient to store and carry, and it also requires honey which is almost entirely down to luck in the early to mid game. Alcohol, which also lasts a long time, is not particularly useful for very similar reasons, even if you gloss over the huge 60% satiety loss compared to juice and even more compared to fruit used in meals or porridge - it's very inconvenient in storage and travel, and it also can take a very long time to make. Five buckets of alcohol worth 4000 satiety can be pretty nice compared to a bowl with a meal (which rarely even exceeds 1500 satiety) if you're fine juggling all those buckets, but all options are ultimately blown out of the water by the pie, easily capable of fitting 32x 480 satiety in a single slot even once sliced, or four times as much if not sliced. Having a simple and cheap way to preserve fruit with no other resource requirements would make jam and alcohol even worse, and as long as you have a large enough farm, satiety loss wouldn't matter too much anyways. And again, while it likely wouldn't be a functionally meaningful addition, it's certainly not something I would mind, especially for variety or roleplaying and so on, or for high-difficulty playthroughs. I feel like making dried fruit into a dedicated "travel food" could also make a lot of sense, to give it a new kind of niche, though I'm not really sure how it could be balanced - it could require to make their spoilage time unaffected by temperature and cellars by extension, or less affected at least.

Well, color me interested. Overall I quite like the direction, and I have a few quick notes and suggestions. On the design: It may be better to be able to override the effects of the previous treatment instead of being permanently locked out of further heat treatments after the first one. As already mentioned by another person on the ModDB, realistically, tempering should always be done after quenching - realism is not the be-all end-all here, of course, so I'd be quite fine with it staying as-is, though it is something you may or may not want to consider. Although, it's worth noting that quenching-only as you've done has the advantage of being a simple, no-strings-attached process, whereas my original suggestion of repeated tempering after quenching runs the risk of being a bit tedious or unintuitive. It would likely be beneficial to remove or adjust all parts of the tooltip which are no longer relevant after a heat treatment, and especially "times quenched" and "times tempered". On balance: Having zero shatter chance on both the low and middle temperature bracket seems rather odd to me - given that both temperature brackets require bellows anyways and can be reached with any fuel, there is very little difference in the setup and cost between these two tiers. A whole +50% power is a huge buff, especially with what seems like just 20% shatter chance (the tooltip showed 40% post factum, I'd have to double-check to be sure what's up with that). If that's the intent, then by all means, but if you care about remaining roughly faithful to vanilla (which I personally think is already somewhat out of whack) then ~30-40% would likely be the maximum that can be reasonably given even on the high bracket in its current balance, unless it's made more difficult or costly. For context, in the vanilla balance, assuming repeated quenching with no tempering and no other shenanigans (there's a way to achieve a slightly better result on low quenching counts with a temper, but the difference will be fairly minimal either way): quenching 8 times for a very high ~51% buff (very close to the high bracket) has a total shatter chance of ~88% (on average ~8 items for one survival), quenching 6 times for a more reasonable ~42% buff still has a total shatter chance of ~69% (on average ~3 items for one survival), quenching 3 times for a decent ~25% buff (almost equal to the middle bracket) has a total shatter chance of ~27% (on average ~1.4 items for one survival). Simiilarly, a 40% buff for tempering is pretty huge - if I recall correctly, the maximum obtainable effective durability buff in vanilla if you multiply by survival chance, assuming no exploits or whatnot, is just ~17% (after quenching > tempering > quenching), so even keeping the modded tempering effect at 20% would still be quite significantly better. Again, of course, if that's the intent then I don't mind, but if you intend to stay somewhat close to the vanilla balance then it may warrant some adjustments.

Do note that there seems to be a bug with one of travertine's generators (#9784) which would allow it to generate in small quantities in slate and phyllite if fixed, and some travertine blocks are possibly missing (#9430). Barring that, travertine indeed spawns in a way very similar to marble, currently only in limestone at any height, and it's also very rare - it's less common than marble in isolation, albeit I'd have to check how common limestone itself is compared to slate and phyllite. I can only wish you luck, because you're gonna need a lot of it, especially if you have a large travertine build in the plans.

Jumped into creative for a quick test. Values given are average, and they may get thrown off slightly when you operate on non-integer total rot quantities, as the stacks will get rounded randomly. 1x red meat => 1 L rot, 1x red meat stew (2x red meat ~ 2 L rot) => 2 L rot, 1x hearty red meat stew (3x red meat ~ 3 L rot) => 3 L rot, 1x hefty red meat stew (4x red meat ~ 4 L rot) => 4 L rot, 1x turnip => 0.5 L rot, 1x turnip stew (2x turnip ~ 1 L rot) => 1 L rot, 1x hearty turnip stew (3x turnip ~ 1.5 L rot) => 1.5 L rot, 1x hefty turnip stew (4x turnip ~ 2 L rot) => 2 L rot. The answer as far as I know is that the meal under the hood actually contains the original ingredients, just packaged into a single stack and given some new properties, so the output rot once the meal spoils is produced from those underlying ingredients.

I've reproduced and reported it in #9774.

Four sets have disappeared, as in the same has happened on four separate occasions? That would be fairly consistent. The game doesn't track regular entities in logs, so it's difficult to say much of anything with certainty. If you want to verify that the sheep are actually despawned, you can try using the /entity find e[type=sheep-mouflon*] command to get the positions of all mouflon sheep within rendered chunks, which will also tell you if it finds any dead sheep. Optionally /entity find e[type=sheep-mouflon*,range=N], where N is the search radius in chunks, if you want to limit the seach to a shorter range. It will not be reliable if some time has already passed after the sheep have gone missing or if you have a lot of wild sheep around. As far as I remember, even open-air pens need light to prevent despawning (especially if you're playing with a longer day cycle, since the despawn behavior is concerned with real time passage). But if the issue has occured in the new well-lit (should be light level 8+) pen as well, then I don't think I'm able to explain it as anything other than a potential bug without some additional information which can probably only be obtained through some proper debugging. Having looked into it further, I've found that this is actually not the case. Animals should only despawn when underground or in other unlit, enclosed spaces, so they shouldn't despawn in an open-air pen. I've done a bit of debugging, found a different issue, but failed to reproduce this problem. If it's not mod interference or some other bug, then I have no idea what could be causing this (may be worthwhile to know the exact mods you're using and your game version at that point, though I'm not sur there's a good way to test mod interference quickly enough).

This was reported frequently in earlier versions of the game, but is it still true? I don't know when that may have changed, but currently all fences have the canStep: false attribute, which should make it impossible for animals to get out of a pen in virtually all scenarios, even if the fence is inset into the ground and there are three layers of snow (except maybe fences with shorter hitboxes which you probably shouldn't inset into the ground, but regular fence placement still works normally). What can get over fences is jumping players, possibly leaping entities (i.e. wolves, bears and locusts, maybe shivers in some way?), and maybe animals could also be pushed out in some cases of entity cramming.

The funny thing is that you can actually pick them back up after planting (which also results in #8848) as long as they are still cuttings and haven't grown into the young state, and doing so also resets the spoilage timer. And if you're absent for long enough that the cuttings end up growing into bushes, then you can just take new cuttings from them. If consistency is the issue, then fruiting bush cuttings being perishable is clearly the odd one out. Crop seeds, tree seeds and saplings, fruit tree cuttings, as well as cattail, papyrus and tule roots, are all non-perishable. Virtually all plant matter in the game besides food has always been non-perishable, actually, right up until fuiting bush cuttings and plant debris have been added. I wouldn't necessarily mind a shift in design philosophy here, as long as implementation is actually decent and not plagued by problems like the fruiting bushes, but consistency is not what such a shift would be driven by. I think that many people in a context like this tend to focus on the wrong things. If the only reason to make plant matter perishable is that it's realistically perishable, then you're making a simulation instead of a game in the best case scenario. From a gameplay perspective, "because it makes sense" is not a sufficient explanation - the best you've given is that it would prevent long-distance relocation of plants, but I personally don't see why that even matters. As long as plants aren't restricted by the climate conditions that they can grow in (which currently is largely the case), this just makes transfer more tedious and time-consuming instead of actually preventing it, whereas if they are restricted by climate conditions, then long-distance relocation doesn't even really matter. And also, that spoilage timer would have to be very short - fruiting bush cuttings currently have 15 days, which is easily enough to go at least from the tropics to the temperate climate on default settings. If I were to design actual reasons for making plant matter perishable, I would focus on three primary aspects: Incentivizing storage options. For example, pasture and meadows which can provide grass, hay, or other fodder which can feed animals, as well as thatch and potentially some other materials, but are only available in the summer unless the player prepares appropriate storage. A lot of plant matter, quite notably wood as well, could be effectively non-perishable only when stored in a sufficiently dry place. Preventing eternal storage and reducing hoarding. It makes the game less stressful, but it also trivializes some things. For example, making sticks and wood perishable (not necessarily turning to rot, but becoming unusable or at least less useful for most purposes like mechanical parts or charcoal) would place more importance on securing local wood sources and deliberately gathering as much as needed when it is needed, instead of hoarding huge amounts of materials in case they might be useful at some point in the far future. Making seeds and cutting perishable falls under this category, but keep in mind that making them fully perishable would probably not be a good idea in several cases (primarily in the case of crop seeds) unless they are made fully renewable as well and certain exploits are prevented. Partial spoilage or reduced quality are also an option. Driving a more developed composting system. I don't see much reason to make things perishable as long as it is as inconvenient as it currently is, forcing the player to wait for items which are already effectively worthless but haven't yet turned to rot - ideally, perishable items should be out of sight the moment they are no longer useful for their primary purpose, and rotten items could potentially have some special uses in their own right. Creating a proper composting system would allow more convenient waste disposal as a much more interesting and immersive source of compost, as well as possibly some other items including earthworms for fishing bait (and as feed for some animals like chickens, hopefully). Do note that making plant spoilage into a difficulty option would make a lot of sense as well.

There's something like six of them. I've figured out that the reason I haven't been able to generate them is actually some kind of bug that I haven't managed to track down yet, whereas random generation does sometimes occur but I've apparently just had putrid luck or forgot that I've found any. It is arguably a bit misleading when you look at "10+ schematics" but a single schematic can actually just be a pile of cobblestone and not anything resembling a building, so there's a chance that I've found the "cities" a few times and just didn't realize it. Regardless, though, the broad point is that actually interesting ruins are rare, while the typical ruins (at least the surface ones) tend to have at best a couple cracked vessels and some bony soil, maybe a collapsed chest with a few low-value items if you're lucky. They are not in any way reserved for story locations if you simply interpret the word "unique" as anything other than "one of a kind". What I mean by making tiled dungeons "unique" is just to give them any kind of special characteristics that make each type of dungeon interesting in its own right to find, explore and potentially return to. This can be done in many different ways: different one-time rewards tied specifically to one type of dungeon each, for example: lore discovery (especially relevant if we ever get any laboratory-adjacent dungeons), item schematics or recipe unlocks (for the refinery, unlocking a schematic for a blast furnace would make quite a lot of sense, although in this case it could also be a bit too restrictive for how progression-critical it may end up being), possibly something like preserved seeds for plants that haven't survived on the surface, resources or other benefits exclusive to dungeons which can be obtained in limited quantity from each, but obtaining duplicates could still be equally valuable: exclusive Jonas parts or some kind of high-quality tools and components like watches or navigation tools (either new items, or just existing parts taken out of regular loot pools and exclusively placed in dungeons), special clothing, accessories, decorations, rare resources like gemstones, and so on - not something that will let the player skip progression, but also not just generic stuff obtainable quickly through regular survival gameplay, various kinds of clutter and artifacts which have to be restored before they can be used or sold (including items from the above two categories), repeatable challenges on each visit to a dungeon (with some limits, of course): gears, Jonas parts or other loot from some kind of respawning enemies or a mini-boss, loot which resets during every temporal storm (potentially can only be collected during a storm, or otherwise resets any puzzles, traps, enemies etc. as well, to serve as something like an actual challenge and not a biweekly fetch quest), possibly a combination of the two above, i.e. a high-value boss which spawns in the dungeon once during each temporal storm (and disappears when the storm ends), though it could be difficult to implement, it could be interesting to completely re-randomize the dungeon layout under some conditions, potentially also during storms (though it would likely require a large land claim) the dungeon could also rotate between a few variants, so that changes in the structure are not removed permanently, blocks or multiblocks which can be repaired and used but likely cannot be moved: special Jonas devices or other advanced tech fit the bill very naturally, and Jonas devices can be given nearly arbitrary gameplay functions to fit many different design goals, the blast furnace would make a lot of sense in the refinery (and again, could also be deemed a bit too restrictive if it's strictly exclusive to the dungeon - if it's just cheaper to repair than to build anew, then that's fine, but also not as meaningful in gameplay). Note that not all dungeons of the same type have to do the same thing, and some functions can be dependent on subsections of a dungeon which may or may not generate. Some restrictions would be useful to keep things more defined and not just random with no rhyme or reason, but there's a lot of freedom to give each dungeon its own twist. And as I've mentioned: all of the above can also be done perfectly fine with regular, one-piece structures, and tiled dungeons have never been a prerequisite to any of this, which is why I've always been skeptical of the benefits that the tiled dungeons could actually bring. Some ideas like lore and decorations exclusive to specific structures have even already been in the game for a long time in some capacity.

The main, overarching design issue that I think the dungeons have is that they just don't have a unique purpose, which easily makes them feel like a nothing burger. We've already had a lot of structures, including some rare, procedurally generated ruins with (sometimes) valuable loot [1]. The tiled dungeons' reason to exist seems to be simply that they are procedurally generated - and even that doesn't actually change all that much in the one dungeon we got, because while the details might be a bit more varied, the overall layout and contents always end up pretty samey. But actually unique reasons for adding the dungeons? Seemingly absent. The potential is there, but as it stands, the dungeons' value lies almost exclusively in easily accessible loot (which could easily be added with non-procedural dungeons as well), and we don't even know if there are any real plans to do anything more with them other than "ruins but procedural". The tiled dungeons don't really serve any purpose that couldn't be easily fulfilled by regular structures. I do hope that these dungeons will eventually be properly unique and not just a gimmick. Traps and enemies are kinda neat, but we can already do that with regular, non-procedural dungeons, whereas coming up with things that procedural dungeons are uniquely well-suited for can be somewhat tricky. Having some unique NPC encounters or story quests would be cool, but there's also nothing that restricts these to procedural dungeons, and in fact it might be easier to do in a robust way using regular structures. One of the main things that I would like to eventually see are sprawling tunnel and mine networks, and the tiled dungeon system is actually (probably) significantly better suited for it than the village system used for overground ruin clusters. [1] This has sent me on a chase to find some of the rare vanilla ruins, and I've found that a lot of them just... don't generate. They can technically generate, but the requirements are so hilariously narrow that the chance for it to happen ends up being virtually zero. Did you know that the game sometimes generates city ruins with 10+ buildings including a large cathedral? I didn't, because I've never seen them, neither in my own gameplay nor on the internet. I wasn't even able to manually get the game to generate one to take a screenshot. And the funny thing is, Better Ruins actually seems to have fixed the problem that makes these structures so rare, or at least they fixed it for their own structures.

What I mean is that having this AI/low-effort content reporting system doesn't fully take away the responsibility of the moderators to make decisions on what actually counts as AI/low-effort, which was given by Tyron as one of the reasons for this system to be chosen. Apart from obvious cases like when an account gets banned and its reports can be reverted, any decision to leave things as they are or revert unjustified reports may be about as contentious as deciding whether to let a mod be, flag it as AI or remove it from the database. The main reason why I tend to prefer something like a like/dislike system, besides simply that it allows people to clearly support and appreciate good mods rather than just report bad ones, is that it allows to set a visibility threshold as the ratio between positive and negative reactions rather than some arbitrary number. How do you determine the appropriate number of reports which make a mod count as AI/low-effort? A small mod may struggle to get enough reports to get hidden despite being completely AI-made and of poor quality, whereas a large, popular mod could easily hit the same threshold even if it actually has no AI involvement - there needs to be some way to scale that threshold based on mod popularity. Having a ratio between positive and negative reactions largely solves that problem.

I somewhat worry that lack of an authoritative definition still leaves that definition up in the air for people to decide. There will inevitably be false or malicious reports which might unfairly cause mods to be hidden for people which set a low threshold (potentially especially dangerous for large mods which might attract negative attention), as well as honest reports which create pushback either way, and those cases would also take time to resolve and may require moderators to make the potentially contentious decision on whether to revert unjustified reports (and most of the time the answer will probably be to keep things as they are, except when an account gets banned). At risk of repeating what some other people might have already mentioned, I will also note three things, mainly because it kind of feels like the system might be needlessly trying to reinvent the wheel: I think it seems counterintuitive to give people the ability to effectively "downvote" AI/low-effort content - a broadly antagonistic interaction - but not "upvote" high-quality content. There is technically the possibility to follow mods, which kind of does the job to an extent, but I feel like this whole new reporting functionality could also be easily implemented as a simple like/dislike or reaction system. It is somewhat odd to introduce the ability to report AI/low-effort content but not have broader reporting functionality integrated into the website (not that I can find anyways, and I feel it should have been part of the ModDB a while ago). It is a natural way to report malware, offensive content etc. (which is thankfully rare) and it concentrates the effort of moderators by allowing to react to clusters of reports instead of having to carefully scan all mods that come onto the site or get updated. An AI/low-effort report category could fit right in, and the combined number of all reports could still be used for some kind of filtering. It seems to me that if a user reports a mod, it would be worthwhile to hide that mod from the user regardless of any threshold that they've set, mainly because the frustration of still seeing a mod that they've reported would likely drive more negativity and increase risk of mass-reporting. Keep in mind that a dedicated "hide this mod" button or "hide mods from this author" button would do the same functionality about as well. I'd imagine that it's probably obvious enough that it's been considered at the very least, but I find it worth mentioning given that I haven't caught any mention of it by any of the devs. Ultimately a system like this is certainly not easy to build in a fully satisfactory way regardless of the exact method, but it will probably end up fine. At the very least, it will be better to have something once it rolls out, and then we'll see if it actually does what the community has been asking for, rather than to have nothing at all.

In case anyone finds this but is struggling to make the translocator work, I've found the root cause of the issue (#6137). In order for the workaround that involves teleporting to the story location to actually work consistently and not just sometimes, any one player on the server needs to, at least once at any point during that session, place or destroy a rickety translocator. This sets the needsSaving bool to true, which allows the translocator's position to be saved correctly.

I kind of agree with the idea, but also disagree with the premise. Why gamify things when it is entirely possible to lean into realism where it makes sense to make the mechanics more engaging? Even weak points similar to what you've described could be impemented without any sort of gamified feel - not necessarily quantitatively realistic, but entirely inspired by reality in the qualitative sense of "rocks are not completely uniform and can be broken more easily when leveraging cracks and discontinuities". Fishing is arguably the best example here, as described adequately by @Rainbow Fresh. In its current implementation, it's basically a "click to materialize a fish" system, and it is entirely possible to add plenty of depth to it through reasonably realistic reeling while scaling down an excess of realistic waiting. Even the waiting part could be made more interesting by letting the player watch the fish under the water purly for visual interest and move or jerk the bobber to get the fish to bite faster in warm water. While implementing something of the sort for all stone blocks could potentially be a bit much, I think it would be quite fine to do it for ore blocks and cracked stone, and potentially even give the player a bit more ore as a reward for more careful mining. Large-scale faults of sorts as an extension of the cracked stone deposits could also be an option, so that most areas wouldn't have the mechanic but sometimes a large strip or layer of blocks (potentially containing ore veins) would have frequent cracks that could make it a more viable location for a mine. And the easiest way to remove the problem of having to quickly figure out where the crack is while mining the block would probably be to pre-generate the weak spots. As long as it's not applied to all stone blocks and instead just a small portion (e.g. ore and cracked stone, as mentioned), then the performance impact would remain very minimal. Trees physically falling over is a huge can of worms for a game like VS, and I personally would say that it goes a bit far. Salty's been playing with this kind of features a fair bit, though, most notably in the Falling Trees mod. More interesting wood processing would absolutely be amazing, though. What TOBG's archaeology wishes it was... Applying something similar to ores or at least gemstones seems like it could work very well in VS. While I don't know what the devs might think of this kind of mechanics, I think having simple "minigames" (technically something like embedded contextual minigames) tied to certain medical procedures, even something as simple as rotating a strip of bandage around a limb, could work really well without an excess of gore. There is a small game called Casualties: Unknown, though fairly distant from VS in theming, which implemented something of this sort in a pretty neat way: 2026-06-22-09-52-23.mp4 Applying dressing in the Casualties: Unknown tutorial. Similar types of minigames in different contexts can be found, for example, in many RPG's lockpicking mechanics, or in games like Among Us as part of tasks. Barotrauma's and Project Zomboid's medical systems are somewhat similar to that of Casualties Unknown with a large variety of afflictions and treatments, although without that kind of minigames. Games like Green Hell have also had some relatively interesting aspects of their healing mechanics, which can be somewhat graphic with realistic visuals but should be fine when translated into the pixelated textures of VS and abstracted away somewhat. Naturally, implementing something of this kind into VS would bring a whole host of questions, challenges and possible problems, but I think it could be a good direction to go into with healing that doesn't involve particularly much gore and at the same time adds a lot of depth and hands-on interaction.

Nope. Some mods allow that. There is no answer that I know of. Personally, I would say that the nerf on mortar is perfectly fine in isolation (you still need just 1/8 lime and 1/16 sand for one block of bricks, or double that for refractory bricks, which isn't all that much), but the firepit mechanics is what needs to change. An item heating overhaul has been on the horizon for a some time like a mirage. A dedicated lime kiln would be very cool too.

When I say "unfinished", I very much mean that some things were shipped in a barebones or buggy state, not just that some features didn't make it in or were explicitly labeled as proof-of-concept. There's a few things that just cannot reasonably qualify as finished features, fishing most notably. I can understand the more aspirational features getting pushed back, but I do not know why things get rushed when the devs have all the control over what gets teased, what gets pushed back and when the update releases, with no publisher setting deadlines and no big release date announcements months in advance. There are even a few features which explicitly were supposed to make it in (unlike the stuff on the "not a single feature was promised" roadmap) and yet were delayed regardless. In several cases we don't even know if there are any significant plans to include them in or before 1.23 - certainly not mentioned in this dev update. I don't think I'm speaking just for myself when I say that I would prefer less frequent or smaller updates which are well thought-out, extensively tested and thoroughly enjoyable, rather than a barrage of new stuff which just seems rushed. Tyron himself has admitted that they should feature freeze harder in the RC phase, which was very nice to hear, though I prefer to hold off cheering until I see how 1.23 unstable goes. This part is, frankly, the best part of this dev update for me, and it's been really nice seeing Maltiez cleaning up the old reports in the issue tracker.