Deliverator
Graphical Hackificator
One of the Firaxis developers who has worked on the SDK has been chatting on Discord and sharing a bunch of information on the mod tools. Reposting it here as it contains a lot of useful info.
GENERAL
Hey guys! The modding tools are finally out! You can download them on Steam under the tools section. If you intend on doing any art modding be sure to grab the development assets depot as well since the art tools will make use of referencing them. There are a few starter projects in ModBuddy to get everyone started. The tools are a bit rough around the edges but we'll continue to update them in the future
There will certainly be bug fixes, more examples and documentation. I'll be updating it as much as I can
Dragging and dropping is still finicky in modbuddy but I've improved it significantly over Civ5's
The Lua editor should be much better this time. The parsing is multi-threaded now.
The (Steam) uploader is separate from ModBuddy, if you already have a mod you can just run the uploader and toss it up on Steam.
I'm sorry for the delay in getting them out but am super excited they are out in the wild now
FrontEndActions are things the mod does when it's enabled to adjust the setup screen. InGameActions are things the mod does when the game is started. You can also specify criteria to the actions to conditionally turn things off. For example, only apply these actions if this leader is playable or if we're in a specific ruleset
<Settings> == <FrontEndActions>, <Components> == <InGameActions>
mods that don't do anything to the game aren't required when loading the saves. So if you have a bunch of leader/civ mods that affect the standard game enabled but you jump into a scenario, those extra mods won't be needed even though they were turned on. The goal was to minimize micro managing mods
There's a setup field called Ruleset. Regular games use RULESET_STANDARD, scenarios use a custom ruleset. This provides a simple way to distinguish between a regular game and a standard one.
InGameActions can use the criteria RulesetInUse to specify only use this action if in standard game
I'm hoping to provide some more examples in the future showing off the modifier system and its uses for gameplay modding as well as the unit attachment system and its uses for kit-bashing 3d models since sometimes you just want to add new weapons and armor and not entire new humanoids
The gameplay DLL is running on a separate thread and has it's own set of lua exposures. The UI scripts act on cached data that may not be 100% in sync with the state of the gameplay dll (for example if it's playing back combat) Because of this the UI-side lua scripts have some different exposures than the gameplay side.
Text XMLs require the UpdateText action
the LocalizedText database table is in a separate database from the gameplay one
fun fact! workshop is integrated into MP If a player wishes to join your game where you're playing some fantastical modder created scenario hosted on workshop but they don't yet own it, they can automatically download it when joining and everyone will see the download progress as they are jumping in
ART TOOLS / ASSET EDITOR
Just a heads up to anyone using the art tools. You'll see the options greyed out in modbuddy at first. You have to have a mod project open before they are enabled (since launching the tools automatically provide the path to the project via command line)
the asset editor has to be launched via modbuddy so that it gets the right command line params
this is because the editor will generate lots of files and meta-data and needs to know where they go and what dependencies are from other projects
also the first time you launch asset editor it will take a while... usually 5-10min on reasonable machines but if you have <4gigs of memory you'll be caught paging a lot of data. This initial launch looks at the assets and generates a dependency graph but does cache it so future launches are much much faster
There's an example modbuddy project that demos making 2d leaders so you should be able to get up and running with that fairly quickly
no 3d art examples yet (I suck at art...) But I'll be adding more example starters in later updates
Everything you need is in the asset editor AFAIK. It's a bear of a tool and can be difficult to navigate but we use it to define practically everything art related in the game. From 2d leaders to units, terrain features and 3d leaders.
Things may be a bit rough around the edges with this first release. But we'll be providing updates and I'm obviously keeping an eye out
To use the asset editor, downlod the developer assets (it's 27 gigs!) then launch the developer tools, click on modbuddy and get that running (you may have to install the shell redistributable). Once it's running, navigate to Tools->Options->Civilization VI and verify the paths are correct. People like to install things to custom steam library paths so it's good to double check. After that's done create a new mod project and then select Tools->Asset Editor. The first time you run it give it about 10min or so. It takes a while to generate a dependency graph of all of the assets but it gets cached so future runs are faster
The .tex files get created automatically by the asset editor. It's used to specify how the textures get processed. The cooking/building process may compress the textures or do things with em based on what context the texture is being used.
The asset tools do have a bit of a learning curve. Best thing to do IMO is to use the starter projects and open the art defs and XLPs created and go from there.
You don't need the assets technically for art mods but in practice you almost always do.
Mod.Art.Xml is a file that tells the cooker what systems need to use what art defs and XLPs. For now you have to hand-edit it to add the references (if you diff the 2d leader example from say the empty mod you can see what changes were made).
the mod.art file and the dependencies go under UpdateArt
if you made any artdefs or xlps for your mod
you'll want the updateart step
and set it to (Mod Art Dependency File)
you will never need to reference the mod.art.xml directly
when your mod includes any art def files or XLP files, the build process creates a .dep file. This is the file you need to reference in your <UpdateArt> action. But! this file is generated at build time. So what you want to use instead is (Mod Art Dependency File) which is just a way of telling mod buddy to fill in the blank later with the generated file.
modbuddy won't do anything with it if there aren't any artdefs or XLPs in the root folder of the mod
those artdefs and xlp's don't have to be part of the modbuddy project either, the build step looks for all of them in the project folder
I verified the textures are correct w/ what's on steam. Some do not open (at least in visual studio 2015) but others do just fine. For example YieldAtlas.dds works just fine for me. The others I suspect have additional information in them perhaps? I'll have to ask our engine guys
BLPs are files that contain the asset data
artdefs are meta-data files
Resources.artdef defines clutter items for specific resources along with variants for terrain and feature type.
ART EXAMPLE
In asset editor, click on the toolbar button that says Open Existing Art Def.
From there navigate to the civ6 SDK assets and open Resources.artdef then do it again for Clutter.artdef
you'll see Resources.artdef specifies the resource type and expanded the base clutter ID along with variants
clutter == stuff on the map
in clutter.artdef you can see the clutter entry for gold which expanded shows that it uses several models for planets of varying scales and rotations
GENERAL
Hey guys! The modding tools are finally out! You can download them on Steam under the tools section. If you intend on doing any art modding be sure to grab the development assets depot as well since the art tools will make use of referencing them. There are a few starter projects in ModBuddy to get everyone started. The tools are a bit rough around the edges but we'll continue to update them in the future
There will certainly be bug fixes, more examples and documentation. I'll be updating it as much as I can
Dragging and dropping is still finicky in modbuddy but I've improved it significantly over Civ5's
The Lua editor should be much better this time. The parsing is multi-threaded now.
The (Steam) uploader is separate from ModBuddy, if you already have a mod you can just run the uploader and toss it up on Steam.
I'm sorry for the delay in getting them out but am super excited they are out in the wild now
FrontEndActions are things the mod does when it's enabled to adjust the setup screen. InGameActions are things the mod does when the game is started. You can also specify criteria to the actions to conditionally turn things off. For example, only apply these actions if this leader is playable or if we're in a specific ruleset
<Settings> == <FrontEndActions>, <Components> == <InGameActions>
mods that don't do anything to the game aren't required when loading the saves. So if you have a bunch of leader/civ mods that affect the standard game enabled but you jump into a scenario, those extra mods won't be needed even though they were turned on. The goal was to minimize micro managing mods
There's a setup field called Ruleset. Regular games use RULESET_STANDARD, scenarios use a custom ruleset. This provides a simple way to distinguish between a regular game and a standard one.
InGameActions can use the criteria RulesetInUse to specify only use this action if in standard game
I'm hoping to provide some more examples in the future showing off the modifier system and its uses for gameplay modding as well as the unit attachment system and its uses for kit-bashing 3d models since sometimes you just want to add new weapons and armor and not entire new humanoids
The gameplay DLL is running on a separate thread and has it's own set of lua exposures. The UI scripts act on cached data that may not be 100% in sync with the state of the gameplay dll (for example if it's playing back combat) Because of this the UI-side lua scripts have some different exposures than the gameplay side.
Text XMLs require the UpdateText action
the LocalizedText database table is in a separate database from the gameplay one
fun fact! workshop is integrated into MP
If a player wishes to join your game where you're playing some fantastical modder created scenario hosted on workshop but they don't yet own it, they can automatically download it when joining and everyone will see the download progress as they are jumping inART TOOLS / ASSET EDITOR
Just a heads up to anyone using the art tools. You'll see the options greyed out in modbuddy at first. You have to have a mod project open before they are enabled (since launching the tools automatically provide the path to the project via command line)
the asset editor has to be launched via modbuddy so that it gets the right command line params
this is because the editor will generate lots of files and meta-data and needs to know where they go and what dependencies are from other projects
also the first time you launch asset editor it will take a while... usually 5-10min on reasonable machines but if you have <4gigs of memory you'll be caught paging a lot of data. This initial launch looks at the assets and generates a dependency graph but does cache it so future launches are much much faster
There's an example modbuddy project that demos making 2d leaders so you should be able to get up and running with that fairly quickly
no 3d art examples yet (I suck at art...) But I'll be adding more example starters in later updates
Everything you need is in the asset editor AFAIK. It's a bear of a tool and can be difficult to navigate but we use it to define practically everything art related in the game. From 2d leaders to units, terrain features and 3d leaders.
Things may be a bit rough around the edges with this first release. But we'll be providing updates and I'm obviously keeping an eye out
To use the asset editor, downlod the developer assets (it's 27 gigs!) then launch the developer tools, click on modbuddy and get that running (you may have to install the shell redistributable). Once it's running, navigate to Tools->Options->Civilization VI and verify the paths are correct. People like to install things to custom steam library paths so it's good to double check. After that's done create a new mod project and then select Tools->Asset Editor. The first time you run it give it about 10min or so. It takes a while to generate a dependency graph of all of the assets but it gets cached so future runs are faster
The .tex files get created automatically by the asset editor. It's used to specify how the textures get processed. The cooking/building process may compress the textures or do things with em based on what context the texture is being used.
The asset tools do have a bit of a learning curve. Best thing to do IMO is to use the starter projects and open the art defs and XLPs created and go from there.
You don't need the assets technically for art mods but in practice you almost always do.
Mod.Art.Xml is a file that tells the cooker what systems need to use what art defs and XLPs. For now you have to hand-edit it to add the references (if you diff the 2d leader example from say the empty mod you can see what changes were made).
the mod.art file and the dependencies go under UpdateArt
if you made any artdefs or xlps for your mod
you'll want the updateart step
and set it to (Mod Art Dependency File)
you will never need to reference the mod.art.xml directly
when your mod includes any art def files or XLP files, the build process creates a .dep file. This is the file you need to reference in your <UpdateArt> action. But! this file is generated at build time. So what you want to use instead is (Mod Art Dependency File) which is just a way of telling mod buddy to fill in the blank later with the generated file.
modbuddy won't do anything with it if there aren't any artdefs or XLPs in the root folder of the mod
those artdefs and xlp's don't have to be part of the modbuddy project either, the build step looks for all of them in the project folder
I verified the textures are correct w/ what's on steam. Some do not open (at least in visual studio 2015) but others do just fine. For example YieldAtlas.dds works just fine for me. The others I suspect have additional information in them perhaps? I'll have to ask our engine guys
BLPs are files that contain the asset data
artdefs are meta-data files
Resources.artdef defines clutter items for specific resources along with variants for terrain and feature type.
ART EXAMPLE
In asset editor, click on the toolbar button that says Open Existing Art Def.
From there navigate to the civ6 SDK assets and open Resources.artdef then do it again for Clutter.artdef
you'll see Resources.artdef specifies the resource type and expanded the base clutter ID along with variants
clutter == stuff on the map
in clutter.artdef you can see the clutter entry for gold which expanded shows that it uses several models for planets of varying scales and rotations
