Build Queue project with 4 new slots

[thunderchero]

Flocke thanks for the encouragement,

I did a lot of testing today and found some info, but still have been unable to get new widgets to display properly.

first id of build queue

Code: Select all

004F9154 8D 85 28 02 00 00       lea     eax, [ebp+228h]

these 2 code blocks loop though the widget table but ignore the 4 new widgets.
I also think this this loops though all widget on selected table. so I really don't understand why it skips new widgets.

Code: Select all

0053E595 89 F8                   mov     eax, edi
0053E597 8B 59 04                mov     ebx, [ecx+4]    ; instanceId
0053E59A 8B 11                   mov     edx, [ecx]      ; typeId
0053E59C E8 1F FF FF FF          call    WDFRead_LoadWidget
0053E5A1 85 C0                   test    eax, eax
0053E5A3 74 15                   jz      short loc_53E5BA

0053E5A5 8B 14 24                mov     edx, [esp+4+var_4]
0053E5A8 03 51 08                add     edx, [ecx+8]
0053E5AB 83 C1 0C                add     ecx, 0Ch
0053E5AE 46                      inc     esi
0053E5AF 89 02                   mov     [edx], eax
0053E5B1 39 EE                   cmp     esi, ebp
0053E5B3 7C E0                   jl      short loc_53E595

one other location I need to test more, when increased 04 -> 08 build queue will only display properly on widgets 2 and 4 all others are pink.
My thought this is reading widget id's and not from table?

Code: Select all

4FDE6D 83 C1 04                add     ecx, 4

I also did a test on energy screen project and found splitting the table would not work.
so now I have moved the "labor" table to allow me to expand the *solar table without moving it.

I am thinking the cmp or what ever is hidden in some place that i have not looked yet.

I wanted to get my current progress documented.

My tests platform is Vanilla 1024 from all in one installer with the relocation code data and code installed
If you install You must fill area 0x0019f400 - 0x01b23ff with 00's before patching.

here is the edited wdf *solar.wdf files with 8 total build queue widgets

edited_1024_8_BQ.zip

(4.3 KiB) Downloaded 98 times

here is my current patch file for changes (each change is labeled)
Note; this is not a functioning patch.

Build_Queue.patch

(22.88 KiB) Downloaded 93 times

Note; All value below are vanilla values and locations, due to increase of 1 -> 4 bytes to prevent value going negative many locations changed.
6C -> CC change locations

Code: Select all

00437F49 0x37349 83 C0 6C                add     eax, 6Ch
004378BD 0x36cbd B9 6C 00 00 00          mov     ecx, 6Ch
004378DB 0x36cdb 83 C0 6C                add     eax, 6Ch
004378DE 0x36cde 83 C5 6C                add     ebp, 6Ch
00437BFB 0x36ffb B9 6C 00 00 00          mov     ecx, 6Ch
00437C18 0x37018 83 C3 6C                add     ebx, 6Ch
0044D51F 0x4c91f B9 6C 00 00 00          mov     ecx, 6Ch
0044D537 0x4c937 83 E9 6C                sub     ecx, 6Ch
0044D53A 0x4c93a 83 C5 6C                add     ebp, 6Ch
0044D6DB 0x4cadb B9 6C 00 00 00          mov     ecx, 6Ch
0044DD34 0x4d134 B8 6C 00 00 00          mov     eax, 6Ch
0044DD39 0x4d139 BB 6C 00 00 00          mov     ebx, 6Ch

60 -> C0 change locations

Code: Select all

