As some of you are already aware, h.coder released the source code for potential future releases of Fetish Master; while the official version is still 0.985e, the Git source is versioned at 0.99. Over the last eight months or so, I’ve been adding my own tweaks and changes, testing how I can bend the engine some without breaking it. None of these have been submitted for consideration to the main branch, as a lot of it is either subjective or hastily coded.
While I haven’t added new events, and only implemented a couple event tweaks and items to test some changes, it should be compatible with most mods. I’ve implemented a new digestion system, but a lot of the stomach content is based on Dohavocom’s code (with some tweaks) and should be compatible with his mod. The main branch also implements most of Maternal-Reads’ organ changes, so the only* issue at hand is Nost’s old mod, which may or may not be getting the clean-up and expansion it deserves soon enough.
*While Maternal-Reads’ mod is largely compatible, the way it’s distributed will be a bit of an issue. I might make a compatibility release, as a lot of things will likely go wrong if installed as-is. If you wish to install it, delete its dist folder first, and note that some of its changes might interfere with some of the changes in either the base 0.99 or this branch of it.
Unfortunately I’ve been a bit lax in terms of taking notes; I made most of my edits on whims and the old forum was the only source of documentation for most of it; neither Google’s cache nor the Wayback Machine captured the old threads in any useful capacity. Still, I’ll try to outline the major changes and caveats below:
Layered Images and Paper Doll supportPreviously, the game supported two image layers - one for the background (DisplayBG()), and one for a character or object in the foreground (DisplayChar()). For modders that wanted a detailed paperdoll system - something where parts of the character image changed based on parameters like clothing, hair color, bust/belly size, etc. - this was pretty limiting.
I’ve added a new method for use in events and templates:
Note the curly braces - while the other image methods take a single string as input (pointing to the matching image), DisplayChars acts on an array, which can be defined on the fly as a series of comma-separated strings inside a set of curly braces. The first image in the list will be the first rendered, making it the bottom layer, while the last image will become the topmost layer.
There are no limitations on the number of images that can be called, beyond memory limits, and otherwise as far as the user is concerned it functions similarly to the other display methods. The largest caveat as of now is that the process is fairly slow (it can cause the game to hang for upwards of a second), and I haven’t really worked on making it efficient.
Simplified flag operations, and EventExistsI was getting tired of how messy it was to get and change a flag's value just for simple increments, so I simplified the process with
IncFlag/DecFlag(string)As the method names suggest, these simply take the flag given as input, get its value, and increment or decrement the value by one respectively. To further simplify matters, there's also
AddFlag/SubFlag(string, int)- similar to the above, it calls Inc/DecFlag on a given flag int number of times. There are also matching methods for personal flags - Per*Flag or *PerFlag, given your personal preference.
I also added a much less generally useful boolean method - EventExists(string). The given string should be the path to an event file, as generally as it would be for adding an event choice. If the file exists, it returns true, otherwise it returns false. This is primarily useful for modders who want their events to extend other mods - in my case I was using it to avoid triggering a certain dialogue path if the game couldn’t find that Dohavocom’s mod was installed, as there was no flag necessarily related to what I wanted to do.
New Digestion and Stomach Capacity codeBefore the old forum crashed, there were some discussions about the inadequacies of the older digestion code. People with massive stomachs could take upwards of a week to digest their loads partially or fully, and the math didn't do a great job of handling low-calorie meals, to the point of some spectacular failures.
As it was written then, the body would digest a set amount of calories per hour, and subtract an amount of food matching the calories digested to total calories ratio, with some quirks for low numbers. I rewrote it to be a little closer to reality - now the body digests a set amount of food per hour based on your maximum stomach size, so that a full (but not stretched) stomach would digest fully over the course of 40 hours or so, with overstuffed stomachs taking longer to process.
Additionally, stomach capacities and stretch capabilities were largely rewritten based on Dohavocom’s code. There are some changes; I don’t factor in things like the desireforfat skill, and some tweaking allows for the absolute maximum capacity to increase naturally, if very slowly, but as far as I’ve found nothing breaks compatibility with his mod. However, the amount of testing I’ve been able to do by myself is limited, and adapting for the old Digest-Up effects is still a bit of a trial-and-error process.
Changes to Body Fat CalculationsThis is where things start getting a little dicey, as there's been limited testing here. Essentially, while the old code calculated an average weight based on the size, it made the assumption that body fat was zero percent, meaning everybody started at a perfect weight, and creating skinny characters was essentially impossible. Instead, I changed the calculations so that a portion of each (adult) character's starting weight is stored as fat, making estimates as to how much added weight would be 'excess' fat and changing some of the body fat level descriptions to be a bit closer to reality. Other changes include metabolism slowing down for underweight/starving characters and additional points of certain physical traits adding to your lean weight to simulate added muscle weight, and changes to the way lactating burns calories to balance things out.
The big issue with this so far is that NPCs don’t eat without being forced to by an event; people who burn calories regularly via activities like milking won’t make up the deficit, eventually draining away their body fat and leaving them skeletal. I’ve contemplated a number of solutions, but until actually implementing one I don’t plan on putting out any sort of pre-compiled release.
Support for limited-stock items in shopsEssentially, using addItemToShop(string, int), you can add an item to a shop in a quantity defined by int; after buying that many, the item disappears from the shop. However, the stock value is currently stored in the store inventory, and gets reset any time the shop is reloaded; you'll want to use this in conjunction with LoadShop below. Additionally, there's still no visible indication regarding the available stock of a limited item in a shop. Otherwise, though, it works more or less as intended.
You may want to use this with a conditional method such as a flag check, as the specified amount of the item will be added to the store each time the AddItemToShop call is made.
'Parallel' organs and multiple sets of breastsThis is a mess of my own creation, owing to looking back at old versions of the SDK and noticing things that could've been implemented but weren't. The idea of a parallel organ was that you could have a second version of an organ under a different name, that still responded to the same action calls and acted on stats featuring its own name rather than a set of stats defined explicitly.
As an example, I rewrote the breasts organ to support this sort of parallelism, with an example item added to the item shop designed to give characters a second set of breasts and a few events and descriptions changed. I haven’t explicitly rewritten most of the events, so I can’t guarantee things that affect the breasts organ would actually affect any other organs typed as breasts under different names.
The basic way of adding a parallelized organ is largely the same as activating any other. The game looks at .exists stats, and if they’re active, it tries loading the organ of that name. However, since something like breasts2 isn’t a defined organ, we have to make it look somewhere else. Instead, we tell the engine to look at the text value defined for the exists stat if doesn’t exist. if it finds something - say, if the text value of breasts2.exists is breasts - we create a new breasts organ, redefine its name as breasts2, and add it to the character. This requires the organ to be written in a way that the stats associated with it don’t have a defined organ name; for example, while the original breasts organ defined the volume of milk held with “breasts.milk_volume”, we need it to be something like this.name+“milk_volume”. If the stat name were the same for both organs, we’d be updating the stat for the original organ twice without even defining a unique stat for the original organ.
Naturally, this isn’t a perfect solution, and it might cause more headaches than it would’ve to just copy and paste the original organ a few times and changing the names. But there might be instances where it’s genuinely useful, complicated as it is. I’d love if I could get some feedback on this.
Permanent shops and LoadShop methodOne of the big issues with the idea of adding limited-stock items to shop inventories was that shops were essentially temporary constructs; every time you open a shop with NewShop(), it creates a new shop. This makes it a pain in the ass if you want to add a limited-stock item but don't want it added every time the shop is opened, or want to keep track of stock between visits.
I’ve added a new method
LoadShop(String title) that simplifies this through the magic of hashmaps. By using it instead of NewShop, it will create a storefront with the specified title if it doesn’t exist, or load the one stored in the world if it’s been created. This also means that AddItemToShop only ever needs to be called once, but again with the magic of hashmaps, if you try to add an item to a shop when it already exists, you won’t get duplicate shop entries (though calling AddItemToShop with a limited stock amount will add that amount of the limited item each time). And of course, if this all seems needlessly complicated, the old method works just fine.
For example implementation, look at the updated event file for the item shop near the outskirts.
I think that about covers the important stuff. There’ve also been a few tweaks to fix what broke when Maternal-Reads’ organs were implemented, although a bunch of udder stuff probably isn’t working yet.
If possible I’d appreciate feedback - what works, what’s horribly broken, what could be improved and what’s too confusing. Most of this stuff was thrown together with little or no actual planning, so there’s a lot that needs cleaning up, but I’d like to know what people find useful and what can get moved to the back burner.
For anyone looking to try it out, make sure you’re using a clean install and fresh saves. The basic 0.99 image pack is available here, and if you’re installing other mods, please don’t copy over the dist folder if they include one.