Katherine K

That or double down on the idea of geological formation and strata, and simply base it on height from the surface. Seems like if land was brought up by geological activity, so would mineral deposits. Though, to be fair, I don't know enough geology to be certain about this. My picture of how the mountains form might be a bit too naive.

GREEN FLAME! No? Nobody? Just me? Well, never mind then.

Pure analytical solution of system of equations actually take way longer than iterative methods, because you end up having to find roots of nth-order polynomial, and for 5th+ order that's still iterative and much, much slower. Analogous problem that I have way more experience with is solving mechanical systems with constraints. Your standard games physics engine. The equations of constraints between multiple objects either connected to or in contact with each other, is actually very similar to the conservation of volume constraints for fluid flow, and the flow itself is very much analogous to the undetermined multipliers in the mechanical system - that is, the constraint forces. In other words, if you have two buckets connected by a tube, amount of water is total momentum, flow is the force, and the parameters of the tube are the constraint between the two. In a games physics engine, you could construct the system of equations, solve it, and just apply external parameters as inputs to get the solved flow. Problem is, if you invert analytically, it's super expensive, and the moment anything changes in the system, you have to throw it all out and start over. Iterative approach is very similar to how you solve linear systems via row elimination. (In fact, that is one of the methods, but not commonly used, because of some optimizations available in other methods.) You basically run through the matrix, and try to balance all of your constraints by pivoting the matrix. On each pass, you drastically reduce the difference between current approximation of the solution and the true inverse. So much so, in fact, that most game engines that use this method don't bother running multiple passes per frame. So you basically check for collisions, collect contact points, apply contact cache (that is, any contacts that persisted are initialized to last frame's step) and you run one iteration of the solver. Then you use that to compute forces and update positions. With a fluid solver, you don't even need to check for block changes. You run that via block update notification. If a block was placed or removed, update relevant constraints and re-initialize relevant flows if needed. Run one iteration of the solver, and update the flows. After a few frames of that to let things settle, if water hasn't spread to new blocks, you can put solver to sleep and keep updating the flows by simply updating the inflow/outflow conditions. This would be analogous in a game's physics engine to a crate coming to rest on the floor. Once the gravity and support forces are balanced, you no longer need to keep updating them every frame. In these cases, the simulated object goes to "sleep" and is woken only if new contact points appear or some external force is applied.

It looks like generation of most ore veins is based on the Y-level, rather than depth from the surface. While the shape of the vein itself can be based on the shape of the surface. I imagine, extreme height variations could push a portion of the vein that started generating at an appropriate Y-level to be partially above the sea level, but it has to be a fairly large, unusually high vein with very sharp variation in terrain. That's pretty unlikely. Especially, if you're interested in rarer, deeper ores. I haven't encountered anything that normally generates at lower Y-levels this way. In contrast, yeah, because surface variations result in distortions of the vein, and many veins naturally generate as a disk by default, if you hit one in the flat area, you just dig out the vein horizontally, having to dig through hardly any empty rock. Whereas in the mountains, the vein will keep shifting up and down from you, often requiring you to get through a lot more rock to get to it. And you end up creating more conditions for cave-ins (if you have these enabled) and unlit areas for monsters to spawn. I generally go where the prospecting pick takes me, but I do much prefer digging in the flatter areas for the above reasons.

Since there exists a natural injective mapping from the set of mathematicians to the set of assholes, namely, from each mathematician to their asshole, the latter trivially implies the former. (P.S. Yes, I know the reference.)

I'm a bit confused about "And You" in the thread title. Are we suggesting setting self on fire as method of illuminating the environment? I have safety concerns about that. In general, I want more chemistry/alchemy. Incendiaries and colored flames are a good use case. Don't know how much practical use there would be in flare arrows, but they're fun, so they get my vote.

That seems like a rather extreme reading. People are allowed to have motivations beyond what they publicly disclose without being liars and cheats. OP is concerned that some of these might run contrary to interests of some portion of the community. That is a valid concern. It doesn't make anyone a bad person. To dial it all the way back, the kind of game I want VS to be and the kind of game Tyron wants to make are very clearly not perfectly aligned. I'm happy with the direction VS team is taking, because the roadmap is clearly communicated and I feel like I can get a fun experience out of the game by changing a few settings from default. If for some reason I had suspected that roadmap is not accurate, and some of the settings I rely on might go away, forcing me to play Tyron's vision for the "correct" way to play the game, I'd be pretty unhappy. And that can happen even if everyone has best intentions and there's just a failure in communication. I haven't seen anything in OP's text that suggests that malice was involved. Only that there are what appear to be contradictions in public messaging. I've given a rundown of why I don't think there actually are contradictions, but I can understand why the statements can seem contradictory if you picture the process of making games a certain way. And that's something that's entirely fair to ask. I agree that some of the OP's posts can come off as combative, but look at all the other posts. The atmosphere in this thread is pretty hostile. I don't think it's fair to put that all on the OP. I don't think the pile-on was intentional, but it did still become one, effectively. And I'm including myself in the culpable group here. With retrospect of how this thread has gone, I'd probably word some of my posts different or avoided them all together. I think this goes for basically everyone involved here, at this point.

