Starfield after v1.15.216 marks the game as a Creation save, if you hook and replace all the functions that force the game back into vanila.

[gir489]

Hi. I'm currently trying to figure out what was introduced in 1.15 that has caused this behavior. This seems to be prevalent in both SFAE and shad0wshayd3's version of the same thing just as a SFSE plugin. Basically, after the user saves, the game now thinks it's a creation save, but we've tricked it into saving a vanilla save. So now if you try to quick load, it'll try to find the quick save within the save set of saves that are marked as Creation saves. However, since it's not there, it will just do nothing.

I have spent over 10 hours already reversing the entire saving serialization and loading deserialization functions. Here's what I found so far.

Using RTTI, I have found that the game dispatches events via a dispatcher, and these events are usually dispatched from the Flash layer to the Creation Kit layer. When you press F9 to activate a quickload, there is some kind of input receiver layer within the Scaleform (flash) RTTI functions, that then binds a key to a text command. In this instance, it is Quickload.

Quickload fires a QuickSaveLoad event. This is caught by the QuickSaveLoadHandler interface, which is an extension of BSInputEventUser which are the types of events dispatched from Scaleform.

The function for the handler is locating at v1.15.216 offset 1E5D550 or here's an IDA signature of the head of the function 48 89 74 24 ? 57 48 83 EC ? 48 8B 3D ? ? ? ? 48 8B F2. Unfortunately, HexRays isn't able to decompile the function properly, but I've hand reverse engineered it, and here's what I found.

It loads and populates a pointer from structure Starfield.exe+5D4D660 which seems to be a pointer to all currently loaded saves.

Eventually it calls sub_1417DAA30 48 89 54 24 ? 48 89 4C 24 ? 53 56 57 41 54 41 55 41 56 41 57 48 81 EC ? ? ? ? 4C 8B F1 which seems to be a function for walking the save directory, and then eventually emplacing the current save profile's save names into the 5D4D660 structure. We'll come back to this function in moment.

After it is populated, it creates and fires a Quicksave event and then at line 141E5D757 it does mov [rcx+50h], eax which sets a flag to run the QuickLoad function. This flag is then read by function sub_1417DFAA0 48 89 5C 24 ? 55 56 57 41 54 41 55 41 56 41 57 48 81 EC ? ? ? ? 4C 8B 3D which then calls sub_1417E0250 48 83 EC ? 44 0F B6 C2 88 91 with a pointer to the save structure, and a short integer of the type of loading operation. This then dispatches a SaveLoadEvent which is caught eventually by sub_141E5DFB0 and then calls sub_14225E5C0 48 89 5C 24 ? 57 48 83 EC ? 80 79 ? ? 48 8B DA 48 8B F9 0F 84 This has a switch table of the parameter given to then do the given operation. According to my notes, I think case 0 is quickload although the function is called quite a bit for other things, so I couldn't be too sure.

Anyway, the problem seems to be within sub_1417DAA30. It's using FindNextFileW within the saves folder. It's iterating all possible 30 files. But after the FindClose function fires, it calls sub_1405D9270 48 89 5C 24 ? 57 48 83 EC ? 48 8B 59 ? 48 8B 79 ? 48 2B 79 ? 74 ? 48 83 C3 ? 0F 1F 40 ? 83 3B ? 74 ? 48 8D 4B ? E8 which for me, after I make a save, is only iterating 8 times. I have 7 creation files, so after that FindFile loop, it must be doing something to populate the save file structure with the save type it's looking for. I have no idea how or what it's doing to do that, as I've tried looking at what each branch does in the function, most of the code isn't called and skipped over. I was wondering if anyone with more experience on reversing Starfield has any insight into the problem.

[gir489]

I've figured out a solution. 74 ? 48 3B D8 0F 85 ? ? ? ? 41 B8 is the offending check.