Ok, "Playable!" may be a bit of an overstatement given this is just a prototype to test out the backend I've built over the last week and to set-up a release workflow. But still, I'm super excited! Currently I handle game projects as more of a background kind of thing and don't say a whole lot about them before they're ready, simply had to many projects fall apart and not go anywhere, but I'm trying something new with this one! (Also worth mentioning, the title is very much a WIP title and just a placeholder! We'll have a fancy name soon enough! ^-^)

Some quick things to mention about the current build, I wanted to just develop something over a week and see how much I could get done and set myself a (relatively) strict release timeline to get whatever I had done out by the end of said week. Technically I took a day longer than planned because I had some save-system issues and got too tired to release yesterday, but 1 day off isn't bad! This version is a very simple front-end and gameplay loop to test the backend systems that will power the actual game, but this does not represent the gameplay of future versions (I already have stuff in the works that will change things rather drastically ^-^). So consider this a test prototype purely designed for testing! (In-fact, a community member in the Discord, alphabetsoupdog123, already helped me find a logic error which I fixed earlier today! Thank you, alpha!~)

Although there are executable versions available for testing (I specifically need people to test on Linux just to make sure the export is working on different repos), I recommend checking out the web-version over on my site for easy and quick testing! (Future supporter-only versions won't release on web, sorry! >.<)

WebGame Version : https://michaelpstanich.com/webgame/idlefoxrpg/

Download Links!
(Public Release 0.0.1)
Website : https://www.michaelpstanich.com/?mode=game&view=ProjectIdleFoxRPG
GDrive : https://drive.google.com/drive/folders/1c6vho59sdO-1EhO9_GiBTXw-CFrA3JU7?usp=drive_link
Mega : https://mega.nz/folder/J5hWWbZC#SXujM5Z_kE2Jbj65Zy5Gbw

(Changelog will not be available for this version)
Basically I implemented various back-end systems which probably are not worth documenting in a front-end sense, and since the gameplay of the proto-type doesn't match what will be the 'actual' gameplay it felt a bit unnecessary. X.x

I felt I should introduce this game with a bit of an explainer, especially considering I've been already working on another project (Data:EnCryptic). There's a really common issue among creatives like myself where we tend to get really ambitious visions and projects tend to scope out of control rather easily. This is something I've been really working on over the last year and it was my goal for 2024 to release a game in some form or another. But there's a snag, I typically don't like releasing things that are unpolished or have issues, it's been a major struggle for me personally to release dev-builds for projects as frequently as I have, but honestly it's been a very positive experience overall I think and has been inspiring for many of our community members! So, I wanted a game project I could try this with while also having a bit of a simpler, non-scoped to hell and back, concept to help test-bed ideas and create assets that can then also be used in other projects.. hopefully. (if they don't suck too much X.x)

So ultimately, I decided a bit off-the cuff I was going to start a project and just release whatever I had after a week of development, see how much I could get done from scratch and for myself to break my habit of 'just one more thing!' That does mean this initial release is VERY underwhelming and I don't think it'll be of any interest to many, nor will the next few releases honestly, but there's the origins and why this is kind of out of no-where!

Idle Fox RPG (WIP placeholder name) is an incremental RPG inspired by character-focused RPGs with diverse ways to level up and acquire skills, along with inspiration from other incremental titles. (Although many equate idle and incremental as the same game genre, Idle Fox RPG will have a more active play style and be much quicker in progression when actively played, but offer some AFK style options in the form of the auto-choice tree mechanic!) In Idle Fox RPG you play as a demon-born fox lady who's been freed from the void by a mysterious fairy with an attitude. After freed, this confused fox lady is able to explore the world and make decisions as she sees fit, she can go out hunting materials for new fancy outfits and gear, fight off the local bandits to raise some reputation, take in quests from tavern go-ers for some coin to buy more pillows, or just sleep the rest of this realm's short existence in the comfort of her new den! The choice is hers yours! Every activity is a skill, every action working toward your strength, every item holds value, and every choice determines your path!

