MKMoose

I see the argument, but having three separate systems (free gameplay, "partially claimed" and claimed) may introduce unnecessary complexity to the claim system which already isn't exactly simple and intuitive. It may be better to either stick to it as is or make it slightly less restrictive globally. I'm not certain on player claims, though. A very similar solution but approached from a different angle (arguably much better) could be to rework some items (make the scrap bomb an actual throwable) and introduce a small class of "portable" items which could be placed in claimed areas, perhaps with some restrictions. They could be automatically broken if in the way of some machinery or otherwise blocking or obstructing something, and they may get automatically collected back into the player's inventory when they walk too far away (just a thought, but I think with a lot of potential). This category of items may include some light sources like torches and lanterns, bags (i.e. backpacks and so on), the firepit or a portable stove, a sleeping bag, optionally ladders, perhaps bombs and other traps (griefing would have to be addressed). The goal is to allow the player to perform some basic survival activities and implement intuitive problem-solving methods that they're used to from outside of claimed areas, without giving complete crearive freedom. Granted, unless limited to an extremely narrow selection of items, this change may still require adjustments to existing story locations, and I don't know if the devs want to do that.

Maybe I just haven't seen the same discussions, but I recall seeing similar suggestions received pretty positively, with the sentiment that implementing it well would feel much more immersive and engaging than just plopping down that same nightmare shiver directly in the player's house with no warning. The current implementation is extremely random and leaves the player with very little agency due to lacking prevention methods aside from exploiting monster spawn mechanics. Either way, the reason I brought this up is that I have seen a bunch of people comment on those discussions, and so they should be familiar with the mechanism I'm describing. This case aims to accomplish a completely separate goal, though, and what I'm saying is also arguably a simplification of another person's suggestion.

It really doesn't have to apply for all blocks, but primarily for tools and devices like ladders, bombs, traps, light sources, maybe a campfire or some new portable cooking pot for an especially large enclosed location. Some restrictions may be placed and some items might get automatically broken at key moments to prevent cheesing and unintended behaviours when something gets obstructed by placed hitboxes. A simpler way to handle removing placed items and blocks (though not universally applicable to all locations) could be to have them become temporally destabilized or otherwise affected after a short period of time in claimed areas, so that they become partially transparent and lose their hitboxes and functionality. Kind of like it has been suggested for temporal storms to make them more dangerous without just spawning enemies on top of the player. The delay before destabilization or whatnot should be long enough to allow using bombs and the like, but fairly short and well-communicated to make the rules and effects clear. Ideally, it would still be possible to pick up the items and stabilize them in some way, even if just by taking them out of the claimed area.

That's fair, and I did mention it in the next sentence after what you quoted. I don't know how normal that is, but I haven't had any real issues with berry spoilage after the first winter, especially considering that berries can easily fruit twice per year. I just use them up roughly as they appear for pies and juicing (and I have never even found bees for jam yet), and any excess can get juiced regardless to get more rot (for some reason the combined mash and juice rot is almost double that of unprocessed berries). The juice gets mostly fermented into alcohol, while fruit mash fulfills a large part of the need for animal feed in the summer. Flax tends to be more useful for animals than for meals, since they get the same number of portions from the same amount of grain despite flax grain's lower satiety. Pies also give you more satiety per portion of grain than porridge, and they last longer. Maybe I'm hyperoptimizing some things, but I've genuinely never found good reason to use the low-satiety fruit and grain for meals, since I've practically never ran out of better foods. Granted, cranberry's slower spoilage can be really nice before you get a cellar and a complete meal-making setup with sufficient supplies.

I'll see if I can work out a solid concept at some point, but in the meanwhile I have a few quicker comments. Overall I agree with a bunch of your points and a few of my criticisms were a little rash, but I'd argue your suggestion has a big issue with scale. First, a note on this: cast iron and pig iron are almost the same - pig iron takes the name from the way it is cast (a main channel called a sow which "feeds" a series of pigs, which are generally 20-50 kg metal chunks, similar to ingots but larger), and the primary difference between the two is that pig iron is poured quickly and tolerates impurities since it's refined later anyways, while cast iron is the result of careful and precise pouring into a detailed mold to obtain a clean and strong product. I'm also not a big fan of some of the inaccuracies in your concept (i.e. pig/cast iron going directly into cementation furnace without processing into wrought iron, or cast iron not being used for tools), if only because I know that the devs value realism and historical accuracy quite highly as well. Wrought iron, is practically the same as that obtained from bloomeries, and historically the blast furnace has largely superseded the bloomery for most applications. I don't see much reason to restrict it for gameplay reasons. While it does sound very appealing in some respects, keep in mind that you're talking about 17th and 18th century advancements focused largely on large-scale industry and bordering on the Industrial Revolution proper, whereas the current technological level of Vintage Story doesn't generally go beyond the 15th, maybe the 16th century. This would require massive development effort into a wide breadth of new features to keep all areas of the game roughly on par. And that's when we still don't have many simpler machines, devices or systems that would arguably be much more important, like a basic loom, fishing, a woodworking system for simple tools, kitchenware and furniture, a glassmaking system for proper bottles and jars, farming improvements in the form tilling or plowing farmland. All stuff that historically appeared and developed well before metal machinery. Large industrial machinery would also realistically take multiple people to run reliably and would supply entire towns or cities, and it most likely wouldn't have developed the way it did if there wasn't a need for this scale of production. I don't know if that makes much sense to add to a game which, although technically allows large-scale multiplayer, is ultimately designed mostly around solo play or groups of a few friends. In that vein, do you know how massive this furnace actually is? A real blast furnace from around the 17th-18th century Europe apparently had about 8-10 m of height (matches yours pretty well if we were to count from the base to the hopper), designed for continuous operation with tapping multiple times per day, operated by a total of about two dozen people split between shifts in a variety of roles in the furnace complex, and outputting at least about 5 tons of cast iron per day. That is not practical for the current state of the game. Even an early 14th-15th century blast furnace apparently had about 5 m of height and and output of about 1 ton of metal per day over 3-4 casts, which is more reasonable though still quite a lot. I think it would be suitable to design a 3x5x3 furnace (or even shorter) with a hollow core, hearth at the bottom and charging hopper or whatnot at the top, which would be much easier to build for the player and to code for the devs. Also, keep in mind that you can put 64 ingots in the space of one block in ground storage, which would mean that, going by volume, even the smaller furnace could still believably hold the equivalent of a stack of ingots if not more, with the necessary fuel. A fairly cautious but realistic estimate could get you a single charge that yields 200-300 kg of output split into 6-9 pigs or an equivalent quantity of directly cast items (more likely some of both), with one tapping about every 6 to 8 hours. The equivalent of one pig may be two ingots of metal (and that would still arguably be a small pig or large ingots, more realistically it should be at least like 4 ingots). The furnace may have a maximum capacity of about 3 charges to allow more efficient continuous operation. Even scaled down further, it's difficult to keep it remotely realistic without having it output at least 8 ingots per cast. It may be reasonable to consider something like an early Chinese blast furnace 2x2x2 in size as well, to allow less efficient casting of a few pots and simple tools before the player invests into a large structure with refractory bricks and a large quantity of sand molds. Granted, there's a lot of places in the game which have completely unrealistic proportions and other concessions for the sake of gameplay, for example for brickmaking or shingle roofs. Thing with blast furnaces, though, is that a decently sized one should realistically have at least multiple times the bloomery's output per cast, or sometimes a few dozen times. There's a reason I keep harping on about how they're used for large-scale manufacturing. I will also mention quickly that a realistic implementation of a blast furnace would ideally require: 1. Large metal ladles with ceramic lining, instead of the simple crucibles. 2. A way to create sand channels through which metal flows into pigs for later processing into wrought iron (this would be very similar or even simpler than detailed sand molds). This is a fair point, but the same could be said of the beehive kiln, albeit to a lesser extent. It's not so good for small batches, but firing tons of shingles or bricks? it's absolutely worth it. The difference is that the beehive kiln has an early-game alternative in the pit kiln which is easily accessible and absolutely sufficient for the average player until they want to create decorative items en masse or fancy a specific ceramic color. For iron you could at best consider the bloomery an earlier alternative, but it would be unlocked at a much closer point in progression to a blast furnace than pit kiln is to beehive kiln. And perhaps more importantly, the bloomery can't produce cast iron, which is a bigger limitation than purely efficiency and cosmetic benefits of a beehive kiln. This is largely why I was suggesting two different furnaces: one small and accessible shortly after obtaining iron to be more balanced in complexity and size with other structures available at that stage of progression, and only then if needed we can consider a 17th-18th century behemoth. Even if we were to discard the gameplay aspects for a moment, it would just be much more realistic to start with an early blast furnace as it first appeared at scale around the 15th century in Europe, instead of immediately jumping from a late medieval bloomery straight to a blast furnace from near the advent of the Industrial Revolution.