0044D04B 0x4c44b 83 C7 60                            add     edi, 60h
0044D37D 0x4c77d 89 43 60                            mov     [ebx+60h], eax
0044D382 0x4c782 8D 53 60                            lea     edx, [ebx+60h]
0044D7DC 0x4cbdc C7 42 60 00 00 00 00                mov     [dword ptr edx+60h], 0
0044D7EC 0x4cbec 83 C2 60                            add     edx, 60h
0044D84B 0x4cc4b 8B 53 60                            mov     edx, [ebx+60h]
0044D870 0x4cc70 C7 43 60 01 00 00 00                mov     [dword ptr ebx+60h], 1
0044D8D5 0x4ccd5 8B 53 60                            mov     edx, [ebx+60h]
0044D905 0x4cd05 FF 43 60                            inc     [dword ptr ebx+60h]
0044DA06 0x4ce06 83 7E 60 00                         cmp     [dword ptr esi+60h], 0
0044DA10 0x4ce10 3B 4E 60                            cmp     ecx, [esi+60h]
0044DA38 0x4ce38 8B 7E 60                            mov     edi, [esi+60h]
0044DB1D 0x4cf1d FF 4E 60                            dec     [dword ptr esi+60h]
0044DA71 0x4ce71 8B 56 60                            mov     edx, [esi+60h]
0044DA86 0x4ce86 8B 46 60                            mov     eax, [esi+60h]
0044DA9C 0x4ce9c FF 4E 60                            dec     [dword ptr esi+60h]
0044DB5A 0x4cf5a 8B 42 60                            mov     eax, [edx+60h]
0044DB88 0x4cf88 83 79 60 00                         cmp     [dword ptr ecx+60h], 0
0044DB98 0x4cf98 8B 71 60                            mov     esi, [ecx+60h]
0044DC12 0x4d012 FF 49 60                            dec     [dword ptr ecx+60h]
0044DBC0 0x4cfc0 8B 41 60                            mov     eax, [ecx+60h]
0044DBD7 0x4cfd7 8B 41 60                            mov     eax, [ecx+60h]
0044DBED 0x4cfed FF 49 60                            dec     [dword ptr ecx+60h]
0044DC4C 0x4d04c 83 7A 60 04                         cmp     [dword ptr edx+60h], 4
0044DC85 0x4d085 83 78 60 00                         cmp     [dword ptr eax+60h], 0
0044DD4E 0x4d14e C7 41 60 00 00 00 00                mov     [dword ptr ecx+60h], 0
0044DD65 0x4d165 8D 51 60                            lea     edx, [ecx+60h]

64 -> C4 change locations

Code: Select all

0044D376 0x4c776 C7 43 64 01 00 00 00                mov     [dword ptr ebx+64h], 1
0044D7E5 0x4cbe5 C7 42 64 01 00 00 00                mov     [dword ptr edx+64h], 1
0044D87C 0x4cc7c C7 43 64 01 00 00 00                mov     [dword ptr ebx+64h], 1
0044D8BB 0x4ccbb C7 43 64 01 00 00 00                mov     [dword ptr ebx+64h], 1
0044D90D 0x4cd0d C7 43 64 01 00 00 00                mov     [dword ptr ebx+64h], 1
0044DA9F 0x4ce9f C7 46 64 01 00 00 00                mov     [dword ptr esi+64h], 1
0044DB20 0x4cf20 C7 46 64 01 00 00 00                mov     [dword ptr esi+64h], 1
0044DB33 0x4cf33 C7 46 64 01 00 00 00                mov     [dword ptr esi+64h], 1
0044DBF1 0x4cff1 C7 41 64 01 00 00 00                mov     [dword ptr ecx+64h], 1
0044DC16 0x4d016 C7 41 64 01 00 00 00                mov     [dword ptr ecx+64h], 1
0044DD55 0x4d155 C7 41 64 01 00 00 00                mov     [dword ptr ecx+64h], 1

68 -> C8 change locations

Code: Select all

0044D005 0x4c405 8B 40 68                            mov     eax, [eax+68h] 
0044D025 0x4c425 89 50 68                            mov     [eax+68h], edx
0044DB9B 0x4cf9b C7 41 68 00 00 00 00                mov     [dword ptr ecx+68h], 0
0044DD5E 0x4d15e C7 41 68 00 00 00 00                mov     [dword ptr ecx+68h], 0

cmp 4 -> cmp 8 change locations

Code: Select all