Since the current version in this posting is fairly simple and lacks any graphics, just a basic interface for testing values and systems, I thought it would be important to outline exactly what my goal here is. The goal is for Idle Fox RPG to be a fully 3D game with 3D character models and 3D environments, but with a bit of a confined scope. One of the main concepts behind Idle Fox RPG is cosmetics which will integrate with various systems and act as one of the driving factors for players (hopefully, anyways >.<). I'm most likely going to use a cell-shader and painterly textures as this is suppose to be a chance to build assets for Data:EnCryptic as well, locations will be small island like locations with simple randomized geometry with a few key locations having much more to it. The UI will most likely follow Data:EnCryptic's design language with simple but sharp UI elements (I know I haven't shown this off yet, it's not 'quite' ready), though I'll most likely aim for a brighter and lighter mood to the overall style. Animation wise I also want to try a more comical/whimsical approach than my previous works, so we'll see how that aspect goes!

Exactly how things will link together isn't quite figured out completely yet, but there are various systems which I'd like to test and have already begun building and implementing into the game. The general gameplay loop has the player looking at their various objectives, both in-game and personal progression goals, then using in-game information to decide where to go and with what gear. Gearing up and selecting a class for the switching system is integral to the gameplay loop where before heading out the player can define different sets of equipment and class combos which will determine what they will have available for that journey. Once prepared, the player will choose on a hex map what region(s) to explore with each hex having different rates for certain activities such as combat with enemies, finding resources for harvesting, or treasure finding! While exploring the player will manage their inventory and can determine what actions the fox lady takes, optionally there's also the auto-choice system which acts like a command list of actions the fox lady will perform on her own through an if-then branching system. Actions run on an act and wait system, think turn-based but real-time by default.

The progression loop is a bit less defined at the moment as I'm still investigating what the best methods for handling different mechanics would be with this kind of gameplay loop. Ideally the player will have various choices in how they want to approach their goals, every activity the fox lady can take part in will have a level associated that will attribute to her base stats and improve her abilities in all other tasks, and every item will have some sort of base-value that can convert down to universal currencies. Currently, the plan is to have the player build up their skills through activities, build up resources to craft their own gear with gear having durability and a life-span. Since gear breaks eventually, the idea is to have upgrades to crafting be a central component where you slowly build-up minimum crafted qualities that make gear acquisition for your favorite sets easier. As the player progresses they'll unlock new cosmetics like outfits, tail/ear customization, apply-able colors, animations, along with your typical new gameplay locations. (how these unlock systems work is yet to be determined)

If you have any thoughts, ideas, suggestions, or are just curious on further discussion, we have a dedicated channel in our Discord that's well worth checking out!

If you try the version from this post you'll notice it's pretty bare-bones as just a very basic and default Godot user interface and some buttons! That's obviously not how the actual game will look, so the next step is getting some 3D models, implementing the proper stylized shaders, and then starting to implement the actual mechanics! Part of building the prototype was getting a lot of the back-end stuff set-up as well as planning the methods to accomplish it. I didn't quite get 'everything' I wanted done before this week was over, but with the systems I've built already, adding new systems should be a lot easier since the base-line types are in-place and what's already built could be extended pretty dang far. Building 3D assets, however, can be VERY time consuming, especially with how slow I am working in blender at the moment, but that's the next major step! Hopefully the next version upload looks completely different and resembles an actual game!

1 - Implement environment models and build transition systems.
2 - Introduce proper player model with clothing system.
3 - Build shader/visual system for the intended cel-shaded style.
4 - ???

