Rainbow Fresh

Hmm, I guess. Though considering we currently incur a loss of 75% of the log's volume by chopping it by hand, I think the game-ification process of tier progression (stronger/more expensive lategame tools = more output) could still rather increase this. As mentioned before it also doesn't have to be an actual sawmill with saw blades. Could just be a mechanically powered splitting head.

Holy circles ancient latin font. I cannot imagine how long this took.

Realistically is might be true that a proper, normal sawmill operating on entire logs does not make firewood, which are rather chunks split out of a small part of a small log; but I think the notion of video game progression is a fun enough argument to make it believable enough that firewood in VS is just 1/16th chopped out of the log (seeing as visually 16 firewood occupy the same space as one log [even if it actually stores 32]) so having a 3-bladed sawmill through which you shove a log twice (cutting, flip 90°, cutting) could work. Naturally the process would be slower than the current mass stack conversion in the inventory but as SnapJelly said, realistically speaking you don't just alchemy-transform items and if the devs eventually get rid of grid crafting I'd assume the process of manual firewood splitting would become atleast as slow and tedious as putting a log on a chopping block and clicking it with the axe there. Therefor an automated sawmill approach would atleast allow for automation so that you can slowly process entire stacks again without constant supervision, much like an automated quern. Only problem would be how to differentiate between wanting to saw a log into board and sawing it into firewood, but going by the decent example of aforementioned mod there'd be two different machines for that. As for why it'd give *less* wood I really don't get. No matter if you saw a log by hand or by fixed contraption, the resulting volume would be the same - and speaking from a videogame balance perspective there needs to be an incentive to upgrade to higher tiers of equipment so if the good ol' axe made in 10 seconds from a stone and a stick gives you 4 per log, a big machine made from a shitton wood and metal and requiring a functioning mechanical network as starting investment better give more than that.

I'm all for a sawmill, if only to bridge the incredible lack of anything meaningful to do with your mechanical power. Not to mention the immersive effect of the sense of progression that could generally replace the crafting grid insta-craft (as the devs want to gradually remove from the game anyway.) The Immersive Woodworking Mod already does a great job introducing these things and I love playing with it ever since; higher yield from investing into better equipment.

Please don't feed the trolls. Grandpa here has been wandering around unsupervised publicly proclaiming how he "refuses to accept" any reality that doesn't align with his in plenty another discussion already. There is no point arguing and nothing to be gained from trying.

Shift-Click crafting is currently whacky and error-prone, so I'd assume something like this just goes on the pile aswell.

Depending on how bad the drain is you can just tank it, if you don't live in it 24/7. Otherwise I can also recommend mods to help with it in a fair and survival way.

Areas of the map have a random "natural stability". This is determined at world generation and there is nothing you can do to change it bar mods, or turning off temporal stability alltogether. So by all means, the dropping stability should have already been nine months ago when you settled there - maybe you just didn't notice it if it is subtle?

So I am playing a world that was generated on 1.21. As such, many traders in the general vacinity are still from a time where they were all traveling in carts; so is the Treasure Hunter in front of my base. I was about to construct a road to his little abode when I thought to myself - why live in a rotten old cart when everyone else these days gets fancy ruined housing? So I wondered - can I teleport this man out of his cart, flatten the whole thing in creative, spawn in a proper trader hut, and teleport him back in? And will that work, or are traders somehow bound to the walls they got spawned in with? Cached confines they shall never leave, this man forever trying to walk on air where this cart floor once was?

Pretty sure that's what the World Edit suite is for. Accessible in Singleplayer or with the necessary Multiplayer permissions by either using the set of "/we" command or enabling the graphical interface by typing ".we" in chat. https://wiki.vintagestory.at/How_to_use_WorldEdit

