Katherine K

Playable flute wouldn't be particularly hard to implement. I can see someone taking it on as a bit of a distraction from some major main task. Sometimes, "scope creep" isn't a bad thing, if it helps your team not to burn out. We often had game jams where people can work on whatever they want for a week at several studios I've worked at, because you get some really fun ideas that way, and devs usually end up rather recharged as a result. This is particularly great for sandbox style games, because a lot of these experiments can become real features.

This is the sort of thing that made me really appreciate it when Minecraft added a proper tagging system to the datapacks.

I don't know how y'all play the game, but when I was playing with temporal storms on, by the second one I'd have bronze, and by the third one I'd have a small windmill. Just one set of sails, but it was turning the quern for me. So I have one storm worth of panning, and one worth of querning, and then there's the rest of the game. I can make a drifter grinder without needing a storm. All you do is dig out a section of a cave and set up some water channels. You stand there until your temporal stability drops enough and the hatman drifters start appearing in numbers. All the benefits of the storm, none of the inconvenience. But it's boring and not fun to play that way. Mob grinders work fine in games where you build an industry out of it. And at that point, it's no longer a survival game. So after all that, I'm still just better off surrounding myself with dirt, waiting for the storm to pass, and then do whatever I was going to do anyways. Just ten minutes later. I started disabling the storms all together and I'm having a much better time playing the game. And I'll recommend to anyone to play the game with temporal storms disabled. They add nothing of value to the game as they are right now. Not as any sort of a dig against the dev team - I get the concept, and I'm sure there will be further improvements. But right now, the game's a better game without them. I'm much more split on temporal stability and rifts. These feel like they add to the game. They just happen to not be adding something I personally want, so I keep them off, and turn up some of the other survival aspects to compensate. But I get why a lot of people consider them to be core of the experience. Storms are, at best, just there.