Worked on some requested additions/QOL/and fixes, also did a ton of testing and alterations for OStim specifically to help fix up some issues. This update comes with improvements to the multi-framework support, now allowing both SexLab and OStim to be used at the same time properly! (You can set what your preferred framework is in the Status MCM, while SexLab should select automatically if it's installed and is recommended you can toggle it to OStim and Succubus Heart will start OStim animations instead of SexLab ones). Still haven't finished the validator but more info will be in the SubscribeStar post if you're curious on more!

Download Links :
GDrive : https://drive.google.com/drive/folders/1yqt2P0fu2JRsjOIcuD7kAa03JuQ3rvZw?usp=drive_link
Mega : https://mega.nz/folder/xgBQDJRQ#4ucsQDMkY1thmkfM6sjy5g

The adventures of trying to ‘fix’ OStim Support

One of the major struggles with supporting multiple frameworks has really just been me not fully understanding how OStim works on an internal level. SexLab is well established with a long history and a foundation that’s built fairly linearly, and I’ve been around that entire time so I’ve been able to slowly adjust over time as I learn and expand my own capabilities. But OStim has a very… uh.. ‘mixed’ past, filled with confusing changes, foundational changes, and the new OStim Standalone we use now is made by a new team with fresh ideas on how things should be done. This has made understanding and debugging specific issues with OStim difficult to debug and get right, I’ve had people report now issues while others have consistent game crashes and weird issues. But this was to be expected, but it has caused some issues. SexLab has its own issues to fix and over time I’ve been able to identify where those holes are and account for them, the issue is OStim not only has many of those same holes and requires the same fixes, but also has additional holes that are remarkably inconsistent! While working on this latest update we were able to find a bug that was only crashing my game every 1 out of 10 animation starts, I applied a work around and now it’s gone but for another user they still crash nearly every time (and when they don’t their game soft-locks).

This update was originally planned to have a custom ‘validator’ which validates if characters are valid for animations and if the situation allows it, but this inconsistency is why I held off and worked on other fixes instead. For SexLab they have a validator already, so I had always just used that with a handful of additional checks when required, but OStim has no such validation and this is what’s leading to the crashes and inconsistency issues I just wrote about. This means building an efficient validator is taking a lot more brain power than initially expected, I figured doing a quick replication of what SexLab does but optimized for Succubus Heart would be more than enough, but it actually failed for OStim checks and was inadequate. After this recent update I’ve determined there’s still a lot wrong with OStim on a foundational level which breaks when conditions are not as the dev team expected, which causes some problems given Succubus Heart is not really conventional.

My solution is to create 2 individual validators, this means I’ll work on an optimized validator for SexLab, then basically add an additional validator for OStim which will hopefully apply work-arounds as we find them until they are either fixed in OStim or a better solution is found. The issue is some of these fixes may not be applied by the OStim devs given their stances on certain types of content. SexLab is very open and compatible with whatever people really want to do, which is nice and allows Succubus Heart a lot of freedom such as full Soul Pets support with creatures, allowing in-combat animations, forcing aggressive/passive roles, ect. OStim however, not only blocks many of these functions but may even be forcing out-right crashes. This showed up while we were debugging Combat Seduction, which allows triggering animations in combat. SexLab animations play and work as expected, even allowing combat to continue if so desired, OStim on the other hand applied a ton of scripts and checks to then stop animations, lock character movement, and even crash the game (though I don’t know if the crashing is intentional or not). To ‘fix’ it I applied some combat stop functions and wait timers, but it doesn’t seem to work in every instance or game. So in the end, this just means OStim will always be buggy under certain circumstances, and this ‘may’ be by design. Logically I ‘should’ disable features that would lead to these causes, but for now I’ll leave them enabled for people that can get it to work properly and we’ll hopefully have a solution at some point!

All-in-all I guess that’s just a long-winded way of saying, OStim support will probably continue to have issues far into the future and I don’t think many of these issues are actually caused by Succubus Heart, but instead OStim itself. Hopefully we get some fixes in the future! (Remember, if you have any issues with Succubus Heart, please let me know! It’s because of bug reports and user support we’re able to find these issues and hopefully fix them! With more data we may figure out a proper solution!)

(entry also available on my personal site : https://www.michaelpstanich.com//blogpost/2024-03-21_Project_Sugar_Cake_0.0.3_DEV_Released.html )
It’s been a good while since I’d made a string parser, but I’m glad I at least had some sort of previous experience! Would have certainly taken longer if I hadn’t (manually managing search depth is a pain >.<) even if it still took longer than expected. What am I referring too? Project Sugar Cake can now register animations through .json files! I’ve added a quick how-to to the ReadMe and placed templates in “~mods/AnimJSON” within the mod’s release package and install. Now SCake comes with the previously mentioned AnimJSON folder where these register .json files will be placed, any .json files you wish to have load in-game must be added to the new “_LoadList.json” file, then when SCake loads in-game it will use that load list to pull the appropriate .json files, parse the .json as a string and properly pass that string to the register to parse and convert into animation data. I won’t go over all the metadata stuff here (there’s a lot) but one of the templates explains each parameter and those templates show how to format things, so it shouldn’t be too difficult to get started! I recommend using a JSON editor with auto-correction and error checking, I used the online editor https://jsoneditoronline.org/ to help speed up the process, and I recommend it! (Easy to understand interface and has both a raw text mode as well as a ‘tree’ mode with more intuitive visuals).

What’s really exciting about this is that .json import options are not just for animators, but users as well! Users can edit or create their own .json metadata files to customize existing animations, create alternate versions, and make their own full events using any combination of animations they like! In the future I’d like to have a UI for this, but that’s still quite far off, but the .json importer does have support within the API so once a UI is up we can implement a ‘refresh .json import’ option or something so you can edit .json files and have them re-import without having to reload your game!

I also updated the Scake_BasicsAnimPak to be compatible with the new version and now supports .json import options. SCake SDK got updated to the new version with the new API call for .json imports.

Download Links!
GDrive Folder - https://drive.google.com/drive/folders/1vYfgMom7UJs2OmJ5B4FGQTMYEOR0n9Vr?usp=drive_link
Mega Folder - https://mega.nz/folder/9hZQ2IIR#Ou77tq4qQxw9UBQsozh6zg

- Project Sugar Cake -
- Full Change Log -
SCake Version 0.0.3 DEV
Note : Data structure had changes this update, BP mods will need to be recompiled with the newest SDK release

Added : JSON string and data parser for registering animations, now you can create JSON files and place them in the ~mods/AnimJSON then add the file name to the "_LoadList.json"
 - - - - - If any errors are in the JSON file's formating it will fail to load (BP limitation)
 - - - - - Animations no longer need to be LogicMods and can be installed like any replacer mod, though BP registeration is still available
 - - - - - Users can create their own JSON files or edit existing ones to create their own events or customize animations
 - - - - - Templates are now included with SCake's main installation
 - - - - - "_LoadList.json" is required, however it is split up in distribution to prevent overwritting player's customized json when updating the mod
Added : SCake_RegisterAllJSON to the API, call this to re-register all JSON animations listed in the _LoadList
Added : "Speed Default" in registered animations now functional
Added : "StartTime" in registered animations now functional
Added : "Speed Mod" in Stages now functional
Added : Keybind K (Start animation between 2 targets) will now try to start a solo animation if the same character is selected twice
Added : "AddTags" in AnimEvent now functional (Appends additional tags to the event in addition to those added in the animations)
Added : Animation Register now sends a total successful registered count whenever there is a pause while registering

Changed : Simplified "Act Types" and introduced "Act Location" to make registering animations easier and allow easier future additions
Changed : "HasPostClimax" for registering events is now set to false by default
Changed : "EquipLocation" is now a 'name' variable type to support socket/bone names and not just presets (Equip system is still non-functional)
Changed : When characters path to animate, even a failed move (When 'Move Failed' would display) will still trigger the animation (characters will just teleport, helps the mod feel less inconsistent and buggy. This issue isn't really with the framework, it's just the quick and dirty AI which bugs out a lot.)

Removed : Anim and AnimEvent Registered messages from showing in ReportUI (Still shows failed registers with error codes)
Removed : Equip Location enum is removed and now invalid (we parse a name variable now instead to allow custom bone/slot names)

Fixed : Sexual Pleasure going into the negatives after an animation (accidentally shipped the wrong build which had this bug >.<)
Fixed : Register component not automatically starting after a game load if a register API function is never called
Fixed : "Stage Order" being ignored and erroring out if the animation playing didn't play through stages linearly
- - - - - Note : This Stage Order bug also broke things like play-time, animaiton playback, post-climax anims, all should hopefully be fixed now
Fixed : Stage Duration for non-looping animations setting to 0 seconds when the number of stages exceeded actor count (Was a very silly mistake X.x)
Fixed : AnimVersion number not working properly (Technically also fixed the internal version number not working correctly, but this means nothing front-end)

- SCake SDK -
- Full Change Log -
0.0.3
Updated for Data Structure changes in SCake 0.0.3
Removed "EquipLocation" Enum as it's no longer used by SCake
Added SCake_RegisterAllJSON function
Added missing register functions to the example mod
Updated ReadMe with variable types

- SCake_BasicAnimPak -
- Full Change Log -
BasicsAnimPack 0.0.3
Added : Now includes SCake_BasicAnimPak.json for installing with SCake's json importer
Changed : Recompiled for SCake 0.0.3 DEV
Changed : UniqueAnimID and name information
Changed : Updated Climax metadata

There’s some limitations to JSON handling in regards to mods, in a normal game project you would just create your own tools and custom nodes to handle this kind of thing or import a plugin but when working with Palworld modding I’ve decided to stick entirely to BP mods to ensure maximum compatibility and hopefully ensure better future support. This leads to some problems, because UE5’s file handling blueprints for files outside the typical asset register (which would require packaging then assets to pull from) is extremely limited, we have to use UE5’s native JSON importer. “So what’s the big deal, doesn’t UE5 have JSON parser nodes already?” Why yes, it does, except they don’t actually function properly! UE5’s native JSON support is abysmal, so instead I use it only to load the JSON and convert it into a string, then I built a fully custom string parser that searches through the string and pulls the data into a data map, which we can then search and use. I take advantage of search depth (tracking start and end points of datasets to separate them) and any with a depth above 0 would be parsed as a JSON string, then I parse those strings whenever the data needs to be pulled and put it into its own datamap. As this process goes on, I store the data pass it into the Animation Register. Well, technically I pull the full JSON string and pass that to the register, then the register calls the parser functions, but you get the idea! (probably?)

Either way, I’m super happy with this method as it’s very flexible and surprisingly fast, and it’s not even had an optimization pass yet! (I need to re-sort fail states so things fail faster if they are going to at all, add null checks to skip logic, and use more skips in places so repetition isn’t required and we don’t process unneeded variables.) Because we parse things into a data map, we can even ignore arbitrary data left in the .json so people can leave comments in there if it helps, similar to how I have the description template set up, though I recommend keeping them to a minimum or remove them before distribution to reduce memory overhead. I also have it planned to process them in batches, currently it just tries to load them all at once which isn’t that great memory wise, but given we’re still lacking animations that can come in a later update!

But there are limitations.

Most of UE5’s file tools for blueprints is actually a plugin, and palworld doesn’t include it! This means we’re very limited on what we can do via blueprints (and I am still not confident C++ mod support will uphold compatibility, especially since SCake needs to have the SDK easily accessible/usable). This has 2 major effects, first we can’t dynamically pull arbitrary assets that are not within pak files and part of the regular asset registry so we have to put the .json into the provided _LoadList.json file so we know which files to pull. We can define a custom path to load from, but we can’t efficiently search a directory without either C++ or plugins (we can technically do it through manual crawling, but by doing so many search calls we could trigger anti-virus safety protocols, it’s also extremely slow). The second issue is when getting the strings themselves. When loading assets it needs to be a defined type, in C++ we just define the type but this isn’t exposed to blueprints without the optional plugin which we can’t use, so this is why I use the JSON function within UE5 to pull the asset itself. This means we have to follow UE5’s JSON import rules, which are very strict and it means JSON files can’t have any formatting errors at all or else it will fail to import. If I could pull the asset directly I could just pull it as a string and try to auto-correct small errors (I already do this to a certain extent with how my parser is built) but I don’t currently know a method within my current scope and limitations. Hopefully we can get around these 2 hurdles at some point, maybe I’ll cave and finally do some C++ stuff while keeping this fallback in-case things break in the future, but for now I think these 2 issues are ones we can live with and things are more than usable! (I just like to make things the best they can be >.< Why do I have to care so much Q.Q)

I’m still following the same plan, but will most likely work on the next few steps in a more free-flow fashion. I want to start implementing very basic versions of various functions to try and get more of the framework filled out and create the baseline, as shown here with how much sooner this update released compared to the last version change, once the base structure is built and complete it becomes much easier to put out new additions and modifications. While making the parser and researching how UE5 handles files via blueprints I found some major leads toward what I could do about persistence and this could pave the way for the rest of the framework to truly be out of Alpha! Though, I shouldn’t understate how much work is really still left to do, I have a feeling a lot of the other parts of the framework will still need to be entirely custom and there’s still planned features for the animation player that isn’t complete yet, there’s also gender swapping systems that could help (it was believed the OK Framework was going to be the solution, but it requires more manual work and isn’t all that flexible so a new solution may still be required. Having it built into the framework also isn’t a bad idea.)

Oh, I got completely side tracked, the actual next step, like, right after I make this release, is to work on tutorials for importing animations into Palworld and how to integrate them with SCake! There’s still not really any good resources for this, so it look like it’s my time to step up and take the torch. Let’s burn some stuffs!~ ^-^ (Fire is pretty.. what were we talking about again?)

Current Road Map
1 ) Create basic tutorials for importing animations and registering them with SCake
2 ) Investigate / implement equipment altering system (for unequipping weapons/armor)
3 ) Implement a basic UI with settings control (including position adjustments for anims)
4 ) Investigate persistence more and try to get stat persistence between save/loads
5 ) Investigate multiplayer compatibility