This is a delightfully detailed suggestion, and I'll gladly reply in turn. I'd argue that the best use for cast iron is to provide a greater breadth of late-game improvements, especially with new cookware and furniture, much as suggested. Currently, the majority of important upgrades are unlocked in the Copper Age and a few things are in the Bronze Age, with subsequent progression having limited impact on building, homesteading and other activities unrelated to combat. While this is desirable to a large extent, as it doesn't lock important features behind lengthy progression that may discourage more casual players, it also leads to iron and steel being potentially disappointing, as they mainly provide stat increases which don't matter all that much outside of combat. Cast iron could serve as a new branch of progression after the initial processing of iron, giving the player an additional direction to progress parallel to steel, with a bunch of rewards that increase the efficiency of regular household or manufacturing tasks. Keep in mind that the benefits shouldn't be too drastic (for example, the 24-portion cooking pot might be a bit overkill, unless it has some drawbacks as well) as to avoid making players feel like they have to get cast iron as fast as possible. It's generally better to give the player meaningful choices for what they wish to prioritize and progress towards, and we want to incentivize and reward players for putting in the effort, not make them slog through until they reach the game proper. Ideally, I think it would be best to have endgame alloys be more specialized. Steel could be favored for high-cost high-quality sharp tools, weapons and armor. Cast iron, however, is brittle and so it's generally not useful for anything that needs a sharp edge, carries heavy loads or has to sustain strong impacts. It is more suitable for simpler agricultural tools, household items and furniture, simply by the virtue of requiring less effort to smelt while being almost as good as steel for those basic applications. This specialization between steel and cast iron may also align neatly with the historical introduction of large-scale cast iron production, which provided broad improvements to the quality of life throughout Europe but had little impact in cases where highest-quality metal was necessary. The main benefit of it was that cast iron products could be produced at much lower cost and much more consistently, benefitting both regular households with easier access to tools, cookware and safe stoves, and trades that needed a consistent supply of uniform metal parts. A simliar approach of specializing different items would also work well for other mid-game and late-game upgrades, for example a firewood-fueled brick fireplace might enable quickly cooking large batches of food with a larger pot, a cast iron stove could allow more fuel-efficient cooking in a regular pot, and a brazier of some sort would only allow cookng certain items (which can be placed on a rack) using coal, but faster than with the current one-at-a-time firepit mechanics. Another example would be a candle holder - worse than lanterns in terms of light radius, but easy to cast in large quantities (I'd argue casting should return two or even four of them per 100 units), without requiring relatively expensive metal plates and additional quartz for each light source. Realistically, pig iron obtained from a blast furnace can be processed into wrought iron in finery forges, which can then be used for steel as it has very low carbon content. While I'm no expert on the topic of metallurgy, I think I can say that it wouldn't be difficult to keep it both historically accurate and well-integrated into the game's progression. The biggest challenge would be communicating all the distinct iron products to a new player. I would also say that the blast furnace should not allow to skip iron refining entirely - instead, iron blooms should be replaced by the pig iron to wrought iron processing, which could be easier but still significant. That's in large part because reducing the need for a helve hammer (which is great for plates, but especially needed for iron blooms) would also greatly reduce the need for automation in general and also for the new high-speed machinery. The sheer size and complexity of this blast furnace concept is arguably unsuitable for the current progression - I think it should be reduced to a smaller size and simplified, to make it more achievable before steel. Historically, early European blast furnaces apparently had about 8 m of height and early Chinese ones were even smaller than that (sometimes as little as around 2 m of height), much less than the proposed 12 m. I'd have to double-check how exactly that is supposed to be measured, but regardless I think it would be better for the blast furnace to be somewhat smaller. Additionally, the average player really doesn't need 72 ingots worth of iron until they start getting into industrial production, and building such a massive structure just to fire it at a fraction of the capacity seems very unbalanced and unapproachable, especially for a newer player. Restricting the blast furnace to only be fueled with coke also seems completely unnecessary, even if it gets the player to engage with more game systems. It could be in some way faster or more efficient, but realistically charcoal is absolutely sufficient. Both for gameplay and realism reasons, there isn't much reason to use coke aside from supplementing charcoal shortages or utilizing types of coal which otherwise aren't suitable for smelting. It may actually make sense to create two different blast furnaces: 1. Smaller and simpler one, easily achievable shortly after or even before iron forging. At most about 3x6x3 in size but perhaps as small as 2x3x2, not counting spill chutes. It would be used for more easily casting smaller batches of simple cast iron cookware and farming tools, serving to more naturally introduce the player to cast iron mechanics in a way that integrates with the current progression much more smoothly. Also, it would be easier to implement for the devs more gradually while gauging gameplay balance and community sentiment, instead of beelining for mass production. 2. A huge blast furnace more similar to the OP's concept for creating large quantities of pig iron that can then be turned into a larger variety of more complex products (including machinery, fences and other construction elements) as well as into steel. There are things that I would argue should not be added to the game this late into the progression on the account of being disruptive, i.e. forcing the player to redo or relearn a lot and sometimes practically build a new home to accomodate the quantity and size of some suggested features. This primarily includes large multi-block furniture, albeit the OP's suggestions seem reasonable in this regard. Other items could also pose issues, like mechanical power parts or cookware, which may replace the earlier ones and leave the player with a bunch of stuff that can only be thrown out. I worry that cast iron would make a lot of items, including the increased variety of clay colors unlocked with the beehive kiln (used for both cooking pots and for realistic-looking fireplaces) kind of obsolete in favor of the generic black items from cast iron. We don't want too many things to default to cast iron in the late game due to alternatives being worse, and historically even something like ceramic cookware still had a lot of uses after the widespread introduction of cast iron because they were cleaner, non-reactive, safer and more resistant to high temperatures. Overall, though, I do like the suggestions, and some of them have also been quite frequently requested by the community (especially a better alternative to the firepit and more light sources, from what I've seen). To add to the list of items that could be introduced with cast iron: - braziers of different sizes may be used to cook food, - large cauldrons, if we go for historical accuracy, would have to serve as a replacement or alternative to barrels for some parts of the leathermaking, dyemaking, brewing and similar processes (cast iron was extremely important for large-scale industrial processes like those), - there's a lot of fun that could be had with decorative building elements, especially complex wrought iron fences of different heights, including a variety of gates in 1x1, 1x2, 2x2, 2x3 and perhaps other sizes, - I would love to have metal buckets, if only just to allow them to be stacked in ground storage (5 on one tile, possibly only if empty), - metal gears with different ratios could be useful for more precise speed and torque tuning. I do like the sand molds, as they get the player to keep some of their old items instead of just throwing all of them out, but they contribute to the same complexity concerns as mentioned before - it may be undesirable to lock large improvements behind such a late-game and difficult to set up manufacturing process. I also think that adding durability to them might not be a great idea. Most of the time some of the mold material has to be removed to get the product out of it, and also the mold cracks very easily, and so it's only suitable for a single casting. If we were to go for realism, then both ceramic and sand molds would have to be single-use, or maybe limited to at most 2 or 3 uses in certain cases. If ceramic molds are already indestructible, then I see no reason to add durability mechanic to sand molds, unless we want to specifically make them single-use. Cast iron machinery has the issue of being a replacement for everything, with most large industries starting to use them around the 17th and 18th century (which is notably later than the current tech level of the game, by the way). Small and precise gear systems, high-speed power transmission, machine frames and structural elements, milling, textile machiney, printing, metalworking. Everything got smaller, faster, stronger, and the old wooden machinery became obsolete. It would arguably even require the addition of new variants of helve hammers, pulverizers and a whole lot of other machinery, not just axles and gears, and may invite brand new features to automate like looms, sawmills and so much else. Starting with one thing may require fifty other new features to match the level of technology with an acceptable level of historical accuracy. That said, I especially like the bellows and the more self-enclosed metal parts that may be neatly integrated into the current system, like the flywheel or the gearbox (probably should have just two gears for simplicity). A good middle-ground, though, may lie in wood-metal hybrids - very similar to wooden machinery, but reinforced with metal, or with some high-load parts replaced entirely - which could be used to upgrade the current machinery in place for better speed and torque tolerance.