I was reading up on the temporal storm suggestions and I still had the sailing context in my head. And I had some ideas. There being things in the water might really be the ticket here to make sailing engaging. It'd fit the mood extremely well, and will give the player something to do. But it has to be done right. Simply having things spawn and be like random mine fields you either run into randomly or have to constantly avoid would be awful. What I'm picturing is more like weather. Something you can see looming on the horizon like an approaching storm. Heck, it could be a literal storm, but worse. I'm sort of seeing this as composed of two parts. One is just a new kind of enemy that lives in the water and attacks you whether you're swimming, rafting, or sailing. Perhaps, with more options to outrun it when sailing. (If wind direction becomes a factor, maybe you can only sail fast enough to escape in certain directions.) The crucial part is spawn conditions. It should show up only during a temporal storm. The second part is these moving storms in the ocean. They could be like a weather phenomenon, but it might be more interesting to have another entity be at its center. This could be a leviathan or a ghost ship from the rust world. Honestly, the nature of the entity doesn't matter too much for this discussion. What would matter is that it can then respond to player and potentially give chase. I don't think it needs to be difficult to outrun it - just the fact that it can move to cut off the player if the player gets close enough is what matters here. The entity would be surrounded with darkness, thunder clouds above, stormy weather, and temporal storm conditions. Meaning, yes, you have to now worry about the water enemies popping out from any direction. So what this does is add an element of planning as you're sailing. When you see a thunder cloud on the horizon, you have to ask yourself, do you want to risk it being just a regular weather or do you want to take a scenic route that avoids it all together? And if you decided to get closer, and you realize it's probably the bad kind of a storm, do you want to turn around now? Take a wide arc and hope it's going in a different direction? Or try to sneak by and hope it doesn't give chase, cutting you off? (Honestly, having the entity have a chance to notice you increase with boat's speed would be great here. Cutting sail to quarter, and hoping you can just make it would be amazing.) With the right level of risk, the density of these storm entities, and ability to anticipate where it's going to go, this can be just the right level of engagement for long voyages. You still mostly point the boat in a direction and wait, but now you're watching the horizon, referencing the map, and maybe even looking for clues in the water if it's night and that's all you can see...

Because currently the game rewards you for packing yourself into a 1x2x1 hole and going to the kitchen to make a snack until the storm passes. And a game rewarding you for not playing it is not generally good game design. As currently implemented, best default setting for the temporal storms is off. And that's a good reason to discuss if they can be improved to change that or possibly really be off by default. And the thing is, the fix doesn't have to be necessarily to make you want to face the monsters. I saw a review of VS recently, and the author made a good point of distinguishing between a survival sandbox game and a thriving sandbox game. A good example of the latter is Terraria, where you get Blood Moon which rewards you for going out and fighting zombie hordes with both the unique loot and a huge supply of currency. If you can build a grinder, you're excited for when it happens. BM stops being a horror, a threat to survival, and instead becomes a lucrative timed event. This doesn't have to be the case in the survival game. In fact, it probably shouldn't. The idea that a temporal storm makes you go, "Oh no. Oh no, no, no, no, no," but with more colorful language is great. If it sabotages your plans for the day, it makes you make hard choices between tending your crops and live stock today and risk, and so on, fantastic. That's survival. But that only works if you are still engaged with the game. If your best option as a player is to just go, "I guess I'm not playing the game for next 10 minutes," the game failed. Your survival is not at risk. Just your fun. Giving a player a strong reason to keep moving could be a way to overcome that. Simplest would be to just put a timer on how long you can stay in one place and you start losing health if you don't move, perhaps even just using existing drowning or freezing mechanics, but that will result in players making series of hiding holes they move between, so now you still have the player not playing the game, and they can't go make a sandwich. So then maybe having penalty be applied to your base, and needing the player to move around maintaining something to prevent corruption/damage to structures, crops, and livestock. But then the solution is for the player to travel far enough to unload the chunks before the storm hits and still hide in a hole. Giving a player a reward for facing the storm is the simplest way to engage the player. I'm not saying it's the correct way to handle it, but it's worth discussing along with any punitive mechanics that encourage participation. The point is that something needs to change. The rest is up to discussion, and this is all this thread really is. Edit: P.S. Part of the problem is that enemies just sense you within a range. Having some stealth elements, besides simply changing detection radius with sneak, could create way more options. But you almost have to go to Alien: Isolation lengths to really make it work. And there still has to be a reason you can't just hide in a dirt hole. But some options there, at least.

It does sound like 1.21 update changes it so that you don't have to hold w anymore. That doesn't solve the problem of there not being much to do, but not having to hold a key is an improvement, letting you spend the time with the map, watching land you're passing, or even crafting on the voyage a lot more manageable. Adding wind direction and needing to adjust the rigging for the course you've selected is probably going to make things a bit more exciting, but for longer voyages, if the wind changes so often that you have to constantly adjust for it, it'll get annoying. And otherwise, it's still put a boat on the course and find a way to pass the time. And there's still only so much you *could* do. But these problems are there regardless of where you're going over a long distance. I'd argue that over land, it's much worse. Having large, open bodies of water gives you options.

That's probably best handled as a separate mod that uses hydro overhaul as a core. Water mills, angled Archimedean screws, and pipes would be a great mod to add on top of it. Rivers can probably also be a separate mod that works with all of the above, but for reasons I outlined in a previous post, hydro and rivers really have to be developed in tandem by the same person/team. @Seyko I wouldn't have the time to really drive a mod to feature-completion most likely. But I have tons of experience with relevant solvers. If I wrote a performant hydro core solver and a river carver as functional modules that do what it says on the tin, would you be interested in driving it to feature-complete and/or maintaining it? I'd also be perfectly happy making it a public git repo for anyone who wants to contribute, so that's kind of an open offer. I just don't want to put in the time if it's going to sit half-finished, perpetually out of date with latest version, and if it's going to be on me to polish and maintain it, it definitely will be.

Currently, there isn't really enough change from one body of land to another. I feel like you have to tune the biome/geology density as well for the world to be enjoyable with more water in it, but also a good balance of these seems very close. Maybe some of the fine changes in 1.21 will get us there.

I generally want casting, clay forming, and carving to get a bit more love in terms of creating custom things. There's no reason, for example, that you shouldn't be able to use custom clay-forming tools to make a custom mold, fry it, and then cast a statuette out of metal. And it really feels like it just needs a bit more UI to tell the game if the thing you'll make a clay form will be a block, placeable item (like bowls and jugs) or a form for casting, and then when you're working on these, a new option in the F menu to move between layers.

This is tricky. You need to make sure your system can quickly reach steady states so that you don't have to update a river-worth of blocks just to confirm that yup, every block still got as much water flowing into it as flowing out of it. This has to be built model-first with that consideration in mind. I'd also suggest that river generation is a huge project on its own. River formation is a kind of optimization problem that's not terribly complex locally - water solves it by just existing, and it's not very smart. But it does take millennia to do so, and you don't normally have that sort of time. You kind of have to pre-simulate rainfall and erosion over a very long time period on the map before you carve out final rivers and mark their watersheds. Then you can pre-place the sources that will generate more or less water depending on rainfall in the region, and the rest will be taken care of by your water physics. If you don't do this, and just try to use a random carver like Minecraft does, then the moment your water becomes simulated, your rivers are either going to run dry or turn into static lakes. I'll be honest, I haven't looked at VS world gen too closely yet. It sounds like there are some generation steps that are applied globally rather than generating one chunk at a time. That'll definitely help, since you do need that preparation step. But you probably also don't want to run the actual block generation for every single chunk in the world upfront (unless the game already does that on world creation...) in which case, you'd need an intermediate representation that lets you store the river as a modifier and apply during chunk generation... None of it is rocket science, but it's a lot of work. Trying to do that and water physics at the same time seems like it might be a bit much.

Nah. Say we wanted total overkill, where we solve for the flow in the entire system. There's a continuity constraint for each branch node, and then pressure/height gradient between the nodes. Say you have, what's a ludicrous number, 10k branches? That's at worst a 30k x 30k sparse matrix to invert to solve the whole thing. (1 potential + 2 flow variables per node). First time, say on load, maybe that takes a few seconds if it's a single thread in C#. Then any time you break or place a channel, walk that change to the nearest nodes in both directions. That gives you two rows and two columns to update the inverse for. If that takes more than 10ms, there's something wrong with the code. So if you were running smooth 60FPS, maybe when you make a new connection for your waterway, you get a brief hitch with one frame jumping from 17ms to 27ms. Then the workload per frame is to update any nodes in loaded chunks (if there was any relevant update to handle there!) and then multiply it into a sparse matrix. That's about 1ms worth of mul/add operations conservatively, so long as JIT cooperates and you don't trip on cache. So we're talking about bringing an even 60fps down to 57fps. And this is for an absolute monster of a farm with 100 x 100 nodes of irrigation in it, meaning if you have at least 9 blocks of channels between nodes, you have covered a square kilometer in irrigated farm land? And we're considering absolutely every single node of this to be available as source or sink, which realistically you'll only have at leaves. And we're updating the network literally on a frame any change happens and updating flows on every frame as well, none of which is necessary. Split that workload between a few frames, and you won't even notice anything's happening. This isn't a particularly hard problem. It's niche. Most software engineers don't have experience implementing stuff like that, but it pops up in a number of places. Physics engines deal with a very similar problem on solvers, where you might have thousands of contact points, each one acting as a set of constraint equations. A lot of computational physics deals with sparse matrices that are much, much larger without any problems as well. So the techniques are there.

So the water spread is not optimized to take the constraints into account. I wouldn't have expected it to be. It'd be trivial to do this optimization for irrigation channels/aqueducts in core game or a mod. I'm not saying optimization isn't important. It's just examples provided haven't been optimized, and they absolutely can be.

In Minecraft that usually happens because of mending. Otherwise, repair still costs an ingot. Which isn't a huge cost, but you still need to get more of that metal. Being able to recycle a portion of materials from metal tools and weapons in VS would basically serve the same purpose, but with a lot more control over how much you get back and how much you need to invest each time. So there's definitely enough levers here to keep the loops while not making the player feel like they're pushing a boulder.

In general, water flow gets computationally complex, because you keep adding adjacent blocks. It becomes a 3D problem. But if your water flow is mostly constrained to a path, it's a lot easier to update. To propagate water changes 100 blocks, you update a 100 blocks. If you just had water spilling everywhere, that'd be a million blocks instead. Ideally, for high perf, you'd constraint the flow to just blocks specifically meant to transport water. So maybe some dirt channels for irrigation and stone channels to build aqueducts with. It's a bit limiting in terms of what you can build with it, but performance wouldn't be an issue. If you want something more general, where water just flows, but can spread over very long distances, yeah, you start needing to get very clever with how and when you update things. Ideally, you want to solve for the connectivity network once, then instead of propagating the changes in water from one block to the next, you just update any sources, and all flowing blocks would be some matrix multiplied by that. You'd still have to do connectivity updates if a block changes, but it's a lot easier here to drop things you can't possibly influence. And you're still going to be working with some gnarly sparse matrices. It's a fun problem, but it doesn't sound to me like anything that complex was being suggested, and restricting water flow to blocks meant to carry water is probably enough.

Why, though? Why does it matter? Say someone breaks a section in the middle, and not enough of the length is loaded to have that propagate to the start and end. Does it matter? When someone loads endpoints, water will still flow. What kind of a problem does it cause? If someone broke middle by accident, it's not a problem until it's a problem. If someone was breaking the middle intentionally to stop the flow, walking the length of the aqueduct to update it doesn't seem like a huge ask. If it is - you can always break the section closer to where you need the effect. As an exploit? In principle, but what's the achievement here? You'll build an entire aqueduct, just to tear it down, so that you can have magic water transport? And one that only works until enough people walk in its vicinity for the update to propagate? It's certainly nothing practical as an exploit. In order for this to be an issue, the aqueduct will need to be hundreds of the blocks long at a minimum, with some express need to mess with the middle section without updating the ends. And I just don't see that coming up or really mattering. You just need the local section of the aqueduct to work so that you can walk its length once to make the flows connect, and past that, global correctness not being guaranteed is just not a problem.

I don't think that's actually necessary. A flowing block already has to know which block is feeding it. All it has to do is check that block. If it's loaded, check if the state changed and that change needs to be propagated. If it's not, then pretend nothing changed and maintain current state. Whether you're doing very simple Minecraft-like water where the state is just level and flow direction, or if you want something fancier, where you keep track of flow rates, this is all you really need.

I thought clothes repair with flax twine and linen was available to all classes. Sewing kit just gives you more repair per flax spent. I do think weapon/tool repair would eventually be nice to have, but recycling metals from them would be a good first start, since we already have that mechanic for some metal items.

Just being able to take slaughtered rabbits out of enclosure before trying to skin them would be a welcome change. All the other panicked rabbits keep resetting the operation. (And full domestication always takes a while...)

Yeah, you can't simply draw a river from a random noise, like you can with hills and caves. You basically have to do the whole watershed and erosion simulation, which is an iterative process that has to take a huge portion of the world. In other words, you can't just generate it one chunk at a time like you can with other terrain features. If you don't care about them flowing, and just want to make canals, that's different, and that's what Minecraft does, but that's not usable for water wheels or anything like that. Honestly, world gen will probably need an overhaul anyways. There are parts of it that are really good already, and it seems like a lot of generation does happen at startup, so there's a path forward on this. But I understand why it's taking a while. You also have to decide how you'll actually handle elevation changes visually. Current system supports 1/16th blocks easily, but that's still a visible step. Probably fine for collision purposes, with some visual smoothing, but it's not "free". This will take some engine adaptations.

The most sensible approach would probably be allowing us to use chisel like we would on a work item we want to scrap, refunding metal bits. Arrow heads can probably just give you two bits each (10 units of metal) and other tools could probably give a discounted quantity based on the wear, down to maybe, like 5 bits (25 units, quarter of original investment) if near zero durability? Having absolutely no reason to hold on to worn tools, instead just always using them to breaking, seems a little boring. Some means of repair or recycling would be great, and given that you might find tools and spear/arrow heads you don't want, recycling is probably a better approach to start with. Especially since we already have the recycling mechanic for select items. It's honestly weird that we can scrap a metal rod, etc., but not a spearhead. I suspect, this really is to avoid people from cheesing the durability on tools, but that's why I think a discount based on remaining durability would make it fair.

In general, yeah. But for lightning rods specifically, I don't think that works. Solder has two crucial properties: 1) It flows when hot, getting sucked into any thin gaps in compatible metals - which is crucial for electrical circuits to avoid air gaps and in pipes to avoid leaks. 2) It melts at a relatively low temperature, so you can work with it without damaging the main metal. And the issue is that you don't care about 1) for lightning rod. You could be dealing with millions of volts of potential difference, so any gaps you might have in your wiring are entirely irrelevant. In fact, people sometimes intentionally leave a gap of a few mm to avoid normal electrical currents flowing, which can help avoiding radio interference, while a lightning will jump that like it's not there letting the lightning rod do its job. So as long as you got the two pieces of metal close to each other, you're done. You don't need solder in between. And 2) actually hurts you. Energy of a typical lightning strike can be in GJ ranges. Most of it, thankfully, gets deposited into the ground and air, but the lightning rod gets *hot*. In some cases, destructively so despite your best effort. But the last thing you want is something like solder holding it together. That will absolutely, no question melt. (Solder has relatively low resistance, but still high compared to copper, so that's usually where a lot of heat dissipation takes place.) And if solder was what held your lightning rod together, you now have bits of fire-starting hot copper falling down, which is the exact thing you wanted to avoid from the lightning strike. And if you had something else hold the metal together, then what's the point of the solder? Using rods to fit together into a structure is probably as close as it gets to making an early-tech lightning rod. Presumably, you'd make some indents on the ends of the rods that let them fit together mechanically. Yeah, I'd probably want a short segment of copper pipe to hammer the rods in from both ends to really make it work, but for an in-game approximation, 3 rods in a grid kind of works. All that said, aside from lightning rod, which happens to be a uniquely bad example, I do wish we'd have a lot more uses for solder. It's just the parts of the still now, isn't it? Crafting chutes and hoppers for starters, maybe? Lanterns as well? Although, some of the metals lanterns are available in aren't exactly solderable. Hopefully, we'll be getting some sort of fluid transport in the future. If we'll have steam power, we'll certainly have piping. That'll be a fantastic place for more solder use.