? ) Work on building new animations

Finally got things done and stable? I think? Multi-character animations are now fully functional! Did a ton for this update, including the API system, new backend structures to make future additions much easier, the framework for a cache system to speed things up once we have thousands of animations, new validation systems for animation gathering/searches/playback, new complex climax animation handling, maybe more things? (Changelog a bit below ^-^)

Changed the default hotkeys for the temporary gameplay module integrated into SCake as well for triggering anims and such.

Input Definitions
- L : Start solo player anim event
- O : Stop any anim event involving player
- U : Show player sexual pleasure in reportUI
- K : Start anim event between player and target
- J : Select 2 targets and start an anim event between them
- I : Stop any anim event involving the target
In the future, once we have a UI and persistence these will be configurable. ^-^ (hopefully these work for now >.<)

Download Links!
GDrive Folder - https://drive.google.com/drive/folders/1vYfgMom7UJs2OmJ5B4FGQTMYEOR0n9Vr?usp=drive_link
Mega Folder - https://mega.nz/folder/9hZQ2IIR#Ou77tq4qQxw9UBQsozh6zg

- Full Change Log -
~ SCake Version 0.0.2 DEV ~
Note : Essentially Rebuilt the entire animation player and added the API systems, not everything is accessible yet but adding things in the future will be much easier once we know what to add

 Added : Animator now supports multiple characters at once (can play Human X Human, Pal X Human, Pal X Pal, whatever!)
