Jim's FM 0.99 branch: new engine features, bloated code, and no practical examples

simulation
java
mod
dev-notes
video-game

#1

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 support Previously, 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: DisplayChars({}).
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 EventExists I 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 code Before 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 Calculations This 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 breasts This 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 method One 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.

You can find the source code for my branch at GitGud. I’ve uploaded a precompiled build to Mediafire (password: fmaster); as it lacks images, you’ll need the image pack linked below.

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.


#2

Update 7/20
– Fixed an issue that slipped into the previous commit, causing the Breasts organ to fail to compile
– Uploaded a precompiled build for those who wish to test but have issues with compiling

Note that while the precompiled build is a standalone version of the game, it’s not intended to be used as a modpack and contains very little in terms of playable content that differs from official builds. If you copy this into an existing install, bad things will likely happen, including all your saves breaking.


#3

I really appreciate the work you’ve done with this kind of thing. I plan on using this stuff, but i’m going to wait until i finish my current update before i make things fit together. Just for my own sanity.


#4

Update 9/28

  • Small tweaks to when body fat percentage calculations are done
  • Added hardcoded dragon_body organ (for use with dragon mod)
  • Added support for persistent shops (see LoadShop in the first post)

Precompiled build link in the first post has also been updated.


#5

the copy i downloaded came with no executable how do I play I got java


#6

If you’re on Windows, use either start.bat for normal gameplay or start_dev.bat for dev mode.

You’ll also want the image pack from the first post if you haven’t downloaded it.

If you’re just looking to play the game, though, there’s a lot of barely-tested code and very little new content for players compared to official releases.


#7

when i download it it has no executable


#8

There should be two .bat files instead of two .exes. They act the same as an executable, just smaller.


#9

I don’t want to sound annoying but whatever I downloaded didn’t come with any executables


#10

There are no executables because Java applets don’t use executables. If you’re downloading from the precompiled MediaFire link, double-click on either the start.bat or start_dev.bat once you’ve extracted the archive. This should start the game; if it doesn’t, then there’s a problem with your Java installation, but I can’t help without knowing what it is.


#11

I reinstalled it now it’s fine thank you


#12

Make sure you install the 64 bit version of Java if you’re running on a 64-bit OS. This will allow apps to use more RAM.


#13

Is there a way to bring back the detailed measurements that the old version had in the appearance screen? I know it kind of defeats the purpose of the actual physical measurements event, but I’m also a nerd like likes watching numbers grow.


#14

Open /cview/full_description.tpl in the Templates Editor and add <%Include(“debug/num_stats”);%> to the bottom of the file. I’m not entirely certain why it was changed to start with but I’ve been too lazy to change it back.


#15

Want me to change it for you, fix a whole bunch of typos I’ve found and send the files to you?


#16

You can if you want, and I’ll probably get around to merging it all, but typo-fixing hasn’t really been my focus. If it’s typos in files I haven’t been messing with you might be better off sending them to h.coder or something to get them implemented upstream.


#17

Unrelated to all that: @jimbobvii , would it be hard to add a folder support for items? It would make dealing with them a lot easier.


#18

I’m guessing you don’t mean subdirectories for .item files, since that already works fine (as long as you remember to use the full path whenever a script adds/checks/removes/etc.).

If you mean folder support for character inventories, etc., then it’s a bit more complicated. It’d probably be trivial to add a ‘type’ field for an item - food, medicine, key, misc, whatever - and update the item constructor. The problem is that my knowledge of actual UI coding is essentially zero; the item editor would have to be updated to allow for specifying a type, and then you’d want some sort of collapsible set of folders populated automatically by ‘type’ descriptor, which I also would have to fumble through.

It’s not impossible, and possibly not even difficult, but it’s not something I feel like tackling any time in the next few weeks.


#19

I meant the first option.

And your were right, it is already there. I remember trying it a couple years ago and having the engine spit errors at me. I must have just messed it up. Thanks though!


#20

Small issue with my dev mode- I can’t seem to edit Organs from the edit character window. The Edit Organ button does not resolve. I’ve had to edit the organs seperately, then Delete/Add.