Noita Wiki
Register
Ryysst (talk | contribs)
(Create a small new section on different path types)
Tag: Visual edit
Ryysst (talk | contribs)
(Add a new section, explaining the basics of ECS)
Tag: Visual edit
Line 1: Line 1:
Now that you have extracted the base game assets & data, you can get to work.
 
 
 
The two common mod locations are:
 
The two common mod locations are:
   
 
* <code>Noita/mods/</code> - Use this for manually downloaded mods or mod development.
 
* <code>Noita/mods/</code> - Use this for manually downloaded mods or mod development.
 
* <code>steamapps/workshop/content/881100/</code> - Mods that you've downloaded through Steam Workshop can be found here.
 
* <code>steamapps/workshop/content/881100/</code> - Mods that you've downloaded through Steam Workshop can be found here.
  +
  +
<br />{{Stub}}
   
 
== Mod directory structure ==
 
== Mod directory structure ==
Line 45: Line 45:
   
 
</syntaxhighlight>The same exact thing applies in XML aswell when defining paths <sup>(eg. spritesheets, projectiles, effects, anything)</sup>
 
</syntaxhighlight>The same exact thing applies in XML aswell when defining paths <sup>(eg. spritesheets, projectiles, effects, anything)</sup>
  +
  +
== The Entity Component System basics ==
  +
Lets break down an example entity, from the base game file: <code>data/entities/props/banner.xml</code><syntaxhighlight lang="lua">
  +
<Entity tags="prop">
  +
  +
<VelocityComponent />
  +
  +
<SimplePhysicsComponent />
  +
  +
<SpriteComponent
  +
z_index="1"
  +
image_file="data/props_gfx/banner.xml"
  +
offset_x="0"
  +
offset_y="0"
  +
></SpriteComponent>
  +
</Entity>
  +
</syntaxhighlight>This is one of the simplest entities you can find, composed of only three components inside it. If spawned in-game, you should see a simple animated banner flag dropping to the ground, without any special functionality.
  +
  +
* <code>VelocityComponent</code> is generally required for anything dealing with physics. It can define a number of things <sup>(eg. gravity for individual entities)</sup>, but here we simply initiate it with default values. You can find all of the values in <code>component_documentation.txt</code>.
  +
* <code>SimplePhysicsComponent</code> gives the entity very simple physical properties. It'll always fall down, stop at any walls and it generally cannot collide with proper physics objects, nor can it be kicked. For proper physics, you'd want a PhysicsBodyComponent alongside with PhysicsShapeComponent, you can find many different examples of this in the data files.
  +
* <code>SpriteComponent</code> simply attaches an image file to the entity, with any given offsets and such. Here an XML file is defined as the source for the image, which is required when you want to add animated sprites to an entity. If your sprite is a still image, you can reference it directly here aswell.
  +
  +
Lets take a look at the image file <code>data/props_gfx/banner.xml</code> next:<syntaxhighlight lang="lua">
  +
<Sprite
  +
filename="data/props_gfx/banner.png"
  +
offset_x="12"
  +
offset_y="30"
  +
default_animation="stand">
  +
  +
<!-- stand -->
  +
<RectAnimation
  +
name="stand"
  +
pos_x="0"
  +
pos_y="0"
  +
frame_count="7"
  +
frame_width="32"
  +
frame_height="32"
  +
frame_wait="0.11"
  +
frames_per_row="7"
  +
loop="1"
  +
></RectAnimation>
  +
</Sprite>
  +
</syntaxhighlight>These separate metadata files are essentially outside of the Entity Component System, and simply define the sprite metadata in the same XML format as everything else. Thus no documentation can be found for the XML elements in the component_documentation.txt, because these are not components nor entities. But lets break this down aswell:
  +
  +
* Here we finally reference the actual image file we want to draw
  +
  +
* The main <code><Sprite></code> element has only one <code><RectAnimation></code> child element, it could have multiple of these, one for each animation <sup>(normal for any characters)</sup>
  +
* The animation name is "stand", and it's referenced as the default one aswell. The names can be anything, but it has to match with whatever's using them.
  +
* The <code>frame_*</code> attributes are quite self-explanatory, but basically the most essential part when defining animations. These have to match with the spritesheet in your image file.
  +
  +
You can go take a look at the file <code>data/props_gfx/banner.png</code>, and this all should become fairly obvious.
   
 
== init.lua ==
 
== init.lua ==

Revision as of 21:30, 28 June 2020

The two common mod locations are:

  • Noita/mods/ - Use this for manually downloaded mods or mod development.
  • steamapps/workshop/content/881100/ - Mods that you've downloaded through Steam Workshop can be found here.


Mod directory structure

This is an example mod, that shows the typical file structure you should follow.

myAwesomeMod/
├── data/
│   └── enemies_gfx/
│       └── player.png
├── files/
│   └── my_custom_script.lua
├── init.lua
└── mod.xml

