v50 Steam/Premium information for editors
  • v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
  • Use this page to report any issues related to the migration.
This notice may be cached—the current version can be found here.

Editing v0.31:Modding guide

Jump to navigation Jump to search

Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.

You are editing a page for an older version of Dwarf Fortress ("Main" is the current version, not "v0.31"). Please make sure you intend to do this. If you are here by mistake, see the current page instead.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
Line 5: Line 5:
 
Generally breaking stuff is fine - nothing that can be changed will affect the DF executable, and new additions can be easily removed.
 
Generally breaking stuff is fine - nothing that can be changed will affect the DF executable, and new additions can be easily removed.
  
This guide is based on a guide originally created for version 0.27.176.39c (originally put to type by one Teldin; page found [[40d:Modding guide|here]]) and has later been rewritten for 0.31.xx.xx by a few different authors, as per wiki tradition.
+
This guide is based on a guide originally created for version 0.27.176.39c (originally put to type by one Teldin; page found [[40d:Modding guide|here]]) and has later been rewritten for 0.31.xx.xx by (a) different author(s).
  
'''See also:''' [[:Category:v0.31:Modding]]
+
'''See also:''' [[:Category:DF2010:Modding]]
  
 
= Modding Guide =
 
= Modding Guide =
Line 13: Line 13:
 
== Basics of DF modding ==
 
== Basics of DF modding ==
  
All the base data that can be edited by prospective modders can be found in the \raw\ folder. This folder contains two subfolders: "graphics" (where you insert [[Graphics set repository|graphics sets]]), and "objects", which contains all the data for generally everything in the game that is not hardcoded.
+
All the base data that can be edited by prospective modders can be found in the \raw\ folder. This folder contains two subfolders: "graphics" (where you insert {{L|Graphics set repository|graphics sets}}), and "objects", which contains all the data for generally everything in the game that is not hardcoded (randomly created creatures aside).
  
Within the \raw\objects folder are a large number of text files - these are the [[raw file|raw files]], and editing them is quite easy - you can also create your own if you wish. For now, take a look at one of the existing files. It should look something like this:
+
Within the \raw\objects folder are a large number of text files - these are the {{L|raw file|raw files}}, and editing them is quite easy - you can also create your own if you wish. For now, take a look at one of the existing files. It should look something like this:
  
 
  creature_standard
 
  creature_standard
Line 29: Line 29:
 
  ...
 
  ...
  
As you can see, each file comprises a header string stating the file name, a second header stating the type of object data it contains, followed by the contents of the file itself. These are all necessary elements of the file, and without them, the file won't be parsed correctly by the game. You may have also noticed the file naming scheme - this is also important; files containing creatures have names starting with "creature_", entity file names must begin with "entity_", etc..
+
As you can see, each file is comprised of a header string stating the file name, a second header stating the type of object data it contains, followed by the contents of the file itself. These are all necessary elements of the file, and without them, the file won't be parsed correctly by the game. You may have also noticed the file naming scheme - this is also important; files containing creatures have names starting with "creature_", entity file names must begin with "entity_", etc..
  
 
Below the headers, there begins a list of entries. Each entry is made up of its own header (in this case, "[CREATURE:DWARF]"), again stating the type of object, and then the object's unique identifier - if an indentifier isn't unique, the game will mess up and you'll get some serious, and potentially very trippy, errors. Below that, we have the body of the entry, which determines the entry's specific properties.
 
Below the headers, there begins a list of entries. Each entry is made up of its own header (in this case, "[CREATURE:DWARF]"), again stating the type of object, and then the object's unique identifier - if an indentifier isn't unique, the game will mess up and you'll get some serious, and potentially very trippy, errors. Below that, we have the body of the entry, which determines the entry's specific properties.
Line 37: Line 37:
 
Before we continue, a few key things to remember when modding the raw files:
 
Before we continue, a few key things to remember when modding the raw files:
  
* Try to avoid modifying the existing raw files when adding objects. It makes removing mods far easier.
+
* Personally speaking, I don't recommend modifying the existing raw files, but if you want to edit an already-exiting creature, always back up the files you plan on editing to a different location. If you want to create backup files directly within the objects folder itself, take heed: the game doesn't distinguish between file extensions. It'll read a .bak file just as well as it'll read a .txt file, and (as mentioned previously) duplicate entries are a very bad thing.
* If you want to edit an already-existing creature, always back up the files you plan on editing to a different location. Since v0.31.22, the game no longer loads backup files, but duplicate entries are still a very bad thing.
+
* When a new world is generated, all the raw files get copied into a \raw\ folder within the applicable save folder. If you want to change something within a game that's already running, you'll have to edit those files, not the ones in ~DF\raw\objects.
* When a new world is generated, all the raw files get copied into a \raw\ folder within the applicable save folder. If you want to change something within a world that's already been generated, you'll have to edit those files, not the ones in ~DF\raw\objects.
 
 
* There's nothing stopping you from just copying an existing creature/entity/whatever, changing the identifier, and modifying it. This can save you a lot of time, especially when it comes to entities... which are coincidentally what we'll be talking about next.
 
