-
-
Notifications
You must be signed in to change notification settings - Fork 10
Modding: Sextalk
The Sextalk plugin has undergone a complete rework in V1.2, whereas the goal was to enhance the supported complexity of the system to accommodate the widespread variety of potentially dialog relevant situations while simultaneously drastically simplifying the editability of the underlying file for ease of access. With the new Sextalk v2 plugin, in theory every user should be quite easily able to modify or expand upon the given dialog options for themselves.
In the following the inner workings of the new Sextalk v2 plugin will be explained, as well as how to read and edit the dialog files.
Sextalk is the plugin responsible for the actors - if possible - talking dirty during sex. The new system uses a centralized clock that ensures only ever one random available actor talks every time the config set cooldown period is over. During the sex and climax states this timer ticks down and, upon reaching 0, chooses a random available actor to say their part before applying the next cooldown. During the transition between most any state, a new line of dialog is immeadiately triggered - meaning that even though your "during normal sex" dialog has only been on screen for 2 seconds, upon triggering climax a new climax-specific line might override this.
The "available" actors are, as before, determined by the position config file which defines if any participating actor is actually allowed to talk in a given state (e.g. to prevent funky Hentai scenarios where the actor actively giving a blowjob somehow manages to hold an entire speech with their mouth full.)
Every actor then chooses a "partner" to talk to, determined by who they are currently actively engaging with. E.g., in three-actor standing the middle (actor 2) one can choose to talk to either the one fucking them from behind (actor 1) or the one they are currently fucking (actor 3), changing the used dialog according to the pair's situation.
Now on to the heart and source of the dirty talk: The dialog files themselves. This is where ultimately all the options for the talk are defined, albeit split into chunks and "modules" to make them easily expandable, editable and removable. The files are located at /dialog/sexbound/<language code>/positions/<position>/, which immediately showcases the first layer of segmentation. Every position uses their own dialog file (defined per species in the corresponding position config) per species. E.g. a Floran during missionary will use the file /dialog/sexbound/<language code>/positions/missionary/floranmissionary.config. This file, including its "base" predecessors, defines all the dialog available to a Floran actor while fucking in this position.
The structure within a given "species x position" dialog file has been very much streamlined to be human readable. You may remember old Sexbound's Sextalk files to be a weirdly confusing, deeply nested mess of states and conditions that are way too strict, as everything ultimately revolves around the main genders "male" and "female", nothing more. It also revolved around the (numeric) role an actor has in said position, which is absolutely none-saying to any normal user.
Sextalk v2 has streamlined the structure to a straight-forward, human-readable minimum that technically supports a near infinite tree of scenarios. It does so by using a modular replacement approach, modules and inheritance. More on that in detail later.
The main structure of a Sextalk v2 dialog file can be described as follows:
header -> interaction type -> actor state -> partner state -> partner species -> dialog module
Example as JSON structure
{
"base": "<base file>",
"content": {
"<interaction type>": {
"<actor state>": {
"<partner state>": {
"<partner species>": {
...
}
}
}
}
}
}The header of the file is used to set some generic setting about inheritance. It consist of up to three parameters:
-
base: Defines another dialog file that is loaded beforehand, whereas the content of this file are applied to. Imagine npctype stacking. -
add: A Boolean setting determining if this file's module content is overriding or adding to the base file's. -
content: The main block containing this file's dialog structure.
To explain what add does with an example:
Imagine having a base file which defines the line "Oh yes!" for vaginal interaction while both actors are in the "sex" state, for any (default) species.
Now your child file (the one you are currently editing) has the line "Deeper!" for the exact same scenario - vaginal, both actors in "sex" state, for any (default) species.
If "add" is set to "true", the result will be that both lines can play in that scenario. If it is "false" (or doesn't exist), "Deeper!" will now replace the previously defined "Oh yes!", and only one line is available for this scenario.
What was previously a lacking combination of "actor role", "actor main gender" and "partner main gender" has been compressed to just the "interaction type". This is determined primarily by what is set in the position's config as well as some body trait conditions, although this shouldn't be of any concern to those who only want to understand and write dirty talk dialog. Currently the following interaction types are supported:
-
vaginal: Normal vaginal penetration. Guarantees that "actor" has a dick or strapon to penetrate and "target" has a vagina. -
r_vaginal: Vaginal, but you are at the receiving end. ("actor" has vagina and is being fucked by a dick or strap-on.) -
anal: Anal penetration. Does not guarantee anything about which genitals are present on "target", but "actor" has a dick or strap-on. -
r_anal: Anal, but it's your ass. See "r_vaginal". -
oral: "actor"s dick or strap-on is going down "target"s throat. -
r_oral: You're giving a blowjob, but this should never happen as you don't talk when your mouth is full with dick. -
cunnilingus_vagina: Like oral, but you can guarantee the "target" has a vagina "actor" is licking. -
cunnilingus_ass: Cunnilingus version that guarantees the "target" does not have a vagina. -
r_cunnilingus: Cunnilingus, but it's your vagina getting eaten out. -
boobjob: Dick or strap-on goes between your boobs. -
r_boobjob: Boobjob, but it's your dick or strap-on. -
masturbate_M: Masturbation with a penis. No strap-ons allowed. -
masturbate_F: Masturbation with a vagina. -
toy_vagina: You're having fun with a fleshlight. You have a dick or strap-on. -
toy_in_vagina: You're having fun with a dildo. It currently goes where it's supposed to. -
toy_in_ass: You're having fun with a dildo. It currently goes up your ass. -
default: No idea what the hell you're doing, but I hope it's fun. (Fallback)
This refers to the technical state the interaction is currently in. There is currently four states available:
-
sex: Just sex. No climaxing or anything. -
preclimax: Special state for being about to cum. -
climax: Currently spreading your bodily fluids. -
postclimax: The 1.5s long transition state after a climax into the next sex round.
Keep in mind, that "preclimax" and "postclimax" only ever appear in pairs. So you do not need any "sex x preclimax" combinations, for example. Only "sex x sex", "sex x climax" (both ways) and "preclimax x preclimax" as well as "postclimax x postclimax". The latter also being optional because it's very rare to trigger this dialog.
Well, it's an actor's species, duh. Only thing of note is that this is where modules use inheritance themselves, and "default" as species is the generic "catch-all". So if you define "default" dialog and then "human" dialog, fucking a human will trigger unique responses as defined there while any other species triggers the same normal default dialog. More on inheritance... now.
On this layer, inside the species layer, you define the actual dialog - which can also inherit or override their generic counterpart. A dialog module consists of the following properties:
-
override: If this dialog adds to the "default" species one or completely overrides it. -
text: The list of stuff to say. -
status: A list of sub-modules based on a status your actor can be in. Duplicates between these and "default"s "status" sub-modules always override. -
otherStatus: A list of sub-modules based on a status your target can be in. Duplicates between these and "default"s "otherStatus" sub-modules always override. -
bothStatus: A list of sub-modules based on a status both actors must have. Duplicates between these and "default"s "bothStatus" sub-modules always override.
These sub-modules themselves consist of up to four properties:
-
override: If the text defined for this module adds to the main module's text or overrides it entirely. -
overrideSoloStatus: Exists only for "bothStatus". Defines if this module and it's counterpart for any singular actor add or are exclusive. -
priority: A number in ascending order that determines in which order multiple sub-modules are applied. -
text: The list of stuff to say.
More interesting are the available statuses you can check for:
-
pregnant: The actor is visibly pregnant. -
heat: The actor is in heat. -
defeated: The actor is defeated as part of Sexbound Defeat. -
hasPenis: The actor has a penis. -
hasVagina: The actor has vagina.
Exmaple in JSON
{
"override": true,
"text": [
"This dialog triggers when both actors have sex"
],
"status": {
"pregnant": {
"text": [
"This dialog ALSO triggers when both actors have sex and you are pregnant"
]
},
"heat": {
"override": true,
"priority": 5,
"text": [
"This dialog triggers when both actors have sex, you are in heat, and it overides the base dialog as well as the potentially applied pregnant dialog."
]
}
},
"bothStatus": {
"pregnant": {
"overrideSoloStatus": true,
"priority": 10,
"text": [
"This dialog triggers when both actors have sex and are pregnant. It adds to whatever exists before (normal or heat, as it loads after heat) and prevents the other pregnant block from applying even when heat does not override it."
]
}
}
}If you have now understood the general structure of a Sextalk v2 dialog file and want to start throwing your own dialog into the mix, the process can be as simple as you want. Utilizing the base inheritance system, you can just "add" to any existing dialog with three different levels of pre-filled content. Here is an explanation with examples:
Let's assume you just want to add new special dialog for a new race. Let's say you want to have humans say unique dialog when fucking a Neki. In that case, you would create a new dialog file, which references /dialog/sexbound/<language code>/positions/missionary/humanmissionary.config as base. Now all you need to define in your new file is "vaginal" -> "sex" -> "sex" -> "neki" and boom - all normal human dialog is intact but they say something new for Nekis. Patch the missionary position config so that it loads the human dialog from your new file instead and you're golden. The same also applies to completely new races with human-esque speech patterns, as humans currently just use the top level default file defaultmissionaryfull.config without changes. This is the easiest entry point for dialog.
Now let's assume you want a bit more control when creating you own dialog. Then you could instead make your base be dialog/sexbound/<language code>/positions/missionary/defaultmissionary.config (note the missing "full"). This is the same dialog, but without any racial flavor text.
For example, defaultmissionary contains all default dialog for every scenario. defaultmissionaryfull contains the additional racial flavor text. By hooking into the former you get only default dialog that is independant of race, while hooking into the latter gives you the full template that already contains special dialog when encountering certain common species.
Finally, you might have a species like the Glitch, Floran or Fenerox with speech patterns that are greatly different from human speech. No need to load all that useless dialog just to make yourself the work to override every single one of it then. Instead you can make your base /dialog/sexbound/<language code>/defaultsextalk.config. This file really just has the bare minimum to fill gaps with none-saying moans and exclamations. (You could also use no base, but I recommend using this fallback placeholder to make sure you have something for scenarios you might missed.)
All these options to make you species' actors talk are nice and handy. But what if your species is more of the "silent enjoyer" kind? No talk, just groaning and plowing? Maybe you had done similar before and realized now that the config option "skipMergeDefaultDialog" is gone, which you used before to ensure no default dialog is used.
Yeah, well, patching configs that the user is supposed to edit is a bad idea - so it's now gone! The user now has full control over if he want's unsupported species' to use default dialog or not. But don't worry, there is obviously a new way you can use your creator's authority and tell the player how to enjoy their game:
The dialog file defined as "default" species is only ever used as a fallback, when no file for your current species is defined. So the solution is simple: Just define one that's empty!
Quite literally, just create an empty file, ideally named something related to the sextalk of your species and ideally located in the "dialog" subdirectory. If you want to look smart and save other people alot of trouble should they, in turn, want to mess with your stuff, fill in atleast the basic patchable structure:
{
"base": null,
"content": {}
}Now, all you gotta do is patch that dialog file into all the position files as dialog for your species! It exists, so no default will ever be used. It doesn't define a "base" file, so the empty "content" is all we get. In which case, your species' actors will forever stay silent (in dialog)! You can also skip the part where you put it into a language's directory and add <langcode> to the path in the position configs in order to apply this silence to all possible languages.