Modding:Developing a Content Mod: Difference between revisions
(Finished manual setup of content mod.) |
m (Domains writeup.) |
||
Line 52: | Line 52: | ||
==== ModInfo.json ==== | ==== ModInfo.json ==== | ||
To register our mod, we have to tell Vintage Story that our mod exists and some details about it. To do this, create a new file called '<nowiki/>''modinfo.json''' inside your mod workspace, either using your IDE or through Windows. Open the file, and paste the following json code: | To register our mod, we have to tell Vintage Story that our mod exists and some details about it. To do this, create a new file called '<nowiki/>''modinfo.json''' inside your mod workspace, either using your IDE or through Windows. Open the file, and paste the following json code:<syntaxhighlight lang="json"> | ||
{ | { | ||
"type": "content", | "type": "content", | ||
Line 89: | Line 89: | ||
== Navigating Assets and Domains == | == Navigating Assets and Domains == | ||
=== Domains === | |||
When Vintage Story loads your mod, it looks inside your mod's root assets folder to find subfolders. Each one of these subfolders dictates a mod ''domain.'' A domain works as an identifier to seperate assets from multiple mods. | |||
For example, imagine there exists two mods which both add in a new metal called 'Natium', but with slightly different functionality. Mod A adds the metal to work as a beginner-level metal, however Mod B adds the metal as an endgame metal. Without domains, Vintage Story would not be able to isolate these items based on the code alone, so it prefixes the domain to every asset. The code for Natium in Mod A now becomes "''moda:natium''", and the code for Mod B now becomes "''modb:natium''". | |||
When creating content mods, you will access many different assets from inside your files, and it is important to understand how domains affect this. If you reference '''Asset A''<nowiki/>' in another asset's file, Vintage Story will automatically prefix your domain onto that reference. However, if you wish to reference an asset that exists in another domain, including the base game, you will need to add that prefix yourself. | |||
For example, let us assume that '<nowiki/>''Asset A''<nowiki/>' in the '<nowiki/>''examplecontentmod'<nowiki/>'' domain wishes to access the default copper texture, which is located at '''block/metal/ingot/copper'.'' If you put that reference inside ''Asset A,'' Vintage Story will change that to "''examplecontentmod:block/metal/ingot/copper','' which will proceed to not work due to the file not existing in that domain. To counter this, you need to prefix that reference manually with the default game prefix, and place it as "''game:block/metal/ingot/copper''". This can also be used with other mod domains to use assets from other mods. | |||
Note that all base game assets are placed under the '<nowiki/>''game''' domain. | |||
== Publishing a Content Mod == | == Publishing a Content Mod == |
Revision as of 12:14, 21 March 2024
This page was last verified for Vintage Story version 1.19.4.
Page in progress.
Developing a content mod can be simple, but certain files and folders need to be setup correctly. For more information on what can be achieved with a content mod, see Content Mods.
Selecting an IDE
When creating a content mod, you will likely be using a lot of JSON files. Although JSON is a human-readable format, it can still be beneficial to equip yourself with an Integrated Development Environment (IDE). Simply put, for the purpose of modifying JSON files, an IDE works as a fancy text editor that helps with formatting.
It is recommended to select from one of the IDEs below.
Name | Free? | Works on... | Recommended for Code Mods |
---|---|---|---|
Visual Studio (Recommended) | Yes - Community Edition | Windows | Yes |
Visual Studio Code | Yes | Windows, macOS, Linux | Yes |
JetBrains Rider | No | Windows, macOS, Linux | Yes |
Notepad++ | Yes | Windows | No |
Content Mod Setup
As stated above, content mods require a certain file and folder structure to function.
Template/Example Setup
In progress.
Manual Setup
Mod Workspace
If you wish to setup your project manually, navigate to your Vintage Story install location, and enter the mods folder. Create a new folder with your mod's name - This will be where all mod-related files will be placed. It is recommended to open this folder in your selected IDE.
Note that creating JSON files may require changing file extensions. If you do not know how to do this, follow these instructions.
ModInfo.json
To register our mod, we have to tell Vintage Story that our mod exists and some details about it. To do this, create a new file called 'modinfo.json' inside your mod workspace, either using your IDE or through Windows. Open the file, and paste the following json code:
{
"type": "content",
"modid": "examplecontentmod",
"name": "VS Wiki Example Content Mod",
"authors": [
"Nat @ Vintage Story Wiki"
],
"description": "An example showcase of content mod additions.",
"version": "1.0.0"
}
This file is a very good example of how a json file is formatted, and you will notice that nearly every asset uses this file format. Json files list a set of "key" : "value" entries, allowing you to change those values to fit what is desired. In this case, the following keys represent:
- "type": "content" - This tells Vintage Story that the mod is a content mod, and should load the provided assets. The options here are "theme", "content", or "code", however for this mod type we will use "content".
- "modid": "examplecontentmod" - This is your unique mod ID, which can be any combination of lowercase letters and numbers.
- "name": "..." - This is your mod's name, and displays how it should be displayed within the game. Note that this is just for display and does not affect the assets you create.
- "authors": [ "..." ] - This is an array of mod authors. Due to this entry using square brackets ([ ]), it tells us that this value can accept multiple values, which are seperated by commas.
- "description": "..." - This is the mod description, which will be shown on the mod manager screen in game.
- "version": "1.0.0" - This is your mod's version. It follows the format of "major.minor.patch", called semantic versioning.
Also note that our file starts and ends with curly brackets ({ }). This tells us that this file contains a single object. If a json file starts with square brackets ([ ]), this tells us that we can register multiple objects within that single file.
You can fill in the values above with your own mod info, or keep them the same. Most tutorials on the wiki will use this modinfo file.
This is just a basic modinfo file. For more information, and a more comprehensive list of available properties, visit the Modinfo page.
Modicon.png
If desired, an image file called 'modicon.png' can be placed or created inside your mod workspace. This will automatically be loaded into Vintage Story, and be displayed next to your mod on the mod manager menu.
Assets Folder
To actually create and modify game assets, Vintage Story searches for specific filepaths. Inside your mod workspace, create a folder called 'assets'. This is where we place our different mod domains. More information on domains can be found in the 'Navigating Assets and Domains' section on this page.
Inside the new assets folder, create another new folder with the same name as your mod id. For example, my folder would be called 'examplecontentmod', as this is my mod id. This new folder is where your mod assets will be created! If a tutorial refers to your 'mod assets' folder, it is likely referring to this folder.
When your mod assets folder has been created, you are officially ready to start modding! Check out the 'What's Next' section to link to tutorials, and come back here when you need a reminder of how to organise your content mod.
Domains
When Vintage Story loads your mod, it looks inside your mod's root assets folder to find subfolders. Each one of these subfolders dictates a mod domain. A domain works as an identifier to seperate assets from multiple mods.
For example, imagine there exists two mods which both add in a new metal called 'Natium', but with slightly different functionality. Mod A adds the metal to work as a beginner-level metal, however Mod B adds the metal as an endgame metal. Without domains, Vintage Story would not be able to isolate these items based on the code alone, so it prefixes the domain to every asset. The code for Natium in Mod A now becomes "moda:natium", and the code for Mod B now becomes "modb:natium".
When creating content mods, you will access many different assets from inside your files, and it is important to understand how domains affect this. If you reference 'Asset A' in another asset's file, Vintage Story will automatically prefix your domain onto that reference. However, if you wish to reference an asset that exists in another domain, including the base game, you will need to add that prefix yourself.
For example, let us assume that 'Asset A' in the 'examplecontentmod' domain wishes to access the default copper texture, which is located at 'block/metal/ingot/copper'. If you put that reference inside Asset A, Vintage Story will change that to "examplecontentmod:block/metal/ingot/copper', which will proceed to not work due to the file not existing in that domain. To counter this, you need to prefix that reference manually with the default game prefix, and place it as "game:block/metal/ingot/copper". This can also be used with other mod domains to use assets from other mods.
Note that all base game assets are placed under the 'game' domain.
Publishing a Content Mod
Updating a Content Mod
What's Next?
Wondering where some links have gone?
The modding navbox is going through some changes! Check out Navigation Box Updates for more info and help finding specific pages.
Modding | |
---|---|
Modding Introduction | Getting Started • Theme Pack |
Content Modding | Content Mods • Developing a Content Mod • Basic Tutorials • Intermediate Tutorials • Advanced Tutorials • Content Mod Concepts |
Code Modding | Code Mods • Setting up your Development Environment |
Property Overview | Item • Entity • Entity Behaviors • Block • Block Behaviors • Block Classes • Block Entities • Block Entity Behaviors • Collectible Behaviors • World properties |
Workflows & Infrastructure | Modding Efficiency Tips • Mod-engine compatibility • Mod Extensibility • VS Engine |
Additional Resources | Community Resources • Modding API Updates • Programming Languages • List of server commands • List of client commands • Client startup parameters • Server startup parameters Example Mods • API Docs • GitHub Repository |