Added : AI Handler to animator to help prevent AI breaking animations / conflicting (still has minor issues)
Added : Position handling to animator, should keep animation in the same place even if characters are pushed or pulled
Added : New validator should auto-sort and organize animating characters
Added : Additional validation for incompatible animations, should prevent any non-compatible animation (that have proper metadata) from playing
Added : More advanced climax handler, now supports specific slots orgasming to trigger specified animations within a registered animation event
Added : Pleasure gain for all characters in animations (was just the host player previously)
Added : Support for Post Climax animation playback after climax animations, skips and just ends if no post anim is found
Added : Support for 'included tags' and optionally requiring those tags when starting animations
Added : Basic stat tracking for characters where it's neccesary (no persistence between save loads yet >.<)
Added : Optimization systems to stat tracking so we only track what's needed (Basic so far, needs more advanced systems in the future)
Added : API Base for other mods to call and use SCake functions (such as starting/stopping animations, needs to be expanded on)
Added : API Call "SCake_StartAnimEvent_Basic" - Starts an animation between the supplied characters with minimal information
Added : API Call "SCake_StartAnimEvent_Advanced" - Starts an animations between the supplied characters with more advanced information
Added : API Call "SCake_StopAnim_PalTarget" - Stops any animation event the target character is involved in
Added : API Call "SCake_SendReportMessage" - Sends a report message to SCake's report UI, visible to the player
Added : API Call "SCake_CheckStat_Pleasure" - Returns the current Sexual Pleasure of the sent character
Added : API Call "SCake_Stat_AddPleasure" - Adds the specified amount to the target's Sexual Pleasure
Added : "Start animation between player and target" with default key "K"
Added : "Start animation between 2 targets" with default key "J"
Added : "Stop animation target is involved in" with default key "I"
Added : Pals play their "Happy" emote/action when animation events end (more advanced emotion handling could be added in the future)

