Build Queue project with 4 new slots

[thunderchero]

Hi Everyone,

here is the test files for those who would like to test this project.

MP_build_test.zip

(234.16 KiB) Downloaded 101 times

warning if you have already installed the first release "test version" you should uninstall test patch before installing MP patch version

files in zip file
"edited_wdf_1024_8_BQ" the files in this folder need to be added to stbof.res with UE if 1024 x 768 is installed
"edited_wdf_1366_8_BQ" the files in this folder need to be added to stbof.res with UE if 1366 x 768 is installed
"edited_wdf_1920_8_BQ" the files in this folder need to be added to stbof.res with UE if 1920 x 1080 is installed
"patches_with_energy_screen" use these patches if energy screen is installed
"patches_without_energy_screen" use these patches if energy screen is NOT installed

the wdf files are for vanilla type mods, some mods with edited GUI may have misplaced buttons or buttons may flicker
example UDM Dominion GUI would have these issues in build screen. But the game would still be playable.

install the relocation patch first
then install the Build_Queue_test patch
add wdf files with UE and save

then test.

enjoy

thunderchero



(original post start of development)
Hi Everyone,

this project is just in it starting stages.

I will be following QD's example from the energy screen project for most of my changes.

what I have done so far
I have created the WDF files *solars.wdf files with 4 extra image place holder.
moved and enlarged the widget table for *solars.wdf to the reloc area 0x0019f720 - 0x0019fb1f (1024 bytes)
linked the 4 calls to the new widet table.

next I will be looking at these sub sections first to see what needs to be edited. (Maybe to allow game to load)
I have already seen several locations to edit for total widgets and widgets for Build Queue

Code: Select all

004F8690 0xf7a90                         proc UI_SolarSys_DestroyScreen
004FDEB0 0xfd2b0                         proc UI_SolarSys_BuildQ_4FDEB0
004F9BF0 0xf8ff0                         proc UI_SolarSys_BuildBox_4F9BF0

my biggest fear is editing how Build Queue is saved in systinfo?

any contributions or help would be greatly appreciated.
thunderchero

[Spocks-cuddly-tribble]

First, the good news is the feature is not used for AI. But the OrdInfo could be a problem if involved.

SystInfo wiki:
Offset 0x00A8 to 0x00AB = address of GUI data for production Queue, length 0x6C

In IDA pro do text seach for "+0A8h]" and all occurrences related to systInfo are for build queue data

length for saved games:

00437F49 add eax, 6Ch

+18h for each new entry to add

code will check entry slots via add 18h (entry size) ; cmp 4 (number max enrties)

EDIT: Means it looks as if. Since it doesn't make much sense if only two values should be needed 1. building ID 2. number of buildings.

many quite hidden like:

AUTO:0044D387 add eax, 18h

AUTO:0044D38D mov [eax-18h], ebx


Some codes to start code analysis:

sub_43A240 productionQueue_
sub_44D080 check_building_IDs_in_productionQueue
sub_44D130
sub_44D300
...
sub_44D9B0 PRODUCTION_QUEUE_MAXSIZE_distinctTotal
sub_44DD30 prepare_new_player_system_productionQueue
...

[thunderchero]

First, the good news is the feature is not used for AI. But the OrdInfo could be a problem if involved.

SystInfo wiki:
Offset 0x00A8 to 0x00AB = address of GUI data for production Queue, length 0x6C

I had already looked at wiki
and yes it is good AI does not use Build Queue. (well I guess they use first slot....)

And thank for all the information I am sure it will be very helpful.

this project has already surprised me, I expected 4 maybe 6 calls to the widget table, but I found 112 calls to widget table. I guess this is due to all the sub screens that use the *solars.wdf.

thunderchero

[thunderchero]

SystInfo wiki:
Offset 0x00A8 to 0x00AB = address of GUI data for production Queue, length 0x6C

last night I started taking a closer look at the data stored on that area here is what I found

Note; all data collected was from a single saved game on turn 1 before turn process. when needed saved game was edited to remove/add structures so upgrades could be added to build queue. One test also required lowering morale to enable adding of morale structure.

