more savegames

[Spocks-cuddly-tribble]

@ SCT the 138h seems to be the total size in bytes +4 of the wdf widget ID's data block. Shifting those bytes should work? What worries me is the unknown 914h 918h

I don't see 914h and 918h in the codes I looked at?

My above 0x120 and 0x138 are NO wdf IDs, but internal data block sizes/pointer!

This project is possible, but quite some work (which IMHO is not justified for this feature). So the approach by TC/Flocke sounds better.

595BD4 wdf_IDs__LoadSave_Screen


595BCC UI_LoadSave_Screen__3C8_bytes

+0-17h screen data ?
+18h start of 24 byte save slot data (12*24 bytes) -> one dword entry is wdf ID for slot
+138h start of 50 byte ingame save description strings (12*50 bytes)
+390h selected object ID (-1 none)?
+394h start of another 50 bytes active text string ?


sub_4F0250 loadsave_ESP -> esp locations (default size E60h)

[thunderchero]

and don't forget you will also need to increase memory pool for additional widgets (pool has a little wiggle room that is why your wdf displays now)

not sure if this is only one or not, release of pool looks to be at end of sub?

004F0B3B B8 C8 03 00 00          mov     eax, 3C8h       ; size
004F0B40 E8 AB 23 FA FF          call    System_Memory_AllocFromUIPool

also total number of widgets at

004F0BC5 BA 27 00 00 00                                  mov     edx, 39         ; numWidgets

opps missed sct edit lol

EDIT2: It's even worse. There is a fixed size data stack and all following locations might need relocation (138h+):

004F0B3B         mov     eax, 3C8h  // size

595BCC save_slots_data_3C8

I'm out...

[Tethys]

Location of interest: 51C5D0
12 cases checked via test eax,eax

584ABC
"Cant find file" warning

@SCT sorry, it was 394h and 390h (916 and 912 resp)

Code: Select all

004F0D32 01C BB 32 00 00 00          mov     ebx, 32h
004F0D37 01C 8D 87 94 03 00 00       lea     eax, [edi+394h] ; 916
004F0D3D 01C 31 D2                   xor     edx, edx        ; Logical Exclusive OR
004F0D3F 01C C7 87 90 03 00 00 FF FF+mov     dword ptr [edi+390h], 0FFFFFFFFh ; 912, -1
004F0D49 01C E8 05 CB 02 00          call    memset_addrEAX_bytesEBX_withEDX ; Call Procedure
004F0D4E 01C 8B 04 24                mov     eax, [esp+4+var_4]
004F0D51 01C 89 3D CC 5B 59 00       mov     ds:dword_595BCC, edi ; 0
004F0D57 01C E8 74 D8 04 00          call    WDFRead_UnloadWDF ; Call Procedure
004F0D5C 01C 83 C4 04                add     esp, 4          ; Add
004F0D5F 018 5D                      pop     ebp
004F0D60 014 5F                      pop     edi
004F0D61 010 5E                      pop     esi
004F0D62 00C 5A                      pop     edx
004F0D63 008 59                      pop     ecx
004F0D64 004 5B                      pop     ebx
004F0D65 000 C3                      retn                    ; Return Near from Procedure

It is my hope that eventually, wdf additions will be standard in UE. If saves can be externally contained without messing stuff up, I am for it

[thunderchero]

Code: Select all

004F0D32 01C BB 32 00 00 00          mov     ebx, 32h
004F0D37 01C 8D 87 94 03 00 00       lea     eax, [edi+394h] ; 916
004F0D3D 01C 31 D2                   xor     edx, edx        ; Logical Exclusive OR
004F0D3F 01C C7 87 90 03 00 00 FF FF+mov     dword ptr [edi+390h], 0FFFFFFFFh ; 912, -1
004F0D49 01C E8 05 CB 02 00          call    memset_addrEAX_bytesEBX_withEDX ; Call Procedure
004F0D4E 01C 8B 04 24                mov     eax, [esp+4+var_4]
004F0D51 01C 89 3D CC 5B 59 00       mov     ds:dword_595BCC, edi ; 0
004F0D57 01C E8 74 D8 04 00          call    WDFRead_UnloadWDF ; Call Procedure
004F0D5C 01C 83 C4 04                add     esp, 4          ; Add
004F0D5F 018 5D                      pop     ebp
004F0D60 014 5F                      pop     edi
004F0D61 010 5E                      pop     esi
004F0D62 00C 5A                      pop     edx
004F0D63 008 59                      pop     ecx
004F0D64 004 5B                      pop     ebx
004F0D65 000 C3                      retn                    ; Return Near from Procedure

those are memory release? and would need to be increased also I think (energy and build queue had same)

[Tethys]

those are memory release? and would need to be increased also I think (energy and build queue had same)

Something like this is what I feared. I'm guessing there is no way around it? Can a new set of instruction be created to handle additional wdf ID table? Knowing where to store and load in the memory release is tricky? If the alternate route is more feasible, and doesn't break compatibility.. we should just do that

BTW, I have easily in the past added additional picture placeholders to wdf files with working in game imagery.

[Spocks-cuddly-tribble]

595BCC UI_LoadSave_Screen__3C8_bytes

+0-17h screen data ?
+18h start of 24 byte save slot data (12*24 bytes) -> one dword entry is wdf ID for slot
+138h start of 50 byte ingame save description strings (12*50 bytes)
+390h selected object ID (-1 none)?
+394h start of another 50 bytes active text string ?[/nfo]

