Solved: Energy Screen Project

[QuasarDonkey]

Energy Screen Project Patch

Vanilla BotF is limited to displaying 7 special and 7 defense energy structures in the solar system (F2) screen. This patch allows for changing that limit.


Patch Tool

I've written a special patch tool as this complex beast involves offset computations, about 30 trek.exe code patches, relocating/rewriting data in Trek.exe, and rewriting the 5 senergy.wdf files.

Get it here: http://sourceforge.net/projects/botfenergypatch/files/

You can separately patch Trek.exe and the WDFs, but both must be used or BotF will crash out!

I have left a copy of the original WDF files with the patch. You'll need to copy the modified WDFs to STBOF.RES.

A thing to note is that the patch tool simply lays out the structures in the WDFs in a single row for Special and a single row for Defense. If you add more than 11 items per row, they'll overlap. You can use the UE WDF editor to manually reposition them.

How It Works

Here is an overview of how the patch works. In order to understand how the patch works, we'll need to take a diversion into the Trek.exe User Interface (UI) system. The UI in BotF is comprised of 21 screens (actually the code has an extra screen CivConf, I'll resurrect that in a future mod ). Each screen is comprised of various widgets like buttons, pictures, text labels, etc. Each screen uses a WDF file to control it's appearance. Each widget in a WDF file has ID associated with it, so it can match to a live widget in the program. There is a matching list of such IDs for each screen in Trek.exe. Let's look at the Opening screen.

The Opening Screen

At offset 594394, we see an array like:

Code: Select all

<2, 139, 4>
<2, 140, 8>
<2, 141, 0Ch>
<2, 142, 10h>
<2, 355, 14h>
<2, 143, 18h>
<2, 144, 1Ch>
<2, 356, 20h>
<2, 9600, 24h>

This is the wdfObject descriptor list. The first number is the wdfObject typeId, 2 representing a button. The second number is the objectId. Widgets in the WDF must have these IDs. By analysing the WDF, we see that ID 139 is the "Continue" button, ID 140 is the "New Game" button, etc. The third number is critical to this patch. It's the offset within the screen's data structure, containing a pointer (offset) to the live widget. Taking a look the function that initializes the Opening screen, we see

Code: Select all

004D0AF8         mov     eax, 28h                ; size
004D0AFD         call    System_Memory_AllocFromUIPool

28h is 40 decimal. This is the size of the Opening screen's data structure. By looking at the above list of wdfObject ID versus data structure offsets, we can piece the Opening screen's structure back together:

Code: Select all

00000000 OpeningScreen_t struc ; (sizeof=0x28)
00000000 widget  dd ?                            ; struct  offset
00000004 btnContinue dd ?                        ; struct  offset
00000008 btnNewGame dd ?                         ; struct  offset
0000000C btnNewMPGame dd ?                       ; struct  offset
00000010 btnLoad dd ?                            ; struct  offset
00000014 btnSave dd ?                            ; struct  offset
00000018 btnQuit dd ?                            ; struct  offset
0000001C btnFame dd ?                            ; struct  offset
00000020 btnOptions dd ?                         ; struct  offset
00000024 btnRetire dd ?                          ; struct  offset
00000028 OpeningScreen_t ends

All those struct offsets are pointers to the live button objects. Offsets on a 32-bit machine being 4-bytes of course. The first entry "widget" contains the main Opening screen itself, i.e. the background image, etc.

So if we wanted to add a new button to the Opening screen, here's what we'd do:

• Expand the screen's data structure to make room for the new button. We'd do this by simply allocating another 4 bytes, 28h+4=2Ch:

  Code: Select all

  004D0AF8         mov     eax, 2Ch                ; size
  004D0AFD         call    System_Memory_AllocFromUIPool

• Add an entry to the wdfObject descriptor list with an unused ID, and set it's offset to point to the start of the enlarged area of the screen's structure:

  Code: Select all

  <2, 145, 28h>