00 - 03 bit mask of all slots? 03 all ships, 01 all structures, 05 trade goods, 07 morale, 02 upgrade
04 - 07 unknown always 00 00 00 00
08 - 09 build queue structure id
0a - 0b if upgrade, upgrade structure id
0c - 0d unknown, upgrade of databank 69 00, upgrade of subspace scanner DC 05
0e - 0f unknown always 00 00
10 - 11 build queue ship id
12 - 13 unknown upgrade of databank 13 00, upgrade of subspace scanner 1E 00
14 - 17 number of object in that build queue

00 - 17 repeats for build queue 2, 3, 4

60 - 63 build slots used (even trade goods count as 1)
64 - 67 unknown always 01 00 00 00
68 - 6b Buy slot? 00 00 00 00, but 01 00 00 00 if I buy item

I could test more combination for bit mask and I will if it become necessary.

[Spocks-cuddly-tribble]

1. AI doesn't have Build Queue data at all, the data is created only for player GUI. But the first slot of the player GUI is always a copy of the current system task data from systInfo and OrdInfo. That's confusing, but good for you i.e. you can ignore AI and ordInfo.

2. File structure with the three entries at the end sucks, you have to search for cmp 4 checks with all special cases and for all references to the end data as well.


sub_44DD30 prepare_new_player_system_productionQueue

Initial data setup:

length (+18h per new entry)
0044DD34 mov eax, 6Ch
0044DD39 mov ebx, 6Ch


For data at the end: (+18h per new entry)

0044DD4E mov dword ptr [ecx+60h], 0
0044DD55 mov dword ptr [ecx+64h], 1
0044DD5E mov dword ptr [ecx+68h], 0
0044DD65 lea edx, [ecx+60h]

Note 80h+ is negative for single byte pointer i.e. you need +3 bytes in code each (for all locations in trek.exe)


Here you could optimize code like:

Code: Select all

44DD4E
mov     eax, ecx
lea     edx, [ecx+90h] -> 90h = 0x60+0x18+0x18 for 4+2 = 6 entries  (+ 3 bytes)
xor     ecx, ecx
mov     dword ptr [edx], ecx
mov     dword ptr [edx+4], 1
mov     dword ptr [edx+8], ecx
nop untill
44DD6A                 pop     ebx

[thunderchero]

1. AI doesn't have Build Queue data at all, the data is created only for player GUI. But the first slot of the player GUI is always a copy of the current system task data from systInfo and OrdInfo. That's confusing, but good for you i.e. you can ignore AI and ordInfo.

I remember when I have switched race to an AI controlled race I have seen items in build queue?

Note 80h+ is negative for single byte pointer i.e. you need +3 bytes in code each (for all locations in trek.exe)

If sub is to big to move to make room the reloc section will come in handy, I will use a long jump to extended code and jump back
I was surprised when I used a long jump, new code will even display in original sub-section when viewing in ida.

[Spocks-cuddly-tribble]

I remember when I have switched race to an AI controlled race I have seen items in build queue?

Switch to player system will create this data i.e. copy the systInfo/OrdInfo data for GUI.

[thunderchero]

I have been editing a little first in the GUI area and got them all to display on all races (some what).
it is not running though all the text code for "empty" but the tool tips already work when you hover over image box "empty"

progress.jpg (215.66 KiB) Viewed 3922 times

I am still collecting code locations of interest before I make any major code edits.

[Spocks-cuddly-tribble]

As first step I'd extend file size only (not entries/end pointer) and look for issues resp. more instances of it in the code.

Code: Select all

00437F49 add eax, 6Ch


0044D51F mov ecx, 6Ch

0044D537 sub ecx, 6Ch
0044D53A add ebp, 6Ch


0044DD34 mov eax, 6Ch
0044DD39 mov ebx, 6Ch

Depending on how many end pointer need adjustment, this project is going to be a tremendous time-eater due to the three byte code issue. Means rewriting and relocating some functions is a time consuming, boring work with little error margin tolerance to avoid hard trackable game issues.

Look at stuff like sub_44D830 set_player_system_produtionQueue_DEFAULT

Code: Select all

0044D84B                 mov     edx, [ebx+60h]

0044D870                 mov     dword ptr [ebx+60h], 1

0044D87C                 mov     dword ptr [ebx+64h], 1

0044D8BB                 mov     dword ptr [ebx+64h], 1