* There's nothing stopping you from just copying an existing creature/entity/whatever, changing the identifier, and modifying it. This can save you a lot of time, especially when it comes to entities... which are coincidentally what we'll be talking about next.
  
 
== Modding civilizations (entities) ==
 
== Modding civilizations (entities) ==
  
Entities - the objects that determine how civilisations work - are stored in entity_default.txt (though, like all other files, you may add more). They follow the same format as any other raw file:
+
Entities - the objects that determine how civilisations work - are stored in entity_default.txt. They follow the same format as any other raw file:
  
 
  entity_default
 
  entity_default
Line 60: Line 59:
 
"[CREATURE:]" links the civilization with a specific creature defined in a creature file. This is the creature that'll be making up the entity's population, and will therefore be the creature you'll be playing as in fortress or adventure mode if the entity is a playable one. For example, if you wanted to do something silly, you could switch the "CREATURE:DWARF" entry in entity_default.txt with "CREATURE:ELF" and you would be marching elves around in fortress mode, although they would still use dwarven technology and language and names and so forth.
 
"[CREATURE:]" links the civilization with a specific creature defined in a creature file. This is the creature that'll be making up the entity's population, and will therefore be the creature you'll be playing as in fortress or adventure mode if the entity is a playable one. For example, if you wanted to do something silly, you could switch the "CREATURE:DWARF" entry in entity_default.txt with "CREATURE:ELF" and you would be marching elves around in fortress mode, although they would still use dwarven technology and language and names and so forth.
  
Oh, and before you get any funny ideas - it ''is'' possible to define more than one creature for a civ, but that won't work in quite the way you probably expect: later on, in the creature section, you'll learn about castes, which will provide a much more viable alternative, so try to bear with us until then.
+
Oh, and before you get any funny ideas - it ''is'' possible to define more than one creature for a civ, but that won't work in quite the way you probably expect: later on, in the creature section, you'll learn about castes, which will provide a much more viable alternative, so try to bear with me until then.
  
 
"[TRANSLATION:]" defines the language file that the entity will be using, which will determine what their untranslated words are for things. This doesn't determine which words they use for naming things, only the way those words are spelt. The default language files are HUMAN, DWARF, ELF, and GOBLIN.
 
"[TRANSLATION:]" defines the language file that the entity will be using, which will determine what their untranslated words are for things. This doesn't determine which words they use for naming things, only the way those words are spelt. The default language files are HUMAN, DWARF, ELF, and GOBLIN.
  
"[BIOME_SUPPORT:]" defines the biomes that civs will attempt to settle in. The "FREQUENCY" value determines the likelyhood of them building there, but also raises an important point: most of the values you'll be setting for things are relative to each other. If one was to type:
+
"[BIOME_SUPPORT:]" defines the biomes that civs will attempt to settle in. The "FREQUENCY" value determines the likelyhood of them building there, but also raises an important point: most of the values you'll be setting for things are relative to each other. If I was to type:
  
 
  [BIOME_SUPPORT:ANY_FOREST:1]
 
  [BIOME_SUPPORT:ANY_FOREST:1]
Line 76: Line 75:
 
This holds true for a lot of values throughout the files, excluding when it simply doesn't make sense, such as in materials.
 
This holds true for a lot of values throughout the files, excluding when it simply doesn't make sense, such as in materials.
  