You're making me want to list out all the little details that make me like this game so much. Granted, I'm taking some of my information from the wiki with limited testing, so take it with a grain of salt. I ain't here to criticize how you play, but cranberries due to their low satiety tend to be most optimal for juicing (be it for drinking, alcohol, fruit mash for animals, or to produce rot) and less useful than the four other types for cooking meals. If you have to eat them raw or preserve to use later then they will last longer, at least. For the other four, though, I don't know of any notable differences aside from appearance and the ability to stack two currant bushes, so you can get quite literally whichever you prefer and I personally just do all of them. Of the temperate fruit trees, all apples and pear don't have any big advantages or disadvantages. Pink apple has a bit higher yield and is arguably best, while pear and yellow apple are general all-rounders, though pear is more resistant to cold and takes longer to bear fruit. Red apple seems to fare best in colder than temperate climates but produces slightly less fruit, and cherry is the standout with half the satiety and very short spoil time but nearly 50% higher yield, pretty bad for cooking but king for juicing. Peach just seems kind of bad, honestly, I don't know why but I don't think it has any notable advantages while having very short spoil time and poor temperature resistance. Among the warm-climate fruit trees there is much more variety, and the most notable mentions are breadfruit which is excellent for meals and lychee which is great for juicing. There's the olive impostor as well, which actually provides vegetable nutrition and therefore can't be juiced, but can be pickled, which gives it a unique niche. I would imagine they might rework berries to be more similar to fruit trees in terms of flowering and fruiting mechanics, with different timings and temperature requirements to differentiate the species between each other. They may serve as an early introduction into the same mechanics that fruit trees follow, similar but slightly reduced in complexity. I'm not sure about other utility, though, since realistically berries are pretty much only used culinarily and sometimes for dyes, both of which we already largely have. At best they could allow drying or freezing food, which would include berries. Maybe also add them to bread dough? Kinda stretches it thin, though, since berries already have plenty of gameplay depth between meals, jam and juicing.