Did you know that? Vanilla Vintage Story has functioning, proper elevators. Now you know! And now that you know that, I'm sure you are either eager to get one yourself at best or curious about what the hell I'm talking about at worst. First things first though: Depending on how much you interacted with the story dungeons so far, the reason why you didn't know this before is because this is by no means obtainable in survival. Yet, atleast - I'm hoping the future rectifies this or atleast someone makes a mod for it (don't look at me like that!) So if you want to have an elevator in your world that badly, you need to either Be in a Singleplayer world and willing to use admin commands and creative mode Be a server owner, admin or creative builder with the necessary permissions to spawn entities, spawn items/use creative mode and run "/dev" commands Create a world-edit blueprint in a separate creative mode world that others can import into their own Sounds good? Good. Now how do you get that sweet, sweet vertical transport device? First off, you want to go to the creative mode inventory and look for "elevator". You will not find the actual elevator (it's an entity, like a boat that goes up and down) but you will find two components you will need. The first the toothed elevator rail; clutter that's just to make elevator look believable and not just float. You will need to dig a 2x2 blocks shaft for where the elevator goes and then I'd heavily recommend lining the walls left and right of where you plan to enter and exit the elevator platform with the rail. The clutter item aligns itself visually with the furthest back-left corner of the block placed, so you want to place it on the right block of the shaft half. Also mind that like most other clutter items, depending on which angle you look the thing can rotate in 12.5° steps so better stand completely straight in front of the target wall, otherwise you might end up placing it weird and the hitbox is unreachable and you can only get rid of it by "/setblock"-ing the thing into air. Now that you have an elevator shaft (I hope you considered digging it 1 block deeper than necessary and, if fully enclosed, gave 2-3 blocks of headroom), it's time to grab the second item: The control lever. I don't know if the 2-lever variant works aswell, I only used the single lever. This is a special block and using anything else won't work, unless it's modded in AND the mod made it a valid elevator control. Place one on every level you want the elevator to be able to stop at - vaguely, does not have to be exact; we'll deal with tuning later. Keep in mind that it seems like there was no rotational variants added to the lever block (despite interaction tooltips saying its supposedly wrench-orientable) so it will have to go onto a solid surface (lest it floats) and you just have to live with its fixed orientation. Finally, you want to position yourself in the very center of the 2x2 shaft, fly up to slightly above the shaft and finally get the actual elevator by spawning in the entity code "elevator". ("/entity spawn elevator 1"). As the elevator - in its initial spawn - is also fixed, should you have built your shaft facing a different way you will need to rotate the elevator by looking at it and running "/entity rotate l[] yaw 90". Congratulations, you have everything in place! But this isn't it yet, sadly, the elevator system is not that robust. You will find the levers doing nothing and the elevator floating there, menacingly, and being rather pass-through-y. Now what? Now comes the hard part. You have to set up the elevator network through two "/dev" commands. This is the finicky part as it's easy to mess up and can lead to unwanted results. First, look at the elevator again and run "/dev elevator sen l[] <network code>", whereas "network code" is a single-word (no spaces allowed) name you personally choose for this elevator network. Remember it well. With this you have now successfully created an elevator network and added your floating elevator platform to it as "the elevator". Said platform mayhaps also started emitting particles. Now you only need the stops. Go to each of your placed control levers. Get their exact block coordinates (or stand on top of them, if possible, to make it easier). Now run "/dev elevator sbn <network code> <position> <offset>" for each of them. The network code is the one you used for the elevator before. The position is either the block coordinates or "~ ~-1 ~" if you stand on top of it. The tricky part - is the offset. The offset determines how many blocks on the Y-axis (up + and down -) away from the actual lever the elevator will stop at this "stop". So if your lever is placed directly on the ground, it'd be "-1" as you want the elevator to stop one block below the lever; flush with the ground. The finicky part is... If you mess up and use the wrong offset. You can obviously run the command again for the same lever with a different offset and the lever will correctly set its own stop resulting in the elevator correctly stopping at the correct height when you use the lever to "call" it. But, if you actually use the elevator itself (by sitting down and using the "up" or "down" control levers inside), you will find it also happily stops at the previously set wrong offset - be that in the air; or the ground. That's because the elevator itself is stupid and not actually linked to the levers; it just remembers "a stop was added at Y-level ABC". Because of this, and the lack of any further commands to control this, it will also remember every wrong offset ever set. Which can make the experience very annoying. Now, as far as I am aware restarting the game should fix this - as I don't think the elevator system itself gets saved, it just gets re-built from the actually existing (block) entities which remember being supposedly part of it. So after a world reload only the last applied offset per lever should apply. But in case this is not true, or constantly restarting the world too tedious (or, in case of a public server, not likely to happen) or you just overall want better controls for a better time, I made a mod specifically for this case - shameless self-plug and all! https://mods.vintagestory.at/moreelevatorcommands That's it - you now control the powers of elevation! I can see why this is not survival-ready right now but also think it's such a cool, underutilized feature that more people could use for cool builds. And maybe spreading awareness about the possibilities might encourage modders to utilize the already existing framework to make even cooler things! Adding storage capacity to a service elevator, anyone? Pretty sure you just need a slick new elevator model and steal the boat's ability to attach a chest to slot!