You can find many details about the rest of the civilization tokens [[entity token|here]]. Besides those mentioned, some fundamental ones are the CIV_CONTROLLABLE token, which lets you control the civ in fortress mode, the INDIV_CONTROLLABLE token, which allows you to play the civ in adventure mode as an outsider, and the ADVENTURE_TIER token, which allows you to play a civ native (non-outsider) in adventure mode. Other tokens that you should pay attention to are START_BIOME and the ones regarding sites, but in general, you can just run through the aformentioned list and add or remove what you want.
+
You can find many details about the rest of the civilization tokens {{L|entity token|here}}. Besides those mentioned, some fundamental ones are the CIV_CONTROLLABLE token, which lets you control the civ in fortress mode, the INDIV_CONTROLLABLE token, which allows you to play the civ in adventure mode as an outsider, and the ADVENTURE_TIER token, which allows you to play a civ native (non-outsider) in adventure mode. Other tokens that you should pay attention to are START_BIOME and the ones regarding sites, but in general, you can just run through the aformentioned list and add or remove what you want.
  
 
If you have more than one civ with the CIV_CONTROLLABLE token, all the available civs from those entities will appear in the group selection section on the embark screen. It may not be immediately obvious from which species each civ may be - while this can be determined from legends mode, the topmost species in the "neighbors" display in the embark screen is always the same as the currently selected species; if your group is dwarven, dwarves will be topmost, whilst (say) elves will be topmost if your chosen group is elven. By default, the game seems to choose a civ (and therefore a species if there is more than one) at random.
 
If you have more than one civ with the CIV_CONTROLLABLE token, all the available civs from those entities will appear in the group selection section on the embark screen. It may not be immediately obvious from which species each civ may be - while this can be determined from legends mode, the topmost species in the "neighbors" display in the embark screen is always the same as the currently selected species; if your group is dwarven, dwarves will be topmost, whilst (say) elves will be topmost if your chosen group is elven. By default, the game seems to choose a civ (and therefore a species if there is more than one) at random.
Line 115: Line 114:
 
An easy method of creating a civilization is just to copy-paste a similar one to the bottom of the entity_default.txt file and edit things to your liking. Remember to always change the civ's "ENTITY:" identifier! This can be anything so long as it's not already existing.
 
An easy method of creating a civilization is just to copy-paste a similar one to the bottom of the entity_default.txt file and edit things to your liking. Remember to always change the civ's "ENTITY:" identifier! This can be anything so long as it's not already existing.
  
At the end of some of the default entries you'll find a list of positions, both ones that'll directly affect you in fort mode (such as nobles) and ones that'll primarily affect worldgen and adventure mode. A list of the tokens applicable to positions can be found [[position token|here]]; they don't require a great deal of explaination.
+
At the end of some of the default entries you'll find a list of positions, both ones that'll directly affect you in fort mode (such as nobles) and ones that'll primarily affect worldgen and adventure mode. A list of the tokens applicable to positions can be found {{L|position token|here}}; they don't require a great deal of explaination.
  
 
== Modding the creatures ==
 
== Modding the creatures ==
Line 121: Line 120:
 
Creature modding is great fun. You can change nearly any aspect of a creature or make your own completely from scratch.
 
Creature modding is great fun. You can change nearly any aspect of a creature or make your own completely from scratch.
  
Modding creatures is very similar to modding civs: it's just a matter of editing, adding, or removing tokens, enclosed in square brackets underneath the creature's [CREATURE:] header. The creature entries contain all of the information about each and every non-random creature in the game, from animals to dwarves to goblins to even caravan wagons. A lot of the creature tokens are fairly self-explanatory; you can find a list of such tokens [[creature token|here]]. But before you start creating your own creatures, you'll want to learn how the tissues system works.
+
Modding creatures is very similar to modding civs: it's just a matter of editing, adding, or removing tokens, enclosed in square brackets underneath the creature's [CREATURE:] header. The creature entries contain all of the information about each and every non-random creature in the game, from animals to dwarves to goblins to even caravan wagons. A lot of the creature tokens are fairly self-explanatory; you can find a list of such tokens {{L|creature token|here}}. But before you start creating your own creatures, you'll want to learn how the tissues system works.
  
 
=== Creature materials and tissues ===
 
=== Creature materials and tissues ===
  
In the most basic sense, a creature is a series of bodyparts. These parts are defined in their own file, and we'll talk about them later. As a specific aspect of how creatures work which throws off a lot of prospective modders is the relationship between bodyparts, tissues, and materials. We're going to show you part of the creature entry for a bronze colossus (bear with us):
+
In the most basic sense, a creature is a series of bodyparts. These parts are defined in their own file, and we'll talk about them later. As a specific aspect of how creatures work which throws off a lot of prospective modders is the relationship between bodyparts, tissues, and materials, I'm going to show you part of the creature entry for a bronze colossus (bear with me):
  
 
  ...
 
  ...
Line 144: Line 143:
 