Standing on the top of the ladder, closing the trapdoor, and jumping isn't awful as means of getting around the current limitations of trapdoors above ladders, but I really do like this idea. Honestly, might not even need a recipe. I don't see a reason why all trapdoors can't just count as ladders when open. It's a higher tier/cost item to build, so I don't think we're at risk of people spamming trap doors instead of ladders, aesthetically, it works, and logically, if there's a thick wooden trapdoor hanging open, I absolutely could grab onto it, and go up it with only slightly more inconvenience than going up a ladder. So just make them always climbable in the open state!

Entirely tangent, but I don't know why it didn't occur to me until I saw this that yeah, generators are perfectly viable at the level of tech we already have. Sure, drawing and coating enough copper wire would be a right pain, but technically, nothing stops you from building one if you have access to copper, iron, wax or resin, and driving it from a windmill isn't that different from anything else we do with mechanical power. Realistically, the kind of RPM you want to get practical voltages would wear out the wood gears and axles instantly, but so would all the gearboxes people are building to make their hammers go brrrr. At some point, "it's a game," does have to come into play. Fingers crossed, future steam power update will give us more options with mechanical power transmission and conversion, and between that, glass blowing, and alchemy, we'll be able to make custom neon signs. Pointless? Yes. But what a flex it would be to show off neon signage on your builds.

