Please confirm you are at least 18 years old of age. Otherwise leave the website.
Sign up
Log in
18+
michaelpstanich
I work in various mediums and will be releasing content ranging from safe for work to R18+ content including Art, Video Game Mods, Video Games and Dev builds, Technical Articles, Game/Tech related videos, AI Work, and whatever else I fancy and Subscribers request!
EDIT : Uploaded a v2 versions which just allows you to set 'Max Wompage Count' to 0 which disables random Wompage. Someone on LoversLab mentioned they couldn't do a boss fight properly because there was too much Wompage! This allows you to disable Wompy Womp before entering such a serious situation!
People have been asking for a gamplay mod for SCake constantly, and, well, here's one that's reasonably usable! Is it great? No. Does it exist? YES! Wompy Womp - Random Sexy Edition is a quick mod I put together more-or-less to prove a point and show you can make a usable gameplay module for SCake in a very short period of time, and here's the result! Wompy Womp - Random Sexy Edition is a mod for Project Sugar Cake which periodically scans for characters and starts random erotic animation events with other characters nearby, making them Womp! The player is only considered for random events if they are above 200% Sex Heat, but if the player is in a solo animation then WompyWomp will scan for another character to add into the Wompage! There's a handful of other things, like there's a menu for customizing how often WompyWomp tries to start an event, how many events can run simultaneously, and how many attempts WompyWomp will make before waiting again. Matching is also done on a distance basis, first checking the closest character when matching so if you're doing a solo womp-session, make sure to be close to your favorite womper!~ =^.-=
Wompy Womp is an example mod and has Source available! You can either get it on Discord (for free) or in the restricted post on SubscribeStar for Subscribers! (I have an upcoming blog post covering why it's restricted within the next week)
This mod is the result of a conversation in our Discord, The Broken Chatbox! A shout-out to Shenova for suggesting this when I had nothing better to do (apparently), also a thank you for testing it! If you'd like to join in discussions like this, see live dev updates, or just hang out, please don't forget to join The Broken Chatbox!~ (https://discord.gg/h3vB7S4FEw)
Periodic (defaults to every 15 seconds) random scanning for matching random characters for animations, randomly chooses between 3 distance fields (Near/Mid/Far) and selects a random target in that distance to match with other characters nearby, matches are only considered valid if they are within a certain distance of each-other
Added a feature which adds the Player to the random scan if they are at 200% Sex Heat or higher (also adds summoned pal if they are at 200% sex heat, but I think they were already added in near scans anyways)
Added if the Player is in a solo animation then when a scan is performed it will try and match the player with another character nearby without doing any normal scans
Added all scans are done by distance first, so closest character is checked first then gets progressively farther as attempts fail or are considered invalid
A max animation handled count meaning only a certain number of random animations will be triggered at once (defaults to 1), more random animations won't trigger until these events have ended, player solo animation check is excluded from this value and will check regardless of how many animations are going
Added a simple menu to customize the frequency of random checks, the max number of random events going at once, and how many scan attempts are allowed per-check all with descriptions, does not persist between sessions and must be editted when loading into the game if desired
What's Next?
So this is a bit of an odd one, because this isn't really a long-term project or anything. Instead, Wompy Womp was just an off-the-cuff project that only took a few hours to put together and acts as an example of a simple gameplay mod for SCake. We've been struggling to get more people on the coding side of Palworld modding so the goal here is to show how quickly and easily you can get something up and running. It only took 15 minutes to post the first iteration, then I logged 4.5 hours on this project before having what we got here (sans some spelling corrections I just did last minute... I wish I could spell properly Q.Q). I'm also providing the source so other modders interested in making modules for SCake can see a simple example and use it as a reference or jumping off point for their own ideas. There are some complications with sharing source files with Unreal Engine I'll be covering in a future post so I won't go over it here, but I do need to be careful with where and how I share these source files so they won't be posted publicly and instead be restricted to Discord and a restricted SubscribeStar post for now until some concerns are addressed. (I am NOT trying to paywall the source, because of how unreal assets work it's just not safe to share the source as openly as other types of code projects unfortunately, however I will be using this method to distribute the code for all the modules I make and eventually SCake/Altermatic/UniPalUI as well)
Currently there are no plans to expand Wompy Womp - Random Sexy Edition, instead these features are going to be expanded upon and included inside the 'Palicious' gameplay module I've been working on.
Project Sugar Cake v0.5 DEV Available! [Palworld Mod]
(New Custom Objects!)
Hmm.. where do I even begin with this update.. It's been much longer than intended since the last update for Project Sugar Cake (sorry! >.<). From accidentally not releasing 4.3, to finding all new issues which required massive reworks, to requests for the API that wouldn't work with the current system, this update has been a bit of a mess internally! But either way, it's here and it's a massive change! (At least on the backend, more about that later!) Honestly, at this point, I can't even REMEMBER what the goals of 0.5 where, but I sure hope I hit those goals! This update featured some massive changes for the backend as well as integrates UniPalUI! (Note : UniPalUI is now a requirement for full functionality!) The first major change comes in the form of custom data objects, previously SCake used a lot of structs but we found that could cause issues with future compatibility when integrating with mods so I decided to move a ton of things to custom objects so they can be more easily accessible and simplify/speed-up some internal systems while also exposing those objects and their variables to the SDK, allowing more complex modules! I'll be expanding on this in the future, but other changes include the transition to UniPalUI for the UI and input, new debug controls that allow more than just 2 actors, a FreeCam mode while in animations (heavily requested!), and a TON of bug-fixes! There's also new detection methods for persistence which should help make it more reliable/performant!
This version comes with the all new detection methods for faster, more performant, and hopefully more reliable detections for tracking and stats! If you notice new issues with these detection methods, please let me know ASAP!
This version switched to UniPalUI for both input and UI handling, UniPalUI is now a hard requirement for SCake to have full functionality!
Do-to saving changes and fixes to the persistence, "SaveSystem" and "SavePal" files from older SCake versions have been invalidated and will reset when loading with the new version. If you wish to keep your old save data despite the changes you can change the save file's "SCake_ModVersion" to "5000" in the associated SCake_SavePal_WorldID.json file, however a lot of data may not load.
This version adds functional Altermatic integrations, requires Altermatic 0.4.0 DEV or newer to take advantage of them! If an older or no version is present then the integrations won't function. (Altermatic is not a requirement, just listens to calls made by SCake for certain functionality)
Adjustment profiles have been reset since the way they are tracked and saved has changed
Added :
__Create_Load_List__.bat will now try to scan .json files for UniqueAnimID and UniqueEventID to try and predict if the json config actually contains animation data (the ID is required for anims/events to register, so if they are excluded then it most likely isn't an anim config JSON)
Started transitioning to the new Unified UI system (May release as its own framework in the future)
Improved and re-enabled Async systems on the Register, this will drastically reduce the freeze-up on initial load but anims will take a short bit to register after the game starts up (Lock-ups can still happen depending on what anim packs you have installed and your hardware, packs with excessively large AnimJSON files will cause a lockup when loading in since the parsing of their data couldn't be fully asynced this update, solution is to create an async parser or have creators split up their json files into small chunks)
"SCake_GetAnimObj" API Function, this returns the AnimObj which stores the data for an animation
"SCake_GetEventObj" API Function, this returns the EventObj which stores the data for an animation
Register now also sends the "Report" to UE4SS's console when "Set_ReportRegFails" is enabled (Still sends an in-game notification)
Added new FreeCam mode which triggers while controlling an animation, use WASD for forward/horizontal and QE for vertical, mouse controls camera direction (Disables while the adjustment menu is open, no gamepad controls for now)
Animation switching in Animation Control menu will now show the Animation Event details in the description box similar to the Animation Event List
Aroused Morphs now apply to all mesh components on an character (enables replacers that use alternate replacer methods or for add-on mesh objects to have functional Aroused morphs)
SCake will now have integrations with SCake and be able to call certain functions when required (Only available on Altermatic 0.4.0 DEV and newer!)
"SCake_ED_SexEquipChanged" Dispatcher, this is called whenever the SexEquip for a Pal Character with an associated PalComp changes (should also trigger when a new comp is first created, however using SCake_ED_TrackPalEnabled is better for that kind of use case)
Added new randomized gender/sex equipment spawning system, now when characters are first detected they will be assigned a random gender based on the user's preference settings (on a technical level, the sex equip is now stored in the PalComp which is used for tracking)
Added Player gender as its own separate setting so it is no longer tied to the no-longer existing hard gender swap system
Added an all new detection system which is replacing the old 'forced' detection system, this new method hooks into game functions and is much more reliable but still needs testing to find edge cases (the old methods still run as a fallback but at a drastically reduced rate)
"Natural Sex Heat Rate" added to the menu, this configures how quickly Sex Heat changes naturally over time before any multipliers or additions
Changed :
Most defaults were changed from their initial 'debug convenient' settings to more gameplay focused settings
- Max Event Duration (90sec > 300sec)
- Base Pleasure Gain Rate (120 > 80)
- Pleasure Loss On Orgasm (80% > 95%)
Drastically reduce default Sex Heat Gain over time (Multiplier * 1.4 per hour > 0.4 per hour) (This should reduce how often characters get aroused and allow more dynamic systems in the future, this should cause heat to 'fill' after a couple in-game days)
Characters should no longer gain Sexual Pleasure or Sex Heat while orgasming (should freeze at the reduce value)
"SendReportMessage" aka Notifications now show through the Unified UI system (UniPalUI)
Most input is now handled by UniPalUI
Animations and Events are now stored as custom Objects (SCake_AnimObj and SCake_EventObj), this allows more flexibility, is more stable to expose to the SDK, easier to use for modules, and should be faster in more complex scenarios
Extended fail conditions for the Register to now fail when non-critical stuff is also invalid such as climax definitions (should help to ensure better compatibility, reduce confusion, and help modders debug their JSON files)
Changed some menu wording/titles
Completely transitioned to UniPalUI for all settings and configuration
Completely transitioned to UniPalUI for all input registers/handling
Changed all controls invalidating all previous keybinds
- Debug targetting changed, now you use the debug keys to select targets and hold a key to start an animation with all targets (This allows animations with more than 2 actors at a time to be triggered in debug animations, previous trace limitations still apply)
- Shift+K : Open Animation Control for Target (Hold for summon)
- J : Touch Self / J with Debug : Target Self for Animation (Hold to touch self)
- G with Debug : Target For Animation (Hold for summon)
- H with Debug : Clear Animation Targets (Hold to start animation)
- R in Anim : Open Adjust Menu
- Shift+[ with Debug : Increase Sex Heat of Targets (by 10)
- Shift+] with Debug : Decrease Sex Heat of Targets (by 10)
Extended distance all debug keys are able to function at
Sex Heat now caps at 1000
During Animation Control, pleasure bars now show at the bottom of the screen and have a different look to them
Increased the time orgasms add to animations without a climax animation to 8 seconds (was 5)
Slightly changed default gender assignments for NPCs (All NPCs should now assign as either Male or Female with Male being the 'default')
Re-organized the Preferences menu to show gender options first, separated Player Gender as its own option within this menu instead of a sub-menu, added appropriate menues for other additions
Preference Settings now contains the Player Gender on it rather than in a sub-menu (it's its own setting now)
Changed hard gender switch menus to "xxx Gender Spawn Rates" for the new dynamic gender spawning system, this menu allows you to set percentage chances for different gender spawns
Changed hard gender switch for human characters into a "base gender" menu where you define what in-game gender each NPC type should be recognized as by default (in-game NPCs have their gender set to 'None' however SCake no longer takes in none as a gender and instead defaults to Male, for female NPCs this setting should be changed to "Female" while the rest can be left as is)
SCake no longer uses "none" as a default gender type and instead assumes male for all undefined genders, none was removed from menu selections (Note : None is still used when defining requirements as a "no sex equip required" type setting, characters will just no longer have a 'none' option)
Requirements for pals to persist have been made more strict to prevent non-relevant pals/npcs from accidentally being tracked while also adding additional systems and checks to make catching when a pal should be persistent much more reliable
Adjustment profiles now account for all characters in the animation when determining a profile to use, this should prevent issues where animations are available for multiple sizes (this update resets old adjustment profiles with this change, uses scale factor which is mostly untested so hopefully it works but if not we'll have to try again with a different method)
Changed some key values in the SaveSystem JSON (since it was being reset this update anyways, figured I could simplify it a bit and remove unnecessary prefix')
Removed :
API Events "SCake_RegisterAnim" and "SCake_RegisterAnimEvent" have been removed to help streamline loading and removed some dependency on Structs (A future version of these functions will be made which allows you to directly create the necessary datamap which will work the same way JSON registration currently does, this allows more features to be utilized with BP anim registering and prevent breakage between versions)
API Function "SCake_AdjustAnimCamPos" has been removed along with the old camera system (Replaced by freecam)
Removed old menu and menu control (Menus are now handled by UniPalUI)
Removed "Game Settings" from SCake's menu since it had no options within (Will return if there's ever anything to add in there)
Removed cam position saving for animations and removed this param from the adjust profile (May be possible to add back in a new form but with the new free-cam the old system no longer functions)
"Use Global Cam Adjustment" has been removed (Made invalid by new FreeCam)
Hard gender switch settings and system completely removed (replaced by dynamic gender spawning system)
Fixed :
__Create_Load_List__.bat will now properly run in admin mode for all users regardless of your environment set up (while in windows at least)
__Create_Load_List__.bat now properly checks for the .json extension before adding to the list
Anim compatibility checker was sometimes checking SexEquips in reverse, making Futa/FullFuta/Andro types not always behave as expected
The __Create_Load_List__.bat file should now work in file paths with spaces in them
Debug Input for starting solo target anims should now report errors like other debug functions (should be easier to understand what's happening, the lack of a notification was just an oversight)
Registration no longer ends early when an AnimJSON used UniqueAnimID or UniqueEventID but included more than one register variable
Co-op skills should now be disabled during player involved animations
Andro should now proper register in compatibility for animations and not break the compat settings (was being skipped in the parser and messing up the compatibility map)
Optimized the JSON parser to save directly to the anim/event object which is a decent speedup
Minor optimization to JSON parser (new method is being investigated which could both save more memory and be much faster, however implementation is difficult)
Removed a lot of unused/unnecessary data which should improve memory usage (and potentially performance?)
Event Register should now properly compare compatibility across all animations and only register with compatible matches
Minor optimizations to save/load functions (switched some methods around for a theoretical 10-25% speed up with their use, but will most likely have no meaningful impact overall)
When calling "SCake_GetPalComp" with a valid pal but no associated PalComp exists, one will be created and properly initialized (This is how the internal function already worked but the API wasn't using it, now it is)
Fixed pals not always being set as persistent when loading from the persist file, causing their stats to reset randomly after a game load (the new load system uses a persist value within the tracker itself now instead of relying on live status read from the game, the original issue was caused when loading a persistent pal's data but it was invalid so it could not check if it should persist)
Fixed certain NPCs and Pals from events being accidentally marked as persistent (the game does not properly flag all NPCs/Pals which caused strange and hard to debug save bloat, stricter requirements and new manual persist methods work around this issue)
Added a delay to saving to help reduce potential stutter from saving at the same time as the game does (reduces processing on a single frame and splits it up a bit better)
New Custom Objects!
If you hadn't seen it, check out the previous update post for Altermatic which goes over a new custom save method which uses custom objects! That method isn't yet implemented into SCake (still need some internal changes before that is viable) but is something coming down the pipeline, but one thing I'd like to briefly touch on here is custom objects! Now it's fairly common in object oriented program to create your own custom objects, but a lot of people don't quite understand what that means, especially in regards to engines like Unreal Engine which have pretty much all the common objects built and ready to use by default. But further still, how does this related to modding? What's the benefit?
To quickly explain custom objects, in object oriented programming like C++ which Unreal Engine uses, you can define specific objects with different properties and you then can use copies or modified versions of these objects however you see fit through parent/child relationships. The specifics are complicated, but for those less technically incline just consider this like a custom basket you can make where you decide what goes inside, how you open/close it, where and how many handles there are, ect. Typically for mods you don't need these all that much since you're generally working on in-game objects, but if you want to implement your own systems it may become necessary depending how things are put together!
Originally SCake was designed to just use dynamic arrays and structs, structs allow you to have a set amount of 'data' in a specific structure which you can pass around like any other variable like a number but it has some major limitations. The first is that a structure has to be broken down and re-built when interacting with the contents, secondly you can't reference specific variables within it, and thrice they can be very tricky to work with and break between changes on them which would cause modules to need updates any time a struct changes. These things combined have honestly made me kind of hate working with Structs in Unreal Engine, especially since we're stuck to Blueprints where they can be even more trouble. The alternative was going through and making/using custom objects.
In contrast, objects are able to be referenced however you want, you can reference individual variables, and you can add/remove content without causing crashes from modules! Fixes all the problems, right? Well, mostly, because while custom objects do solve many problems they can also be tricky to work with in code. They must be created with a parent relationship, in this use case we parent directly to SCake's main actor which prevents the objects from being garbage collected. Objects also can't be passed as variables, instead you pass around references so this change required a complete sweep of the code to change how all these functions worked and how data is passed around. Other than that though? It's honestly been amazing and much easier to work with than structs! The major trade-offs we have to consider in the future however, is that Objects take slightly more memory and can only pass as reference so if we want to, say, clone data or use pointers instead of values we have to do all those calculations manually which could be a pain if ever required.
Generally though, I think this is a massively beneficial change and something I should have done from the start! Technically I was already using this method before with Actor Components, which are objects but with additional functionality like running OnTick and contain several other features a raw object type lacks. Stuff like the Animation Player runs inside it's own component called SCake_EventComp which each animation has its own instance to prevent accidental cross-talk, so it makes sense I'd also move things like Animation/Event data into custom objects as well!
What's Next?
Ok, we've been talking about multiplayer for quite a long while now, but I think it's actually going to happen. In the Discord we've been talking about it here and there and I plan to try and get a meet-up going in voice chat so we can get people together to test some various multiplayer stuffs! People seem really interested in getting it all going, so it's certainly the next major step! I'd also like to mess with getting audio (the next most requested feature) but right now there's some issues working with WWise that Palworld uses and isn't version safe so I may need to run with Unreal Engine's default systems and see how it goes. I haven't messed with audio for quite a few updates, not since I messed with subsystem injection, so that may be tricky. I also want to work on Palicious Lust, which is the Gameplay Module I said I'd work on and may release some early test version on Discord soon! (Also going to be trying to implement some animation related stuff, like getting mesh restrictions working and implementing the callbacks during animation systems implemented fully)
Current Road Map
1 ) Work on getting multiplayer working properly 2 ) Investigate audio integration 3 ) Work on Palicious Lust gameplay module 4 ) ???
Altermatic v0.4 DEV Available! [Palworld Mod] (Now With A 'Real' Save System!)
New detection methods are now live in Altermatic along with a new complex save system to help with performance and reliability! This update didn't really come with much front-end changes, but there's a good number of fixes and new backend stuff that is pretty transformative to how Altermatic works!
Worth keeping in mind, from this version forward UniPalUI will be required for the UI and input implementations, versions from this point on won't include the integrated version of UniPalUI to help with compatibility and reduce potential update confusion. This update comes with all new detection methods with the old method still available as a fallback that runs much less frequently. These new detection methods still need to be thoroughly tested to see what is/isn't caught, but overall the new methods should perform much faster and swap meshes 'generally' much faster with a few odd exceptions do-to pal initialization being inconsistent (for example, when taking a pal out of the Pal Box). The save system also got a complete overhaul with a much more complex system. This new save system performs much faster (a general theme of this update) and should be much more reliable but given the complexity is a lot greater it can also be much more error prone if done incorrectly, please report bugs if you find them! Thank you!
This version comes with the all new detection methods for faster, more performant, and hopefully more reliable detections for swaps! If you notice new issues with these detection methods, please let me know ASAP!
This version completely changed the internal structure (again) as well as the save system, all previous saves before this version will invalidate and swaps will re-roll as they re-appear
Added :
When SCake is also installed, Altermatic will attempt to re-roll characters if their Gender is switched through SCake's systems (functions through a dispatcher)
All new detection system which uses several in-game hooks to try and catch characters the frame they become visible, improving not only the visual experience but potentially performance as well (Still has the old method as a fallback but runs much less frequently which should result in a performance improvement)
All new save handler system has been added which should speed up save processing by using a custom object with less processing required while saving (stuff is saved into data-maps dynamically then converted into JSON when saving rather than working on validated/invalidated data when saving, should speed up the saving process drastically but is more error prone so requires much more testing/maintenance)
New menu using UniPalUI which shows the default keybind for re-rolling meshes and contains a new configuration menu
"InvalidID Attempts" config setting added, this changes how many times Altermatic will try and process an ID that's found but initially invalid
"Fallback Frequency" config setting added, determines how often Altermatic will use a fallback method for catching exceptions
"Reload Config JSON" setting to configuration menu which loads the current config JSON
Added config save JSON file called "_Altermatic_Config.json" which stores global Altermatic settings, this file should be created when editing the configuration settings and exiting the menu (If you edit this externally while the game is running you'll want to enter the menu and select the "Reload Config JSON" option to apply the changes, otherwise any changes you make won't take effect until you reload your save and if you change settings the config file may be overwritten)
Changed :
Changed the values for the Best Matching System so that PrefTrait matches now take precedent over no PrefTrait matches and also prevent 'IsRarePal' from being swapped with non-rare pal swaps (Behavior for "Rare" trait is unchanged)
ReqTrait match is now -25 degrade
PrefTrait match is now -5 degrade while a non-match remains +5 degrade
IsRarePal non-match is now -110 degrade
Rewrote the entire internal structure to use custom objects and expand the use of pointers rather than duplicating data, also required rewriting much of the swap logic as well (this includes a full re-write into the new save handler)
New save handler is much more aggressive in checking for characters that should persist (Player and Pals) however it is also much more strict in what it considers persistent (This should mean obvious pals that should persist like party summons should persist much more reliably but could also mean some edge cases may not meet the requirements of the new system, please let me know if you find things that should persist but do not!)
Removed :
No longer displays a message when SCake is detected (reduces notification spam, will move this info into the menu)
SkelMeshSwaps without a SkelMeshPath defined will now fail to validate (The null shortcut, "SkelMeshSwap":"", still functions but is highly discouraged as it causes many technical issues, especially with manual swaps)
Fixed :
Now properly sends notifications through UniPalUI instead of trying to run through SCake (Also fixed a potential crash when a JSON error was detected but SCake was not installed to send the error to the UI)
Integrations for SCake/UniPalUI now has proper guard-rails to prevent them running when they are not installed and causing errors/crashes (I think the only crash was the one mentioned just above, but now it should be much less likely to happen again)
Improved randomization for SkelMeshSwap by not relying on shuffle functions and allowing match pairings to search further
MatReplace should no longer accept null entries
Fixed certain NPCs and Pals from events being accidentally marked as persistent (the game does not properly flag all NPCs/Pals which caused strange and hard to debug save bloat, stricter requirements and new manual persist methods work around this issue)
Added a delay to saving to help reduce potential stutter from saving at the same time as the game does (reduces processing on a single frame and splits it up a bit better)
Building A 'Real' Save System
Strangely enough, this actually ties directly to my game development project Data:EnCryptic which recently I'd been working on revising the data structure for some new systems. One major component to an RPG (to which Data:EnCryptic is) relates to how the game stores and saves data. When creating a save system there's a few ways you can do it, but generally you have some sort of container which has the data that needs to be saved and is filled at some point then translate that container into a save format. In Data:EnCryptic's case, stuff has to save regularly and there's very little reliance on manual saving given the game has inspirations from idle games and potentially allows short play sessions.
What this ultimately lead to was investigating further ways to optimize the system to ensure it doesn't become a performance bottle neck, and that's mostly related to how we fill that container and translate to the save format. When modding we generally take the easiest route first, we need to just get something 'to work' and we often don't have to worry about any major issues arrived from doing things in a sub-optimal way. This means Altermatic (and SCake) ran its save system in very inefficient way. It's the first thing you would think of when building these systems, first you have the container, so when you save we just go pull all the data we need and put it into the container right? Then we just translate, so we just do it in 2 steps, easy-peazy! The problem? That's a LOT of work to do in a single process! When you're dealing with small amounts of data there isn't much of an issue, pulling a few swaps and storing it, then translating to a JSON string isn't too bad, but what about doing that while the game is already running logic and we start dealing with hundreds of swaps? It becomes a bottleneck quickly, especially on lower-end systems which is even more exaggerated by Palworld's already lacking optimizations!
So, what's the solution? Well, the solution in code and method is complicated, but in words it's quite simple. As the game plays and we start applying/storing swaps we then apply it to the save container we mentioned before, this fills the data so we don't need to pull the data when we want to save! Another addition is we can start translating any of that data which is immutable or won't change, and in Altermatic's case there's some optimizations I applied here. To get into specifics, Altermatic's save system now has a custom save object, this object stores various Data Maps for each different 'type' of data. When Altermatic applies a swap and notices it should persist between sessions it will then, at the time of the swap, process the swap and store it into these data maps. These Data Maps are actually already Strings as well since Altermatic has other storage systems for storing the actual data using pointers, though I won't get into the pointers system in this posting but know it basically speeds up the translation process to effectively nothing. This means when we save we actually just run a quick check to see if we've stored all the data we need using a quick id check, only processing what we'd missed, then we compile the data maps into a single JSON object and save to file! This DRASTICALLY improves the saving performance, and with the other optimizations I'm hoping this comes at zero cost in other areas (such as the pointers, which are also much faster than the duplicate data method I used previously).
Now, argue-ably this does have a minor trade-off of memory usage and some interface time when actually performing swaps which is why I had to also implement the pointers system. Previously data was stored multiple times depending on how often the data was used in swaps. Now, however, data is only stored once and everything else uses a pointer to the 'real' data. I won't cover the specifics given that's a whole'other topic to cover, but ultimately it means storing the data maps is fairly low on memory usage since the translated strings are just a list of pointers with splitters rather than full-form data! If you're curious, you can take a look at the save file to see what I mean! Each ID stores a pointer to a swap that then points to the appropriate data, though I do warn it's a bit difficult to read through without context. The real trade-off here however, is the loading and maintenance costs. Loading this pointer system requires some special logic which, while technically still faster than the old method isn't exactly 'optimal' given JSON still has to be parsed as a String, which is relatively slow (in Godot with Data:EnCryptic I use a binary file format by serializing the save data object which is much more efficient in all respects but also can't be externally edited without a specialized tool). For maintenance I'm referring to actually building and maintaining the system internally, a system like this can get very complex very quickly and given Altermatic now has several different detection methods and systems for applying swaps, I'd be lying if I said it didn't cause a few head scratches when something didn't quite work as expected. This means it'll take longer to debug any persistence issues, but overall the trade-off seems well worth it, and given Altermatic most likely won't see major additions in features for a while now it was a good time to do it... now I just have to also do this with SCake... Q.Q
What's Next?
Next I'd like to implement a menu for swapping skins on characters, preferably with some sort of selection state like maybe making the keybind Shift+O open a select menu for that specific character which shows different skins available to swap to. The only complicated part in that process would be creating a rendered texture to display in the menu, which is actually something I've never done in Unreal before! I am hopeful that research into that would pave the way toward reversing the in-game menu system and be able to reflect changes in the me paldex and various menus as well. After that I know some have wanted Altermatic to support player replacers in a much more dynamic way since there's not really a flexible framework that allows entire replacers and the like, so I'll most likely do some research in this regard while doing the menu stuff, if it's not too difficult I could implement it sooner rather than later but I have no idea what would actually be required here.
Current Road Map
1 ) Implement a menu for checking available swaps and swapping characters live using UniPalUI 2 ) Investigate menu replacement and player replacer method 3 ) ???
[New Mod!] UniPalUI v0.1 DEV Available! [Palworld Mod]
Finally, after a TON of work, UniPalUI is finally here and ready to release! As typical, this took a bit longer than expected but also turned out much more advanced than I had originally planned. UniPalUI went through 3 different re-writes just so I could make sure things were done right the first time, and I'm VERY happy I did! Into chatting about UniPalUI, the newest Palworld framework mod you all voted for! Unified Palworld User Interface for Mods, or UniPalUI for short, is a new framework mod for Palworld which adds a gameplay enabled menu for mods to add and interact with. UniPalUI also comes with an input handler, meaning mods can use UniPalUI to also handle keybindings and shortcuts for whatever they please without having to roll their own! The original goal of UniPalUI was to create a unified interface for my own mods since creating a unique menu for each one was a ton of work and didn't really seem feasible, however now UniPalUI is a universal framework ready to be used by any modder that takes interest! UniPalUI also doesn't stop mods from having their own implementations and is created with a large amount of flexibility so modders are free to use it as they see fit. Personally been using UniPalUI over the last month during test builds and it's freakin' awesome! (Though, I may have some bias... ^-^)
This is a revised changelog based on the the last few major revisions since Integrated versions, some details may be missing or vague and all previous changelogs were discarded (UniPalUI went through a near complete re-write, so old logs were irrelevant anyways)
Added :
Notification System, this displays messages in the top left for a few seconds then disappears on their own, useful for gameplay or debug functions to show information during gameplay
Mod Menu System and Register, press Shift+Y to open up a new menu on the left side of the screen and show the mouse cursor, can interact with the menu using the mouse, has a universal back/mod selection/exit button, gameplay continues while the menu is open and you can use the middle mouse button to rotate the camera (Some gameplay actions can change controls/menu focus which may lock UniPalUI's function, simply close the menu with Shift+Y to fix)
Added several menu box types for the menu
- "Text" BoxType, this generates a text box with interactions
- "Toggle" BoxType, this generates a toggle box with interactions
- "Select" BoxType, this generates a box with a left and right selection
- "Header" BoxType, this generates a text box without any border or interactions
- "Custom" BoxType, this generates an empty box for inserting your own widgets, has no interaction handling
Input Handler and Register, UniPalUI now has its own input handler which can register inputs and listen for them, delivering a callback when necessary, the Shift+Y menu inputs use this input handler
Callback Functions Interface used by mods to receive UniPalUI callbacks, this interface, called "UPI_InterfaceFunctions", is required to receive said callbacks properly
API System, created several functions for mods to use for interacting with or adding to UniPalUI, check the SDK for more details on each function
- "PalPlayer"/"PalPlayerController" Variable for convenience
- "HideUI" Variable which says whether UniPalUI is attempting to hide the base-game's UI (careful toggling this yourself)
- "UPI_RegisterMod" API Functions, registers a mod with UniPalUI
- "UPI_RegisterInput" API Function, registers an input with UniPalUI
- "UPI_SetInputActive" API Function, sets whether the stated input is actively listened for
- "UPI_EnterInputState" API Function, adds an input state to the top of the stack
- "UPI_ExitInputState" API Function, removes an input state regardless of position within the stack
- "UPI_SendNotif" API Function, sends a notification to the Notification System
- "UPI_OpenMenu" API Function, opens a new mod menu (or enters a new page)
- "UPI_CloseMenu" API Function, closes the active mod menu (or goes back a page)
- "UPI_AddMenuOption" API Function, adds a new menu box to the active menu
- "UPI_UpdateMenuOption" API Function, modifies a menu box with new information
- "UPI_UpdateDescBox" API Function, sets the text to show in the Description Box
- "UPI_ResetMenu" API Function, clears the menu and sends an open callback without closing the page/menu
- "UPI_ExitMenu" API Function, forces UniPalUI to close the menu
- "UPI_Callback_KeyPressed" Callback, called when a registered input is pressed
- "UPI_Callback_KeyHold" Callback, called when a registered input is held
- "UPI_Callback_KeyReleased" Callback, called when a registered input is released
- "UPI_Callback_MenuOpened" Callback, called when a menu is opened
- "UPI_Callback_UIHover" Callback, called when a menu box is hovered
- "UPI_Callback_UI" Callback, called when a menu box receives an interaction
- "UPI_Callback_MenuClosed" Callback, called when a menu is closed
- "UPI_SecureCode" Interface Function, called for securing mod details
- "UPI_MenuGenBox" object added to SDK, this is the reference object for a generated menu box and comes with a list of variables to access
Added credits section to the mod menu which is currently only accessible manually (will be exposed to the API when system is polished up, currently it requires manual sets which could cause issues if done improperly)
Removed :
Code for Integrated versions removed and cleaned up for public release, Altermatic users will want to update to 0>4 DEV or newer
The Origins of UniPalUI
There's a universal requirement for mods once they get to a certain complexity, the need for user interaction and configuration that is separated from the game it's for. Sure, you can get by with simple input commands, external file edits, or even hacking in-game menus but eventually it just makes more sense to use a mod menu system of some kind. However, Palworld didn't really have one that fit my own needs, so I looked into making my own solution. Project Sugar Cake actually had a sort of simple-but-hacky menu that sort of served this purpose well enough but the mods I was working on expanded outside of SCake's realm, and SCake's menu had become extremely annoying to update as it took a lot of manual work at each step. The solution? I unified ui for all my mods, but I decided to ask the community if they thought this should be another framework style mod and the results said yes!
The Visual Design
The visual design is somewhat basic just to get things rolling, but could see improvements over time if necessary. The general idea is to take inspiration from the in-game menus but create a distinct look to ensure mod elements separate themselves from the game itself. This isn't to everyone's liking of course so there could be different visual options in the future, but I do think this is a better choice. It also means we can keep the same visual design even if PocketPair changes their UI design or assets since all of UniPalUI is standalone.
The design centers around simple squares and sharp shapes to give an almost 'system console' feel while also having some elements from the game's menus with their stretched squares found throughout their elements. This caries through to the main color chosen which is the accent light blue PocketPair seemed to use in many of their menus which seems to make things fairly readable. If you've seen SCake's placeholder menu design, you'll probably notice the similarities, but the entire system is written completely differently and is much more expandable/flexible. (SCake's System Settings in UniPalUI) The design feels quite slick, but I do have some concerns about colors and readability so in the future I'd like to have some configuration options that allow you to change menu transparency and colors. There is a bug I ran into with UE5.1 however, where changing tint-color at run-time causes any image elements to 'block out' and change background/.border color as well and even if disabling tint afterwards there'll be a black square stuck behind the element. This kind of makes customization a bit more difficult, so I'll need to figure out some work-arounds for this if we want full customization of every element.
The Methodology
When designing UniPalUI I used my game development knowledge to build a menu system normally implemented into games but with a more mod-friendly approach and with as little manual work as possible. The method I went with is generally called a "call and callback" system where you call specific functions to start an ops and await a callback before taking another action. More specifically, with UniPalUI you register your mod to receive callbacks, then when receiving these callbacks the mod is able to run whatever logic it needs as well as registering for more callbacks. This type of design is used in all sorts of game systems but works especially well for menu and navigation systems since you can create open-ended systems with-out major limitations.
In terms of steps, the first thing a mod does is register with UniPalUI. To do this, we set up some form of object that can take Events and implement a Unreal Engine Interface (an interface is a set of functions/events which you can apply to any object and call regardless of the parent class). This interface (called UPI_FunctionsInterface) gives the object all the callback events UniPalUI will want to call, you can then easily apply these events to your chosen object's script and UniPalUI's callbacks will call them when appropriate. After you set up the interface you register the mod with UniPalUI with the object you chose and some basic mod details, you can also register to show up in the mod selection menu in the same function. After this you're set up for all callbacks! Now you can register for other callbacks, such as setting up callbacks for when certain inputs are pressed, or when the menu is open you call functions to generate buttons that ultimately just give a front-end to sending specific callbacks!
Strengths and Weaknesses
Alright, now let's talk about some Strengths and Weaknesses, starting with the latter since that's most likely the most important. First off, we're using UE Interfaces, this means to register a menu you do need to have a custom object of some form which can have Events/Functions. This isn't a huge requirement but does mean lua-only mods won't be able to have a menu without making a simple object in UE first since Interfaces need to be compiled with a blueprint object. After that however, you can use Lua exclusively and I'm looking into a method to skip this requirement by having a 'lua mods' object set up automatically but this requires a special register which is separate from the current register since they will all register on the same object (basically a standalone mod object that handles multiple lua mods automatically).
Second major drawback for newer modders will be complexity. UniPalUI was designed to be very flexible which comes with a trade-off, you're expected to handle all the logic yourself. Now for some, such as myself, this is actually a huge benefit since this flexibility allows modders to implement any type of system they want without having to 'work around' a limited and rigid system. For new modders however this part could prove challenging to some as it'll be much more in-depth than simply creating a JSON list. I have added some simple examples in the SDK however, and will most likely try and expand these examples or make new ones/tutorials if other modders take interest in UniPalUI, but for now I'll be playing it by ear, see how things go and see what really need articulating the most before spending time on my signature in-depth technical write-ups.
Strengths however, are a plenty. Currently there are limited button types pre-built with UniPalUI which does make things 'seem' somewhat limited on the surface, however these basic button types allow any type of functionality since we can add custom logic in any way we see fit. But even more useful is the ability to add custom widgets within the UI itself using the "Custom" BoxType which is an empty menu box where you can add your own widget. This does require you to set up your own handling (will probably improve in the future) but you could add any button type you want! I've also added some complex logic to these few basic types in SCake's menu for more advanced functionality already as well, such as creating percentage-based sliders using the "Select" BoxType (the one with left/right arrows), and I've also used logic to generate menus based on dynamic listings such as having an entry for every pal by pulling data from the monster params data table.
That's all possible because menus are not 'loaded' but rather 'generated' at run-time. Modders define what menus get created and what entries do, all UniPalUI 'does' is create the front-end and handle all the callback functionality while modders can handle all the response logic. This also makes UniPalUI a powerful tool that could even implement gameplay functionality, especially with input handling. SCake is the best example as of writing given it's had the most development, porting stuff was also a breeze once UniPalUI was ready for release as well! For instance, when SCake starts an animation it enters its own input state which handles the new free cam and has a menu button on R by default, this opens a standalone menu with adjustment and animation switch settings in an easy to use menu.
There's a few more strengths to using UniPalUI that still need more development but already have quite a benefit. This includes the Input Handler's conflict management which only allows a single mod to use a keybind, as well as support for modifier keys. This still needs development since the current version doesn't allow key rebinding (will get its own custom button type) however modders could handle this themselves if there's a need before re-binding is enabled. But that's probably as much as I'll write into this post, UniPalUI is a very interesting project for me personally as it's another dive into building frameworks and systems which are intended for others to use. I've got a lot to learn in the space still, but so far so good... right?
What's Next?
I'm not really sure where to go with UniPalUI since, currently, it works as I'd like it to. I'd like to finish implementing the Slider BoxType which didn't get finished before release so I could implement it and maybe some customization options so people can customize the menu a bit for readability, but outside of that I'm not really sure. As mentioned, UniPalUI was created primarily for my own use as a way to unify menu implementations across all my Palworld mods, like SCake and Altermatic. I may also expose my JSON save/load functions using UniPalUI in the future as well as that could prove useful for those looking to save settings in a way that can be externally edited, but that still requires a lot of manual work to use properly. Either way, I'm sure I'll think of stuff to add in over time, but unless other modders use UniPalUI I imagine it'll be updated much less frequently than other mods.
Current Road Map
1 ) Finish implementing slider box types 2 ) Implement some customization to help with readability 3 ) Whatever else comes next?
See something you like? Subscribe to see even more!
Subscribe Now
Creator Stats
122 subscribers
41 posts
Goals
$71 of $500
per month
(Monthly Goal) Would ensure part-time work on projects and ensure a constant flow of updates to content without worries of financial strain or burn-out.
$71 of $800
per month
(Monthly Goal) Would provide the potential to go full time, working on projects and producing content as seen fit by subscribers!
SubscribeStar and its trusted third parties collect browsing information as specified in the Privacy Policy and use cookies or similar technologies for analysis and technical purposes and, with your consent, for functionality, experience, and measurement as specified in the Cookies Policy.
Log in