• Add a button (type 2) entry to opening.wdf, with ID 145.
• Add some code to make the button do something. Easy -- here's how the Continue button adds it's callback:

  Code: Select all

  004D0BE5         mov     edx, offset UI_Opening_btnContinue_Click
  004D0BEA         mov     eax, [esi+OpeningScreen_t.btnContinue]  ; esi+4
  004D0BED         call    PushBtn_SetClickCallback

That's actually simplifying things, because you can't simply just expand the list of wdfObject descriptors, because you'd end up overwriting other data in Trek.exe. So you must find a large enough empty space in Trek.exe to relocate that whole block, and change any references to it in the code.

The SolarSys:Energy Sub-Screen

The SolarSystem Screen is a bit more complicated than the Opening screen, since it has various subscreens, but we can use the same technique to extend it. In this case, we piece together the screen's data structure as (cut down for brevity):

Code: Select all

00000000 SolarSysScreen_t struc ; (sizeof=0x278)
00000000 widget  dd ?
...
00000054 btnSummary dd ?
...
00000190 picEnergySpecial0 dd ?
00000194 picEnergySpecial1 dd ?
00000198 picEnergySpecial2 dd ?
0000019C picEnergySpecial3 dd ?
000001A0 picEnergySpecial4 dd ?
000001A4 picEnergySpecial5 dd ?
000001A8 picEnergySpecial6 dd ?
000001AC txtEnergySpecial0 dd ?
000001B0 txtEnergySpecial1 dd ?
...
000001C4 txtEnergySpecial6 dd ?
000001C8 picEnergyDefense0 dd ?
...
000001E0 picEnergyDefense6 dd ?
000001E4 txtEnergyDefense0 dd ?
...
000001FC txtEnergyDefense6 dd ?
00000200 txtEnergyTitle dd ?
00000204 txtEnergySpecialTitle dd ?
...
00000270 picChat dd ?
00000274 field_274 dd ?
00000278 SolarSysScreen_t ends

The code doesn't reference each picEnergySpecial# directly, but uses them in an array by keeping a counter (edx in this example), and incrementing an offset by 4 (eax):

Code: Select all

004F115D         inc     edx
004F115E         add     eax, 4
004F1161         cmp     edx, 7

In order to extend the number of energy structures, it would be unrealistic to expand the array inside the structure, since we'd end up having to change tons of offsets. Instead, like with the Opening screen, we just enlarge it. Say we wanted 14 special and 14 defense structures, that's 14 pics + 14 labels + 14 pics + 14 labels = 56 objects; 56 * 4 bytes = 224. The old size was 278h = 632, so the new size 632+224 = 856:

Code: Select all

004F8AAB         mov     eax, 856               ; size
004F8AB0         call    System_Memory_AllocFromUIPool

Then we have to adjust all offsets to 190h (position of picEnergySpecial within SolarSysScreen) to now point to 278h. Likewise, you need to do the same of picEnergyDefense, txtEnergySpecial, and txtEnergyDefense.
You also need to extend the list of Energy subscreen wdfObject descriptors at offset 5960F4:

Code: Select all

005960F4 stru_5960F4
005960F4         wdfObjectDesc_t <14, 2400, 200h>
005960F4         wdfObjectDesc_t <14, 2401, 204h>
005960F4         wdfObjectDesc_t <14, 2402, 208h>
...
005960F4         wdfObjectDesc_t <14, 2446, 1FCh>

and add ID's for the new energy structure widgets. You also need to mod those third entries, the offsets within SolarSysScreen, so 190h -> 278h, 194h -> 27Ch, etc. In order to fit these new entries in, you need to relocate the data at 5960F4, and change any references to the new location. The patchtool places the new data at 68A000.

Finally, you must add the widgets to the WDF files.

Here's a list of all ASM offsets than need modding:

