Modding:Race Modding Guide - Lilith's Throne (2024)

[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 sh*t out of someone.

It may be helpful to keep some browser tabs open for "research" (like a wiki page, and furry p*rn) 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.

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

Main article: Modding:Parser Primer

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>

Then, 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

#ENDIF

#ELSE

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

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.

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:

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

Coverings

Coverings are found in the folder as res\mods\<author>\race\<race name>\coveringTypes\<covering>.xml, and the internal name for each is <author>_<race name>_<covering>. You will generally have three for body hair, eyes, and hair (respectively body_hair.xml, eyes.xml and hair.xml), and one covering for fur, scales, skin, etc. depending on what exactly your race needs. Covering types are not inherently tied to any particular race, so if you want to use existing covering types for these, you can. It'll just mean that the coloration for your species will be the same as another's.

These covering types are usually used in the #Body Parts you define for the race. The body hair covering is directly reference in the #Body Definition.

The abstract type is found in src/com/lilithsthrone/game/character/body/coverings/AbstractBodyCoveringType.java.

Covering Patterns

The "naturalPatterns" and "extraPatterns" maps are used to give weighted probabilities for different fur/skin/scale patterns to appear in generated characters.

The subelements are each "pattern" elements, with an attribute "weighting" giving an integer weight, and the content matching one of the patterns in CoveringPattern.java. The ones you should generally use are:

• NONE
• HIGHLIGHTS
• STRIPED
• SPOTTED
• MOTTLED
• MARKED
• FRECKLED
• OMBRE

"NONE" is plain and unpatterned.

An example of a natural pattern map, from Hyena-morph fur:

<naturalPatterns>

<pattern weighting="1">SPOTTED</pattern>

<pattern weighting="1">STRIPED</pattern>

</naturalPatterns>

If "naturalPatterns" is absent or empty, the map is just filled with "NONE" with a weight of 1. If a pattern is in both "extraPatterns" and "naturalPatterns", then that pattern is skipped over in "extraPatterns".

Covering Colors

These elements define which colors are available to the covering. If the covering is patterned, "primary" colors are on the ground, and "secondary" colors are the one that appear in pattern markings. For example, striped fur with orange as the primary and black as the secondary might be described as "orange with black stripes" in body descriptions. The colors in the "natural" lists are used when generating characters, and the "extra" colors only appear in transformation menus changing the colors of the covering.

There are two ways to set these lists:

1. Use a "values" attribute in this element. The "value" attribute matches a color list preset found in ColourListPresets.java, such as "naturalFurColours".
2. Explicitly list out colors. For each color to add to the list, create a "colour" sub-element with the text value being a color in PresetColour.java. Usually, you would use one of the one starting with "COVERING_".

The example in hyena-morph fur:

<naturalColoursPrimary>

<colour>COVERING_TAN</colour>

<colour>COVERING_BROWN</colour>

<colour>COVERING_BROWN_DARK</colour>

</naturalColoursPrimary>

<extraColoursPrimary values="allCoveringColours"/>

<naturalColoursSecondary>

<colour>COVERING_BLACK</colour>

</naturalColoursSecondary>

<extraColoursSecondary values="allCoveringColours"/>

Note you can use either the "values" attribute with a colour list preset, or list out the preset colors as sub-elements, but not in the same element. If you have both, the list preset given in the "values" attribute takes precedent.

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

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

• 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