At the top, we can see the "BODY:" token, followed by a list of bodyparts. As you've probably guessed, these parts make up the physical form of the colossus. But the colossus has to be made out of something - it has to have tissues. And those tissues also have to be made out of something - in this case, bronze.
 
At the top, we can see the "BODY:" token, followed by a list of bodyparts. As you've probably guessed, these parts make up the physical form of the colossus. But the colossus has to be made out of something - it has to have tissues. And those tissues also have to be made out of something - in this case, bronze.
  
Below the BODY token you'll see a TISSUE token, followed by an identifier, much like the others we've seen. The TISSUE block is determining how the tissue works, and which purposes it'll serve. As the colossus is just going to be made out of this one tissue, this tissue needs to act like bone, muscle, and everything else combined, hence the MUSCULAR, FUNCTIONAL and STRUCTURAL tokens. The tissue also references a material - INORGANIC:BRONZE - the properties of which are declared in the inorganic materials file, and the tissue is subsequently made out of this material. With us so far?
+
Below the BODY token you'll see a TISSUE token, followed by an identifier, much like the others we've seen. The TISSUE block is determining how the tissue works, and which purposes it'll serve. As the colossus is just going to be made out of this one tissue, this tissue needs to act like bone, muscle, and everything else combined, hence the MUSCULAR, FUNCTIONAL and STRUCTURAL tokens. The tissue also references a material - INORGANIC:BRONZE - the properties of which are declared in the inorganic materials file, and the tissue is subsequently made out of this material. With me so far?
  
 
Below the tissue definition is the TISSUE_LAYER line. TISSUE_LAYER allows you to control where each tissue is applied. Its first argument defines if it's to search by bodypart category (BY_CATEGORY), bodypart type (BY_TYPE), or look for a specific part (BY_TOKEN). That's followed by the parts argument itself, which is in this case ALL (so the game's looking for parts in all categories, which is to say, every bodypart). This is followed by the tissue to be applied, BRONZE. So the TISSUE_LAYER token is telling the game to select all bodyparts in every category and make them out of the tissue "BRONZE". The colossus is now made of bronze.
 
Below the tissue definition is the TISSUE_LAYER line. TISSUE_LAYER allows you to control where each tissue is applied. Its first argument defines if it's to search by bodypart category (BY_CATEGORY), bodypart type (BY_TYPE), or look for a specific part (BY_TOKEN). That's followed by the parts argument itself, which is in this case ALL (so the game's looking for parts in all categories, which is to say, every bodypart). This is followed by the tissue to be applied, BRONZE. So the TISSUE_LAYER token is telling the game to select all bodyparts in every category and make them out of the tissue "BRONZE". The colossus is now made of bronze.
Line 237: Line 236:
 
This can save you a lot of time and space if you're making lots of changes common to many creatures. In general, if you're making a creature that's fleshy or chitinous, there's detail plans already included in the game to help you out. You should only have to resort to declaring tissues individually (like our bronze colossus) if you're doing something really out-of-the-ordinary.
 
This can save you a lot of time and space if you're making lots of changes common to many creatures. In general, if you're making a creature that's fleshy or chitinous, there's detail plans already included in the game to help you out. You should only have to resort to declaring tissues individually (like our bronze colossus) if you're doing something really out-of-the-ordinary.
  
Another great thing about templates (and so, detail plans) is that they can be modified after being declared. Let's say we wanted our dwarves to be perpetually on fire (don't ask). We declare the body stuff normally:
+
Another great thing about templates (and so, detail plans) is that they can be modified after being declared. Let's say I wanted my dwarves to be perpetually on fire (don't ask). We declare the body stuff normally:
  
 
     ...
 
     ...
Line 273: Line 272:
 
     ...
 
     ...
  
Note that this makes use of DF's built-in temperature scale. You can read more about that [[temperature scale|on this page]]. We're also referencing material tokens, which we haven't gone over yet - we'll talk about making your own materials later.
+
Note that this makes use of DF's built-in temperature scale. You can read more about that {{L|temperature scale|on this page}}. I'm also referencing material tokens, which we haven't gone over yet - I'll talk about making your own materials later.
  
 
=== Creature castes ===
 
=== Creature castes ===
Line 327: Line 326:
 
== Modding items ==
 
== Modding items ==
  