Code: Select all

        // size of SolarSysScreen structure:
        0x4F8AAB

        // refs to senergy wdfObjects
        0x4F9025
        0x4F8706

        // refs to number of senergy wdfObjects
        0x4F9020
        0x4F8701

        // refs to special energy pictures
        0x4F117A
        0x4F118F
        0x4F1E86
        0x4F720D
        0x4F721B

        // refs to special energy text labels
        0x4F1197
        0x4F1AF4
        0x4F1F11
        0x4F1FB1
        0x4F2174

        // refs to defense energy pictures
        0x4F1151
        0x4F1166
        0x4F1FDE
        0x4F724A
        0x4F7258

        // refs to defense energy text labels
        0x4F116E
        0x4F1B12
        0x4F2069
        0x4F2109
        0x4F2144

        // "cmp X, 7".
        // change 7 to NumDefense
        0x4F1161
        0x4F1E5D
        // change 7 to NumSpecial
        0x4F118A
        0x4F1E7B
        //Note: 0x4F1B95 contains "cmp (benefitType), 7"; not relevant here

        // change 1C to 4*NumEnergySpecial
        0x4F1AE3
        // change 1C to 4*NumEnergyDefense
        0x4F1B08

Consult the Trek.exe ASM and the patchtool for more details. I've left out a few more details, since the patchtool does a few additional things. But that's basically it.

Hope someone finds this informative / not too incomprehensible.

[Peter1981]

Wow QD just trying this with the TOS MOD hope it works....

It works !!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!

THis is a major improvementr QD so glad you've don this for us definately a must for new (an old) mods

I must admit I was a little secptical of this working in the case of the TOS MOD as it has had so many code changes made but it worked beautifully a generous round of applause from me QD well done.

[QuasarDonkey]

I must admit I was a little skeptical of this working in the case of the TOS MOD as it has had so many code changes made but it worked beautifully a generous round of applause from me QD well done.

Why thank you. I tried to keep code changes to minimum, and the new data gets written to large unused data block in Trek.exe that no-one seems to know about (asm offset 68A000). So I don't think it will conflict with any existing mods.

Thanks for testing. Sidenote: I've found that modifying the parameters to "patchtool 11 11" seems to result in the tightest fit that does not require manual adjusting of the WDFs.

P.S. I see you're a Rear-Admiral now, Peter. I believe you outrank me sir

[thunderchero]

well I have not had time to test yet

but so far so good

I am editing the wdf file I had (since locations were already set)

but did notice one thing.

to use the patch.bat I had to edit it to

patchtool.exe 14 14
pause

instead of

patchtool 14 14
pause

I have a doctors appointment so will continue when I get back and post my images

thunderchero

[QuasarDonkey]

to use the patch.bat I had to edit it

Oh thanks thunder. I'm running on Linux here using wine, so it lets get away with things like that. I'll update the zip file for others.

Edit: for those of you who already downloaded: see thunder's comment above. I also fixed the patch.bat file in the zip file if you just want to redownload it.


Also thunder, since you're editing you're own WDF's, here's something you should be aware of: I changed the ID's of some of the entries in the WDF's. You'll need to modify them in your WDF to get it to match the Trek.exe patches.

Code: Select all

2460 -> 2407
2461 -> 2408
2464 -> 2409

The reason I did this is that the 10 non- energy structure objects in the WDF now have ID's going from 2400-2409. That means we can use 2410+ sequentially for the energy structures, without worrying about conflicting ID's. I did this to simplify the coding of the patchtool. There's really no way around it.

It's actually worse than that. The patchtool totally rewrites the WDF's. So the ID's of all the energy structure objects will probably be different to your WDF's. I think it'll be easier for you to just edit the newly generated files.

I'll post all the other such technical details soon (probably tomorrow).

[KrazeeXXL]

I wasn't here for a month, so a belated welcome to AFC from me.

Wow, and in this single month you're here, you solved that energy screen problem?!

Not bad, not bad at all

[QuasarDonkey]

Thanks, I'm glad to have found this community. I used to love playing BotF, but hated some of the bugs in it. I never thought I'd be fixing them in this manner.

I hope the energy screen project is finally solved. My tests on vanilla BotF have been good. I've tested with 20+ structures as different empires, and it works fine for me. Although if you build too many Special structures, they roll over to Defense, but it doesn't happen the opposite way; at least I think that's the order. So if you're missing structures, it's not a bug in the patch, but a limitation in BotF...

