[Starfield] Objects do not collide while havok settling is enabled

[Bobbyclue]

Late last year (September 29th, 2025 if the CK logs are accurate) the Starfield creation kit havok settle functionality stopped working correctly. While gravity is still simulated, objects will not collide with one another while physics are simulated, which makes it pretty much useless.

This appears to be the result of a license key for havok expiring. The CK log files indicate this with various notifications, including, "Assert ID: 0x234A9824 Message: in 'hkKeycodeManager::setKeycode', condition: 'false'." amongst others that will display when attempting to enable havok physics through the UI.

From what I can see the workaround seem to be pretty trivial. Address 0x147455b3d in the 1.15.222 Starfield CK seems to be the function call where the variable used to determine if a valid license is present is located. In my own testing forcing the input parameter, likely a bool, to true allowed havok settling to function again.

Not quite sure how the fix would be best organized here, so just opening this ticket for now rather than a pr. If more details are needed I'm happy to provide.

[Perchik71]

The main problem is that I deleted Starfield. I see you have some experience.... what stage you are editing at option? the .exe in hex editor or already in the debugger after launching the application?

[Bobbyclue]

I made a plugin for CKPE actually, based off of the test plugin. Had found the log error strings in ghidra and worked backwards from there, then set up what I found in the test plugin.

[Perchik71]

I like that... you are the first one who created the CKPE plugin, at least the one who told me about it.
You have every right to upload it to the nexus or anywhere else. I even wonder what will come of it. I'll add this, but later, while I'm plagued by Fallout 4 AE updates. Obviously I won't be returning to SF anytime soon.

I understand from the address that this bool variable is static and is located in the .rodata/.rdata section, possibly .data/.pdata.
CKPE makes all changes immediately after injection, which means that this memory does not change directly in the code (since this method works), which allows you to use a similar technique.
And the variable itself is the result of compilation.

You can also add the patch directly to the CKPE via pull request.

[Perchik71]

I also probably need to delete outdated plugin projects.
MyFirstPlugin need rewrite.

[robertgk2017]

@Bobbyclue Definitely feel free to merge that into CKPE directly, thats a really good fix.

[Bobbyclue]

I take a crack at it, but not positive on the full process. Not entirely sure how the .relb files are supposed to work, or at least how to take them and make the relevant .database and pak files out of them. My plugin just points directly at the address, so while it works it'll also need some cleanup to integrate properly.

[Perchik71]

I think this will be relevant only for 222, it makes no sense to use .relb, but you can:

for %%I in (base_f4_1_11_137\*.relb) do creationkit_f4_1_11_137 -PEUpdateDatabase "%%I"

where creationkit_f4_1_11_137 - .exe

Edit: This command is batch, one is enough to upgrade .relb always replaces the current patch data, the patch name must be unique.

[Perchik71]

fixed in new editor