Changed : "Start solo player animation" default key changed to "L"
Changed : "Stop player involved animation" default key changed to "O"
Changed : "Report player's sexual pleasure" default key changed to "U"
Changed : SyncPosition animation setting now defaults to disabled
Changed : Animation player was re-built and has much more advanced functions now with better duration tracking
Changed : Orgasms now add additional animation time so they don't conflict with normal stage progression
Changed : Reduced how quickly Sexual Pleasure decays when outside an animation event

Removed : A lot of debug notifications should no longer show up in the release build (sorry if I missed any >.<)

Fixed : Fixed animations only ever registering as "female solo human" animations
Fixed : Animation player getting stuck and freezing indefinately if cancelled improperly
Fixed : "Pals in Animation" tracker getting stuck if animation event was cancelled improperly
Fixed : Animating characters getting pushed/pulled or continueing movement if already in motion when animation starts
Fixed : Typos/misspellings in data structure

With this update came the SCake SDK! This SDK makes it very easy for other modders to access SCake’s API to trigger animations, stop them, or pull/modify data related to SCake! The API is a bit more limited for now, but the main functions (starting/stopping animations) is there, so if you’re a modder that’s interested it may be worth looking into.

To use the SDK, you’ll still need to set-up a modding environment for Palworld with UE5, but once that’s out of the way you just download the newest SCake SDK version, then extract the “mod” folder into your environment’s “Content” folder. Inside is a small example mod along with the “ProjectSugarCake” folder, which you do NOT want to include with your mod when you export your mod. The SDK functions by creating “dummy” assets where you can call within your blueprints/c++ mods, then when you run your mod in a game with SCake installed it will access the SCake API and run the required logic. It’s a fairly simple processes once you’re familiar with UE5, but if you ever need help don’t be afraid to reach out or post for help over in our discord! ^-^