0044D8BB                 mov     dword ptr [ebx+64h], 1

0044D8D5                 mov     edx, [ebx+60h]

0044D905                 inc     dword ptr [ebx+60h]

0044D90D                 mov     dword ptr [ebx+64h], 1

If there is hundreds subs like this you are going to have a lot of fun....


EDIT: For all 'mov dword ptr' hard coded four byte values you can use 'mov byte ptr' so you don't have to free code for them (except initial setup from my post above). For all other you need smarter coding.

[thunderchero]

I found moving the full *solar.wdf table was problematic to say the least. screen would not destroy properly.

So I had to take a different approach for adding new build queue widgets. The original 4 slots add from the table at 595DA8 as normal
the new 4 slots add from new table at 68a320. this table only has those 4 slots.
At 4F8BF1 it starts to load the *solar.wdf table (34 widgets) when that completes I added new code to add the 4 new slots from 68a320

so far this method is reacting the same as before, see image above. and they try to display new widgets when forced with cmp 8.

I hope since all the widget id's are in order (+4) they will be selected properly. but we will not know until all the code has been changed
28 02, 2c 02, 30 02, 34 02, 38 02, 3C 02, 40 02, 44 02

If there is hundreds subs like this you are going to have a lot of fun....

Just a few I may need to look at for +60h, +64h and +68h

Code: Select all

