Streetwind

I think that anything in the player's inventory is fixed at x1.0 perish speed, but I don't actually know for sure. I might be wrong.

This is new with 1.18, in a way, though not as new as you may think. Food spoil speed has always scaled with temperature. The hotter it gets - and I notice in your screenshot that it is summer - the more quickly perishables will spoil. In previous versions, storage containers like clay vessels would display only their own modifier to food spoil speed, while the modifier from temperature was applied silently in the background and was not shown anywhere. From 1.18 onwards, storage containers show the sum of all modifiers applying to food stored within.

I would start by simply appending the word to the same command you already entered to get this message, and resubmitting it that way.

The default location for the game's logfiles under Windows is: %appdata%\vintagestorydata\logs

You're more likely to get an answer to this if you hop on Discord and talk directly to admins from large servers like Aury Fury, or even the official test server. There's probably only a dozen people or so in the entire VS community who even have the experience required to give a non-speculative answer.

It's something meant to appear during temporal storms, or while you have 0% temporal stability. If you see it at any other time, it's likely a bug.

I think they might spawn less frequently because the world is "noisier" with the new terrain generator. There may be fewer places where it can spawn. That said, I've seen surface copper deposits generate. Spotted around a dozen in my current 1.18 playthrough.

Alternatively, if the world is set to have soil affected by gravity, and there was a cavern below the dirt layer, it may have collapsed. That said, given that there are indeed burning pit kilns in this screenshot, I wouldn't be surprised if Digitalr was right