Items are fairly simple to deal with. By default, each item type is contained in its own file; this may help make browsing for a specific item easier, but from a purely technical point of view, it's possible to throw all items into one file. Unfortunately, item tokens don't seem to be especially well-documented (at least as not as well as the other object types), but you should be able to figure out most things by way of our explainations and your assumptions.
+
Items are fairly simple to deal with. By default, each item type is contained in its own file; this may help make browsing for a specific item easier, but from a purely technical point of view, it's possible to throw all items into one file. Unfortunately, item tokens don't seem to be especially well-documented (at least as not as well as the other object types), but you should be able to figure out most things by way of my explainations and your assumptions.
  
 
Let's look at the entry for, of course, the thong:
 
Let's look at the entry for, of course, the thong:
Line 344: Line 343:
 
Most of these are pretty obvious if one compares them to the other entries in the file. There's a layer for the item, determining where it's worn; a coverage value to determine how well it protects you from cold and other things; a size token to determine how much it counts for when it's under something else; a layer permit token to determine how much can be worn under it; and a material size token to determine how much raw material it takes to make it.
 
Most of these are pretty obvious if one compares them to the other entries in the file. There's a layer for the item, determining where it's worn; a coverage value to determine how well it protects you from cold and other things; a size token to determine how much it counts for when it's under something else; a layer permit token to determine how much can be worn under it; and a material size token to determine how much raw material it takes to make it.
  
Now, if you wanted to mod these to turn them into metal thongs (ouch!), you would simply have to add [METAL] to it somewhere. Simple! These tokens work by tying into material properties - some materials are designated as suitable for making hard items, some for soft, etc..
+
Now, if you wanted to mod these to turn them into metal thongs (ouch!), you would simply have to add [METAL] to it somewhere, and probably [HARD] instead of [SOFT]. Simple! These tokens work by tying into material properties - some materials are designated as suitable for making hard items, some for soft, etc..
  
 
Weapons involve a little more detail:
 
Weapons involve a little more detail:
Line 360: Line 359:
 
  [ATTACK:BLUNT:100:1000:strike:strikes:pommel:1000]
 
  [ATTACK:BLUNT:100:1000:strike:strikes:pommel:1000]
  
SIZE determines how heavy the weapon is. This has a substantial effect on weapon effectiveness. SKILL determines which skill is used in using the weapon; a list of skills can be found [[skill token|on this page]]. MINIMUM_SIZE determines the minimum size a creature must be before the weapon can be wielded, while TWO_HANDED determines how large a creature must be in order to wield the weapon with one hand.
+
SIZE determines how heavy the weapon is. This has a substantial effect on weapon effectiveness. SKILL determines which skill is used in using the weapon; a list of skills can be found {{L|skill token|on this page}}. MINIMUM_SIZE determines the minimum size a creature must be before the weapon can be wielded, while TWO_HANDED determines how large a creature must be in order to wield the weapon with one hand.
  
Attacks take a little more explaination. The first value determines the contact area of the weapon's attack; this should be high for slashing weapons and low for bludgeoning, piercing and poking ones. The second value determines how deep the weapon penetrates - for BLUNT attacks this value is ignored as they're not supposed to penetrate anyway, but in the case of EDGE attacks it should generally be lower for slashing attacks and higher for stabbing attacks.
+
Attacks take a little more explaination. The first value determines the contact area of the weapon's attack; this should be high for slashing or bludgeoning weapons, and low for piercing and poking ones. The second value determines how deep the weapon penetrates - for BLUNT attacks this value is ignored as they're not supposed to penetrate anyway, but in the case of EDGE attacks it should generally be lower for slashing attacks and higher for stabbing attacks.
  
 
Following these are the adjectives used; they should be self-explanatory. Finally, we have the velocity modifier, which has a multiplying effect on the weapon's size for the purposes of determining how powerful it is in combat.
 
Following these are the adjectives used; they should be self-explanatory. Finally, we have the velocity modifier, which has a multiplying effect on the weapon's size for the purposes of determining how powerful it is in combat.
  
Other, more miscellaneous items are generally simple and shouldn't require any further explanation.
+
Other, more miscellaneous items are generally simple and shouldn't require any further explaination.
  
 
Once you've made an item, you just add it to the civ entry so a civilization can actually craft it, and it's done.
 
Once you've made an item, you just add it to the civ entry so a civilization can actually craft it, and it's done.
Line 389: Line 388:
 
The most important tokens are "CONTYPE" and "CON": CONTYPE means the bodypart in question is connected to a certain ''type'' of bodypart, while CON means it's connected to a ''specific'' one. TOKENID is yet another identifier, which should be unique, as it's referenced every time something uses CON or BY_TOKEN. DEFAULT_RELSIZE defines, of course, what the bodypart's size is in relation to the other parts. CATEGORY defines a category for the part, which can be unique or shared with other parts. This is referenced whenever BY_CATEGORY is used.
 