004FDF5F 0xfd35f 83 F9 04                cmp     ecx, 4
0044DC4C 0x4d04c 83 7A 60 04             cmp     [dword ptr edx+60h], 4 limit production is full
0044D9C7 0x4cdc7 83 F9 04                cmp     ecx, 4 PRODUCTION_QUEUE_MAXSIZE

Misc table change locations

Code: Select all

#*solar.wdf total widgets
>> 0x000f01e7 22
#*solar.wdf total widgets
>> 0x000f01fe 22
#offset for moved table 5960F4 -> 68a320
>> 0x000f0203 44 5f 59
#*solar.wdf total widgets
>> 0x000f7ad3 22
#offset for moved table 5960F4 -> 68a320
>> 0x000f7b1c 44 5f 59
#memory increase *solar.wdf
>> 0x000f7eac 78
#*solar.wdf total widgets
>> 0x000f7ff2 22
#offset for moved table 5960F4 -> 68a320
>> 0x000f8237 44 5f 59
#memory increase 4F9C30
>> 0x000f9039 2c
#memory increase 4FD610
>> 0x000fca20 3c
#memory increase 4FDF10
>> 0x000fd31c 34

[Spocks-cuddly-tribble]

one other location I need to test more (...) I am thinking the cmp or what ever is hidden in some place...

Good logic analysis. You are right in sub_4FDE40 is a very good hidden cmp 4:

Code: Select all

004FDE5F                 lea     ebx, [eax+10h] //  10h = 4 entries * 4 bytes -> you need 20h

I don't know data structure from input string [eax] in sub_4FDE40, so I'm not 100% sure about:

Code: Select all

004FDE75                 mov     eax, [ecx+10h]

And there could be more issues...


EDIT: Also I'd check QD's energy screen project codes wrt to changes of the memory allocation (mov eax before call sub_492EF0)? Here:

Code: Select all

004F8AAB                 mov     eax, 278h

EDIT3: Looks more like:

Code: Select all

004FDF1B                 mov     eax, 34h

The entire sub_4FDF10 might need adjustments?


EDIT2: You also should re-read my first post here, I don't see codes on your lists I hinted there like:

Code: Select all

0044D0BC                 cmp     ecx, 4

[thunderchero]

I think this is my main issue, I suspect this is a wdf issue, but wdf's look correct

load all widgets for 595DAC at 4F8BFF
this goes to WDFRead_LoadWidgets 53E580
at 0053E5AB 83 C1 0C add ecx, 0Ch
move 12 bytes to next widget
I put a breakpoint on each build queue ID in the 595DAC table
it will load the original 4 widgets correctly
on the 4 new widget the point break is orange not red?
it still goes though the code on those id's but I think something is not being set correctly.

orange.jpg (455.05 KiB) Viewed 3670 times

I have adjusted memory in 4 subsections I increased same as energy project 8 bytes per widget

Code: Select all

#memory increase *solar.wdf
>> 0x000f7eac 78 02
#memory increase 4F9C30
>> 0x000f9039 2c
#memory increase 4FD610
>> 0x000fca20 3c
#memory increase 4FDF10
>> 0x000fd31c 34

EDIT2: You also should re-read my first post here, I don't see codes on your lists I hinted there like:

Code: Select all

0044D0BC                 cmp     ecx, 4

I am keeping track of earlier post
I left out many of the cmp 4 since they had no effect at this time. but I still have a much longer list.

I am thinking my issue is at an earlier point

one other location I need to test more (...) I am thinking the cmp or what ever is hidden in some place...

Good logic analysis. You are right in sub_4FDE40 is a very good hidden cmp 4:

Code: Select all

004FDE5F                 lea     ebx, [eax+10h] //  10h = 4 entries * 4 bytes -> you need 20h

I don't know data structure from input string [eax] in sub_4FDE40, so I'm not 100% sure about:

Code: Select all

004FDE75                 mov     eax, [ecx+10h]

first and second change resulted in CTD entering F2 screen while I do expect they maybe needed I feel my first issue will be required first.