"At rest" photons also have energy and are finite. That's EM contribution to the vacuum energy. It's a somewhat outstanding problem, because upper limit on vacuum energy from cosmology is in disagreement with the lower limit we get from standard model in quantum physics, but both agree that it's non-zero but finite. Quantum mechanics relies quite heavily on any system being very large but finite, in general. And thanks to General Relativity, that might as well be true. Even if true universe is infinite, only a finite part of it can ever influence any region of space you wish to study. So for any practical purpose, the universe is finite and contains only a finite number of particles at any given time, because there are only a finite number of particle states to begin with. Too late. My Ph.D. research was particle theory. I never defended, because I ran away to California to join a circus game development studio, but I was basically finished with the research itself and had most of my dissertation written. (Thinking I'll finish it remotely. What a naive, young fool I was... )

I have seen a lot more over-reaction to your posts than from you. So this is totally fair. I don't think your concerns are going to materialize, but I don't understand why some replies are acting like you're a villain for having them. It's truly bizarre. Game dev is, thankfully, nowhere near that toxic in most places. And if anyone would tell others to, "keep their mouth shut," in a meeting, they'd be talked to to make sure that doesn't happen again. I don't know what it is about tech industry in general that makes people act in such insensitive way towards others' inexperience. Is it because salary is the only motivation, and so your career climb is the most important thing about the job? In game dev, we're there to make games, because we like making games. If somebody's having opinions about something they don't understand, it's not because they're trying to show off, but because they care about the game, want to contribute, and don't know how. A far responsible thing is to show them how, rather than just shut them up. I want someone to keep making good games once I retire, so I have to help junior devs learn. We still have a bunch of culture problems, and even just general tech culture toxicity seeps in, but just recognizing that people around you aren't a competition really makes a difference more often than not. I'd take the middle ground. College gives you the tools for preparing for a career and being part of society, because it teaches you how to navigate that repository of wisdom and how to learn from it. It's why the stupidest complaint ever is, "Why am I learning this, I won't need it." To know how to learn something you haven't learned before. You're going to have to learn many things not taught at your institution, and if you haven't learned how to learn, you're going to have a hard time. Kind of to that point, there are a lot of programs popping up that promise to teach you a specific trade and make you fully industry-ready. My experience with game engineers who've gone through this has been mostly negative. They are barely more experienced than someone we'd hire out of a high school. A bit more mature, so that's still a win, but in terms of the career skills, it's a start from scratch. I'd much rather have someone who had a humanities degree, then went to a boot camp to learn to program. That's somebody who knows how to learn. I know they can adapt.

Without seeing this from the inside, I can't speak with certainty, of course, but a lot of this is just how gamedev runs, honestly. I sort of get why these can look like a bunch of red flags, but it doesn't align with my experience. People making games have opinions about what they're making. If we didn't care what to make, so many of us could make better money elsewhere. But in the end, somebody has to call the shots. So there being a lot of input from the devs, while one-two people are making final decision is not a contradiction. You can often find resources for game B that you can't for game A, even if game A is already in progress. This partially goes to the point above. People don't necessarily all want to make the same game. More people working on the same project does make the project go faster, but it's not linear. If you double the team, you don't get the game in anywhere close to half the time. Because you get more inefficiencies, more management and planning overhead, more people butting heads, more stuff that gets made and gets thrown away, because some designs changed... In cases where there is shared tech, build pipelines, and other scalable parts of the project, having the team get split into two games might be the most sensible thing to do with the resources you have. And finally, finding really good people for all of the disciplines is hard. Even now, when so many awesome people got cut from their jobs due to many studios downsizing, hiring is a huge challenge, because so much about game dev talent is hard to put on a resume. When you know people, you've worked with them, you know that they're good and you know how to put a project together, and there's an opportunity to work with them again, you jump on that opportunity. I'm not going to say it's never nepotism, and higher up the chain you go, the more often it is nepotism. But what I'm seeing here, with Tyron wanting to bring in some known good talent from Hytale, is very sensible.