I guess you need to look around a bit more closely then. Clay is by no means valuable, unless you are burning through your Fire Clay supply - which is rare, tedious to produce otherwise and needed for much more valuable late-game progression. So... ...as Enby already mentioned - it's not about the min-maxing of materials. If you think the look of cobblestone fits whatever it is you are building nicely, then use cobblestone. If you more want a texture like the w&d blocks, then you know where to spend your resources. Yes, w&d is 1:1 clay for blocks while cobblestone is 1:2; but it is much easier to just grab a stack of dirt, a stack of sand, a stack of clay and cut a bunch of grass to make a stack of blocks worth of daub, which could last longer if you don't fully plaster every single block than it is to grab a stack of clay and *eight* stacks of rock to make 2 stacks of cobble - especially since the latter *certainly* requires you to already have a pickaxe while w&d can be done theoretically day 1. They may not be renewable but especially dirt is something you should not think about. You'll more than quickly enough find that you'll get more than you'd ever *want* to store of that stuff if ever you do any kind of terraforming or excavation. If you *want* to think about it and be smart, you'll specifically use low fertility soil for crafting and keep medium+ for when you need to place some but that's it. Sand might become more of a dwindling commodity in your area if you use alot of it; but the only other thing you'll really need it for is mortar which is it's own very tedious and costly process just for an as in-efficient fancier brick. And usually there are patches of sand all over the place, especially near/in gravel deserts, and mortar isn't picky of the rock type of the sand so that's not really an issue either.

I like the idea of a description when you click the marker. Gives the ability for longer descriptions without completely blocking the map on hover. That said, I too both color code my waypoints and name them like what's there but in shorter form; so I may have a propick icon (for general area rockstrata readings) that is dark gray (because slate is the first layer) named "Slate - Conglomerate - Basalt"

I used a calculator once at the beginning. After getting the questionably late Eureka realization that... in bulk the Tin Bronze can be scewed to use slightly more copper than the (at the time perceived) scarce tin than just doing 9:1. Ever since then I have just been eyeballing it though with slight adjustments in the higher bulk ranges; so technically using neither a calculator nor my brain. And none of this matters once reaching the iron age anyway, so... I like the abacus idea should a calculator be added to the game for, e.g., alloy rate calculations but I don't think we need a tool like that specifically. Gotta do some work by good ol' hand!