[Spocks-cuddly-tribble]

I am thinking my issue is at an earlier point (...) while I do expect they maybe needed I feel my first issue will be required first.

Correct, my edit3 refers to this. Sub_4FDF10 actually creates this intermediate file for the build queue wdf widgets. So you need to analyse and change its structure there (4 to 8 entries) and the code of all locations where it's read e.g. sub_4FDE40.

I never analysed wdf files and their widgets, so the 'move 12 bytes vs. 8 bytes memory' part sounds strange to me. Means, I could misinterpret relevant parts of this code to assess all needed adjustements. But you need at least:

Code: Select all

004FDF1B                 mov     eax, 34h // +8 entry?

004FDF2F                 mov     dword ptr [ebp+10h], 0  // +4 entry

004FDF5F                 cmp     ecx, 4 // +1 entry

004FDF5C                 mov     [edi+10h], eax   // +4 entry

[thunderchero]

so the 'move 12 bytes vs. 8 bytes memory' part sounds strange to me. Means, I could misinterpret relevant parts of this code to assess all needed adjustements. But you need at least:

my statement on increase of memory was based on energy screen project difference

At
004F8AAB B8 78 02 00 00 mov eax, 278h ; size (632)
changed to
004F8AAB B8 58 03 00 00 mov eax, 358h ; size (856)

that is an increase of 224 bytes
he added 28 (14 images + 14 text) widgets for that increase 224/28 = 8

but I may be misinterpreting values myself or their might have been unused bytes in vanilla.

edit; I just did a few quick tests on vanilla,
game will not load at 48 02 but will load at 58 02
also game will still load at 78 03

the other 3 locations I just doubled original value

[Spocks-cuddly-tribble]

sub_4FDF10 writes build queue data 1 to 4 into the intermediate file:

ds:595DA8 address main data

The address of the intermediate file is stored at [main data+50h]:

Code: Select all

004F9164                 mov     [ebp+50h], eax  // address intermediate file

For slots 1-4 write in intermediate file at:

[?+14h]
[?+18h]
[?+1Ch]
[?+20h]

But first it tries to read data from (you need to figure the source of this data):

[?+228h]
[?+22Ch]
[?+230h]
[?+234h]

Code: Select all

004F9154                 lea     eax, [ebp+228h] // base address main data

Now the problem is that, after the IDs 1-4, both files have further fixed data addresses.


If I'm not mistaken, this would mean for the intermediate file:


sub_4FDF10

not needed:

Code: Select all

004FDF2F                 mov     dword ptr [ebp+10h], 0

004FDF5C                 mov     [edi+10h], eax

addresses +4 entry:

Code: Select all

004FDF36                 mov     dword ptr [ebp+24h], 0

004FDF9D                 mov     [ebp+28h], eax

004FDFA5                 mov     dword ptr [ebp+2Ch], 0

004FDFAE                 mov     dword ptr [ebp+30h], 0


004FDF5F                 cmp     ecx, 4 // +1 entry

sub_4FDE40

Code: Select all

needed:
004FDE5F                 lea     ebx, [eax+10h] -> 20h
not needed:
004FDE75                 mov     eax, [ecx+10h]

And this is just the beginning....

[thunderchero]

But first it tries to read data from (you need to figure the source of this data):

[?+228h]
[?+22Ch]
[?+230h]
[?+234h]

Code: Select all

004F9154                 lea     eax, [ebp+228h] // base address main data

Btw I see the +228h in the code, but how do you see the other 3 id's?

These are the 4 original slot id's
original/current 4 id's
28 02, 2c 02, 30 02, 34 02
4 new id's I created in wdf and table
38 02, 3C 02, 40 02, 44 02

these are the placeholders id's the *buildq.wdf is added to those placeholder
the *buildq.wdf has 2 widgets, an image widget and text widget, this is what the new build queue slots are missing the loading of image and text entry.
I think the images and text is added in sub 4FD3AC

Also please keep in mind I am still a pakled when it come to coding, example;