/worldconfig foodSpoilSpeed 0 Although I'm not sure if 0 is a valid value here. Some of these worldconfigs have minimum lower limits, you'll have to experiment. The closer to 0 you can set it, the slower food will spoil. After you enter this command, exit to main menu and reload your world, then enter the command again without a number to let it print the currently active value. If you entered something invalid (for example if it doesn't like 0) it will likely display the default value of 1. Then you can try something else, like 0.1.

That "square that indicates the area" is probably drawn by the mod VsProspectorInfo. It is not a feature of the base game.

Auto-pause during character generation is a feature in version 1.18, which is currently undergoing final bugfixing before its stable release. Until then, I recommend that you make a test world, take your time to try out all the customization options and read all the classes, and decide what you want. Then you can speedily click through it all in the world you actually want to play. Or, you could install the latest 1.18 release candidate. It is quite playable already.

Yep, I have four parallel installs at the moment: 1.14.7, 1.16.1, 1.17.11, and 1.18.0-rc.6. Although admittedly I haven't touched the two older ones in a long while... I start each one with a custom shortcut that remaps the data folder, so they don't interfere with each other. The default VS data folder under %appdata% is completely unused. When I updated rc.2 to rc.6 from within the game, only the 1.18 instance was touched. The other installs remain as they were.

The integrated update worked fine for me. Went from rc2 to rc6 without issues.

This is not possible, but you can achieve the same look by using multi-material chiseling.

I brought this up to Tyron after the release candidate went up, asking whether the team was planning further work on world generation. The answer was yes, there is further work planned, but not in 1.18. The lore update was already delayed too much to spend even more time on this at the moment. So for the time being, we'll need to wait until this update is out and refined, and work on 1.19 starts. IIRC Tyron suggested once before that the theme of 1.19 could be "de-jank 2.0", and if the players consider the terrain janky, that seems perfectly in theme to tackle for that update In the meantime, I've been trialing this mod, which shifts the weighting of landforms around some and adds a few custom ones. It doesn't get rid of all the sins, like floating islands and shattered mountains, but my gut feeling says its made them a bit more rare and the world feel a bit more natural. Sample size of about a dozen worlds tested without the mod (creative flight exploration), and one world currently in testing with it (actual gameplay). Maybe give it a try as well?

Perhaps this might help you:

That, at least, already exists. In the inventory, when hovering over an item, pressing H opens the handbook at that entry. Out in the world, when pointing the mouse at a block, pressing shift+H does the same. (Or possibly sneak+H, in case you rebound your sneak key to something other than shift.) I agree with the CTRL+A part, would very much like that for all text fields in the game (handbook, waypoints etc).

Craft some tongs and hold them in your off hand The recipe is in the handbook. You will need them to handle anything hotter than 300°C.

Take a look here: https://wiki.vintagestory.at/index.php/Chisel Particularly at the section "Microblock Chiseling" and "Multiblock Chiseling". You can also find people demonstrating how to in various youtube videos.

Not currently, no.

It does not, no. But that's not unbalanced, that's just a minor lack of convenience. Game balance is for default settings. As soon as you go and play with the rules of the world, you're changing the balance of the game in myriads of ways, some more obvious, some less. This is then on you, as the player, and no longer on the game. When a player goes and changes their days-per-month setting, it is honestly not asking too much to expect them to also adjust other worldconfig settings, like cropGrowthRateMul or playerHungerSpeed, to dial the game in to where they need it to be. You're not getting extra meat from slaughtering animals either when your months are 30 days long, even though you still need to eat just as often, and animal breeding takes much longer, and wild animals are no more numerous than before. Ever thought of that before? There are tons and tons of unexpected consequences from deviating that strongly from the default settings. The game allows you to do this, but it leaves you with the responsibility for your own actions.

Have you tried restarting the PC completely, to ensure that no zombie process is hogging the address?

Well, either 1.17 changed crop growth times in general and 1.18 made them scale to month lengths, or the other way around. Both changes were made, I'm just not sure in which order. Expect your harvests to become even more rare in the future though, because the average crop now has a growth time around two months, no matter how long your months are. (They drop twice as much produce once fully grown, though.)

No, certain things have always been independent of the seed. Additionally, some world customization settings (particularly the world size itself) will cause completely different terrain for the same seed.

@dakko@fran6 /time speed [60] is the simulation speed of the world. If you increase this number, everything gets fast-forwarded; if you decrease it, everything slows down. This includes plant growth, fuel consumption, weather pattern changes, even the movement speed of clouds and the waving of foliage in the wind - anything in the world that changes over time. Only things that are not "the world", i.e the animation speed of the player and creatures like animals and drifters, are unaffected. Other than that, you could think of it literally as a slow-mo or timelapse button on a video. /time calendarspeedmul [0.5] changes the amount of realworld time that will elapse for a given amount of ingame time to pass. Specifically, it modifies "IRL minutes per ingame hour", and at the default value, every ingame hour takes two IRL minutes. A multiplier of 1.0 would then, obviously, be one IRL minute per one ingame hour. Lowering the multiplier makes the calendar progress more slowly, and thus everything that depends on the calendar will happen more slowly. Things that do not depend on the calendar, like the amount of time a piece of firewood burns in a firepit, or the speed at which a cloud moves across the sky, are not affected. That's how this command differs from /time speed. /time hoursperday [24] does exactly what it says on the tin. Days behave as if they had fewer (or more) hours. That means that processes which are defined in terms of how many hours they take still take exactly as long in real time, but ingame, a different amount of days/nights may pass. For example, pit kilns using firewood take 20 ingame hours by default. With 24 hours per day, a kiln will burn for 0.83 ingame days, equaling 40 IRL minutes. With 12 hours per day, the pit kiln will burn for 1.66 ingame days, still equaling 40 IRL minutes. The path of the sun in the sky will accelerate and you will see more sunrises and sunsets in the same amount of real time. /worldConfig daysPerMonth [9] also does what it says on the tin. It sets how many days are in each of the 12 months of the calendar, and thus, processes which are defined as taking a specific number of days will happen in a smaller (or larger) fraction of a whole year. In past versions, this mainly affected crop growth and berry bush repopulation; if you set something like 30 days per month, you could have like 3 harvests per month for some crops if you didn't also change the growth time of crops to be equally slowed (via /worldconfigcreate float cropGrowthRateMul [1.0]). Come 1.18, this is no longer necessary, as crop growth time will be defined in months, and will thus auto-adjust to the number of days per month you choose. Important notes here are: /time speed and /time calendarspeedmul just modify the rate of the passage of time. They get saved with your world, but you can turn them on and off willy-nilly without causing any problems. The other two, however, which set the number of hours per day and the number of days per month... those edit your calendar. And this is a recipe for trouble in existing worlds, especially since worlds do not start when you think they do. For example, if you spawn into a new world on May 1st, as normal, and then immediately enter /time hoursperday 12, then your calendar will jump to September 1st! How, you may ask? Because the world started on January 1st, year 0, but you only spawned four months later, on May 1st. Each of those four months had 9 days with 24 hours in them, and you are now retroactively setting them to have only 12 hours each. The game maintains the time elapsed, and to have the same number of hours pass, there must now be twice as many days, and thus twice as many months. daysPerMonth has a similar effect: start a default world where you spawn on May 1st, and then immediately set /worldConfig daysPerMonth 30, and you will find yourself freezing your butt off on February 7th instead. Figuring out exactly where your calendar will end up after one of these commands gets more and more difficult the longer the world has already existed. And you may see unexpected side effects, too. Your crops might all spontaneously grow up - or revert to a previous growth stage - or even get damaged or die, if the new date has a temperature unsuited for those crops. Or your entire food cellar's contents may transform into rot all at once. And once food has rotted, you can't un-rot it anymore, even by undoing the changes you just made. Toying with timescales in existing worlds is dangerous and should never be done without a backup! And then there are the /time set and /time setmonth commands. Which simply make the game jump to a specific point in time, such as the following morning. You may think: these sound great to circumvent problems like those caused by the calendar-modifying commands above... and you would be half right. And half wrong. They will certainly let you move the current date to a month/season you are comfortable playing in, if your prior edits put you into an undesired month. But keep in mind that each execution of these commands fast-forwards you to the next instance of that moment in time. Each /time set morning will move you forward to the next morning, never back to the current one, not even when mere seconds have passed. Each /time setmonth aug will move you to the start of the next August in the future, never back to the start of the current August you may already be in, not even when mere seconds have passed. And all that time that gets skipped forwards will faithfully get processed in the world. Your food will rot. Your crops will grow/freeze/die. And so on. Finally, there used to be ways that let you turn back time, such as supplying a negative value to /time add. They should all be patched out by now, to my knowledge, and you should never, ever try to find new ones. Because the principal result of trying to revert time is a permanently bricked save. The game is not set up to do this properly. Don't try making it do this.