World gen would have to change quite significantly. Since simulated weathering/erosion would be part of the generation step, I suspect a lot fewer places would end up with straight up exposed rock, and most of these that would are already not great for settling. I don't think a bit of travel to find a suitable river to settle on is unreasonable. I do agree that this doesn't work great with the current respawn mechanic. But then I'm of the opinion that there need to be better ways to set a permanent spawn point anyways. As for mining, I think it actually needs a bit more challenge. I know collapse risk option already sort of gives you that, but flooding is a real danger in any mining operation. What this really says is we need ways to manage that risk. I suspect, we'll also end up with a lot more caves partially flooded as a result. Again, that is something you can account for in world gen, adjusting where the carvers are applied and what materials are added. Part of the problem is that a lot of these interactions are complex enough where it's hard to say how it'd impact the game and how to balance it without trying it out. I should have a bit of time I can dedicate to a mod coming up around mid-September, depending on how a few other things land. The core ideas behind aquifiers should be relatively quick to put together. Rivers and free-flowing water are a lot more work, but I think just having porous/cracked rocks able to hold water, replenish with rains, and fill voids is enough to test out key ideas to see if this has legs. If it works, I can play around with rivers/channels later. I have no idea if I'll have time to take it beyond proof-of-concept, but at this point I'm willing to give it a shot even if just to satisfy my own curiosity. I've done water physics for games before. But not quite like this. Could be very interesting.

Yeah, this is part of why I think the water solver needs to be very robust. Basically, you want to have concept of ground water. It won't be infinite, but it should be vast enough to be effectively so for most tasks in most relevant regions. OP's approach of allowing blocks to be porous is what lets you do that. Rain will wet the top layer of blocks, which will refill the ground water as water seeps through. At some depth, porous blocks are replaced by non-porous, and that holds the ground water. It's a simplified model, but it should be enough. That would make farming in some areas easier than others. If you have granite under 1-2 layers of dirt, you're probably not going to be doing much farming there without building an aqueduct from somewhere else. In contrast, if you have a thick layer of sediment rocks, you might have effectively infinite water, so long as you don't mind working the crank of a well. With current world-gen you could just use sea level as proxy for ground water level, and have it never change, but I don't think that's terribly exciting. With river basins being properly simulated, you could easily have areas that are 20-30 blocks above sea levels, yet still have lakes, rivers, and ground water that's just a few blocks below the surface. Solving for all of the dynamics on every game tick is obviously impossible, but also not necessary. Ground water levels should only vary gradually with seasons, unless player does something truly drastic to the terrain, which is also unlikely to happen all at once. So long as relevant relations between rainfall and water levels is pre-computed for every chunk during world gen, adjustments can be made as they come in due to player placing or removing blocks as it happens. And yeah, none of it is a requirement for water wheels. This would be by far the most comprehensive way to implement rivers, wells, and player-built irrigation. But you could absolutely just mark sources with "flow" during world gen, and only allow player to build water wheels on these. But then you couldn't, say, partially dam a slow river to make the water wheel go brrr, and that really seems like part of the fun with a feature like that.

Agreed, but the problem with this is that is a pretty niche task. If this was a large studio, it's not too big of a problem to hire a specialist specifically to develop AH. For the team the size of VS? I think the most viable path is that this is developed as a mod, then integrated into core VS with permission. Yeah, but a worldgen mod is entirely viable here. It would likely conflict with almost any other worldgen mod due how thorough it has to be, but so many people mod the heck out of their mechanics without touching the world, that I think it'd be fine. And again, if that becomes the starting point for integration into the game, that's fantastic. Performance is a big problem. I was thinking of how I'd approach the solvers for both the river worldgen and core AH, and I don't think I'd want the core to be running C#. Generally, overhead of pure compute isn't that high with C#, thanks to JIT, but it's still significant, and it's a lot harder to make C# code run better when you do find a bottleneck. Fortunately, it wouldn't be all that difficult to have a bit of platform-independent C++ code that runs the core solvers imported as unsafe DLL. The mod would then register any block changes with the core, run the sim tick, and then communicate any state changes back to the game. That would allow the core AH to make use of SIMD, threading, and better optimized code, while keeping the wrapper in C# land. That would make the mod to be harder for anybody to work with, but I think "hydrodynamics solver," even a highly simplified one, is already a pretty big skill barrier.

Still happening in 1.20.12. I have no useful information for repo conditions, but /time speed and /time stop commands had no effect, despite both printing standard response to log and the actual speed variable seemed to be updating fine, as I was able to read it back with /time speed. Exiting the world and loading in again had no effect. Closing the game and opening it again had no effect. Going to bed resolved the issue just like for other people here. That's all I got.