addresses +4 entry:

Code: Select all

004FDF36                 mov     dword ptr [ebp+24h], 0

when you say addresses "+4 entry" would that be +4 per slot for a total of +16 or is the +24 already 4 entries so for 4 more double it?

Code: Select all

004FDF5F                 cmp     ecx, 4 // +1 entry

I already have this set to 8, or are you saying it should be 5? but that make no sense to me.

[Spocks-cuddly-tribble]

Source = code location where it writes slot id's to [main data +224h + 4* slot number], to ensure this happens for slots 5-8.

+4 per slot for a total of +16 (searching for all codes reading this will be main issue)
+1 per slot for a total of 4+4=8

[thunderchero]

funny thing is I thought the Gui would be the easy part of this project....

if you look at the changes to the energy screen project it was simple

each change only had a couple locations for
new id for first image widget of special
new id for first text widget of special
new id for first image widget of defense
new id for first text widget of defense
increase number of widget per type
increase total widgets
increase total energy widget
increase memory
change table location

Code: Select all

<< 0x000f0553 b0 02    first text second type
<< 0x000f0563 0e       widgets per type
<< 0x000f0568 b0 02    first text second type
<< 0x000f0570 20 03    first image second type
<< 0x000f057c 78 02    first text widget
<< 0x000f058c 0e       widgets per type
<< 0x000f0591 78 02    first text widget
<< 0x000f0599 e8 02    first image widget
<< 0x000f0ee5 38       energy widgets (text and images)
<< 0x000f0ef6 e8 02    first image widget
<< 0x000f0f0a 38       energy widgets (text and images)
<< 0x000f0f14 20 03    first image second type
<< 0x000f125f 0e       widgets per type
<< 0x000f127d 0e       widgets per type
<< 0x000f1289 78 02    first text widget
<< 0x000f1314 e8 02    first image widget
<< 0x000f13b4 e8 02    first image widget
<< 0x000f13e1 b0 02    first text second type
<< 0x000f146c 20 03    first image second type
<< 0x000f150c 20 03    first image second type
<< 0x000f1547 20 03    first image second type
<< 0x000f1577 e8 02    first image widget
<< 0x000f660f 78 02    first text widget
<< 0x000f661d 78 02    first text widget
<< 0x000f664c b0 02    first text second type
<< 0x000f665a b0 02    first text second type
<< 0x000f7b02 42       total widgets
<< 0x000f7b07 00 a0 68 table location
<< 0x000f7eac 58 03    size of initiate solar screen
<< 0x000f8421 42       total widgets
<< 0x000f8426 00 a0 68 table location

[Spocks-cuddly-tribble]

The Build Queue is a dynamic and variable feature, so it's much more complex than just buildings in a fixed order. I think QD hinted this before. It's not too late to abort....

[thunderchero]

The Build Queue is a dynamic and variable feature, so it's much more complex than just buildings in a fixed order. I think QD hinted this before. It's not too late to abort....

we still have a working "phantom" build queue, the next 4 to be built will display, when one is built 5th will move into 4th slot this will continue until there is 4 or less in queue.

and the way code is setup with 4 byte values if you want it could be increased to what ever max build queue that is desired.

I have already tested without wdf and table changes. and even have a patch for it (relocation patch required first)

max popup still works and when it is a limit one build it is removed from list

[thunderchero]

Hi Everyone,

I did some testing using the phantom build queue, I had no issues what so ever.

so now the question remains, since GUI is not an issue how many hidden build queue's should be in patch?

I think this patch will be most used when starting a new system. Most mods even in late in game don't have more then 12 structure that will need built.

so that is what I was considering to use as base patch setting. you would see 4 with 8 hidden.

thoughts?

I also wonder how this will effect Flocke adjustments to editing saved games with UE
I expect or hope it will be a simple "if" statement with a little bit more of code.

thunderchero

[Martok]

Oh goodness yes, I think 12 "slots" for the build queue would be plenty.

Tremendous work, by the way!

[thunderchero]

