DavidLokison

I only recently discovered the fact that there has been world config settings sitting directly under our noses in the DLL files of native Vintage Story mods. This led me to thinking that those settings are, against common interpretation, not hard coded in the game client but instead able to be configured by the mods themselves. And here we go, there are in fact two different approaches to add those settings to a mod: AssemblyInfo and worldconfig.json. The former I will be talking more about in a post regarding AssemblyInfo and pure DLL mods, but the latter is even able to be done in a pure Content mod. What is a worldconfig.json and what is it about? Internally the class that is deserialized from that file is called ModWorldConfiguration. It has two members, PlayStyles and WorldConfigAttributes, both of which configuring a different part of the world creation screen. PlayStyles { "PlayStyles": [ { "Code": "myfancystyle", "PlayListCode": "survival", "LangCode": "myfancystyle", "Mods": ["game", "survival"], "ListOrder": 20, "WorldType": "standard", "WorldConfig": [ "WorldClimate": "realistic", "GameMode": "survival", "DaysPerMonth": 30, //... whatever other configs you wanna default to ] } ], "WorldConfigAttributes": [] } The PlayStyles array adds entries to the list of presets to choose from when generating a new world. So if you ever had the the idea to essentially save "preset savegames" so you can copy their settings into a newly created world... This is the same, but superior. A PlayStyle object consists of the following members: Code: Fairly undocumented. Seems to have something to do with grouping different playstyles together, judging from the language files. PlayListCode: The modid which this playstyle depends on. When the mod selected here is disabled, the playstyle will no longer be listed. LangCode: The ID part of the language code. The actual language code used will be "game:playstyle-<LangCode>" for the title and "game:playstyle-desc-<LangCode>" for the description. There is no way to change the domain, see below. Mods: Fairly undocumented. Maybe has something to do with which mods get activated by default or something. ListOrder: The position under which the entry will be sorted. Higher values are lower in the list. For comparison: VSSurvivalMod uses values of 5-7, VSCreativeMod uses a value of 10. WorldType: "standard" or "superflat", specifies which world generation type to use. WorldConfig: An object where you can specify any world configuration settings you wish to apply by default. See Wiki/World Configuration for details. You can also include your mod per-world configuration in here. In order to display the translation correctly, you have to add a specific language file, which is situated at game:lang/worldconfig-<Language>.json. So, if you want to make an english translation for the example above, you put your file in assets/game/lang/worldconfig-en.json and provide the following content: { "playstyle-myfancystyle": "My Fancy Style", "playstyle-desc-myfancystyle": "Just some default settings I like to play with" } Why not in your mod domain? Well, the game specifically only checks the "game" domain for world config entries, so those all have to go into the game category. Why that "worldconfig" prefix? This is needed for preloading. If a mod is registered which has world config settings (or, has a worldconfig.json, I am not sure yet), it enters a list of preloaded content. In addition to the game's native preload assets, language files at game/lang/worldconfig-*.json (well, actually only for those languages present in the languages.json file) are being loaded. And only those. That means, if you were to update the language file by supplying a standard game:lang/en.json for example, the settings would only apply after you loaded into a world at least once. Which is way after you'd need this setting. Note: This article is not finished yet. It is missing the WorldConfigAttributes array, what happens on a code collision and some other bits and baubles here and there. I plan to add to this post when I have researched the topic more, but I wanted to at least share my initial findings here. Thank you for reading this post. Now go about and make yourself some presets!

You are very welcome! I am glad to have found the underlying issue in the first place. Also: everything that helps people make more well-documented mods. It's always a pleasure to see someone actually putting in the effort to document their added items and come up with a decent description. Cheers to more info in the game and less dwelling in unstructured mod info pages.

Necroing this here but I actually took a deep dive into the handbook text source code today and opened a PR for fixing the issue for good (hopefully). In the meantime what actually ended up working for me was instead of using { "<domain>:<item|block>-handbooktext-<code-with-variants>": "<your awesome handbook text>" } to duplicate the domain like so: { "<domain>:<item|block>-handbooktext-<domain>:<code-with-variants>": "<your awesome handbook text>" } Yes, this inserts another colon into the path.. but that doesn't seem to cause any issues currently, so I will be using this method as a workaround until the issue is fixed. Hope this helps at least some people out there who want to write handbook content for their mods.