I've found that I have to set land percent a bit down if I want to get a world that has viable sailing. That doesn't seem to have changed much from 1.20 to 1.21, but I haven't played enough with the latter to confirm it.

I find that objections to adventure mode is very strange in a game where the base survival mode is technically a mod. Just one that happens to ship with the game. I can see some concerns about the team resource allocation, but it sounds like the intent is to expand the team. Adventure mode would then be developed basically as an in-house mod. The impact on the survival side should be more mechanics and functional blocks that ended up working for both. That seems like a win-win. Having worked on projects where sharing code between multiple games in flight is difficult due to them existing on completely different versions of the engine (or worse, different engines) and on projects where there is a shared core for multiple games, I much prefer the latter. Being able to share fixes, features, and just sections of code makes development far more efficient, expands the pool of people who can help, gives you better redundancy if someone goes on vacation or something, etc. You end up with better games in less time with less stress for the entire team. Throwing that away just because somebody is only here for game A and not game B is really silly.

Yeah, I would definitely want a realistic, inclined Archimedes screw for moving liquids up in any sort of a mod that tries to deal with liquids more realistically. Along with something like a suction hand pump for doing the same task manually, perhaps?

What a combination of topics to combine into one thread! We have clockmaker ability to hack locusts. I suspect any summoner-esque additions to be moving in that general direction. If you think about it, what is a roboticist but a sci-fi necromancer? The parallels between the two are under-explored, IMO. (Big shout to the Locked Tomb here.)

I assure you, my Canadian girlfriend is 100% real! But to bring it back on topic a bit, given that hot meals giving you heat is already a feature, it sounds like all we need is mechanics for brewing more drinks and reheating meals. Some of the flowers we find might be great for herbal teas, and yeah, if there are cocoa beans, hot chocolate. But also, how about some mulled wine? There could be so many new possibilities. The only limitation I see is that it really looks like heat is directly tied to satiety. Maybe drinks and soups should have a higher intensity multiplier? Water has amazing heat capacity, so it'd make sense for soups to warm you up better than stews despite not being as filling.

There would really need to be more fine control for this. Like, distance blocks can go, types of blocks this can affect, etc. Like, would I turn on this feature for items that can be stored on a floor in a pile, limited to a 3x3x3 area around the drop spot? Sure. It might be useful to just dump a bunch of nuggets while mining and pick them back up later. Blocks like sand and gravel showing up in a limited height tower and collapsing? Yeah that can be fun for hole filling, etc. Solid blocks? Probably not. Everything in my inventory in arbitrary radius on death? Absolutely not! I don't want to be on my way to build something, get jumped by a bear, and now have several stacks of stone and cobble to mine through to get my stuff back! The solution to death drops should just be a container, honestly. There are already mods that do this. IMO, this should be an option in vanilla and probably on by default.

Some people need a reminder that if you die in Canada, you die in real life.

Yup. Your body reducing circulation to the limbs in the cold is actually a defensive measure that protects your core temperature from dropping too much. Alcohol overrides this defensive measure, making your extremities feel warmer, but at the cost of losing heat a lot faster. Some colder places get a lot of alcohol-related deaths in the winters, because people fall asleep outdoors. People often think it's just the alcoholics that are at risk, but you don't even have to be all that drunk. If you just happened to be tired and dozed off while a bit drunk, your limbs don't get cold before your core temp drops too far, meaning you don't wake up from feeling cold and skip directly to severe hypothermia, lethargy, and eventually death if nobody intervenes. Once you are in a safe, warm environment, a bit of alcohol can help you warm up faster, because now the heat is flowing into your body, and restoring the circulation is beneficial. Doesn't take much, though. You certainly don't need to get sloshed.

Monsters is a bit generic. Works, I suppose. I was hoping for something a bit more thematic. I do like rusted. A bit allegorical, but fits at least some of the established narrative and themes.

Oh, I didn't even realize that's how that setting worked. I thought it'd just keep the wolves and bears off my back in the early game. I've been plinking at horrors in caves from the distance with the bow, and didn't realize they weren't hostile. Just tested it against a random shiver, walked right up to it while it was skittering about, and it was very, "How do you do, ma'am," about it. A very polite shiver, it turns out. Yeah, I definitely would like to see these split between animals and supernatural creatures. Do we have a canonical term for all of them, by the way? A lot of the older content refers to just drifters, but we now have shivers, bowtorns, locusts, and bells, and it seems like it would be convenient to have a collective term for all of them. Turned? Corrupted?

Yeah, there are things game fast-forwards correctly, and things it doesn't. Intoxication is in the latter category. Sleep should definitely reduce intoxication at least the same amount as equivalent number of hours would otherwise.