There are different approaches to proc-gen that one can take, and store/re-generate different amounts of data as needed. It seems like the engineering team on VS is perfectly capable of working with spatial hierarchies and memoization techniques required for this. The high level concept here is to make your proc gen fractal-like. This lets you "warm up" distant chunks without running full generation. E.g., you probably don't need all the cave generation to be done when you're just passing by a chunk within render distance of it. And you can store just what's been generated for future use, so if you have multiple players repeatedly using the same route, the "edge" of the generated region can remain low fidelity until somebody decides to explore the area properly. It's work, and for all I know, that's what's planned for the future, but the good thing about this is that it can be done incrementally, improving performance and increasing viable world size as you're making it better. I'm optimistic based on what I've seen so far.

Seems like a tech compromise, possibly a temporary one. The ingot isn't really the same item until it cooled down to a certain temperature. Making it all work exactly the same would mean you have to be careful not to melt ingots in your forge. Which might, actually, be a cool addition, but would make working some of the softer metals a proper pain if you're not careful enough juggling ingots between the forge and some temporary pile. I do appreciate the fact that you can still pick up the ingots while they're kind of hot and put them on the forge already at 300°C or so, potentially saving a bit of fuel if you're working a bunch at once. But for higher melting point metals, like copper or even bronze, being able to dump out an ingot at 700°C straight onto an anvil, skipping the forge entirely, would be kind of neat, yeah.