Oh boi, I ain't gonna read all the rest as it clearly seems like we are still spinning in circles. "Reading is a nice skill to have" - Yeah, so is being able to accept the words you read without having to go "Yes, I can agree with that, but actually you are still wrong so here is my single take again". Your numbers are swell and all, but have we all ever considered one teeny, tiny, crucial core consideration here? You say you want to have about 2h of food available. So that someone with nothing to their name on an always-on multiplayer sever with no available outside help can return after a long, long period of absence and have the mental freedom to just "Come back for a quick round of something fun". Something fun here being anything but engaging with the game's core premise of *survival*. Ok, fine. So we now introduce reliably available forever food that a fresh, bought the game today, first days player can acquire in preparation (so, the half a stack full of emergency cattail roots I was running around for like 100h with) for the potentially inevitable black-hole that rips them from video game reality, while being otherwise such a bad choice to consider for food (so you have to do double the work - make food and make backup food simultaneously) for anyone else. The person in question has now done this - solely moving the impact of how shit it is to have to deal with food when you would love to do virtually anything else by preparing food in advance instead of making it a re-entry hurdle; And now the big question nobody talked about before (or if it was in the last 3 walls of text - sorry, didn't read): What then? Your player comes back for a quick, small, 2h session where they can live off of just their forever food supply and not worry about starving while "finishing what they started" before leaving. Then log off again. Cool. And when they... log in the next time? Still no food. Forever food supplies gone. And, you won't believe this, we are in the exact same situation we would be in without this forever food, just postponed by a single short gaming session! At this point, no matter if they keep playing regularly (in which case bro, if you plan on keeping up then keep up and solve the food issue first) or vanish for another IRL month, they have no food. The only way to return to the game and continue is by getting fucking food. An entire mechanic that already spawned THIS much controversy BEFORE even being implemented, to give the single-odd player on a big multiplayer server (that only a part of all VS owners actually play on) in a really inconvenient situation (possibly of their own making) can get 2 whopping hours of leeway. Leeway that, by any means, should generally be used to acquire a proper food supply again anyway. You don't come back after 6 months with nothing left to your name and focus on just "Oh yes, I wanted to chisel this bridge!". That's like returning to your IRL wood workshop with a half finished table you wanted to finish after a year, thinking you could just waltz back in, fire up the saw and do it - ignoring the completely dusty place, probably unpaid electricity bills so you got no power, maybe a critter infestation somewhere in the corner; and you are suggesting adding a roomba for this particular person to be able to ignore reality for the entirety of this one unfinished table. I'm generally all for making the game enjoyable and accessible to people and I do understand where this "mental wellbeing" argument comes from. Re-entry hurdles are what kills games. Anyone who ever played a mobile/gacha game knows that. All this FOMO, all this routine that if you fall out of the loop just once, catching back up would cost you more than you are willing - or able - to give. But at some point it just gets ridiculous for how far you want to go. The argument of wanting more readily accessible forever food as emergency ration for unforeseen circumstances so that people can more easily get back into the swing of things? Decent. Doing so under the pretense that this is *specifically* for that 1 in 10.000 players that winds up ignoring or very unfortunately unable to obtain all the other failsaves? Questionable at best. Now we have specified *even further* that we do this for poor John who only played the game for like 15h so far? At this point, screw the re-entry hurdle this guy didn't even get over the normal entry hurdle! We could reasonably argue that this person would not really lose much of value even if they had to start over fresh because they get trapped in a starvation loop! People have restarted playthroughs for much sillier things! So no. Good job on all the calculations, even though my personal experience doesn't seem to really back them up. But this is plain out getting stupid. Not to mention constantly moving the goalpost to try and find some tiny bunker corner you can hide in and defend your claim, then yelling at people for not understanding what you want. If we really want to give more leeway to multiplayer people - the notion that the player's inventory is safe from time progression while offline is the most sensible path here. Even though I still personally think we don't really need that. Now, for the side quests: Animal starvation. You can run a test to prove me wrong as I am solely going off of memory and personal singleplayer experience, but animals don't lose weight - ever - outside of winter. I'm also rather confident they need to be actively loaded in in winter to lose weight. So no, the player vanishing for several in-game years, living alone far away from everyone else so their chunks should never be loaded in will have good weight animals at the ready, even if coming back in the middle of winter. The "But we have other forever food why are those ok and this suggestion not?" argument. For all I care, the other forever food can get a perish timer like anything else, and most of them probably simply don't because nobody bothered updating the necessary mechanics. Walnuts - probably non-perishable because they are primarily tree saplings, and tree saplings don't spoil. Makes no sense to me and I defend my stand from another thread discussion fruiting bush cuttings: They are all plants, plants die if not in soil - give saplings perish timers. Seeds could be too tediously unbalanced but saplings; there is no need to stockpile them. Cattail/Papyrus/Tule roots - and probably bamboo shoots as well. Plants. Rot. Done. Vintage Beef is a rare easter egg - can stay. Honey; at some point putting a 100 year timer on things is just silly so ok, can stay non-perishable for simplicity's sake. Fat; now this one is a tough one. Making it inedible seems a weird downgrade yet making it perishable also seems weird as it is primarily a crafting ingredient for all things mechanical. Or sealing crocks. But considering you need fatty animals for this, the gate to obtaining is high enough so we can overlook this. Now as for how *long* all their perish timers should be is up for discussion and balancing, but all these other things should really, reasonably, rot. Boom. No more "but we already have it so why not have more" argument for forever food. And the traveling discussion - yes yes, it's *not the core claim, just an optional bonus*, I know, calm your horses. Long distance travel in Vintage Story - is an active challenge. Because basically all food spoils, and most of it rather quick, logistics is something to genuinely consider. Building outposts as resting spots where you can stock back up - not because you have a trunk full of non-perishables to gather from, but because you have a small, functional secondary base from which you can forage, hunt and fish. On top of potentially storing long-lasting food like grains in a cellar should you anticipate coming this way again soon (like a camp on the way to a new story location). Especially when going south, chances are you can establish an outpost where you can plant some crops that don't wither all year round. On demand food. Or bring and propagate livestock. It's an active investment like most anything else in the game, and by design - a good design that is what makes VS stand out and fun for myself and others. The world is already bland, repetitive and boring enough, could you imagine running 20.000 blocks in a straight line with an inventory full of forever food? Atleast you have something to do! Keeping the eyes open for some foragables, managing stock; maybe spotting a particularly well-endowed buck to bring home as trophy. Planning where it would make sense to construct and outpost. Maybe planning roads to key locations for easier travel in the future. You want to take this away too? And the subsequent argument of the dangers of the poles... Is pointless. Going to the poles is currently literally just a bragging right. There is nothing there to do or gain other than going there for the sake of crossing it off the bucket list. As such, it is your responsibility to plan for this harsh trip, no demand things that trivialize it. And for those players choosing a cold climate start... They voluntarily chose this challenge and really don't need a cop-out either. But hey, as you said - forever food being good travel or outpost rations is just a side idea, not relevant to your core claim that you refuse to lighten up on no matter how many counter-arguments you are presented with, because you simply don't want them to be true.

Have you ever confirmed the one you grabbed off the tool rack in the first place actually was real? Client-server desync happens alot since 1.22, mostly with crafting though. Where you can seemingly craft things just fine (cause the client predicts it) and then, when actually trying to use things or place blocks the server says "Actually no, you never did" and the ghost items vanish into thin air with the original (material in your crafting grid) being retrievable again.

Everything in the VS databases is stored as raw byte data in BLOB format. You wouldn't be able to decipher anything if you tried. Since you are trying to transfer EVERYTHING over regardless though, just moving the data to the entry with the right player UUID should do the trick. EDIT: To find the UUID, just check "playerdata.json" in the "Playerdata" folder, assuming you both have been on the same world with your individual accounts.

Then what if it does spin normally and does produce power, but so little it's essentially worthless? It makes logical sense and could furthermore act as kind of "Didn't read the instructions" tutorial. You have a water wheel, you put it in water. It spins cause the water flows. It doesn't spin strongly enough though (bonus points if the stopping waterwheel also blocks water from flowing through) - the solution: You need stronger/faster water! Rapids.

Yes.

A room is any fully enclosed space of maximum 14x14x14 blocks dimension. A cellar is a fully enclosed space of maximum 7x7x7 dimensions with, I assume, an overall negative cooling score. I have no idea what the criteria for your HUD mod are to display either icon, but any cellar is a room, but better. It means things stay fresh longer while a room just... Makes you not freeze to death in winter. Your house being built out of stone makes all the walls certify for a cellar. Hence both your levels, I assume within 7x7x7 or 9x7x7 max 150 blocks restrictions, count as cellar. Remove one floor block and both rooms are connected, being bigger than that and only classifying as a single "room".

More information over here:

The block-rapidwater-* variants sound like item codes. You won't find those in the world because it's solely what you get from the creative inventory to place the actual block into the world. I'd also assume you won't find "rapidwater-still-7" as naturally generating rapid water is always flowing (or atleast in 99.99% of cases). So I'd assume, if it has the same naming scheme as normal water, that you are looking for either "rapidwater-flowing-7" or "rapidwater-flowing-6". Assuming wildcards work - which they usually do, you can also broadfire "rapidwater-*" and see if *anything* sticks.

Just a hunch that I cannot confirm right now, but try "water-rapid-7" or "water-rapidflowing-7"

On further investigation, the game's code has a sub-command for the /we (worldedit) suite "rebuildrainmap" that is supposed to regenerate just the rainmap for all loaded chunks. Assuming that is actually available in-game it would be a much safer alternative to full chunk regeneration - though I have had unreliable experience with commands before (e.g. there are supposed to be map command that allow redrawing your map for every loaded chunk but in-game that command does not exist) and I have not used worldedit before so take that with healthy restraint of excitement.

What player data are we talking about? If we are talking inventories, I think they could be part of the save-file SQLite database (if there is no relevant files in the playerdata folder, am currently not home so can't check). In that case you need to most certainly make a backup, get an SQLite DB editor, open that thing up, try to somehow figure out which UUID belongs to which player and replace it with the new UUID of the target player, then hope it works. Map data is stored on your PC in the VintagestoryData folder under "Maps" - it's a separate DB file with the filename being the UUID of the world (if they only played on one it should be easy enough - in fact, if they played on their PC they already have the map data they explored; you don't.)