Here’s some examples of how to use the API (check the SDK Readme or the SDK itself for more API calls and specifics)

I’ve been modifying my road map a bit, so things are in a bit of a different spot than before, primarily I want to try focusing on getting more animations onto the framework and getting the mod noticed a bit more. I need to contact a mod on Nexus Mods and see if the mod would be allowed over there (there’s some restrictions on Palworld mods and I’m not sure if Sugar Cake runs afoul to these) and will start making proper download pages on places like LoversLab since the mod is now properly usable, with one exception… That exception being animations. Currently we’ve still not had any animators output any animations for the framework, but in order for things to really get going we are going to need those, so we’re a bit stuck. It’s a 2 way issue, you need the framework for proper animations, but you need animations for the framework to be meaningful. So, I’ve shifted focus slightly to try and account for this and will most likely be making a few of my own animations (though I am very slow at it Q.Q).
 
Current road map
1 ) Create string parser for registering animations without BP modding
2 ) Investigate / implement equipment altering system (for unequiping weapons/armor)
3 ) Implement a basic UI with settings control (including position adjustments for anims)
4 ) Investigate persistence more and try to get stat persistence between save/loads
5 ) Investigate multiplayer compatibility

? ) Work on building new animations and tutorials for it

Not sure exactly what I’ll focus on after that, but we’ll see how things go over the next couple weeks and see what people request the most! If you have suggestions, please send them my way!