A lot of the new additions seem to be completely optional. Hopefully, this means that while the total complexity of forging will increase, the minimum effort required to obtain a usable product will not change much if at all. Quenching and tempering are also generally only used for ferrous alloys from what I've seen, which means that working with copper and bronze will likely stay mostly unaffected. I do also hope they don't overdo it with the new features, because metalworking is already pretty complex as is and takes a while for a new player to learn and master, but it is undeniable that the current mechanics have a lot of potential for greater variety while forging and for additional refining and maintenance after the initial forging. I think I trust them to balance this quite well to avoid overwhelming newer players.

We kind of already have this in the game, since most class-exclusive items (some of which can be purchased from traders anyways) are designed to be an upgrade over items that can be crafted by everyone. The sling is the only properly unique class-exclusive item, but even that can just be considered an early alternative to the simple bow. In some cases, even partially removing class exclusivity could make one of the items kind of redundant. Say, take the tailored gambeson - its cost is very similar to the regular one, but reduced availability makes it possible to notably increase its strength to give a class-specific advantage to having the Tailor on the server. But if you make it available for everyone, then the weakened one crafted by other classes would have to be very similar to the regular gambeson in order to be balanced (due to very similar cost). And at that point, why do we even need the regular gambeson in the game, if every class can craft something very similar at about the same cost? That is not to say that you can't retain some interesting tradeoffs between similar gear, just that it may be difficult to do so in a meaningful way for items that were originally designed to be class-exclusive improvements over items craftable by everyone. The tuning spear and the Blackguard items have additional lore and theming reasons to be class-exclusive as well.

What do you mean by "most"? Are there any locations that cause the sky to turn sepia at all times? And it better not only be that one lore location that I haven't seen yet but which has been mentioned in every other conversation about instability. Overall, what you say seems like a lore-driven interpretation. Purely in terms of gameplay, ambient surface temporal stability is almost entirely unrelated to rifts and temporal storms, and may even be argued to be separate from ambient underground stability. They are all essentially separate gameplay elements with different purposes that are only notably related through the player's temporal stability. Bundling any of them together, though more accurate in some respects and more useful in some contexts, detracts from both the topic of the original post and the topic that the thread has largely shifted onto, as almost the entirety of this conversation is specifically focused on ambient surface instability.

If the windmill is connected to the large gear in such a way that one rotation of the windmill causes five rotations of the shaft that drives the helve, then you have a 1:5 gear ratio, making the helve hammer able to work five times as fast. However, because the large gear has five times higher radius, it transfers force using a that much longer lever and so has five times lower torque. Every mechanical part has a certain resistance, and the torque on the driving axle has to be high enough to overcome that resistance - otherwise it will not be able to turn (or if it's already turning and higher resistance is applied, it will slow down and stop). By lowering the torque transferred to the helve using the large gear wheel, you're increasing the torque that has to be produced by the windmill to overcome the helve's resistance. You can make it work, but you will need higher power input. You may need something like three full windmills, but the exact value will depend on a bunch of other factors as well, including how much uptime you want. The devs have said they aim to add more mechanical power parts, including a water wheel once they have a good river implementation as well, so perhaps we're gonna have that not too far into the future.

It may be a good thing to consider if only for the sake of realism and immersion, but it also has a few undesirable side effects that would have to be addressed. It may also be useful to make it clear in some way to the player what "underground" is and what "enclosed space, but not counted as underground" is, as well as clarify how cellars fit into all that. Cellars are already a little finnicky as is. Food spoilage currently reaches the minimum rate at -5°C, which would mean that cellars may effectively increase food spoilage rates relative to outside, making them counterproductive in low temperatures and incentivizing finnicky food management. One potential fix here is to reduce food satiety once frozen (and reduce spoilage rate while frozen), which would make cellars and caves useful even in the arctic while allowing to deliberately freeze food to let it last longer. Seraphs can only freeze while the temperature is lower than 0°C, and various plants have their own temperature requirements. With the underground always being no less than 5°C, freezing and crops dying would become much less threatening or even almost a non-issue, even in the arctic, once the player finds a suitable cave - no need to even dig one. The easy solution here may be to add some sort of consequences to staying in positive but close to freezing temperatures, and reworking plant growth to avoid exploits, but that would again have downstream balance implications.

The TLDR of the argument as I understand it is simply that historically hammocks were practically never used on ships of this size and kind. They were primarily seen on larger vessels designed for much longer travel times, with large crews, high cargo capacity, and sufficient space below deck to actually fit those hammocks somewhere without them getting in the way. The same point goes for a crow's nest - the boat is just too small for it. Vikings have used their relatively small vessels (compared to 15th to 17th century transport and military ships) to move horses and other animals, so having a spot for an elk is even quite realistic, wheras sleeping would more likely just be done on the benches. There's also the potential problem that sleeping on the boat while no one is keeping watch is just asking for problems, but I think we can mostly ignore that for the sake of gameplay. Either way, yeah, it would be great to have a way to sleep on the boat. I don't think there's any big argument against it. But specifically a hammock doesn't really fit this specific boat.

I would like to mention the different design factors for salt extraction, which would allow multiple salt extraction methods to exist simultaneously in balance. To give some context to it, the methods for sea salt that I would consider are: 1. Simple seawater boiling. May need a secondary step (seawater -> brine -> salt). Would require the most fuel, with about 10 l of seawater required for each 1-3 l of brine, which then converts at some rate into salt (realistically it's about 300 g per 1 kg of brine or a bit more, but the game's ratios are not realistic). The first step of concentrating seawater into brine may dirty the pots with other salts and sediments. 2. Obtaining brine from crystallizations in shallow depressions near the coastline, or alternatively, from salt lakes or brine springs, but that would be rare. This fully or partially skips the initial boiling of seawater to concentrate salts, but is extremely slow as it typically requires to wait for natural salt crystallization near oceans in dry regions. Those crystallizations are scraped to obtain wet salt cake, which is washed to obtain brine. 3. Proper salterns with multiple large ponds. The most sophisticated and difficult to set up process, but allows to obtain relatively large quantities of salt purely through evaporation over several weeks. The ponds would probably be made with clay and could be actually really large, like upwards of 100 blocks each, though probably with some upper limit. In the first pond sediments are separated, in the second one I think calcium salts separate, and in the third pond clean sodium chloride crystallizes and can be raked. Evaporation requires dry and warm climates with low rainfall. May be tough to implement without significant simplifications from the real process. It may be useful to add shallow evaporation pans to the game, allowing to boil seawater more efficiently than in a pot. All of these methods could benefit from simulation of salt concentration, but that's not easy to implement and far from necessary for gameplay purposes. With that, the balancing factors are: 1. Time. Both boiling and evaporation are long processes, in the case of boiling also generally requiring regular refueling, meaning the player would have to stay nearby throughout the process. 2. Fuel. People often overlook this, where in reality it's perhaps the most important factor why sea salt is rarely extracted in colder climates despite seawater obviously having about the same amount salt concentration. Boiling away 1 t of water (yielding 35 kg of salt directly from seawater or something like 300 kg from brine) apparently takes about 6 t of dry firewood, last I looked it up. Obtaining salt through boiling seawater would therefore not be a free process - it would effectively be a fuel to salt conversion. 3. Startup and scaling cost. Efficient methods of obtaining sea salt require larger setups and a lot of preparation to get significant returns. 4. Climate requirements. The best methods of obtaining sea salt only work in hot and dry areas with a period of very low rainfall. And let's not forget you actually need seawater, which may be very far away depending on where the player decides to settle. Relative to halite, which once found is nearly free until exhausted but may take a while to locate, these factors offer plenty flexibility to balance different salt sources between each other.

I don't see how that helps in the slightest. Not only would you need to know the mechanic exists, but then you need to obtain a tool to check? Is this tool likely to have prerequisites involving building a base, just to tell you if you if that base (already under construction) is in a good area? It's like noticing there's a problem with players getting confused with a certain tutorial, and then proposing the handbook need to be crafted first to get to that tutorial. This suggestion was never meant to address the issue of building in unstable areas. The point here was (though phrasing wasn't ideal) that if we decide to remove the spinning gear for the sake of immersion or a more horror-like feel, then we don't have to entirely rely on environmental clues and the like to detect instability, because similar functionality to the spinning gear can be moved to in-world items or devices. If implemented this way, then environmental cues would serve a fundamentally different gameplay purpose from measurement devices. I also specifically said a bit earlier when initially bringing up these tools or devices that it would require additional effort put into adjusting surface instability in such a way that it doesn't feel unfair before the player can reliably detect it. Frankly, I don't fault you for not connecting the two in these walls of text.