[thunderchero]

so far it works great,

here is the image of feds with 28 structures on energy screen. BTW I had a lot more energy building but most were special so they went off screen and did not go to defense (expected vanilla did this too).



if anyone wants my edited wdf here they are

wdf_3.rar

also just edit lexicon 1170 and 218 (delete text for special and defense)

and use the trek.exe that QD files created

thunderchero

[QuasarDonkey]

Nice pic, that's a pretty sweet layout. Do you have those for all the empires, or just feds?

Some points I'd like to mention:

In my analysis, I stumbled on the code that controls that behaviour of rolling over defense structures to special. I'll try make a patch so that it works both ways. I think that would top this off nicely.

Also I was playing a lot with MPR stuff before, and I noticed MPR supports multiple resolutions: 640x480, 800x600, and 1024x768. You only need to patch 1 byte in Trek.exe to get it into 1024x768 (I've tested this and it works). Well, if you were replacing the graphics, you'd also have to change a few references to 800 and 600 in Trek.exe, but they're easy to find.

Do you think anyone would be interested in switching all BotF graphics to 1024x768? It would require new artwork and adjusted WDF files. But that way, we'd have plenty screen real estate for many more structures. I'm sure there are some artists in the community who could muster up something nice.

[anjel]

ehem... i´ve been reading for some time... i can´t believe yet what has been achieved here, i feel like a phaser at stun level has hit me thank you very much QD !!!!
I´ll be glad to help, in the graphic area, to enlarge the screen at what size it is neccesary

PS: and i share your feeling about be, nowadays, one the modders of this great game, for years i´ve just been playing it and nothing more else, but now, in my case, making new ships just feel fantastic

[thunderchero]

Nice pic, that's a pretty sweet layout. Do you have those for all the empires, or just feds?

all races here they are

wdf_3.rar

also you need to edit the lexicon 1170 and 218 (special and defense text) just delete the text.

thunderchero

[QuasarDonkey]

I´ll be glad to help, in the graphic area, to enlarge the screen at what size it is neccesary

I guess this means we can start another project. I'll dig up my old notes and post what info I have soon.

Thanks TC, I check it out now.

[thunderchero]

Thanks TC, I check it out now.

I also updated other post with all races images so I have now tested all races with 28+ buildings

thunderchero

[QuasarDonkey]

BTW I had a lot more energy building but most were special so they went off screen and did not go to defense (expected vanilla did this too).

The solution to this could be really simple. Instead of an equal split, say 14 + 14, why not have 0 (if allowed) or 1 defense structures + 27 or 28 special. That way, the defense structures would always go over to special, right?

[thunderchero]

BTW I had a lot more energy building but most were special so they went off screen and did not go to defense (expected vanilla did this too).

The solution to this could be really simple. Instead of an equal split, say 14 + 14, why not have 0 (if allowed) or 1 defense structures + 27 or 28 special. That way, the defense structures would always go over to special, right?

I think for now it is best 14 14

it would really depend on what type of structures the modder adds to his mod some might want defense and some may want support.

this would be better

Some points I'd like to mention:

In my analysis, I stumbled on the code that controls that behaviour of rolling over defense structures to special. I'll try make a patch so that it works both ways. I think that would top this off nicely.

also to this comment

Some points I'd like to mention:

Also I was playing a lot with MPR stuff before, and I noticed MPR supports multiple resolutions: 640x480, 800x600, and 1024x768. You only need to patch 1 byte in Trek.exe to get it into 1024x768 (I've tested this and it works). Well, if you were replacing the graphics, you'd also have to change a few references to 800 and 600 in Trek.exe, but they're easy to find.

Do you think anyone would be interested in switching all BotF graphics to 1024x768? It would require new artwork and adjusted WDF files. But that way, we'd have plenty screen real estate for many more structures. I'm sure there are some artists in the community who could muster up something nice.

I am not sure how many more changes my installer can handle lol

thunderchero