Modding:Race Modding Guide

[Primary Author: User:Sightglass]

[Article WIP]

LT's modding system has the ability to add new races and subspecies to the game, or to add new subspecies to existing races. A race mod is composed of XML files defining things such as body parts, subspecies and coverings, SVG images for icons and items, arranged in structured folders. In addition to defining a race and subspecies, these mods also often will include associated racial items to make transformative potions, combat moves, or custom text colors for names and descriptions.

Since the mod is made entirely of XML text files and SVG images, creating a race mod requires at least a text editor and a SVG image editor. [User:Sightglass: For the text editor, I recommend something like Notepad++ with some more-than-basic features like regex-based search/find/replace. Just anything that you're comfortable with and can use efficiently. For the SVG editor, I HIGHLY recommend Inkscape. Importantly, it seems to produce SVGs that are the most compatible with LT, as well as being relatively easy to pick up.]

[User:Sightglass: Author Note - The first parts of this guide are about how things work and are put together, the specific file guides are for very technical details. If you want to start making species mods, you probably only need to read through the general guide. The technical details are mostly intuitive since it's all labeled. Don't need to read through them unless you're looking for a specific thing.]

General Guide

General Process

It is much easier to start a new race mod using an existing race as a template. An annotated example is the Hyena-morph species, found from the game's res/mods/innoxia/race/hyena folder. Each of the XML files in the hyena race explains the file and each element of the XML.

A folder named after the mod's author should be directly under the res/mods folder. Within that folder, there will be subfolders each designating what they contain. Copying an entire race's folder helps keep the structure together and provides you with the XML files with the structure already in place. For example, "someone" might start a new race mod by first creating a folder res/mods/someone, then copying the res/mods/innoxia/race/hyena folder into it, then renaming the hyena folder into res/mods/someone/race/giraffe. Then, it is easy to just go through the files and change them from defining a hyena to defining a giraffe. Go through each file, changing the elements as needed to fit your new mod. Other parts of the mod, such as items and combat moves, will go in different folders and will be discussed in the sections below.

I generally follow this order when planning a race mod. This isn't strictly necessary, but I find this order to be helpful when working to help ideas come together.

1. Race and subspecies - What kinds of (usually anthro) creature do you want to add to the game (and have people bang)? What discrete varieties are there, and how are they differentiated from each other? For a real creature how can you anthropomorphize and adapt their real-world behavior into lewdness? For a fictional creature, how do you lewd their depiction?
2. Body Parts - What unique features do they have? Can these be used to distinguish different subspecies?
3. Items - For a race, it's practically necessary for there to be at least one item (usually a food) that can be used to create a transformative potion. Otherwise, the race would be difficult for the player to make themselves into. There is also usually a drink item, that enchants into a buff/restoration potion. I usually choose a food that's thematically associated with the creature, or a from the cuisine of the area that the creature is from.
4. Other Things - Unique combat moves usually. Can exhibit a special ability that the race has, such as a snake's venomous bite, or a kangaroo kicking the shit out of someone.

It may be helpful to keep some browser tabs open for "research" (like a wiki page, and furry porn) as you write, for inspiration or to add details when actually making the mod.

Then it's on to actually editing the files. I follow this order generally. Again, not strictly necessary, but helpful it avoiding having to backtrack and change things back. However, all of these parts are very interconnected, and unless you have EVERYTHING entirely planned out from the outset, you'll need leave placeholder values in, and go back and change things later. Keep in mind that whatever you have planned might change entirely, depending on what strikes you as you write, and what you may discover during "research".

1. Race definition
2. Colors (for description text, icons, etc.)
3. Body parts
4. Coverings
5. Racial body
6. Subspecies
7. Subspecies icons
8. Lore book
9. Potion Items
10. Combat moves (if any)
11. Name lists (if using)
12. TESTING TO MAKE SURE EVERYTHING WORKS

These parts are explained further in the #Mod Structure and Files section and the individual sections for each part.

Mod Structure and Files

"File Path" is the folder and file names for each part. If the filename is a placeholder, it means that there are multiple files, one for each definition for body parts, coverings, etc.

"Internal Name" is the name assigned when the LT modding engine loads in the file. These are generally generated from the file path.

"Requires" means that this part must reference another part. "May Require" means that this reference is optional, or can use existing items as a placeholder.

"Icon" specifies if a part uses an SVG icon.

For the file paths in the following table <an> is the author name (for example, "sightglass" or "dsg"), <rn> is the race name, and the other placeholders are self-explanatory.

Part	File Path	Internal Name	Requires	May Reference	Icon	Description
Race Definition	<an>/race/<rn>/race.xml	<an>_<rn>	Racial Body			The definition for a grouping of subspecies, and some basic info like litter sizes and disposition. If adding subspecies to an existing race, Don't Add This
Racial Body	<an>/race/<rn>/racialBody.xml		Body Parts			Template of body parts, and sizes, and other parameters the game uses when making a new character's body.
Body Parts	<an>/race/<rn>/bodyParts/<bp>.xml	<an>_<rn>_<bp>	Coverings	Race		One file for each body part type definition. May have multiple types for a slot (such as multiple tail varieties).
Coverings	<an>/race/<rn>/coveringTypes/<ct>.xml	<an>_<rn>_<ct>		Color		A covering such as skin, fur, scales, chitin, etc. Sets colors, patterns and modifiers that can spawn
Subspecies	<an>/race/<rn>/subspecies/<subsp>.xml	<an>_<rn>_subspecies_<subsp>	Race, Book Entries	Body Parts, Items, Color	Icon	Defines a subspecies of the main race. Needs at least 1 "main" subspecies. One file per subspecies.
Book Entries	<an>/race/<rn>/subspecies/bookEntries.xml	Uses a "tag" attribute				Lore text that appears in the encyclopedia.
Items	<an>/items/items/race/<item>.xml	<an>_race_<item>		Race	Icon	Item definitions for potion base items. Generally need at least 1 TF base item (usually food).
Combat Move	<an>/combatMove/<move>.xml				Icon	(Optional) A special combat move. One file per combat move.
Color	<an>/colours/<color>.xml	<an>_<color>				(Optional) A custom color. Can be used in entries above. One file per color.
Names	<an>/race/<rn>/names.xml			Subspecies		(Optional) Custom name triplets for a race and/or subspecies.

XML File Format Primer

Lilith's Throne modding system loads in content as Extensible Markup Language (XML) text files. It's just text formatted to fit a certain structure, and they can be opened and edited by any text editor, though some will have tools like syntax highlighting and XML-checking tools to help catch mistakes.

Here's a dummy example, to show how things are structured:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<tag>

   <element>text content</element>

   <emptyTag/>

   <cdataElement><![CDATA[CData Stuff]]></cdataElement>

<elementWithAttribute attribute="attribute value" secondAttribute="second value">this is also content</elementWithAttribute>

<emptyTagWithAttribue attribute="this is also an attribute value"/>

   <outerElement>

       <nestedElement attribute="yet another attribute">this is content too</nestedElement>

<nestedElement attribute="yet another attribute">contented for a second</nestedElement>

   </outerElement>

</tag>

An XML file is arranged as elements, each having an opening tag <tag> and a closing tag </tag>.

The name of an element (which goes in the tag) follows a few simple rules:

1. Must start with a letter or underscore ( _ )
2. Cannot start with xml
3. Are case sensitive!
4. Cannot contain spaces!
5. Can also have digits, hyphens, and periods, in addition to letters and underscores, but can't start with those (rule 1)

(Note: Most tag names used for LT are only letters with occasional numbers, and are usually in camelCase)

The stuff between the tags of an element, there may be content: <element>text content</element>. An element without content is usually entered as a self-closing tag ending in a slash: <emptyTag/>, or otherwise entered as tags with nothing between them: <tag></tag>. An element's content may be text or another element, which is called a child element: <element><childElement/></element>. Child elements can open with the same tag as others nested in the same parent.

Content for a tag in the form of <![CDATA[CData Stuff]]> is "character data", used to encapsulate text that may otherwise be interfere with the syntax of an XML document. For LT, it usually marks something that is sent to through a parser to perform scripting commands and/or displayed on screen as text.

Tags can also have attributes, which are key-value pairs included in the opening tag and formatted like: <tag key1="value1" key2="value2"></tag>. Each attribute in a tag must be unique.

The order in which elements appear usually does not matter. When the game is looking for an element with a specific name, it will find the first matching one within the scope. If the game is looking for multiple elements with a name, it will generally iterate through all of them in a certain scope.

Parser Primer

LT's parser takes in text from mods and resource files, executes scripts to perform game actions or retrieve information, applies formatting, and outputs text marked up with html to display onto the game screen.

Modders will definitely want to read the #Scripting section.

See also for reference: Parser Command Reference and Parser Target and Binding Reference

In-Game Guide

The following is taken from the parser help scene in the game's debug menu:

Innoxia’s super fun and interesting guide to parsing

You put in the input, and it returns a nice output!

Input:

Everything is parsed using square brackets, split into the following pattern:
[target.command]
or, for the few special commands that require arguments:
[target.command(arguments)]
or, for parsing as a script:
[#command]
or, for parsing as a script which suppresses output:
[##command]
(This means that the command will be executed, but no String output will be displayed.)

An example of use in a sentence would be:

As you start to read Innoxia’s tedious parsing documentation, [lilaya.name] steps up behind you and wraps [lilaya.her] [lilaya.tail+] around your [pc.leg]. Leaning in over your shoulder, [lilaya.she] groans, [lilaya.speech(Oh my God. This is so boring, [#pc.getName(true)]!)]’

parses to:

As you start to read Innoxia’s tedious parsing documentation, Lilaya steps up behind you and wraps her thick tail around your legs. Leaning in over your shoulder, she groans, Oh my God. This is so boring, Vivian!

Target tag:

The target of a command is an NPC’s name, or ‘pc’ for the player character. Target tags are case-insensitive. (i.e. pc is treated the same as PC, pC, or Pc)
If an unrecognised name is passed, the output will read ‘INVALID_TARGET_NAME’.
Currently accepted target tags can be viewed in the ‘Targets’ page.
e.g.:
[lilaya.command]
[pc.command(arguments)]
[npc.command]

Command and argument tags:

Command tags determine what output is returned. They come in two varieties; with and without arguments.
Arguments are passed inside brackets that follow the command, ignoring any spaces that you may insert.
i.e. [pc.command(arguments)] is the same as [pc.command (arguments)].
Command tags are only case-sensitive for the first letter. (i.e. command is treated the same as cOMMAND, cOmMaNd, or commanD)
Arguments are specific to each command, and you’ll have to refer to the command documentation to find out what arguments a command takes. (Don’t worry, there aren’t many that take arguments.)
e.g.:
[pc.speech(Hello reader!)] outputs Hello reader!

Command modifier (a_ an_)
You may insert ‘a_’ or ‘an_’ to automatically generate the appropriate pronoun before an argument. (It’s your choice if you prefer a_ or an_, they both work in exactly the same way.)
e.g.:
[npc.height] outputs ‘tall’
[npc.a_height] outputs ‘a tall’
[npc.an_height] also outputs ‘a tall’

For some body part names, this provides a little more complexity.
e.g.:
[npc.arms] outputs ‘wings’
[npc.a_arms] outputs ‘a pair of wings’
[npc.an_arms] also outputs ‘a pair of wings’

Command modifier (Capitalisation)
Most commands are able to apply capitalisation. The ones that don’t, such as numeric output commands, will still happily take a capitalised command, but capitalisation won’t be applied.
To capitalise an output, all you have to do is capitalise the first letter of the command name.
e.g.:
[npc.height] outputs ‘tall’
[npc.hEIGHT] also outputs ‘tall’ (I’m sure nobody would ever do this…)
[npc.Height] outputs ‘Tall’
[npc.a_height] outputs ‘a tall’
[npc.A_height] outputs ‘A tall’
[npc.a_Height] also outputs ‘A tall’

Command modifier (+ D)
Most commands that return a name are able to apply additional randomised descriptors. (You can check to see what commands accept ‘+’ and ‘D’ modifiers in the ‘Commands’ page.)
To apply additional descriptors to the returned output, all you have to do is add a ‘+’, ‘d’, or ‘D’ to the end of the command.
This works in combination with ‘a_ an_’ and ‘Capitalisation’ modifiers.
e.g.:
[npc.arms] outputs ‘wings’
[npc.arms+] outputs ‘feathered wings’
[npc.armsD] also outputs ‘feathered wings’
[npc.armsd] also outputs ‘feathered wings’
[npc.ArmsD] outputs ‘Feathered wings’
[npc.a_arms+] outputs ‘a pair of feathered wings’
[npc.A_arms+] outputs ‘A pair of feathered wings’

Some outputs have more randomisation than others.
e.g.:
[npc.pussy] outputs ‘slit’
[npc.pussy] outputs ‘cunt’
[npc.pussy+] outputs ‘wet pussy’
[npc.pussy+] outputs ‘tentacle-lined twat’

Conclusion:

Valid command syntax:
[target.command]
or
[target.command(arguments)]

Examples:

[brax.name] leans back in [brax.his] chair, wondering what happened to [arthur.name] after [brax.he] handed [[arthur.him]] over to Scarlett.
outputs:
‘Brax leans back in his chair, wondering what happened to Arthur after he handed him over to Scarlett.’

[rose.name] leans back in [rose.herHuis] chair, letting out a sigh as [rose.shyeHe] takes a sip of [rose.name] coffee.
outputs:
Rose leans back in command_unknown chair, letting out a sigh as command_unknown takes a sip of Rose coffee.
Note: Typos will cause the parsing system to return an invalid command string, whereas incorrect commands (such as typing .name instead of .herHis) will not throw an error!

[lilaya.name] storms up to [innoxia.name], shouting angrily in response to finding out that [lilaya.her] sex scenes haven’t been fixed yet, [lilaya.speech(What the hell are you doing Innoxia?! You said my scenes were going to be re-written weeks ago!)]
outputs:
‘Lilaya storms up to Innoxia, shouting angrily in response to finding out that her sex scenes haven’t been fixed yet, What the hell are you doing Innoxia?! You said my scenes were going to be re-written weeks ago!’

Dialogue written by Innoxia for Lilith’s Throne v0.4.9

Scripting

Body Generation

See also: Races#Race and Subspecies Calculation

When a character is being generated using a specific race and subspecies, body generation (from a modder's perspective) is influenced in three places:

1. The template, using racialBody and the race stage
2. "applyRaceChanges" in race.xml
3. "applySubspeciesChanges" in the subspecies XML file

Firstly, the racialBody lists what parts the new character's body starts out with. For characters that are not fully furry, some of these parts (such as the face and torso) will be replaced by the human part types. For half-demons, demon parts will be put into certain areas. The racial body template also covers some general parameters, such as femininity values, body size/muscle, dick size, etc.

Next, the race changes are applied. This applies to all characters of that race as they are created, and usually are for body characteristics that aren't covered in racialBody, and aren't specific to just some subspecies of the race. An example is for Charisma's Spider-morph race giving greater spider-morphs a 50% chance of spawning with six arms (plus two legs):

   <applyRaceChanges><![CDATA[

       #IF(RND.nextInt(100)<50 && targetedBody.getRaceStage()==RACE_STAGE_GREATER)

           [#targetedBody.setArmRows(3)]

       #ENDIF

   ]]></applyRaceChanges>

The, subspecies changes. These changes are usually for traits specific to the subspecies and used to differentiate them from other subspecies of the race. An example from Innoxia's Spotted Hyena-Morph, ensuring the coat is spotted for the subspecies check, and additionally making them taller:

   <applySubspeciesChanges><![CDATA[

       [#targetedBody.setCoveringPattern(BODY_COVERING_TYPE_innoxia_hyena_fur, true, COVERING_PATTERN_SPOTTED)]

       #IF(targetedBody.isFeminine())

           [#targetedBody.setHeight(targetedBody.getHeightValue()*1.12)]

       #ENDIF

   ]]></applySubspeciesChanges>

This matches the check in the spotted hyena's subspecies weighting:

   <subspeciesWeighting><![CDATA[

       #IF(targetedRace==RACE_innoxia_hyena)

           #IF(targetedBody.getCoveringPattern(BODY_COVERING_TYPE_innoxia_hyena_fur, true)!=COVERING_PATTERN_STRIPED)

               100

           #ELSE

               0

           #ENDIF

       #ELSE

           0

       #ENDIF

   ]]></subspeciesWeighting>

While the subspecies weighting and the subspecies changes are usually linked together by the design of the race mod, there's nothing in the code to enforce this. If the subspecies changes are done incorrectly, characters that are supposed to be that subspecies won't have the intended traits. If the weighting is done incorrectly, characters with the traits won't be recognized as the right subspecies.

But, this can be exploited by clever design to make, for example, one subspecies whose offspring instead generate as/recognized as a different one. One idea is for a queen bee subspecies to mostly spawn sterile normal bees.

See also: Races#Race and Subspecies Calculation

Making SVG Images for Race Mods

For general guidance, see also Solace's Inkscape guide: Modding:Inkscape for LT

Species mods for LT will need SVG icons for subspecies and items, and potentially also combat moves, status effects and any other extras.

SVG, being a vector graphic, is usually better suited for designs that are easily formed by geometric shapes. While it's not impossible to make very good organic shapes in a vector graphic, it takes a lot more effort and adjusting to make clean but easily recognizable. It's something to consider when choosing what items you want to make with the race mod, and what the subspecies icons can be. Also consider the fact that the icons are usually seen at a small scale, so choosing a simpler shape can make it more recognizable when very small.

The circular icon for a subspecies is composed of an actual icon (given by the iconName element of the subspecies XML) overlaid background. Leaving the backgroundName element empty will make the subspecies use the default background, which uses the second replacement color. For the icon itself, there are several different options one can try. Usually the simplest way is to draw a distinctive body part of the race or subspecies, such as a hand for humans, or a pair of fangs for a snake-morph, or a paw for cat-morphs and dog-morphs. It has the advantage of being much simpler and easier to make look recognizable. Another common way is to give just the head and face, usually in side profile like rabbits and wolves. It may take a lot of adjustment to make a good head/face silhouette. Using a reference image over manually tracing over the contour with a path is a good way to start towards a recognizable silhouette. Exaggerating a few shapes and features a little can also help make it legible at small sizes. Drawing features like beaks and ears as separate shapes, and adding different colors to them can help them pop out. Less common overall (but common in races made by DSG) are icons depicting the entire body. Exampls are ferret-morphs, shark-morphs and bear-morphs. While having just a head gives the challenge of adding enough detail to make it recognizable, full-body icons have the challenge of how to add details that are legible at very small sizes without cluttering the icon as a whole.

For items, it's often a little easier to be creative. Depending on what you make for the food and drink items, you may want to stylize or simplify the shape to something easily constructed. Packaging like a bag, can or bottle is kind of simple, and lets you make it distinctive with a made-up logo. There are already cans and bottles in the game, so you can try borrowing those to get started. Like for subspecies icons, you may want to choose something with an easy shape, like a bun or candy-drop, rather than something a complex shape, like a pile of onion rings or jalebi. It's up to you though, and it's fun to try making an interesting-looking challenging-to-draw food.

Finding Things In The Codebase

The code for the game is publicly available in this github repository: https://github.com/Innoxia/liliths-throne-public Use the "dev" branch of the repository, since that is the branch used to make public versions of the game.

Most of the time, it is unnecessary to look into the code base. If you are using Innoxia/DSG's races as starting points, those include pretty extensive comments explaining the files, elements, and possible values.

But, if you want more information on how things work, or what different options do, where you look depends on what you want to do.

A brief explanation of LT's class system (not the one with demon aristocracy): LT's code uses a lot of "AbstractThingType-ThingType" arrangements. The "abstract" type is a class definition, defining what properties an object has, while the non-abstract one is an enumeration of those abstract objects. It's sort of hard to explain without and example, so example: The AbstractRace.java code defines what a Race is, setting up what properties it has (but not giving them actual values), what methods and functions it has, etc. Then, the Race.java code is an enumeration of the different actual races, like HUMAN, DEMON, HORSE_MORPH, each of which fills values for the properties defined in "AbstractRace". Other enumerations don't have an abstract class, since the properties and functions are defined in the same file. These are usually simpler collections of values, like in Disposition.java.

To see how a particular thing is loaded in, look in the abstract definition, usually under a static { block

• For race and subspecies, the folder src/com/lilithsthrone/game/character/race has AbstractRace/Race as well as enumerations for various race/subspecies properies (disposition, categories, nocturnality). Useful if you are making a subspecies for an existing race, or giving damage bonuses vs certain races.
• Most of the classes in src/com/lilithsthrone/game/character/body define what the body parts on a character are, and what methods can be used on them. The Body.java templates a character's body as collection of the part objects defined by the other files in that folder. This may be most useful when writing up the racial/subspecies changes/subspecies checks, as a reference on how to modify a character's body or query for the body's properties.
• Body part types_, as in the different varieties of arms or wings a character can have, are enumerated in src/com/lilithsthrone/game/character/body/types, while the abstract definitions are in src/com/lilithsthrone/game/character/body/abstractTypes. These are handy to reference while making body part types for a race.
• src/com/lilithsthrone/game/character/body/valueEnums has enumerations for things like body shape, covering patterns and modifiers (textures), and leg configurations. These values are used throughout the mod, especially making #Body Part definitions and the #Racial Body definition.
• src/com/lilithsthrone/game/character/attributes/Attribute.java enumerates the attributes, useful for making the subspecies stat bonuses.

Testing

Whether you intend to publish the mod to the mod-sharing channel in the Discord, or just use it for your own game, TEST YOUR MOD.

While testing out the various parts of the mod, try keeping the error log (found in data/error.log) open in Notepad++. If the game encounters an error, it will write a line to that file, and the next time you click into NPP, it will ask to refresh the file.

Mods are loaded when the game executable starts up. That means that after modifying mod files, you need to close and open the game again for it to update.

I generally follow these steps when testing a mod to find potential issues:

1. When the game starts up, check the error log.
2. Go into the Debug Menu > Main tab > Race Resets, and transform the player character to each of your subspecies. Make sure that you are correctly recognized as each subspecies. This checks to see if the subspecies changes and race weighting are applied correctly. Also check the subspecies icon and status effect. If the subspecies is not set correctly, check the error log to see if the issue is in the subspecies changes, subspecies weighting, or both.
3. With the player character as the race, open the player's character description. Check for typos and error messages, and look in the error log.
4. Try to make a transformative potion for the race (and probably each subspecies). Make sure all the part names are correct.
5. Check items for typos, icon issues and errors in the description. Try using the items on both the PC and NPCs, to check the use messages for errors or typos.
6. As a human, drink the potion. Read the transformation description for typos or error messages, and look in the error log.
7. Test combat moves. Check whether the critical condition works correct, and check the descriptions in both crit and non-crit hits for errors and typos.
8. Whatever other extras you may have. Try to be thorough!

Specific File Guides

Table Format

For each file guide, the table lists the elements that can be included in the XML file. Refer to the XML primer if you are unfamiliar with the terminology of this section or in the file guides.

The columns of the table are:

• Element - What goes in as the name of the tag
• Description - Describes what goes in the contents/attributes, and how it is used in the game.
• Type - What kind of content is expected in the content for the element. All content is either raw text or CData, but may be interpreted differently when loaded in by the game
  • Text - Simple text content. For LT, it often is used to call up a particular value in an enumeration, like a particular body part type or an item. For this, use the internal name for the object.
  • CData - Character data, usually things that get passed through a parser for displaying things on screen and/or doing scripting stuff
  • Float, Int - The game will need a numerical value for the content. Make sure it's a number!
  • Element - The game expects a nested element here. The description should include what that child element is named and what content/attributes it has.
  • Boolean - A true/false value. The content should be literally the text true or false.
  • Root - Used for the root element. See note below.
• Options - Whether this element needs to be in the file (Required), can be left out (Optional), or needs to be in but can be left blank (Required, Can Be Blank). Missing a Required element may cause the loading the file to fail, since the game needs that element to properly define a type.
• Values - For Text-type contents, some will have a handful of valid options. For smallish numbers, the possible accepted contents are listed. Usually CAPITALIZED, may HAVE_UNDERSCORES.

Each table will also list the name of the root element. This element holds all other elements (except the header).

Race Definition

This file defines a new Race and should be put in as res\mods\<author>\race\<race name>\race.xml. The internal name for the race will then be <author>_<race name>. The file itself does not contain very much, with most of the other race mod files defining the actual content, just referencing the race. For subspecies mods (defining new subspecies for an existing race), this file is left out and the rest of the mod uses that existing race.

Element	Description	Type	Options	Values
race	ROOT ELEMENT	Root	Required
racialBody	Points to the racialBody.xml file located in the same folder. The contents reference the racialBody named as <an>_<rn>, similarly to how the race is named. See: #Racial Body	Text	Required
applyRaceChanges	Applies body changes to a character of the race during creation. See: #Body Generation	CDATA	Required, Can be Blank
name, namePlural	Non-gendered, anthro (singular,plural) name of the race, used for general use such as in the encyclopedia and crowd descriptions.	CDATA	Required
nameSillyMode, namePluralSillyMode	Same as "name" and "namePlural", but used in Silly Mode. Defaults to those if not present.	CDATA	Optional
nameFeral, nameFeralPlural	Two mappings for (legConfiguration,affinity) pairs and names for a feral with that leg configuration and affinity. Each element of the contents is a "name" tag with a "legConfiguration" and/or "affinity" attribute giving the leg configuration and the text contents giving the name. The "legConfiguration" attribute is required. If the "affinity" attribute is left out, the game will fill in pairs with the legConfiguration and all affinities. Ex: <name legConfiguration="QUADRUPEDAL"><![CDATA[hyena]]></name> Unspecified affinities/legConfigurations default to using the first loaded. This is probably the most complicated part, so see the example below the table.	Element, CDATA	Optional
defaultTransformName	The name that will be used when referring to transformations related to this race. Used in the self-TF menu, and in the enchantment menu for potions.	CDATA	Required
colour	Text color for the race, used in places like the encyclopedia or crowd descriptions. Can be custom or preset. See: #Colours	Text	Required
disposition	"How this race will typically treat strangers." Not used for much currently. See: Disposition	Text	Required	CIVILIZED NEUTRAL UNPREDICATABLE SAVAGE TABLE SAVAGE
racialClass	A vague taxonomic category for this race. Some settings control things like whether scalies generate with scale-hair, whether furries are bald, etc. "OTHER" is used for slimes, elementals and similarly-nonbiological races. Not used for much currently. See: RacialClass	Text	Required	MAMMAL BIRD REPTILE AMPHIBIAN FISH INSECT OTHER
combatBehavior	Combat strategy used by NPCs. Defaults to "BALANCED" See: CombatBehavior	Text	Optional	BALANCED ATTACK DEFEND SEDUCE SPELLS SUPPORT
chanceForMaleOffspring	Sex ratio for this race during litter generation as a decimal 0.0-1.0, giving the chance that any offspring of that race generates as masculine. Will usually just be 0.5	Float	Required
numberOfOffspringLow, numberOfOffspringHigh	Upper and lower bounds for a litter size, before modifiers. The upper bound should be greater than or equal to the lower bound. For reference, humans are (1,2), many furry species are (2-4) and rabbit/snake are the highest at (2,8).	Int	Required
defaultFemininePreference, defaultMasculinePreference	The default "furryness" preference, of how furry characters of this race are generated. Only sets the starting value of the preference, and the player can change it in their settings. Androgynous characters are lumped into the feminine preference. There's not much point to using the "HUMAN" value, since it essentially converts them all to humans. See: FurryPreference	Text	Required	HUMAN MINIMUM REDUCED NORMAL MAXIMUM
affectedByFurryPreference	Whether or not the furry preferences in (defaultFemininePreference, defaultMasculinePreference) can be modified by the player. When true, effectively locks the race to generate at the specified level Recommended to keep this "false" unless the race specifically needs to spawn at a certain level for some reason.	Boolean	Required	true false
racialFetishModifiers	Mappings for modifying how likely this race will spawn with certain fetishes. Each element is a "fetish" tag. The text content is the fetish. The attributes "love", "like", "dislike" and "hate" are the weights for that fetish spawning as a like or dislike. Omitted attributes have a weight of 1.	Element, Text	Optional
feralPartsAvailable	Whether or not the race can have feral parts to turn them into a taur or something. Usually should be "true" for most furry races.	Boolean	Required	true false
ableToSelfTransform	Whether the race is allowed to use the self-TF menu, like slimes or demons. Usually should be "false".	Boolean	Required	true false
flyingRace	Whether the race is usually considered winged and flying. If "false" and not demonic, a character with wings will be described as such (ex: "winged pig-morph"). If "true", having wings won't appear in the race name (ex: "dragon-morph") Usually should be "false".	Boolean	Required	true false

Feral Names

As an example of how the feral name system works, here's an example from DSG's Dragon-morph race:

   <nameFeral>

       <name legConfiguration="QUADRUPEDAL"><![CDATA[dragon]]></name>

       <name legConfiguration="TAIL_LONG"><![CDATA[wyrm]]></name>

       <name legConfiguration="TAIL_LONG" affinity="AQUATIC"><![CDATA[sea serpent]]></name>

       <name legConfiguration="TAIL"><![CDATA[sea serpent]]></name>

   </nameFeral>

   <nameFeralPlural>

       <name legConfiguration="QUADRUPEDAL"><![CDATA[dragons]]></name>

       <name legConfiguration="TAIL_LONG"><![CDATA[wyrms]]></name>

       <name legConfiguration="TAIL_LONG" affinity="AQUATIC"><![CDATA[sea serpents]]></name>

       <name legConfiguration="TAIL"><![CDATA[sea serpents]]></name>

   </nameFeralPlural>

In this example, all quadrupedal feral dragons are called "dragons", while those with fish-tails (TAIL) are called "sea serpents". For ones with snake-like tails (TAIL_LONG), it depends on Affinity. The first one, <name legConfiguration="TAIL_LONG"><![CDATA[wyrm]]></name> will fill all affinities with "wyrm", and the second specifically overwrites the AQUATIC affinity to be "sea serpent".

Fetish Maps

As an example for how the fetish maps work, here's an example from Innoxia's Hyena-morph race:

   <racialFetishModifiers>

       <!-- You can define the attributes 'love', 'like', 'dislike', and 'hate' to have weightings, with those omitted having a default weighting of 1. In this example, hyenas are more likely to like or love the dominant fetish than dislike or hate it. -->

       <fetish love="3" like="5" dislike="2" hate="1">FETISH_DOMINANT</fetish>

   </racialFetishModifiers>

These weights are multiplied with a player's fetish settings, meaning that they can still influence whether or not characters will spawn with a like/dislike of a fetish.

Racial Body

This acts as a template for body generation, defining what #body parts are included when a character of the race is being generated. The file name should be res\mods\<author>\race\<race name>\racialBody.xml. The internal name for the racial body will be <author>_<race name> (same as the race's internal name, but the only place this is used is in the #Race Definition).

Most of these elements have very self-explanatory names on how they are used, so the descriptions will just add notes on what the contents should be. Additionally, many parameters are separated for masculine and feminine character generation.

Entries in the table are grouped into ones using the same enumeration values, or using very similar parameters. They appear in roughly the order they appear in most racialBody.xml files, based on the one in for hyena-morphs used in a template. The Index column gives the order the elements appear in breaking the grouping, if you want to follow that. Elements that have male/female are still combined into a single row, since the blocks of elements repeat for male then female.

Index	Element	Description	Type	Options	Values
0	racialBody	ROOT ELEMENT	Root	Required
1	personalityChances	A map for weights of how common Personality traits are for the race as a whole. Each sub-element should be an "entry" element, with the attribute "chance" giving the chance as a decimal 0.0 to 1.0, and the contents should match a PersonalityTrait. Example, giving a 50% chance of spawning with the "CONFIDENT" trait:    <personalityChances>        <entry chance="0.5">CONFIDENT</entry>    </personalityChances> The base chance of most traits is 0.05, influenced by other parameters of character generation. Leaving this element out, or empty, will use the default chances. Can be overridden by subspecies personality weightings.	Element, Text	Optional, Can Be Blank
2	orientationFeminineGynephilic/orientationFeminineAmbiphilic/orientationFeminineAndrophilic/orientationMasculineGynephilic/orientationMasculineAmbiphilic/orientationMasculineAndrophilic	Base weights for a character of a certain Femininity to be a certain Sexuality attracted to feminine, both, or masculine bodies. Should be positive integers. Total weight does not have to add to 100, though it may make the math easier. This distribution is also governed by player settings, so it's not too important and can be left as the default values: 20/40/40/60/30/10.	Int	Required
3	bodyMaterial	The body material that this race will spawn with. Leave the content as "FLESH". Don't use anything else, unless you want weird things to happen.	Text	Required	FLESH FLESH FLESH
4	bodyHair	Use the body hair type defined in the race's #coverings. Can also use one defined for other races, but not recommended. BodyCoveringType For other coverings, it is defined in the #body parts.	Text	Required
5	genitalArrangement	GenitalArrangement, usually "NORMAL"	Text	Required	NORMAL CLOACA CLOACA_BEHIND
6	maleHeight/femaleHeight	Height is in centimeters, from 15 to 366. Normally around 170-185. Values below 152 ("ZERO_TINY" and smaller in the Height enumeration) are for "short stature" subspecies, and has its own element in the #subspecies definition.	Int	Required	15 to 366
7	maleFemininity/femaleFemininity	Femininity ranges from 0-100. Cutoffs for femininity are found in this enumeration. Body randomization gives this about a 5-point swing either direction, so the "maleFemininity" is usually <35, unless you want the race to generate androgynous characters instead of masculine ones. For "femaleFemininity", this value is usually >65 to generate only feminine characters, and less to generate androgynous characters.			0 to 100
8	maleBodySize/femaleBodySize	Body Size ranges from 0-100. Cutoffs for different categories are found in this enumeration.
9	maleMuscle/femaleMuscle	Muscle ranges from 0-100. Cutoffs for different categories are found in this enumeration.
12	armType	These body part slots specify a single type that a character of this race can generate with. The text contents should be the internal name of the type. A character can be changed to a different variant in the racial or subspecies changes. Some slots can use the "NONE" type, to avoid having this part entirely. These are: Wings, Tail, Tentacles, Antenna, Horn, Crotch-Breasts	Text	Required
14	assType
22	breastType
36	breastCrotchType
50	faceType
51	eyeType
52	earType
54	hairType
58	legType
60	penisType
68	torsoType
69	vaginaType
10	antennaTypes	These body part slots can have different varieties, like different horn types. For each type to be made available, add a sub-element with the name "type" and contents of the types internal name. During body generation, the game will pick one of the values listed in the element.Example:    <tailTypes>        <type>innoxia_sheep_tail</type>    </tailTypes> To not use this particular body part, (for example a race without antennae), only add the "NONE" type:    <antennaTypes>        <type>NONE</type>    </antennaTypes> For some body parts, there are generic part types that don't have an associated race. In the enumerations linked below, those particular types will use Race.NONE. These include: Horns, Wings. Generic parts can also be added as modded content.	Element, Text	Required
56	hornTypes
66	tailTypes
77	wingTypes
17	anusCapacity	Capacity values for various penetrable orifices, from 0.0 to 25.0, following the Capacity enumeration. Approximately the diameter of a comfortable penetration. Typical values: 1.5 for Anus. 0 for Breasts/Crotch-Breasts. 2.5 for Vagina. Size must be 7 or greater and capacity must be nonzero for nipple-penetration to be possible.	Float	Required	0.0 to 25.0
32	maleBreastCapacity/femaleBreastCapacity
46	breastCrotchCapacity
72	vaginaCapacity
18	anusWetness	Wetness rating for various penetrable orifices in arbitrary units. Enumeration value from 0 to 7, following the Wetness enumeration. Typical values: 0 ("dry") for Anus. 2 ("moist") for Vagina.	Int	Required	0 to 7
73	vaginaWetness
19	anusDepth	Depth rating for various penetrable orifices, ultimately used as a multiplier to depth calculated elsewhere. Enumeration value from 0 to 7, following the the OrificeDepth enumeration. Typical value: 2 ("average")	Int	Required	0 to 7
33	maleBreastDepth/femaleBreastDepth
47	breastCrotchDepth
74	vaginaDepth
20	anusElasticity	A rating for how quickly an orifice will stretch to accommodate larger penetration. Value from 0 to 7, following the OrificeElasticity enumeration. Typical values: 3 for Anus and Breasts/Crotch-Breasts. 4 for Vagina.	Int	Required	0 to 7
34	maleBreastElasticity/femaleBreastElasticity
48	breastCrotchElasticity
75	vaginaElasticity
21	anusPlasticity	Rating for how quickly an orifice will recover from being stretched, and if it will recover entirely or partially. Value from 0 to 7, following the OrificePlasticity enumeration. Typical values: 3 ("resilient", slowly recovers to original size) If the player has gape content enabled, values above 5 will not recover entirely, and 7 will remain permanently gaped and not recover at all.	Int	Required	0 to 7
35	maleBreastPlasticity/femaleBreastPlasticity
49	breastCrotchPlasticity
76	vaginaPlasticity
11	maleAntennaLength/femaleAntennaLength	Length in centimeters. Leave as 0 for races without natural antennae.	Int	Required
13	armRows	How many pairs of arms characters will spawn with by default. Default value is 1. Up to 3 pairs are supported by the game.	Int	Required	1 to 3
15	maleAssSize/femaleAssSize	Thiccness value, from 0 to 7 following the AssSize enumeration. Typically 2 (small) for male and 3 (large) for female.	Int	Required	0 to 7
16	maleHipSize/femaleHipSize	Similar to cakedupness, but for the hips, and following the HipSize enumeration. If omitted, will use the maleAssSize/femaleAssSize values.	Int	Optional	0 to 7
23	breastShapes	A list of breast shapes available for natural character generation. Sub-elements are "shape" elements, with the values matching BreastShape. Listing all non-udder shapes manually:    <breastShapes>        <shape>ROUND</shape>        <shape>POINTY</shape>        <shape>PERKY</shape>        <shape>SIDE_SET</shape>        <shape>WIDE</shape>        <shape>NARROW</shape>    </breastShapes> Alternately, use an empty "breastShape" tag with an "udderShapes" attribute. The list above can equivalently be entered as <breastShapes udderShapes="false"/>. Having the "udderShapes" attribute be "true" adds the "UDDER" shape to the list in addition to the rest.	Element, Text OR Empty with attribute	Required	ROUND POINTY PERKY SIDE_SET WIDE NARROW UDDERS
37	breastCrotchShapes
24	maleBreastSize/femaleBreastSize	An integer from 0 to 91, according to the CupSize enumeration. For reference, 0 is "flat", 1-3 are not considered breasts for the purposes of sex/gender naming, C-cup is 7, F-cup is 11, and cup sizes F and up progress up as F, FF, G, GG, H, etc. up to N but skipping I/II. Typical values are 0 and 7 for M/F, 6 for crotch-breasts. Size must be 7 or greater and capacity must be nonzero for nipple-penetration to be possible.	Int	Required	0 to 91
38	breastCrotchSize
25	maleBreastRows/femaleBreastRows	Pairs of breasts, from 1 to up to 6. Usually 1 for chest, 2 for crotch-breast.	Int	Required	1 to 6
39	breastCrotchRows
26	maleNippleSize/femaleNippleSize	An integer from 0 to 4, according to the NippleSize and AreolaSize enumerations. Typically nipples are 0 for male, 1 for female, 2 for crotch-breasts. Typically areolas are 0 for male, 2 for female, 2 for crotch-breasts.	Int	Required	0 to 4
28	maleAreolaeSize/femaleAreolaeSize
40	breastCrotchNippleSize
42	breastCrotchAreolaeSize
27	maleNippleShape/femaleNippleShape	Shape matching the NippleShape enumeration. Typically "NORMAL"	Text	Required	NORMAL INVERTED VAGINA LIPS
41	breastCrotchNippleShape
29	maleAreolaeShape/femaleAreolaeShape	Shape matching the AreolaShape enumeration. Typically "NORMAL"	Text	Required	NORMAL HEART STAR
43	breastCrotchAreolaeShape
30	maleNippleCountPerBreast/femaleNippleCountPerBreast	Number of nipples per breast, up to 4.	Int	Required	1 to 4
44	nippleCountPerBreastCrotch
31	maleLactationRate/femaleLactationRate	Despite the name, actually controls milk capacity. Integer is amount stored in mL. Typically 0 for races that do not lactate unless pregnant.	Int	Required	0 to 100000
45	breastCrotchLactationRate
53	maleLipSize/femaleLipSize	Lip size rating an integer 0 to 7, according to the LipSize enumeration. Typically 1 ("average-sized") for male and 2 ("full") for female.	Int	Required	0 to 7
55	maleHairLength/femaleHairLength	Length in cm, from 0 to 350. Typically 12 for male, 25 for female. Is overridden by furry/scalie hair preferences.	Int	Required	0 to 350
57	maleHornLength/femaleHornLength	Length in cm, from 0 to 75. Inputting a 0 will disable horns for that femininity, allowing you to let only one spawn with horns. Other horn parameters such as number of rows/points are controlled in the horn #body parts type file.	Int	Required	0 to 75
59	legConfiguration	The default Leg Configuration for this race, following the LegConfiguration enumeration. Usually "BIPEDAL". If subspecies are defined with different leg configurations (for example horse-morph vs centaur), the different leg configurations are applied at the subspecies changes in #body generation. The leg configurations compatible with leg types is controlled in the XML for those legs (see #body parts). Also make sure that the leg configuration used here (and in other places) match up to feral names in #race definition and #subspecies.	Text	Required	BIPEDAL QUADRUPEDAL TAIL_LONG TAIL ARACHNID CEPHALOPOD AVIAN WINGED_BIPED
61	penisLength	Length of the penis (for those who have them), in cm. Must be an integer 0 to 100. A typical value is 18 cm, a little larger than the worldwide average. It's a porn game, after all. A value of 0 is "microscopic".	Int	Required	0 to 100
62	penisGirth	A thickness rating for dicks and clits, as an integer from 0 to 6, according to the PenetrationGirth enumeration. For penises, typically 2 ("narrow"), 3 ("average"), or 4 ("girthy"). For clits, usually 0 ("thin").	Int	Required	0 to 6
71	clitGirth
63	testicleSize	An integer from 0 to 7 in abstract units, according to the TesticleSize enumeration. Typically 2 ("average", human-sized), 3 ("large", for most furries) or 4 ("huge" for like horses and such).	Int	Required	0 to 7
64	testicleQuantity	Number of nuts. Allowed values are 2 to 8, and can be odd. Usually 2.	Int	Required	2 to 8
65	cumProduction	An integer for the capacity of cum storage in mL, from 0 to 10000. A typical value is around 80, compared to a realistic average of 1.5-5 mL for real-life ejaculations. It's a porn game. General "cum levels" are categorized based on the CumProduction enumeration.	Int	Required	0 to 10000
67	tentacleType	Currently unused (as of v0.4.9), as tentacles are only used for the leg configuration CEPHALOPOD. Leave this as <tentacleType>NONE</tentacleType>.	Text	Required	NONE
70	clitSize	Clitoris length in cm, as an integer 0 to 100. A typical value is 0, for just a nub. Lengths above 4 enable using the clit as a penetrator. Size enumeration is in ClitorisSize.	Int	Required	0 to 100
78	maleWingSize/femaleWingSize	Size rating for wings, as an integer 0 to 4. Usually 0. For wings to enable flight, requires a size of 3 or greater for most leg configurations and all ferals, and 4 (max) for non-ferals with QUADRUPEDAL, TAIL_LONG and ARACHNID.	Int	Required	0 to 4

Body Parts

These files each define a single part type, and are found in the folder as res\mods\<author>\race\<race name>\bodyParts\<part name>.xml, and the internal name for each is <author>_<race name>_<part name>. While the file name doesn't necessarily have to match what body part it is, it is recommended that you name them so they match (such as keeping the face type in face.xml). There can be multiple types for each body part, for example different tail variants as seen in the salamander-morph race: tailFlame.xml and tailFrost.xml.

These parts appear in the #Body Definition and could also appear in subspecies changes. Many of these will use the #Coverings you define for this race mod.

Depending on the body part, the elements required for each XML differs. Using existing parts from another race as a template is the easiest way to make sure all the required elements are present. You can also refer to the abstract types in src/com/lilithsthrone/game/character/body/abstractTypes. The constructor that takes in an XML file (example public AbstractArmType(File XMLFile, String author, boolean mod) in AbstractArmType.java) shows how the object loads up from the XML. Though the elements differ, there are common elements shared between different files:

Element	Description	Type	Options	Values
[root]	The root name generally matches the part name, such as "penis" inside "penis.xml". The name of the root does not seem to actually matter though.	Root	Required
race	The name of race for a body part. Usually should be the internal name of the race (e.g. innoxia_hyena). Can also be set to NONE for "generic" parts that don't affect race calculations, and are available to all racial transformation potions. Avoid doing this for parts other than horns and wings, to avoid cluttering the potion enchantment menu.	Text	Required
transformationName	The name that will be used when referring to transformations related to this type (such as when changing body parts in the self-TF menu). Usually just the race name (e.g. "hyena"). For different variant types, can be made different to make it easier to choose the right variant for potion making/self-tf.	CDATA	Required
coveringType	Depending on the part, should be either an existing covering type, or one of the coverings defined in the race's #Coverings. If the part XML has a code-defined covering (e.g. "TONGUE"), it should probably be left alone.	Text	Required
tags	Tags associated with the part type. Can define things like whether a face is a muzzle and has fangs, whether a tail can be used to penetrate orifices, etc. Tags can be found in BodyPartTag.java, which has comments to tell you which tags can be used with what parts. Each sub-element is a "tag" elements with the contents being the tag name, example: <tag>TAIL_TYPE_FUR</tag> If left empty, will generally be filled with default tags.	Element, Text	Required, Can be empty
names namesPlural namesMasculine namesFeminine [x] before above	Note the plural in the element name. Each sub-element is a "name" element, with the CDATA contents. Lists out names that can be used to generate body descriptions of this part. Ex:    <namesMasculine>        <name><![CDATA[hyena-]]></name>    </namesMasculine> If left empty, generally uses a generic list.	Element, CDATA	Required, Can be empty
name namePlural [x]Name [x]NamePlural	Just a single name for a part (or aspect of the part), in the CDATA contents.	CDATA	Required
descriptorsMasculine descriptorsFeminine [x]descriptorsMasculine [x]descriptorsFeminine	Each sub-element is a "descriptor" element, with the CDATA contents. Lists out descriptive statements used to generate body descriptions regarding this part. Ex:    <descriptorsMasculine>        <descriptor>hyena-like</descriptor>        <descriptor>fluffy</descriptor>    </descriptorsMasculine> This are outside of the full body description, and are instead used in scenes like sex or combat.	Element, Text/CDATA	Required, Can be empty
transformationDescription	The description shown when transforming the part into this part, such as when drink a TF potion. Goes through the parser. Depending on the part, may be split into two variants for different conditions, such as single vs multi-tail. Usually ends with a statement clearly summarizing the transformation. Ex: Letting out an involuntary moan, [npc.name] [npc.verb(feel)] [npc.her] penis shifting into a new form, and [npc.sheIs] hit by a wave of overwhelming arousal as a thick sheath suddenly grows around the base of [npc.her] shaft. As [npc.she] [npc.verb(pant)] and [npc.verb(gasp)] for air, the tip of [npc.her] cock narrows down as it tapers into its new form. <br/>[npc.She] now [npc.has] a [style.boldHyena(hyena-like penis)], [npc.materialDescriptor] [npc.penisFullDescription(true)]. <br/>[npc.She] [npc.has] [style.boldHyena([npc.ballsCount]#IF(npc.isInternalTesticles()) internal#ENDIF balls)], [npc.materialDescriptor] [npc.ballsFullDescription(true)], which produce [npc.cumColour(true)] [style.boldHyena(hyena cum)].	CDATA	Required
bodyDescription	How this part is described in a character's description page.	CDATA	Required

Depending on the part, there will be other elements (ex: default girth, penetration modifiers for a penis). In the hyena body parts, there are comments for each.

In the race folder, you can put parts that are not in use (such as horns, wings, etc.) into res\mods\<author>\race\<race name>\unused_bodyParts\. This isn't strictly necessary, as that folder is just ignored, but it can be handy to keep track of what parts are not used (or what parts are WIP).

Colours

Each individual color XML file defines a custom text color, as res/mods/<author>/colours/<colour name>.xml (note the UK spelling). The internal name of the color is <author>_<colour name> (ex: clayRed.xml).

Element	Description	Type	Options	Values
colour	ROOT ELEMENT	Root	Required
metallic	For metallic colors, the color selection will have shading for a metal luster, and will have "metallic" automatically added to certain descriptions. Should be "false" in most cases, since most of the time the custom colors are used in description or icon text.	Boolean	Required	true false
name	The name of the color, used when displayed in descriptions or color selections.	CData	Required
colour	A hex code for the color. Six hexadecimal digits, for RGB. Uses the Java function Integer.parseInt Oracle Doc. Ex: a62e21	Text	Required
lightColour	A lighter version of the "colour" element. When using this for description text and icons, can just be the same as "colour".	Text	Required
coveringIconColour	The color displayed in color selections. Can be left out or be left empty, in which case this defaults to the value in "colour".	Text	Optional
formattingNames	Alias names for this color, especially convenient for parser color formatting. Sub elements should be "name" elements, with CData content of the alias. Example: <name><![CDATA[brickRed]]></name> in the color XML will let the parser use [style.boldBrickRed(This text gets displayed as brick red)] for color styling.	Element, CData	Optional
tags	Purportedly adds colors to certain lists for covering generation, etc. Does not appear to actually do anything yet. Leave as empty-tag element. Subelements would be "tag" elements, with the content being text matching a ColourTag.	Element, Text	Optional

Using Colors

Usually though, you can use one of the preset colors here: PresetColour.java.

These colors are used either as text mod XML files, or in CData sent through the parser.

When using the colors in an XML file, it should use the internal name of the color (ex: sightglass_clayRed).

When using it to style text in the parser (see the parser primer section on style), use one of the formattingNames (ex: [style.boldBrickRed(This text gets displayed as brick red)]).

Other Resources

• Modding:Parser Primer / Parser Command Reference / Parser Target and Binding Reference
• Modding:XML File Format Primer
• Modding:Inkscape Guide for LT
• Modding:General Modding Guide