Streetwind

@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.

This has already been implemented as of 1.18.0-pre.7 At least for pots and bowls. Unsure if it's working for crocks as well - but even if not, you can just use bowls to scoop the crocks empty and wash the bowls. Toss them into the water like you would do with rot-filled bowls.

@Diche Bach Yes, this appears to have changed across versions. In a backup-ed 1.14 instance I still have, the item.json file is still under survival, not game. Meanwhile in 1.18 prerelease, which I also have installed, I find it under game instead, as you describe. Other files in the same locations wouldn't need to be touched, so it doesn't really matter what they are.

Yep, that is how the new terrain generator looks at the moment. You will see this especially when you turn the world height higher than 256 blocks. I don't know if, or what, further changes are planned; we'll have to wait and see.

I don't know the reason, but I just want to remark on how oddly appropriate it is that you get killed by a nightmare drifter every night.

I don't know what you're translating, since I haven't interacted with the lore content of 1.18 yet (waiting for stable). But I'm pretty sure that's a proper name, referring to a person called Jonas. So you wouldn't translate it at all.

AMD has bad OpenGL driver support, I think. Meaning for non-DirectX games, Nvidia is the vendor of choice. As the above results handily underline.

Yes, weather will continue to be a thing. Unfortunately, the setting "always spring" appears to be broken in current versions of the game, from various reports. You may need to wait and see if 1.18 fixes it.

Well, primarily I wanted to focus on producing instructions on how to separate the data folders that works reliably for everyone. If you feel like it is worth expanding on that, feel free to add anything you like, so long as it makes sense.