00447035 C7 81 A8 00 00 00 00 00 00 00       mov     [dword ptr ecx+0A8h], 0
0044703F C7 41 54 00 00 00 00                mov     [dword ptr ecx+54h], 0
00447046 C7 41 58 00 00 00 00                mov     [dword ptr ecx+58h], 0
0044704D C7 41 5C 00 00 00 00                mov     [dword ptr ecx+5Ch], 0
00447054 C7 41 60 00 00 00 00                mov     [dword ptr ecx+60h], 0
0044705B C7 41 64 00 00 00 00                mov     [dword ptr ecx+64h], 0
00447062 BB 14 00 00 00                      mov     ebx, 14h        ; num
0044D005 8B 40 68                            mov     eax, [eax+68h]
0044D025 89 50 68                            mov     [eax+68h], edx
0044D04B 83 C7 60                            add     edi, 60h
0044D376 C7 43 64 01 00 00 00                mov     [dword ptr ebx+64h], 1
0044D37D 89 43 60                            mov     [ebx+60h], eax
0044D380 89 D8                               mov     eax, ebx
0044D382 8D 53 60                            lea     edx, [ebx+60h]
0044D7DC C7 42 60 00 00 00 00                mov     [dword ptr edx+60h], 0
0044D7E3 89 D0                               mov     eax, edx
0044D7E5 C7 42 64 01 00 00 00                mov     [dword ptr edx+64h], 1
0044D7EC 83 C2 60                            add     edx, 60h
0044D84B 8B 53 60                            mov     edx, [ebx+60h]
0044D870 C7 43 60 01 00 00 00                mov     [dword ptr ebx+60h], 1
0044D877 B8 01 00 00 00                      mov     eax, 1
0044D87C C7 43 64 01 00 00 00                mov     [dword ptr ebx+64h], 1
0044D8D5 8B 53 60                            mov     edx, [ebx+60h]
0044D905 FF 43 60                            inc     [dword ptr ebx+60h]
0044D908 B8 01 00 00 00                      mov     eax, 1
0044D90D C7 43 64 01 00 00 00                mov     [dword ptr ebx+64h], 1
0044D8BB C7 43 64 01 00 00 00                mov     [dword ptr ebx+64h], 1
0044DA06 83 7E 60 00                         cmp     [dword ptr esi+60h], 0
0044DA10 3B 4E 60                            cmp     ecx, [esi+60h]
0044DB33 C7 46 64 01 00 00 00                mov     [dword ptr esi+64h], 1
0044DB1D FF 4E 60                            dec     [dword ptr esi+60h]
0044DB20 C7 46 64 01 00 00 00                mov     [dword ptr esi+64h], 1
0044DA71 8B 56 60                            mov     edx, [esi+60h]
0044DA74 4A                                  dec     edx
0044DA75 8D 04 95 00 00 00 00                lea     eax, [ds:0+edx*4]
0044DA7C 29 D0                               sub     eax, edx
0044DA7E C7 44 C6 14 00 00 00 00             mov     [dword ptr esi+eax*8+14h], 0
0044DA86 8B 46 60                            mov     eax, [esi+60h]
0044DA89 8D 50 FF                            lea     edx, [eax-1]
0044DA8C 8D 04 95 00 00 00 00                lea     eax, [ds:0+edx*4]
0044DA93 29 D0                               sub     eax, edx
0044DA95 C7 04 C6 00 00 00 00                mov     [dword ptr esi+eax*8], 0
0044DA9C FF 4E 60                            dec     [dword ptr esi+60h]
0044DA9F C7 46 64 01 00 00 00                mov     [dword ptr esi+64h], 1
0044DB5A 8B 42 60                            mov     eax, [edx+60h]
0044DB88 83 79 60 00                         cmp     [dword ptr ecx+60h], 0
0044DB98 8B 71 60                            mov     esi, [ecx+60h]
0044DB9B C7 41 68 00 00 00 00                mov     [dword ptr ecx+68h], 0
0044DC12 FF 49 60                            dec     [dword ptr ecx+60h]
0044DC15 5E                                  pop     esi
0044DC16 C7 41 64 01 00 00 00                mov     [dword ptr ecx+64h], 1
0044DBC0 8B 41 60                            mov     eax, [ecx+60h]
0044DBC3 8D 50 FF                            lea     edx, [eax-1]
0044DBC6 8D 04 95 00 00 00 00                lea     eax, [ds:0+edx*4]
0044DBCD 29 D0                               sub     eax, edx
0044DBCF C7 44 C1 14 00 00 00 00             mov     [dword ptr ecx+eax*8+14h], 0
0044DBD7 8B 41 60                            mov     eax, [ecx+60h]
0044DBDA 8D 50 FF                            lea     edx, [eax-1]
0044DBDD 8D 04 95 00 00 00 00                lea     eax, [ds:0+edx*4]
0044DBE4 29 D0                               sub     eax, edx
0044DBE6 C7 04 C1 00 00 00 00                mov     [dword ptr ecx+eax*8], 0
0044DBED FF 49 60                            dec     [dword ptr ecx+60h]
0044DBF1 C7 41 64 01 00 00 00                mov     [dword ptr ecx+64h], 1
0044DC4C 83 7A 60 04                         cmp     [dword ptr edx+60h], 4
0044DC85 83 78 60 00                         cmp     [dword ptr eax+60h], 0
0044DD4E C7 41 60 00 00 00 00                mov     [dword ptr ecx+60h], 0
0044DD55 C7 41 64 01 00 00 00                mov     [dword ptr ecx+64h], 1
0044DD5C 89 C8                               mov     eax, ecx
0044DD5E C7 41 68 00 00 00 00                mov     [dword ptr ecx+68h], 0
0044DD65 8D 51 60                            lea     edx, [ecx+60h]

My list for 6ch is much shorter and many may not be needed, but wanted to keep track

Code: Select all

00437F49 83 C0 6C                add     eax, 6Ch
0044D51F B9 6C 00 00 00          mov     ecx, 6Ch
0044D537 83 E9 6C                sub     ecx, 6Ch
0044D53A 83 C5 6C                add     ebp, 6Ch
0044D6DB B9 6C 00 00 00          mov     ecx, 6Ch
0044D6F7 8D 77 6C                lea     esi, [edi+6Ch]
0044DD34 B8 6C 00 00 00          mov     eax, 6Ch
0044DD39 BB 6C 00 00 00          mov     ebx, 6Ch
0043777A 66 8B 71 6C             mov     si, [ecx+6Ch]
004378BD B9 6C 00 00 00          mov     ecx, 6Ch
004378DB 83 C0 6C                add     eax, 6Ch
004378DE 83 C5 6C                add     ebp, 6Ch
004379CC 66 8B 4A 6C             mov     cx, [edx+6Ch]
00437AFF 66 8B 7F 6C             mov     di, [edi+6Ch]
00437BFB B9 6C 00 00 00          mov     ecx, 6Ch
00437C18 83 C3 6C                add     ebx, 6Ch
0043A96D 8B 4A 6C                mov     ecx, [edx+6Ch]

