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!
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?
Palworld Modding Shift : How modding should proceed after IO Store split
(This is a PSA for Palworld Modding Communities which will be posted in a few other places. If you're here from one of said places, Hi! Careful checking out my posts, they may contain NSFW content! =^.-=)
Well this has been a mess...
Over the last 2 days we've had some really confusing changes for Palworld modding, the large Sakurajima update was super exciting but it also came with a surprise! With the update, PocketPair changed the packaging format to use a superior format with something called "IO Store", this newer format allows for fast loading and better streaming for many platforms and is a huge benefit in other categories. The issue? When the game is set to use a different packaging type, other packages become incompatible. This means mods in the older .pak format were no longer compatible with the set of IO Store .pak types, and vice-versa, meaning only one package type can be used at once. This 'broke' all previous mods Palworld had released for it, thankfully updating mods is really easy (it's a tick-box in UE5, then you just re-package and distribute the new pak format) but the community got impatient and vial toward the devs, so they reverted the change in format, but only on Steam.... (aka, Steam on old format, XBox/Gamepass on the new format)
Now, this has been a mess, and it's been really confusing with inconsistent messaging. So I want to make a post here with recommendations for modders on how to properly adapt then go over the situation and try my best to explain things in more detail (like why a switch to io store was even done in the first place, explain how reverting is going to cause us more issues as time goes on, and then explain how you can help improve things as either a modder or user).
--- --- ---
Users/Player - Here's some recommendations on how to proceed from this point forward
Rec. 1 : HAVE SOME PATIENCE. Like, holy damn, just wait for mods to be updated before storming PocketPair with pitchforks, alright? (Note, this isn't directed toward my usual NSFW audience, you guys have all been really awesome and patient. This is more targeted toward the casual crowd that lost their minds within minutes of the update)
Rec. 1.1 : Building off that last point, shifts in the modding space for games that are updated over time is extremely common and it's perfectly normal! PocketPair should be making changes that are the best for them and the game and we shouldn't impede their efforts. Modders will get around to updating everything and replacements for older mods will naturally take the place of those that don't. This is all expected, it'll take some time but moving forward is a positive change. (I understand the frustration when stuff stops working, but chill, things'll get fixed ^-^)
Rec. 2 : Take caution when updating from now on. Disable automatic updates for your platform and wait for experienced users to test the waters and see what does/doesn't work if your mod set-up is important to you. If you are an experienced user or modder, make sure to back-up previous versions just in-case something breaks and you need to revert for either play or testing. Even games out of early access can get a random update years down the line that breaks things (Looking at you Capcom, why did you do this to RE? What did we do to deserve such punishment? WAS IT THE BOOBIE MODS??? Q.Q)
Rec. 3 : State your platform when reporting issues and, if a mod doesn't support your platform, kindly ask the modder to release a compatible version. Since we now have to support 2 different formats this means there could be differences between the 2 we're not aware of. It's always best practice to note your platform when reporting issues, but this makes it even more important. Additionally, typically when modders don't release a compatible version for multi-platform it's normally caused by a lack of knowledge or time. So be understanding and link to resources like this one so they can get a track on what's going on and what to do to make a compatible version!
--- --- ---
Modders - Here's some recommendations on how to proceed from this point forward
To ensure the best experience for everyone, we as modders should try to support all of the latest versions of Palworld that we can. Previously that was easy since both PC versions were on the same format, even though they were technically different builds the functions and code between them were still compatible so even script mods had no issue. However, (at least at the time of writing) now we have 2 versions that require different steps to support, Steam's PC release, and then the XBox build that includes the PC Gamepass and MS Store releases. This means we need to supply 2 versions of our mods packaged for each platform from this point forward unless PocketPair decides to revert their revert and moves both platforms to IO Store (or they harm everyone by moving the xbox build back to the old format, I'll explain later why this would be a bad thing). This doesn't apply to Lua or C++ mods since they are loaded by UE4SS in an unpackaged state, but for BP mods and replacers, we'll need 2 versions.
So, here's my recommendations for Palworld modders moving forward. (Nearly all of these apply even if PocketPair moves to a single format, so consider these 'best practices' of a sort)
Rec. 1 : Backup versions before updating. This applies to both the game version and mod versions! Preferably you'd keep an archive of your mod releases so you can always revert or reference back if something goes wrong. In this specific case it was easy for us to just release the 'previous version' as the Steam compatible version if you had released an IO Store version. Should also be fairly well known that game updates can break mods, if you're not an experienced modder it may be best to wait for others to test the waters and for tools to be updated if required before updating.
Rec. 2 : Modders should move their entire workflow to involve the UE5 editor, preferably using the Palworld Modding Kit ( https://github.com/localcc/PalworldModdingKit ). You can find a guide to setting up the modding kit on the modding wiki ( https://pwmodding.wiki/docs/category/palworld-modding-kit ). It looks daunting at first, but don't worry, once things are set up it's rather simple. The reason for this is reliability and consistency. I've been telling modders in our community to set up and use UE5 for their mods since it allows a lot more advanced workflows and ensures their set-ups survive changes like this. (Also worth noting, UE5 is required for animation importing, which is a bit of a focus for our community...) If you're looking for another guide on this matter, you can check out my SCake animation importing guide (no NSFW images in the guide itself, don't worry - https://www.michaelpstanich.com/article/SCake_HowToMakeAnimsGuide ) For everyone that followed this advice the IO Store change was just a tickbox in the editor and a repackage, it took less than 10 minutes to push a new version out and was fairly painless, everyone should be shifting to workflows like this one to prevent breakage in the future.
Rec. 3 : Package a version for each format/platform which means 1 for Steam with the old format and 1 in the new IO Store format for XBox/Gamepass. If you set up UE5 and start using ChunkIDs to separate your mod packages properly then this should be relatively easily to do (just a pain on the release and docs front). As mentioned in the previous Rec. 2, UE5 has these tools built in and IO Store is just a checkbox within the packaging settings (Go to "Platform" in the top bar, then down to "Packaging Settings" as a quick access to packaging settings. The setting here is called "Use Io Store" which you'll package 1 time with and 1 time without). For my own workflow I separate things into incrementing ChunkIDs (ChunkID determines what pak-# the file goes into), then when you go to Platforms > Windows > Package you'll get an export with each package number, I copy that into a folder then toggle on Io Store and run the process again to copy into a different folder. (Annoying, but not difficult)
Rec. 4 : Include version compatibility in your ReadMe/Download Pages/Filenames. We can't really determine what will be compatible in the future, but for current versions try to ensure users know which version is for which platform. Personally I'm doing this at a file-name level where the archives for Steam will now prefix with (Steam) and XBox/Gamepass prefixes with (XBox-Gamepass), then all version compatible stuff (like, say, lua exclusive mods) will have no prefix. It'll take time to have everyone following these kinds of standards, but try to keep your community/followers posted on where compatibility is if its relevant to you.
Rec. 5 : Adopt open modding and collaboration! One of the major issues I noticed was a lack of communication in the modding community about what was happening and a lot of selfish hostility demanding things that didn't make a whole lot of sense, eventually leading to this worse-than-before situation. We as modders should be working together to get things working instead of pushing against one another and refusing any help, or refusing to help others. If we continue down this path and keep giving PocketPair these mixed signals then modding is going to be completely screwed. Ultimately, in this case, PocketPair listened to less-than-experience 'modders' that refused to adapt and listen to more experienced modders, and has made the modding scene much more complicated as a result. We need to start sharing standards and better knowledge with one another so that things like this are less likely to happen in the future and adaption is quicker. (Our community had already adopted this mentality and we were fully updated without any struggle, and again after the revert. These things matter and can make all of our lives much easier. If you're confused about a change, ask experienced modders about it and be patient, listen in and be ready to adapt. A great modder adapts, a bad modder gives up and refuses to change.)
--- --- ---
Explaining the situation
Ok, now lets actually explain the shift in package types and what's going on.
Why switch to Io Store? Simple, it improves loading and streaming assets on a wide range of platforms/hardware. While for a lot of modern systems you won't notice a difference (especially if you're not hitting memory limits or have a lot of io bottlenecks) this has massive benefits to console specifically, especially XBox Series S. So the reason PocketPair made this change was to make overall improvements to Palworld for all platforms which should reduce load times and improve performance across the board. Of course there's other things they could do to improve these things, but it's such a massive win on console that there's no reason not to do it.
Ok... so why on PC where it's not as effective? This most likely comes down to their development pipeline and because the XBox version IS the PC version. Well, for Gamepass/MS Store version at least. The XBox/Gamepass version of Palworld has always been a different build than the Steam version (at first it even had different features/content!). However, PocketPair has synced up their development and now they are most likely just different packaged versions/exports. PC DOES have benefits from IO Store, so it's not like it was a bad call, but in reality PocketPair most likely just synced up their 2 pipelines into a single process so both versions were effectively the same package but with different exports (for platform reasons). So since Io Store is a massive win for console, when they synced up the PC version just switched to the overall better IO Store package type for universal gains and easier development.
Makes sense. So why do we now have 2 versions? This is where stuff gets complicated, because it has to do with the "have patience" statements I made earlier. In short, changing the package method meant that all older mods needed to be updated, so when people launched the update for the first time none of their mods worked! This lead to casuals and incompetent 'modders' to immediately complain to PocketPair, blaming them for the mods breaking while demanding a revert. And PocketPair caved... probably the best argument for "don't listen to your community" I've seen in quite a long while. As mentioned previously, the IO Store format is a massive win for consoles so they most likely couldn't revert the change on XBox to hit their performance targets and obligations, which directly affects the Gamepass/MS Store versions. So yeah, only the Steam version was reverted, and the community forced this issue onto itself.
Yeah but, at least old mods work, right? Some do, some don't, really depends what's changed, and this only applies to the STEAM version, XBox/Gamepass is still screwed. The reality is that most mods need to be updated eventually anyways and there's shifts in the scene that would replace a lot of the earlier mods already, so reverting the change really doesn't do much for us in the long-term. This revert is short-sighted, both from the community and PocketPair. But still, it'll be nice to use the older mods that do still work. Keep in mind that only BP mods and replacers needed .pak files anyways, script mods through lua or C++ were never affected and instead all broke because of changes within the game (as they do over patches). The real concern here, however, is that PocketPair could bring back IO Store for Steam since it just makes sense to do so from a development perspective and for the long-term health of the game. When they do, not only will previous mods be broken, but also all those made after this revert, ultimately doing even MORE damage than if we just kept IO Store and modders adapted. In other words, we'll be right were we already were but even worse off.
--- --- ---
And that's what I want to help prevent! I'm making this PSA to let people know what's happening and help educate users/modders, while also advocating that we start making dual packages now to prevent future issues and help people adapt. There is a silver lining here in that we have the chance to 'get use to' these better practices and packaging for IO Store without mods being 'completely' unusable, but that does only benefit Steam users. So, let's say Steam does switch back to IO Store packages, then we can just transition to using the IO Store versions already packages for XBox/Gamepass! This will help minimize potential loss of mods in the future and ensure everyone gets to access mods to the same capacity, a win-win! Of course, if the community had already adopted better practices to begin with then none of this would have been an issue, but we can't change the past, only work toward a better, more sustainable future!
A reminder to everyone, if you ever need help you can always try our community, The Broken Chatbox ( https://discord.gg/h3vB7S4FEw ) to ask for help! Also, be very careful which guides you follow! There's a lot of bad info out there written by people who have no clue what they're doing/talking about (especially on YouTube, I cringe every time >.<). Hopefully as time progresses we get some better guides with best practices and proper information, and I hope to help on this front when I get the time.
Either way, thanks modding community for intentionally stepping on a rusty nail, now let's work on the anti-biotics!
See something you like? Subscribe to see even more!
Subscribe Now
Creator Stats
125 subscribers
42 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
