About SKK

Since you have read this far, you may be interested in why/how SKK solutions for Creation Engine have a good reputation for conflict free quality.

I create solutions to address issues or add new capability that are specific to my needs, so don’t need to guess at what “good” looks like. If that works for you then happy days, but as my Bartle player psychology type is in the smallest sub 10% cohort, I do not expect broad adoption or massive download volumes.

(1) No base game hacks. SKK solutions abhore modifying base game platform content as I have zero tolerance for fixing conflicts in my own games, let alone creating more of them for others. Everything is new adds or bas egame wrappers. Exception: Fallout 4 Synthetic Player alt start game dialog.

(2) Full disclosure. Where base game content must be modified, every change is documented and disclosed so users can make informed decisions about quality and issues. Only 1 out of the 60 published mainstream solutions actually modifies base game content (Fallout 4 Synthetic Player alt start dialog.

(3) No external dependencies.

SKK solutions for Creation Engine (Fallout, Starfield) never use external DLL injections like Script Extenders:

(a) To ensure they are always Xbox and Gamepass compatible.

(b) To avoid publishing solutions that suddenly stop working when the game .exe is updated trashing a players savegame. If someone selects an SKK solution it will just keep working until they  break their own game.

The DLL injection based solutions published for Unity and Unreal have to be recompiled for most game EXE updates so users are not left in a broken state due to SKK content. With over 100 published Creation Engine solutions, that would not be sustainable.

(4) Cut content. SKK solutions create dynamic experiences with scripts working to a compute budget like the old mainframe days. Only functions that are worth the script processing time are kept, else they are cut. On average 50% of developed content is cut from a final SKK release to maintain your game performance.

On the Bethesda Creation Engine, Papyrus script processing resource is extremly limited and one bad recursive or blocking script can hoover most of it up. As an example Fallout 4 settlers auto equipping “best” armor from the local workshop is often requested. Whilst both weapons and armor auto upgrades were done and “working” several years ago, the armor element will never be released as the massive script processing overhead to iterate through worn/inventory lists for each actor blocks all other scripts in the workshop area. Publishing it would be like giving a zippo lighter with your name on it to an infant. You can learn more about these Creation Engine issues on the SKK Script Lag Detector page.

On the Unity platform scripts enjoy FixedUpdate (physics) and Update (frame) real time events. Hooking into these high freqency events to poll for conditions to trigger QOL functions through Harmony patches is high overhead non consentual intrusion.

(5) Testing. Testing. Testing. The games we try to enhance do not have comprehensive (sometimes any) platform API or SDK specifications, so we dont really know what we are doing to a game when they are hacked around or added to.

The only way to deliver a sensible level of quality is through comprehensive testing which is properly instrumented to expose issues. This is not just playing a game, it’s repeating fixed scenarios in the game whilst looking at a real time debug output log which is coughing up instrumentation data from custom debug scripts. When doing something that has never been done before (like making workshops  properly hostile) 50% the time is R&D writing and running tests to validate a concept and its impact on the game, maybe 25% of the time is actual solution development and the remaining 25% is game validation testing. In toto the dev:test ratio is 1:4 or higher across several hundred hours effort.