I've written about this multiple times before, in reply to people asking, but I think it's time to give this its own dedicated thread with a cleaned-up how-to guide. The default installation of Vintage Story is fine for most people. It is also convenient in the way that it keeps all of its user data in the user profile, so that a computer that is used by multiple people (in a family for example) will allow every player to have their own savegames, mods, and configs without interfering with anyone else's. However, sometimes an enthusiast might want to have more than one version of the game in parallel. Perhaps they want to keep an old world around but still play newer versions too. Perhaps they want to test the latest prerelease without risking their saved worlds. Perhaps they want to have a singleplayer instance and a multiplayer instance with different modsets, without having to toggle them all manually everytime they launch the client. And when this enthusiast then installs two versions of the game into separate folders, they will discover that it doesn't work right. The two game instances can be launched separatedly, but they aren't properly separated. The same savegames and the same mods show up for both. The reason for this is - you may have guessed it - that the user data is kept in the user profile, as mentioned before. This includes config files, logfiles, saved games, map data, installed mods, and more. Even when there are multiple parallel installations of the game on the disk, launching each one still accesses the same default location for the user data, and therefore loads the same user data. In order to fully separate two or more parallel instances of the game, each one must be told to use its own unique user data folder. Where these are to be located is fully up to you; they can be placed into the game's install directory if you are the only one who uses this computer, or kept inside the user profile if not, or anywhere else really. The name doesn't matter either. You could even place the data folder on an external storage medium, so long as you ensure that it is mounted when you launch the game. I'm going to describe this process for Windows users, as that covers 95% of the game's userbase, and Linux users tend to be more tech-savvy anyway and won't need as much help. (And also because I don't have Linux.) Step-by-step guide, to be done separately for each installed version of the game: Create the directory where you want your data folder to be located in the future, and copy its full, absolute path. Paste the path into a text file or something similar for later reference. You don't need to recreate the folder structure inside the data folder, the game will do that on its own. Go to your VS install directory and create a shortcut to vintagestory.exe. The easiest way to do this in Windows is the select the file, so that it is marked blue. Then, using the right mouse button, click and drag the file to an empty space inside the folder (or some other folder, or even the desktop, wherever you want it). Upon releasing the mouse button, a context menu pops up. Select "create shortcut". Rightclick the shortcut, and select "Properties". A small window pops up, with a few editable fields. The topmost one is called "Target". Inside this field, do not delete anything that's already there. Instead, go to the very end, press spacebar once, and then write --dataPath your:\path\here. That's a double dash at the front. You input the absolute path to your desired future data folder that you set aside during the first step. If the absolute path to your custom data folder contains spaces, then that path must be encased in double quotes, so that Windows understands it. Do not encase the argument switch (the --dataPath part), just the path itself. Some people have reported issues with loading mods from this custom data folder, while for others (like me) it is working without problems. I have no real explanation for why this happens. But in case you suffer from this, or you just want to preempt the possibility of it happening, you can append an additional switch: --addModPath your:\path\here\mods. Again, if that path contains spaces, the path (but not the argument switch) needs to be enclosed in double quotes. Press OK to close the properties window. Doubleclick the shortcut in order to launch the game. Pay attention to your desired future data folder; the game should auto-populate it with certain required files and subfolders. If this did not work, you made a mistake with the shortcut somewhere. If this worked correctly, you can now close the game again and move your savegames and other user data over from the default data folder (%appdata%\vintagestorydata) to the new one. Examples: Putting the data folder into the install directory, the path to which includes spaces: "d:\games\vintage story\1.17\vintagestory.exe" --dataPath "d:\games\vintage story\1.17\data" --addModPath "d:\games\vintage story\1.17\data\mods" Note how each of the three paths (but not the two argument switches) are encased in double quotes, because all three contain a space. Keeping the data folder in the user profile, without spaces in the path: d:\games\vintagestory\1.17\vintagestory.exe --dataPath %appdata%\vintagestory_1_17 Note how there are no double quotes here. It won't break if you add them anyway, but they're not required, as there are no spaces in any of the paths. This example omits the --addModPath switch, but it could be added just the same as in the first example. A note regarding the new auto-updater! Since version 1.18, Vintage Story now has a comfortable way to install game updates. You simply click a button inside the client and it downloads and installs everything for you. Unfortunately, that function doesn't support multiple parallel installations. It relies on an entry in the Windows Registry to know where VS is installed, and that entry is rewritten everytime you run the installer. That means the auto-updater only works for the installation that you installed last. Even if you launch a client you installed previously, and start the auto-update process from within it, it will not update the client you started it from, but rather the client you installed most recently. Always. There is no workaround for this, other than not using the auto-updater. If you want to maintain multiple installations and keep them all updated, you'll have to do manual updates like in the past.

Thanks for sussing that out I'll edit my post to reflect how to properly place the quotation marks. EDIT: Actually, nevermind, I think I'll make a new post entirely, since that one isn't as nice as I want it to be.

The potential for mod folder confusion is probably fairly small, given that the kind of person who launches a game with a commandline parameter is probably also the kind of person who can tell folders apart

I just raised an issue about this on GitHub today. Not because I have this problem, but because I keep seeing people mention it and there wasn't one before.

Alas, the common, straight uranium ores like uraninite/pitchblende are not fluorescent. That takes more exotic combinations of elements. Autunite would be pretty, though.

Notice how there's an excess quotation mark after vintagestory.exe? That's breaking your path. Removing it (but keeping the quotation marks at the beginning and the end) should hopefully fix things.

I've written about it here. If it doesn't work for you, tell me at which step it's failing.

Uranium does not currently generate, but I've seen some people lobby Tyron to turn it on for 1.18. We'll have to see how that turns out.

No, just Discord.

@BronzeSpartan The reason OP is asking is because there's a new game mode coming for 1.18 that doesn't have any traders (or anything else that implies the existence of other people). It's meant for people who want a stone age simulator and don't care about the lore and story. @Ruyeex You could always cook up a bunch of regular clay bricks, switch to creative mode, delete the bricks you made, and pull out some red and brown ones in their stead.

Such a seed doesn't exist yet, because Vintage Story cannot generate oceans yet. Thus islands are also nonexistant for the time being. This will change with the coming 1.18 update. You can take a look at it in the prerelease, but keep in mind that it is still quite unstable at the moment. Also, the ocean generation is still highly experimental and fairly likely to change again before the stable release. Starting a new savegame for long-term play with the prerelease is a bad idea - give it another month or so to reach stable first.

This already exists, but you have to be logged in for it.

You can generate the world you want in singleplayer, and then make your multiplayer server use it.

I always fully reinstall major versions. Comes with the territory of having a separate install of each version I want to play

The glider you get from interacting with the story event/dungeon is incredibly fast. Sure, you need a high place to jump off of - but you can travel decently by leaping from a hill, gliding to the foot of the next hill, hopping up that hill, and leaping off the top to glide again. Admittedly, that won't let you cross massive oceans. But a tall launch tower at the water's edge will get you across pretty much any lake in the default worldgen setting. Also, the raft is probably a first prototype for the boating system. I don't expect it to be the final word on water travel. But already, it is more useful than you think - it lets you avoid getting wet in winter while crossing bodies of water.

On one hand, I love the idea. On the other hand, I'm not a fan of outright disabling a game mechanic. Perhaps the scarecrow could track how long it has been placed? That would just be a simple calendar check. And the longer it has been there, the more likely it becomes that animals will decide to ignore its presence. You could then let the player change something on the scrarecrow - like changing its pose or dressing it in a different shirt, or even picking it up and placing it in a different spot - to reset the counter and restore the scariness.