The most important tokens are "CONTYPE" and "CON": CONTYPE means the bodypart in question is connected to a certain ''type'' of bodypart, while CON means it's connected to a ''specific'' one. TOKENID is yet another identifier, which should be unique, as it's referenced every time something uses CON or BY_TOKEN. DEFAULT_RELSIZE defines, of course, what the bodypart's size is in relation to the other parts. CATEGORY defines a category for the part, which can be unique or shared with other parts. This is referenced whenever BY_CATEGORY is used.
  
A list of bodypart tokens can be found [[body token|here]].
+
A list of bodypart tokens can be found {{L|body token|here}}.
  
 
Let's take a simple example, a head:
 
Let's take a simple example, a head:
Line 441: Line 440:
 
An entire humanoid body. The foot bone's connected to the ankle bone...
 
An entire humanoid body. The foot bone's connected to the ankle bone...
  
"BODYGLOSS" entries, which you can sometimes find applied to creature entries, are simply replacement words for specific part name strings in a creature. For example, you'll find the bodygloss [BODYGLOSS:CLAW_HAND:hand:claw] in body_default.txt; you can then use this in a creature via "[BODYGLOSS:CLAW_HAND]" and it'll replace all instances of "hand" with "claw" in that creature. Be warned, however—if you were to, say make a bodygloss [BODYGLOSS:EARSTALK:ear:stalk:ears:stalk], it would not only change "ear" and "ears" to "stalk" and "stalks", it would also change "h'''ear'''t" to "h'''stalk'''t"! For all intents and purposes the body part will still function as the proper part, though.
+
"BODYGLOSS" entries, which you can sometimes find applied to creature entries, are simply replacement words for specific part names in a creature. For example, you'll find the bodygloss [BODYGLOSS:CLAW_HAND:hand:claw] in body_default.txt; you can then use this in a creature via "[BODYGLOSS:CLAW_HAND]" and it'll replace all instances of "hand" with "claw" in that creature. For all intents and purposes the body part will still function as the proper part, though.
  
 
== Plants ==
 
== Plants ==
  
Plants are, again, not unlike creatures. With what you've learned so far in regard to tokens and the materials system, running through the notes included in plant_standard.txt should explain most things. [[Plant token|Here's the list of plant-specific tokens]].
+
Plants are, again, not unlike creatures. With what you've learned so far in regard to tokens and the materials system, running through the notes included in plant_standard.txt should explain most things. {{L|Plant token|Here's the list of plant-specific tokens}}.
  
 
== Workshops ==
 
== Workshops ==
  
Standard workshops are still hardcoded, but some of the more recent additions such as the soapworkers workshop and screwpress can be found in the [[building token|building_custom.txt file.]]
+
Coming later
  
 
== Materials ==
 
== Materials ==
Line 461: Line 460:
 
Finally, let's look at inorganic_stone_mineral.txt. Here we can see that in addition to the changes made to the template, there are also ENVIRONMENT tokens - these tell the game where to place these minerals during worldgen.
 
Finally, let's look at inorganic_stone_mineral.txt. Here we can see that in addition to the changes made to the template, there are also ENVIRONMENT tokens - these tell the game where to place these minerals during worldgen.
  
[[material definition token|Here's a list of material tokens]]. It should also help you out with any modifications you want to make regarding those creature modifications we were making a while back. See, it all ties together in the end. The beauty of the current materials system is that there's actually very little difference between, say, leather and iron - they're fundamentally the same thing, just with different properties, which is how things really should be.
+
{{L|material definition token|Here's a list of material tokens}}. It should also help you out with any modifications you want to make regarding those creature modifications we were making a while back. See, it all ties together in the end. The beauty of the current materials system is that there's actually very little difference between, say, leather and iron - they're fundamentally the same thing, just with different properties, which is how things really should be.
  
 
== Examples ==
 
== Examples ==
Line 471: Line 470:
 
[http://www.bay12forums.com/smf/index.php?topic=28829.0 A list of many mods and community-developed utilities]
 
[http://www.bay12forums.com/smf/index.php?topic=28829.0 A list of many mods and community-developed utilities]
  
{{Category|Modding}}
+
[[Category:DF2010:Modding]]
{{Category|Guides}}
+
[[Category:DF2010:Guides]]

Please note that all contributions to Dwarf Fortress Wiki are considered to be released under the GFDL & MIT (see Dwarf Fortress Wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel Editing help (opens in new window)