Update,

I have not had much time to do any further testing on this project after having two random crashes while adding items to build queue (I estimate the 2 crashes happened over 2000 items added) so this is rare so far.

I have not been able to reproduce during debug, or been able to reproduce consistently. it may be an unnecessary code or missing a code location.

here is the unofficial patch if others want to test.
note; 4 visible 4 phantom patch

phantom_Build_Queue.patch

(13.59 KiB) Downloaded 91 times

reminder the relocation patch is required
viewtopic.php?p=53896#p53896

[Spocks-cuddly-tribble]

The GUI part of the project is still possible. The effort depends on:


1.) Number of codes for the four end data entries of the intermediate file [+24h, +28h, +2Ch, +30h] (single bytes) each +4 per new queue slot

2.) Number of codes for the memory allocation of the intermediate file (e.g. 4FDF1B mov eax, 34h) also each +4 per new queue slot

3.) Number of pointers for locations after the build queue wdf slot IDs and/or all larger hard coded widget IDs (like energy screen new IDs).


Example: Base pointer to first build queue ID: 4F9154 lea eax, [ebp+228h]. 228h +4*4 (default build queue slots) = 238h+ pointers to next data

Will adding more widgets IDs in main data ds:595DA8 affect all or some of the following code locations? Or even more locations?

Code: Select all

004F8B05                 mov     ebx, 258h
004F8B0A                 mov     edx, 320h


004F8B85                 mov     dword ptr [ebp+23Ch], 0
004F8B8F                 mov     dword ptr [ebp+240h], 0
004F8B99                 mov     dword ptr [ebp+244h], 0
004F8BA3                 mov     dword ptr [ebp+248h], 0
004F8BAD                 mov     dword ptr [ebp+24Ch], 0

004F8BBC                 mov     dword ptr [ebp+250h], 0

004F8BC8                 mov     dword ptr [ebp+254h], 0


004F9528                 mov     eax, [ebp+270h]

004F958B                 mov     eax, [ebp+270h]

004F95A2                 mov     dword ptr [ebp+274h], 0

004F95AC                 mov     dword ptr [ebp+258h], 0

004F95B6                 mov     dword ptr [ebp+238h], 0

I see the +228h in the code, but how do you see the other 3 id's?

That's what I meant with 'think of it as a variant of the Shell game'. Watch the pointers:

Code: Select all

004F9154                 lea     eax, [ebp+228h] // base pointer to first wdf build queue ID to eax

004FDF19                 mov     esi, eax // now to esi

004FDF47                 mov     [ebp+8], esi // also store base pointer at [intermediate file+8] for later use

004FDF4E                 mov     edx, [esi] // load wdf slot ID from pointer

004FDF58                 add     esi, 4 // adjust pointer to next ID for loop

004FDF5F                 cmp     ecx, 4 // stop after max queue slot (i.e. last pointer adjustment gets ignored for esi, not for edi)

EDIT: Some suspects @ point #1 (+ 4 per new queue slot) I'm not sure wrt the first four.

Code: Select all

004FD5D3                 mov     [eax+24h], edx

004FD5D8                 mov     ecx, [eax+24h]

004FD5F3                 cmp     dword ptr [eax+2Ch], 0

004FD5FE                 call    dword ptr [ecx+2Ch]


004FDE30                 mov     [eax+2Ch], edx

004FDE90                 mov     dword ptr [eax+30h], 1

004FDEA0                 mov     dword ptr [eax+30h], 0

004FDEBA                 lea     edi, [eax+10h]  // hidden cmp 4

004FDECB                 mov     eax, [ebp+28h]

0053DD8C                 cmp     dword ptr [eax+28h], 1

0053DD99                 mov     dword ptr [eax+28h], 1

the *buildq.wdf has 2 widgets, an image widget and text widget, this is what the new build queue slots are missing the loading of image and text entry.

So there also should be hard coded 4 and/or 8 and total widget numbers?

Example what is this for:

Code: Select all

004F913F                 mov     edx, 4