Modding:Race Modding Guide

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.]

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. 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.

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?
Body Parts - What unique features do they have? Can these be used to distinguish different subspecies?
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.
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".

Race definition
Colors (for description text, icons, etc.)
Body parts
Coverings
Racial body
Subspecies
Subspecies icons
Lore book
Potion Items
Combat moves (if any)
Name lists (if using)
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:

Must start with a letter or underscore ( _ )
Cannot start with xml
Are case sensitive!
Cannot contain spaces!
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

Flow Control

Using var

Body Generation

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

The template, using racialBody and the race stage
"applyRaceChanges" in race.xml
"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.

Making SVG Images for Race Mods

For general guidance, see also: Modding:Making SVG Images 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.

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: #Colors	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>

<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. [TODO: Sorting index]

Element	Description	Type	Options	Values
racialBody	ROOT ELEMENT	Root	Required
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
bodyHairId	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
genitalArrangement	GenitalArrangement, usually "NORMAL"	Text	Required	NORMAL CLOACA CLOACA_BEHIND
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
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
maleBodySize/femaleBodySize	Body Size ranges from 0-100. Cutoffs for different categories are found in this enumeration.
maleMuscle/femaleMuscle	Muscle ranges from 0-100. Cutoffs for different categories are found in this enumeration.
armType assType breastType breastCrotchType	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
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	Element, Text	Required
anusCapacity maleBreastCapacity/femaleBreastCapacity breastCrotchCapacity	Capacity values for various penetrable orifices, from 0.0 to 25.0, following the Capacity enumeration Typical values: 1.5 for Anus. 0 for Breasts/Crotch-Breasts. Size must be 7 or greater and capacity must be nonzero for nipple-penetration to be possible.	Float	Required	0.0 to 25.0
anusWetness	Wetness value for various penetrable orifices. Enumeration value from 0 to 7, following the Wetness enumeration. Typical values: 0 for Anus.	Int	Required	0 to 7
anusDepth maleBreastDepth/femaleBreastDepth breastCrotchDepth	Depth value for various penetrable orifices. Enumeration value from 0 to 7, following the the OrificeDepth enumeration. Typical values: 2 for Anus and Breasts/Crotch-Breasts.	Int	Required	0 to 7
anusElasticity maleBreastElasticity/femaleBreastElasticity breastCrotchElasticity	Refers to 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.	Int	Required	0 to 7
anusPlasticity maleBreastPlasticity/femaleBreastPlasticity breastCrotchPlasticity	Refers to 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 for Anus and Breasts/Crotch-Breasts. 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
maleAntennaLength/femaleAntennaLength	Length in centimeters. Leave as 0 for races without natural antennae.	Int	Required
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
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
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
breastShapes breastCrotchShapes	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
maleBreastSize/femaleBreastSize breastCrotchSize	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
maleBreastRows/femaleBreastRows breastCrotchRows	Pairs of breasts, from 1 to up to 6. Usually 1 for chest, 2 for crotch-breast.	Int	Required	1 to 6
maleNippleSize/femaleNippleSize maleAreolaeSize/femaleAreolaeSize breastCrotchNippleSize breastCrotchAreolaeSize	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
maleNippleShape/femaleNippleShape breastCrotchNippleShape	Shape matching the NippleShape enumeration. Typically "NORMAL"	Text	Required	NORMAL INVERTED VAGINA LIPS
maleAreolaeShape/femaleAreolaeShape breastCrotchAreolaeShape	Shape matching the AreolaShape enumeration. Typically "NORMAL"	Text	Required	NORMAL HEART STAR
maleNippleCountPerBreast/femaleNippleCountPerBreast nippleCountPerBreastCrotch	Number of nipples per breast, up to 4.	Int	Required	1 to 4
maleLactationRate/femaleLactationRate breastCrotchLactationRate	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

Body Parts

Coverings

Subspecies

Book Entries

Items

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)]).

Combat Moves

Name Lists

Other Resources