Lets break it down a bit:

  • myAwesomeMod/
    • This is the root folder, the base path of your mod. Choose this carefully, as you will have to reference it all over the code later on. Note that this is not the visible "name" of the mod.
  • data/
    • This folder follows exactly the same structure as the Noita's data files that we extracted earlier. Use this ONLY when you want to override base assets.
  • enemies_gfx/
    • A folder that gathers together all enemy & friendly spritesheets
  • player.png
    • The player animation spritesheet (minä, the purple witch). Inside the data/ folder this is directly replacing the base game spritesheet when this mod is activated.
  • files/
    • This folder is for any and all custom assets/scripts/data you want to include in your mod, should be used when you don't want to directly replace existing assets (ie. almost always)
  • my_custom_script.lua
    • A custom script file, which could be doing literally anything or be called from anywhere. Try to name yours a bit better than this example.
  • init.lua
    • The starting point of your mod, includes hooks for post-/pre- world init, player spawn, etc. This is where you should probably start with a "Hello world"
  • mod.xml
    • The mod metadata definition file, includes the name, description and bunch of other settings.

Referencing files in different paths

As noted above, the data/ and files/ folders behave very differently from eachother. Due to this, you reference files in them slightly differently aswell. The data/ can essentially be considered as its own virtual filesystem inside Noita which can be referenced directly, but everything else needs to have your full mod path in it. For example including files in Lua, with the above structure:

-- Partial path for data files (also when overwritten and even if it's not included in *your* own mod)
dofile_once("data/scripts/lib/utilities.lua")

-- Full path for own scripts
dofile_once("mods/myAwesomeMod/files/scripts/my_custom_script.lua")

The same exact thing applies in XML aswell when defining paths (eg. spritesheets, projectiles, effects, anything)

The Entity Component System basics

Lets break down an example entity, from the base game file: data/entities/props/banner.xml

<Entity tags="prop">

  <VelocityComponent />

  <SimplePhysicsComponent />

  <SpriteComponent
    z_index="1"
    image_file="data/props_gfx/banner.xml"
    offset_x="0"
    offset_y="0"
  ></SpriteComponent>
</Entity>

This is one of the simplest entities you can find, composed of only three components inside it. If spawned in-game, you should see a simple animated banner flag dropping to the ground, without any special functionality.

  • VelocityComponent is generally required for anything dealing with physics. It can define a number of things (eg. gravity for individual entities), but here we simply initiate it with default values. You can find all of the values in component_documentation.txt.
  • SimplePhysicsComponent gives the entity very simple physical properties. It'll always fall down, stop at any walls and it generally cannot collide with proper physics objects, nor can it be kicked. For proper physics, you'd want a PhysicsBodyComponent alongside with PhysicsShapeComponent, you can find many different examples of this in the data files.
  • SpriteComponent simply attaches an image file to the entity, with any given offsets and such. Here an XML file is defined as the source for the image, which is required when you want to add animated sprites to an entity. If your sprite is a still image, you can reference it directly here aswell.

Lets take a look at the image file data/props_gfx/banner.xml next:

<Sprite
  filename="data/props_gfx/banner.png"
  offset_x="12"
  offset_y="30"
  default_animation="stand">

  <!-- stand -->
  <RectAnimation
    name="stand"
    pos_x="0"
    pos_y="0"
    frame_count="7"
    frame_width="32"
    frame_height="32"
    frame_wait="0.11"
    frames_per_row="7"
    loop="1"
  ></RectAnimation>
</Sprite>

These separate metadata files are essentially outside of the Entity Component System, and simply define the sprite metadata in the same XML format as everything else. Thus no documentation can be found for the XML elements in the component_documentation.txt, because these are not components nor entities. But lets break this down aswell:

  • Here we finally reference the actual image file we want to draw
  • The main <Sprite> element has only one <RectAnimation> child element, it could have multiple of these, one for each animation (normal for any characters)
  • The animation name is "stand", and it's referenced as the default one aswell. The names can be anything, but it has to match with whatever's using them.
  • The frame_* attributes are quite self-explanatory, but basically the most essential part when defining animations. These have to match with the spritesheet in your image file.

You can go take a look at the file data/props_gfx/banner.png, and this all should become fairly obvious.

init.lua

ModLuaFileAppend( to_filename, from_filename )

ModMagicNumbersFileAdd( filename )

ModMaterialsFileAdd( filename )

Important and interesting files

  • genomes.csv
  • translations.csv
  • wang_something.csv
  • post_final.frag
  • magic_numbers.xml
  • data/scripts/utilities.lua
  • Lists:
    • Spells: scripts/gun/gun_actions.lua
    • Perks: scripts/perks/perk_list.lua
    • Status effects: scripts/status_effects/status_list.lua
    • Materials: materials.xml

Debugging

  • noita_dev.exe
  • logging & the easy mod for it
  • CheatGUI Mod [Steam Workshop | Github]
  • All changes should appear upon starting a new game; the game detects if any mod files have changed and will do a full restart
  • lua debugger instructions in the noita modding folder