that is a lot of locations

[thunderchero]

Update....edited

As first step I'd extend file size only (not entries/end pointer) and look for issues resp. more instances of it in the code.

I started the code changes for 6C -> CC +96 (24 x 4)

right now
I can start new game
I can save game
auto save is saving game
I can load any game I create after changes.
I can not load prior saves that were saved before changes. (expected)

I have extracted the systinfo from a saved game before and after changes. they are exact same except the changed save has 96 byte at end. This is what I wanted so that is good.

from my tests I might be change some that may not be needed?

here is list of my changes for far. all locations were edited to use CC 00 00 00 (4 byte).

Code: Select all

00437F49 83 C0 6C                add     eax, 6Ch
0044D51F B9 6C 00 00 00          mov     ecx, 6Ch
0044D537 83 E9 6C                sub     ecx, 6Ch
0044D53A 83 C5 6C                add     ebp, 6Ch
0044D6DB B9 6C 00 00 00          mov     ecx, 6Ch
0044D6F7 8D 77 6C                lea     esi, [edi+6Ch]
0044DD34 B8 6C 00 00 00          mov     eax, 6Ch
0044DD39 BB 6C 00 00 00          mov     ebx, 6Ch
004378BD B9 6C 00 00 00          mov     ecx, 6Ch
004378DB 83 C0 6C                add     eax, 6Ch
004378DE 83 C5 6C                add     ebp, 6Ch
004379CC 66 8B 4A 6C             mov     cx, [edx+6Ch]
00437AFF 66 8B 7F 6C             mov     di, [edi+6Ch]
00437BFB B9 6C 00 00 00          mov     ecx, 6Ch
00437C18 83 C3 6C                add     ebx, 6Ch

if I edit this code change game will load but can't turn, save, load.

Code: Select all

0043777A 66 8B 71 6C             mov     si, [ecx+6Ch]

this make me wonder if I am making changes that are not needed example 4379CC and 437AFF maybe even 44D6F7

I will keep testing.

but it is promising to still have game loading and saving after changes.

I had a strange issue at 437C18, when I jumped a small bit of code to extend to 4 byte statement it would crash on game load. But when I move the complete code block game would load. it looks like just moving the small statement broke the code for "repne movsb" command. but this is good to know.

[Axis]

This four more slots would be a real nice addition.

[Spocks-cuddly-tribble]

I can't verify the entire list right now, but all from sub_446DA0 prepare_clear_systInfo have nothing to do with this. Also 43777A, 4379CC and 437AFF are wrong.

Looking at these codes again would be a good exercise to learn to watch what's actually stored there. Think of it as a variant of the 'Shell game' i.e. no knowledge needed but just powers of observation and simple logic.

Also you should test switch from player to AI system (and conversely), there is some strange codes for this case. Losing and conquering systems should suffice.

Good luck with the project!

[thunderchero]

This four more slots would be a real nice addition.

if some one wanted to edit around 100+ values and create edited wdf's, I left enough room for 12 more build queue slots (20 total)

Project update,

I added all the 60h, 64h, 68h and cmp 4

currently I can,
add 8 structures to build queue
build all 8 structures without any crashes (have tested over 100 turn in single test no game play just adding structures and pressing turn until home world was eliminated)

The issue I have right now is the GUI
I have the normal 4 build queue slots
and still have the 4 pink boxes (as image above)
when an item goes into first pink slot the slot "tool tips" will still say empty but once first build completes 5th item will move into 4th slot and be invisible. this is the same for slot 6, 7, 8

So next I guess i will be studying the gui/wdf's and figure out what is needed there.

after a quick compare of energy screen project changes I will have to edit,

initiate solar screen memory size (if energy screen project is installed value will require adjustment)
initiate *buildq.wdf memory size
and it looks like I still need to find how code selects build queue slots I have been looking for first slot ID but it looks like it might use last id, but I am still not sure.

Maybe at that point this project might be ready for a though testing.

[Flocke]

Sounds great!
Am amazed by all the asm coding you do in this and already the energy screen project.
Honestly, myself I still always have hard times reading the asm code. Without of a deep analysis I just stare at the code and be amazed of what you get accomplished! Well done!