Thank you for such a detailed response! Being able to simply disable surface instability indeed seems like the simplest option and I certainly wouldn't oppose it, but do keep in mind that my suggestions stem largely from the question of "how could we change surface stability so that people don't just ask for it to be removed". A mechanic that some people want gone may just need to be adjusted for them to enjoy it instead, and it may benefit all other players as well. I should say, this will be a really long post, though the TLDR is that I agree with the counterpoints that feel like address what I said well, and there seem to be a few things that didn't quite land that I want to explain better. Maybe, but that can also teach the player to start ignoring the stability mechanic, instead of paying attention. I think the current system is fine, as the drain to 0 will teach the player that stability loss is bad, and they should be careful how long they hang around in unstable areas. Most unstable areas on the surface, however, are also a slow drain, so the player will still be able to spend a decent amount of time there before they need to leave. The counter suggestion I have to this idea is to restore a good chunk of stability should the player die with low stability(as far as I know, currently the gauge remains at whatever it was on death). Mechanically, it gives the player a brief grace period to improve their situation before they potentially die again, while also helping to alert them to the cause(the meter was empty, they took damage and things got weird, but now it's somewhat full and they're fine). From a lore standpoint, it makes some sense too, in that if the player is able to respawn, that indicates they have at least some stable grasp on the present timeline. I don't know how common that really is, but I've seen a bunch of people start ignoring the stability mechanic because it didn't seem like it was doing anything, so I was thinking that making it do things more often as the player moves between areas of different stability would let people notice the gear earlier and pay more attention to what it does without the threat of going all the way to 0% stability. I guess it may be difficult to come to any reliable conclusion on whether stability closer to binary or more continuous is better, because even with a statistical advantage on either side there will always be a portion of people who start ignoring the mechanic. A larger partially unstable area would essentially serve as a warning around a potentially fully unstable area inside of it (if those even appear on the surface - we could limit surface instability to solve a part of the "can't build here" problem). I also don't see restoring a portion of stability after death as a counter-suggestion. I mean, it seems like a good suggestion that aims to achieve somewhat related goals, but they could work in tandem perfectly fine as well. Incidentally, the other thing I have against distorting sounds or applying weird overlays in unstable areas, is not just that that kind of detail is reserved for majorly messed up areas/events, but also that...it would get very old, very fast. Imagine building your base in a stable chunk, with lots of unstable areas nearby. Now instead of just occasionally hearing distant Rust ambience when out hunting/foraging, you have to put up with "temporal storm light" each and every time. Oh, but I hate the effects of temporal storms, at least the visual ones. I had to turn them down in accessibility settings. And that's totally not what I'm suggesting. This point largely revolves around the issue that temporal stability is almost entirely disconnected from the world (aside from lore reasons), and it only really has an effect on a meter in the UI, which only then causes a second-order interaction with the player. This is largely why some people have said that it feels arbitrary and tacked-on. And yes, it could be argued from a lore standpoint, but that really doesn't make the gamplay side of it better. The way to solve this is not to introduce immediate visual distortions or something of the sort, because that's still focused on the player. Instead, make instability affect the world in subtle ways. Not drastic like a deadly disease hit the place or something, but just enough to get the player to think "there's something odd about this area, let me check if it's unstable". Side note: stability could also be used when generating the density distributions for various berry bushes, wild crops and other useful items, to avoid attracting newer players into unstable areas that just happen to be bountiful in surface resources. In the same vein, areas like deserts and the like could have lower average stability than forests, since they're inherently less appealing to the player. It could easily even be argued through lore or through basic intuition. This is also part of the reason why I'm suggesting to make animals less common in unstable areas. Granted, these generation changes could have the effect of not exposing the player to enough unstable areas to get them to learn about instability, so there's a balance to be struck here. It's not necessarily about replacing the gear with audio or visual cues, because the spinning gear functionality can also be moved to in-world items that the player could craft or otherwise obtain. Either way, it would shift interaction with game systems away from the UI and into the game world, which is incomparably more immersive and engaging, and not because it's "realistic". It involves psychological factors that make the player feel like they are interacting with the game at a deeper level, and realism has little to do with this, even if it's helpful. Granted, it could risk obscuring crucial information as you described, which is why it has to be done well (in conjunction with other changes) and shouldn't be carelessly extended to things like health and satiety. Do note, though, that the game already greatly benefits from this approach of putting things in the world instead of abstracting them away in several other areas, primarily in the various crafting systems. Also, health and hunger are currently much better placed in the game world than instability, because as the player gets hit, uses healing items, prepares and eats food, these are clear interactions between the character and their surroundings. Isn't having to figure out what's stable and what isn't kind of the point? If the goal is something like a creeping unsettling feeling as you mentioned at some point, then removing all direct and reliable indicators of instability seems like a necessity to me. I can't really be anxious or uneasy if the game outright tells me when I'm in an unstable area with absolute certainty and even allows to easily gauge roughly how much time I have before I need to leave. The two are largely just incompatible and favor completely different gameplay styles. If we want a more cautious, horror-like approach to instability, then I say the spinning gear goes out the window (or at least gets adjusted significantly in some ways), while in-world indicators (be it environmental or from devices and tools) have to be imprecise enough to retain a certain unknown element, or expensive or slow enough to make it impossible to accurately map out large areas. The problem of wasting time building in unstable areas, I believe, cannot be addressed without adjusting how stability itself works in some fashion (or making those areas unappealing for other reasons, but we're on the same page that making unstable areas stick out is not what we want). No external change will magically make it possible to stay in an area which is designed to heavily punish the player for staying in it for too long. I do like this idea, though rather than change the range of instability I would simply keep things as-is and perhaps just ramp up stability loss significantly in unstable chunks during temporal storms. I also think something like this would be critical if you're going to stop unstable chunks from draining stability entirely, as that way if the player gets complacent enough to build in one they're in for a very rude awakening later once a temporal storm hits. My point here primarily aims to address the complaint that surface instability kind of just renders certain areas of the world unusable, by simply making it so that practically all areas of the world would face instability at least once in a while, though not excessively often. This necessarily means that not only would the range of instability change, but ideally the entire distribution would evolve over time. Each area would still probably have a constant component to represent the average stability in that place, but even the most unstable areas shouldn't be always unstable and should see periods of safety once in a while. This shifting instability would allow much more building flexibility, since while some areas may still be less optimal on average, none or at least much fewer would be outright unusable. It would also put more focus on instability as a mechanic that everyone has to watch out for lest it catch them off-guard, instead of it being nearly irrelevant unless it happens to be close to an important spot. And I will mention again that shifting surface instability implemented in this way would likely have to be tied to rift activity and temporal storms in some way (especially to the storms), because it would be plain stupid to have three mechanics which seem to be very closely related in lore but barely related at all in gameplay. As for the second point, temporal storms already drain stability very quickly and I'm assuming that it's additive, so I was frankly taking it as a given that less stable areas should be more dangerous during temporal storms regardless of whatever other changes we might make to them, since in those areas the player would be able to stay in the storm for a shorter amount of time before their stability drops below the safe threshold. Granted, maybe it would require some balancing to land at the right numbers. Either way, the original goal is that the player can still stay there if they choose to in spite of the added risk, with hopefully clear enough consequences but without getting messed up by indefinite 0% stability.

It's possible to prevent spawns within a certain radius of any sufficiently illuminated block, instead of directly reducing the light threshold. It would have a bit different side effects, but the core effect of increasing coverage of light sources is the same.

Personally, I don't like this solution, because it ruins the unsettling element of the mechanic entirely. Yes, it's more obvious, sure, but it's also practically a neon sign in the player's face that SOMETHING IS WRONG HERE! The current implementation is more subtle and can be easily missed, yes, but that also helps keep the player immersed in the creeping horror and more unsettling elements of the world. At a glance, everything is fine on the surface, aside from certain events that a total trainwreck(like temporal storms), but that lulls the player into a false sense of security. Spend too long in the wrong spot, and they may quickly find the distant ambience of the "other reality" filtering in. This take frankly surprises me, because I would say that the current implementation is much more of a neon sign than diegetic clues (signs present in the game world). A kind of easy to miss neon sign, yes, but also kinda simplistic and unimmersive. Recognizing unstable areas basically boils down to "oh the gear it turning the other way". I think I would much prefer if it was more in the vein of "this place seems a bit odd, let me check if I can find any indications of instability". But that is almost completely squandered once the player realizes that the turning gear is practically the only indication of instability in the entire game (aside from sky turning to sepia and so on, but that's player instability and not world instability), and it is also immediate and completely reliable. One thing that I really don't like about the current implementation, though admittedly it could be by design, is that the trigger and effect are not well correlated, because the effects of instability take a while to kick in and stay active for some time after leaving the area, which makes the spinning gear a necessity to recognize instability with any level of accuracy. Combined with the randomness in the stability distribution itself, this creates a system with unclear causality and poor feedback to player actions (except the gear which turns immediately but may be easily missed). Such a system provides very limited learning opportunities, meaning that a new player will often struggle to understand it without a tutorial - and at that point, a large part of the mysterious and unsettling vibe vanishes in a paragraph of explanatory text. This is a very cool ideal, but I cannot say I've ever experienced anything close to it while playing myself. To actually get this unsettling feeling in the best way possible, the player needs diegetic clues, not UI. That's the same issue as chat messages for temporal storms, which do their job sufficiently well but have nothing immersive about them. Instead of making the player focus more on their surroundings, they take the player out of the game by making them pay more attention to the UI. And by the way - what is there to investigate? If I search an unstable area, will I find an explanation or an answer? Nope, it's just a random 3-dimensional distribution that only really affects a meter in the UI. If I ever find an answer to anything, it's gonna be somewhere in the lore, but that still doesn't answer why a specific area is unstable. I do agree with the idea of what temporal instability should aim to achieve from a design perspective and with how it should be approached by the player because of this, but it just ain't doing it for me very well, at least not on the surface. I wouldn't claim it's terrible and in urgent need of a rework as some have said, but I think there is plenty of space for improvement. With that, here's a few independent ideas on how it could be changed: 1. Player stability shouldn't fall all the way to 0% in every unstable area. Presumably implemented by restoring stability faster while it's low, this would make the mechanic less binary and allow to increase surface instability while making it easier to stay in "partially unstable" areas indefinitely if you can deal with the effects. Limiting "fully unstable" areas to below ground would also prevent new players from getting messed up if they don't notice that an area is unstable, because they won't get stuck in endless full-on storm-like effects. 2. The functionality of the spinning gear could be moved to an actual item or device (or a few of them with distinct purposes or different qualities) to make it so that precise evaluation of an area's instability is only possible when the player deliberately investigates it. These could be a variety of "measurement devices", starting from simple temporal gears and ending at sophisticated Jonas tech. At the very least, only show the spinning gear in UI if the player has a temporal gear in inventory. Note that this suggestion is probably the largest of these five and would also require additional effort to make sure that unstable areas don't feel unfair before the player can detect them reliably. 3. Subtle clues could be added to the environment, like rust particles, slight dark fog, a bit sparser or discolored vegetation, reduced animal and insect density or just reduced commonness and volume of their sounds. The purpose of these is primarily to avoid pulling the the player's attention to the UI (especially if implemented alongside suggestion 2.) and instead encourage to analyze the environment critically. That said, it shouldn't be a fully consistent and reliable way of gauging instability. 4. Actual sources of (additional) instability, presumably in ruins, would do wonders for player agency. They would increase instability in an area around them and ideally it would be possible to destroy, disable or weaken them. Granted, they shouldn't be the only source of surface instability and in some cases they may effectively just increase existing ambient instability and not create a distinct unstable pocket, because we don't want the player to feel like they can completely cleanse an area and control stability - it should still be an everpresent risk that can catch the player off-guard. 5. Slow instability fluctuations would be able to really, properly catch the player off-guard. Ideally, they should be tied to rift activity and temporal storms in some way, peaking during temporal storms. The fluctuations should change the shape of the instability distribution and not just reduce or increase it uniformly, and would have to be tuned appropriately to avoid kicking the player out of their home for an extended period of time. In a more extreme and sophisticated implementation, it could cause unstable areas to effectively move through the world in a way that can be observed and tracked. Overall, it would require more regular stability checks and on-the-fly adaptation from the player. They could also be cyclical, repeating around once a year or so. I'm not suggesting that all of these be implemented, and some may be found to cause downstream issues or just be unfit for the vision of the game, but I believe they have a lot of potential to improve the overall experience.

Simple, functional, avoids clutter. Provides gameplay incentives to encourage searching for more resource deposits. This is arguably the best suggestion I've seen for more complex tool or weapon mechanics, especially if you also consider some interesting tradeoffs and not just ways to increase durability. Sharpening is the big thing for any blades and it could offer plenty of depth by consuming durability to grant increased work speed or damage. It could also involve a minigame of sorts in the style of various crafting mechanics to enable more skill expression. Oiling or greasing seems like an interesting way to increase maintenance complexity for iron and steel items specifically in the late game, though to make it remotely realistic it would also be necessary to add rusting (prevent rust with oiling or remove it afterwards with other methods; reduced durability loss while clean), and I don't know if we want to go this route. Reducing the rate of regular durability loss while oiled seems like a fine enough simplification, if necessary. It could be interesting to implement it in a way that ideally encourages oiling after each use, though may also end up tedious. Handle replacement could be a thing, but it would have to be sufficiently unobtrusive and simple, so that advancing through the ages actually yields a notable increase to tool lifetime, because exchanging "replace the tool every 10 minutes" for "replace the handle every 10 minutes, and the toolhead every hour" basically doesn't change anything. Alternatively, just allow using better handles in place of sticks to slightly increase the base tool durability. The above three, alongside cleaning which probably isn't a great fit for the game, were historically the most important parts of regular tool maintenance. Not all of them are necessarily crucial to be implemented, but all of them arguably stay within a suitable complexity balance and have a lot to offer to improve the overall experience. More miscellaneous features like bowstring durability, bowstring tension or armor deformation can be implemented as well for things other than metal tools. Reclaiming material from used tools is a fine idea as well and again very common historically. For copper and bronze tools it's typically done though recasting and for iron and steel tools through reforging into smaller tools of similar shape, both of which would have notable implementation issues in the current smelting and forging systems. There's also problems with reduced metal consumption rate and item clutter, as has been brought up in this thread. It's something I would be interested to see, but I worry it would require heavy balance changes and could end up causing many more issues than it solves . More complex systems could be cool and realistic, but the gameplay goals that are to be achieved here are very important to keep in mind. Mods sometimes take a great feature and develop it in a highly unbalanced way, ending up with an overcomplicated, sometimes outright bloated feature that feels like it wants to take over an excessively large chunk of the core gameplay loop. The way I see it, we primarily want three things from more complex tool durability and associated mechanics: 1. The new options should facilitate player agency and mastery by allowing to prioritize different goals and exchange resources for different ones or for various benefits, be it time, oil, metal, durability, work speed or anything of the sort. Resource tradeoffs and conversions are crucial for the game as it is currently designed and it should stay that way. Things like recasting don't do that - they just return clutter that can be reprocessed for new things at very little additional cost. 2. The system should improve interaction with tools, to treat them more as important items that the player can care for so that they give back in turn in a more dynamic way, and not as a fixed-rate resource expenditure. A small amount of extra effort should give substantial benefits to reward deeper engagement with the game, but without punishing the player if they skip it. Toolsmith apparently puts this as the main goal for its mechanics, and it seems fairly well-implemented in that regard. 3. The system has to be entirely or mostly optional and shouldn't increase the baseline complexity of the game, so as to avoid overwhelming new players with excessively complex features or tacking on extra maintenance effort on those who don't want to engage with it. This is primarily where Toolsmith ends up pretty much completely unfit for the vanilla game, and that's why it should stay as a mod for those who want the extra flavor. Stone tools should remain entirely as they currently are, and further as the player advances through the game complexity should be added progressively and slowly, only significantly increasing towards the end of progression for the highest potential gains with iron and steel tools. As a side note, my one pet peeve is that hammers seem to get used up way too fast. On my current world I've already used more metal on hammers than on pickaxes at the beginning of the Iron Age, and I still have close to a thousand various ore nuggets left to process, two dozen ingots in storage, and multiple unfinished deposits. Maybe I've just been lucky or haven't experienced enough late-game prospecting, but it feels kinda wrong how the most blunt tool in the game seems to get used up by far the fastest for me.

I'd be fine with that, but wouldn't look forward to all the complaints about not being able to craft bronze knives or copper axes. And we'd be linking those people to mods that add the old way back in. I feel like a simple solution to this issue is kind of already in the game - make it so that you can keep using sticks, but using a better haft slightly increases the durability of the item, the same way bones do for stone knives and axes. Alternatively, though at higher dev time cost, make it so that a handle has its own durability independent of the tool, returning a toolhead with reduced durability when broken. A better handle would last longer or even all the way through the tool's lifespan and beyond. This would be arguably much more realistic and immersive, and could also open up a bunch of adjacent possibilities like bowstring durability, separate armor layer durability and so on. Granted, it might get complicated and annoying, but the first solution is always a possibility as well.

It's at the top of the screen, to the right of block info. In most cases you have to point at a relevant block (e.g. at an anvil if holding a hammer) for it to be visible. If Sprint + F or Crouch + F to cycle tool modes were to be added (I would prefer Crouch + F), then I would want that indicator, maybe along with the mode's name, to show up next to the cursor for a moment when switching modes. Perhaps it could also appear briefly when switching tools or when the cursor is moved over a relevant block. Maybe have an option to just keep it there at all times as well, though it would have to be mostly transparent or otherwise less obtrusive.

An alternative way to obtain salt would be nice. I would imagine, though, that if sea salt is ever added to the game, it would be a more lengthy and involved process than just boiling seawater in a pot. That's just the balancing approach in Vintage Story, from what I've seen - it can't be too easy to obtain in large amounts, so that food preservation isn't trivialized early into the progression and seeking out salt deposits retains most of its attractiveness. Perhaps something like this, after a relatively quick search: salt very slowly deposits in shallow depressions very close to coastline in areas with low rainfall and decently high temperature, scrape the accumulated salt to obtain wet salt cake, wash the cake clean to obtain concentrated salt brine (pretty much the same mechanic as panning), pour the brine onto shallow ceramic evaporation pans (pans made from lead or iron could contain more brine and increase evaporation speed), put the pans over a fire to evaporate (could be done on a firepit, would take a fairly long time), finally, scrape a small amount of salt out of the pans (I'm not sure about exact conversion ratios). The above process has the advantage of being easy to build from existing mechanics despite being fairly complex. More advanced saltworks could be added as well, but it would be a larger and more challenging to implement feature, and the level of complexity may be a bit excessive even for Vintage Story unless significant simplifications from the real process are made. I mean, they could reuse barrel mechanics and have the player use a single pond for evaporation, but I'm not sure if that's particularly exciting compared to the real setup which takes in seawater with the tide into a large pond, and then requires small gates to be opened to move the brine into a series of similar ponds at appropriate times over days or even weeks until salt crystallizes in the last one and can be raked. Starting with a simpler setup, easier to implement or mod in, would allow to gauge the balance and community sentiment before putting a lot of time and effort into the big thing.

Focusing on this group (humongous sample size of 3, since your previous post) seems like a very basic logical error to me. Remind me what it was? Selection...? Survival something? Every single game has a target audience, and the games with widest appeal tend to be shallow and generic. If a mechanic is not to your liking, then mods are your friend, not a way to wave you off for the people who don't see the need for it to be changed. If a mod becomes popular, then devs have more reason to implement something similar into the base experience, and also have a working example of the functionality which reduces uncertainty that would come with implementing a completely new and untested feature. You'd be more likely to be listened to if you actually listened to others yourself. But I don't know if you want to engage with it, since there's no guarantee that it will work. You're clinging to the idea that prospecting is being replaced by mods while ignoring two explanations of what the most popular prospecting mod actually does, seemingly unable to check it yourself as well. And you're maintaining that people who don't want the system changed (aside from Thorfinn) use mods that "fix" prospecting, despite multiple explicit statements to the contrary. Other mods tend to be gamey or bloat the prospecting pick with multiple largely redundant modes, but the most significant ones from what I've seen at a glance are: - depth-independent (usually high-range) Node Search variant - also suggested in this thread, - proximity to nearest ore block - seemingly the most common suggestion, and probably the least creative as well, - long-range search for rock types instead of ores. I think there's also a mod which overrides the permille value to correspond to the actual amount of ore blocks in an area. There are some ideas for various, minor or major, ore generation changes. Some ores could have surface-level signs, like discolored vegetation near sulfide deposits. Veins could be larger (but low-yield) to reduce the frequency of shafts that have to be sunk. Lastly, there are other suggestions which focus on adding less random alternatives to prospecting, primarily through processing large amounts of low-grade ore. And I probably missed a whole lot, still. Any of those strike your fancy?

Fair enough, and I'm now also thinking that cases where a player would specifically want one of the effects and not the other are rare enough that a common strategy could likely be to just place both devices next to each other. If anything, there's still an option to make it configurable with a checkbox or two, or diegetic levers. It would also probably just be easier for the devs to add a second effect to something that already exists.

I disagree here. The stability gauge already keeps the player informed of their own stability level, as well as whether or not the local area is stable or unstable. I will note that the sky does already turn sepia in unstable areas, however, it takes a massive amount of instability to cause that effect. I have to agree with the take that some in-world feedback would be arguably much better than having to look at the spinning gear. Sky turning to sepia in unstable areas isn't really a proper thing, in the sense that it's caused by the player's low temporal stability and not unstable areas directly. Here's a suggestion, though: sparse and warped vegetation. Also lack of regular animals and erratic animal behavior if brought into the area. Doesn't have to be a drastic effect like a deadly disease hit the place, but just enough to slightly change the vibe and make the player feel like something's off. Perhaps also some dark mist and smoke or strange stone intrusions, maybe some mutated or glitchy insects, or anything in that vein, to enhance the unnaturalness in the areas and also introduce some underground indications of especially unstable places, not just surface ones. I don't know how many people actually refer to it as "sanity", but I've never once felt like it would be more intuitive myself. Either way, even if it's a large portion of people, I don't think that's a good reason to just rebrand it to sanity. If anything, I'd prefer that the feature be expanded to be more distinct from typical sanity mechanics and have more impact on the world, rather than just on the player. Granted, the current effects of low temporal stability - glitchiness and waveyness, texture overlay, massive gears turning, nightmarish monsters - do kind of give sanity vibes and arguably are not very good visually (I had to turn some of them down in accessibility settings, just couldn't really play with them normally). Full support on that, I was personally kind of surprised that the rift ward doesn't already just increase players' temporal stability slowly to counterbalance temporal storms and low-stability areas. The exact balancing is up for debate. Big changes kind of feel like they could justify a name change as well, although even a very surface-level glance makes me feel like blocking rifts and improving temporal stability are probably a pretty similar thing lore-wise. Still, a separate device could be a bit better gameplay-wise, mainly because it should arguably last longer than a rift ward and act in a larger area.