You have to change all relevant statements for (plus the wdf stuff):

0Ch (very few, I spotted only one yet)

For 595BCC

120h
138h
390h
394h

This is only a very small part of this project (for 394h I see only 6, plus the above, yet):

004F044B         lea     esi, [ecx+394h]

004F0481         add     ebx, 394h

004F0656         lea     esi, [ecx+394h]

004F0698         add     edx, 394h

004F0745         lea     eax, [ebp+394h]

004F088E         lea     edi, [edx+394h]

[Tethys]

yes but what is it (390h and 394h)? The whole wdf table size? If so, thats kind of a critical discovery since it means will need to be changed every time a wdf adds a widget ID. But this cannot be the case, TC has added widget ID's to some screens. Energy screen, build queue. I don't know if this value needed to be changed, maybe to avoid crashing, or if it is just irrelevant to this type of extension.

[Spocks-cuddly-tribble]

internal data block sizes/pointer!

(...) 595BCC UI_LoadSave_Screen__3C8_bytes

+0-17h screen data ?
+18h start of 24 byte save slot data (12*24 bytes) -> one dword entry is wdf ID for slot
+138h start of 50 byte ingame save description strings (12*50 bytes)
+390h selected object ID (-1 none)?
+394h start of another 50 bytes active text string ?[/nfo]

They have nothing to do with the wdf itself or the specified widget IDs, but just with the number of save slots to display.

390h = 18h+ [(24dec+50dec) * number of displayed slots]

So 595BCC itself + pointer for 390h and 394 have to be encreased by 0x4A (74dec) per new save slot

[Tethys]

I see 50 listed a few times as well. This is just in one subroutine as well. Dozens of these might exist.

Code: Select all

004F0CDD 01C BB 32 00 00 00          mov     ebx, 32h

004F0C5D 01C 8D B7 38 01 00 00       lea     esi, [edi+138h] ; end of ID table +4? (new 50 01?)
004F0D22 01C 83 C6 32                add     esi, 32h        ; Add

004F0D32 01C BB 32 00 00 00          mov     ebx, 32h

and don't forget you will also need to increase memory pool for additional widgets (pool has a little wiggle room that is why your wdf displays now)

So you're saying I should add another one ???

[thunderchero]

TC has added widget ID's to some screens. Energy screen, build queue. I don't know if this value needed to be changed, maybe to avoid crashing, or if it is just irrelevant to this type of extension.

yes, here is example of location energy screen gets edited; 78 02 00 00 -> 58 03 00 00

004F8AAB B8 78 02 00 00          mov     eax, 278h       ; size
004F8AB0 E8 3B A4 F9 FF          call    System_Memory_AllocFromUIPool

as I said before memory pool has a buffer, so yes adding a non functioning frame will still work due to buffer

[Tethys]

How much wiggle room are we talking? Because I am about to go test the 14th widget in game, report back with a follow up screenshot. Three locations in the wdf file need adjustment for the ID's to properly sort.

Prelim.png (368.03 KiB) Viewed 508 times

Widget inserted fine, there is even button interaction (click on the empty save and it will illuminate, a sound plays)

Prelim1.png (257.78 KiB) Viewed 505 times

The wdf itself has little to do with the code function, all that matters is the widget IDs and the container(s) that contains them. I can fill the screen with buttons and images if I wanted to because I know the locations in the wdf which dictate which id's are present and how many. In loadsave.wdf these locations exist at hex offsets: 0x029 (how many total widgets), 0x031 (how many buttons), and 0x061 (how many non-button type?)(all textbox + picture placeholder)

Followup Note: Interesting thing, the non-functional button sound is audibly lower than a functioning empty one. I clicked an empty game9 slot and it was audibly louder. Perhaps some calculation in the sound file to scale up the beep?

[thunderchero]

yeah adding widgets and displaying is easy compared to getting them functional.

just look at build queue topic I had all 8 queue displaying very quickly. btw what is your goal double save slots? if so why not just start with wdf having 12 extra?

and I see you are still editing galaxy mod good luck getting code changes out to replicate, if you don't have a back up right before you started and made no other changes.

[Tethys]

I just wanted to find all the necessary code first to insert one additional slot, then create a patch from those code locations for use to a broader audience.

good luck getting code changes out to replicate, if you don't have a back up right before you started and made no other changes.

You keep saying this, but I've yet to encounter any issues? I do have backups of before any major changes. Little changes I can revert, wdf's can be replaced and etc. I updated some graphics files, and fixed some of the crashing (which was due to damage values present on unarmed ships). I keep vanilla on hand for reference. GALM is still pretty vanilla in this area of the code. Finding any code changes shouldnt be much of an issue.

[thunderchero]

but if we don't know your changes it makes it tough to help right now

[Tethys]

but if we don't know your changes it makes it tough to help right now

The only change related to loadsave functions: Move wdf ID table to relocation table, nop old ID table, rerouted dword pointers to code in relocation table (was not necessary to jump back to any old code locations)

So most of the analysis is on SCT new IDA database (some done with QD database), I added some labeling for myself for keyword searching, and I was still looking over the code. I thought it would be a little easier than its turning out to be. And further discouraged by SCT's revelations several posts above.