Topic: Hex Editing of Starfleet executables

[Corbomite]

Adam,

I think this would benefit from more eyes, so I am posting this here instead of in our PM's.

Most of this Hellbore code makes sense (if I got the right code chart and am reading it right), but there seems to be extraneous and/or missing information:


0B 0A 09 08 07 06 05 00 14 11 0F 0D 0A 08 04 00 0A 09 08 06 00 00 00 00 1E 19 16 13 00 00 00 00


0B 0A 09 08 07 06 05 00 = 11  10  9  8  7  6  5  0 = 97%   92%   83%   72%   58%   42%   28%   0%  (all % rounded to nearest whole#) - These are your To Hit chances. The numbers represent what you need to roll on two d6 to score a hit. The "00" may just be a placeholder or represent an absolute miss under the proper conditions.

14 11 0F 0D 0A 08 04 00 = 20  17  15  13  10  8  4  0 - This is normal damage, but again the "00" seems to be a placeholder or represents a miss, but is extraneous if that is taken care of in the chance to hit.

0A 09 08 06 00 00 00 00 = 10  9  8  6  0  0  0  0 - This is half of the damage applied to the weakest shield before the other half of the damage is distributed across the other five, but I don't know why it stops at 6 (and the 6 really should be a 7). It may be that Taldren isn't using all of the SFB specs for some reason. There should be code somewhere that handles the rest of the distribution.

1E 19 16 13 00 00 00 00 = 30  25  22  19  0  0  0  0 - This is overload damage. The last "00" may be a placeholder because it serves no purpose since there is no bracket there. There should also be more information like in the set of numbers above for the division of damage onto the weakest shield, but for OL's. It should look something like this: 21 0D 0B 0A 00 00 00 00 if they are being consistant in their format.

[Javora]

So what happens when you put a value other than 00 in that spot?  Also if I have time I'll try to find my old assembler text books and try to find anything to do with colors and how it handles changes.

[Corbomite]

It may be that PPD, Hellbores and Enveloping Plasma are linked in some way.

The only other in game weapon that uses 2d6 is the Mauler.

[Corbomite]

Remember page 9, I had the values posted. You commented on how lines 64/68 weren't apart of the 2d6 percentages.
I have to check that out later when I come back from work. Maybe it's linked.

These?

64   3C E3 BC D3   0.0278
68   3D AA CD 9F   0.0834
72   3E 2A B3 68   0.1667
76   3E 8E 3B CD   0.2778
80   3E D5 59 B4   0.4167
84   3F 15 59 B4   0.5834
88   3F 38 E8 A7   0.7223
92   3F 55 59 B4   0.8334
96   3F 6A AC DA   0.9167
100   3F 78 E8 A7   0.9723


They're just exactly what Tar said they were. They are the To Hit % for rolling a 4, 3 or 2 on 2d6, i.e. 17%, 8% and 3%. I assume that they are there to account for ECM at long range since HB can withstand a shift of 3 and still hit at range 40.99.

Another interesting thing is there don't seem to be any range brackets. How does it know how far away it's firing? Unless that other jargon does that.

[TarMinyatur]

0A 09 08 06 00 00 00 00 = 10  9  8  6  0  0  0  0 - This is half of the damage applied to the weakest shield before the other half of the damage is distributed across the other five, but I don't know why it stops at 6 (and the 6 really should be a 7). It may be that Taldren isn't using all of the SFB specs for some reason. There should be code somewhere that handles the rest of the distribution.

That is the damage for a Fighter-based Hellbore. Its default maximum range is 8.9, the 4th bracket.

[Corbomite]

0A 09 08 06 00 00 00 00 = 10  9  8  6  0  0  0  0 - This is half of the damage applied to the weakest shield before the other half of the damage is distributed across the other five, but I don't know why it stops at 6 (and the 6 really should be a 7). It may be that Taldren isn't using all of the SFB specs for some reason. There should be code somewhere that handles the rest of the distribution.

That is the damage for a Fighter-based Hellbore. Its default maximum range is 8.9, the 4th bracket.

Your'e right. I'd completely forgotten about them being half strength. Cool, at least you found where we can shorten the range, which I always wanted to do. That leads creedence to the idea that all the multiple shield weapons are somehow linked or in a similar place in the code (I hope).

[TarMinyatur]

Last night I changed every value that may represent the phaser b shield damage. I found (2) 0.333333, (1)0.33 and several 0.3's. I change it to 3 as you mentioned but I found no 45 damage to shield impact.

Maybe Taldren used a 3.0f as a divisor instead of a 0.333 as a multiplier.

15 * 0.333f = 15 / 3.0f

There will be many 3.0f, so you need to search in the code that references the the first row of the Phaser-B damage charts. Look for a divide instruction.

[TarMinyatur]

One instruction out of many is this:

Code: [Select]

fdiv    ds:flt_123ABC

The "f" means use floating-point math (instead of strange integer math in which 5/2 = 2).
The "div" means divide.
The ds:flt_123ABC is where your data is stored, such as 3.0f.
 
It could alternatively be ds:dword_123ABC if your data in IDA is shown as a dword, 40400000h, instead of a float, 3.0.
(I like to turn all the dwords into floats when they make sense. Press "D" in IDA to cycle, "Alt+D" to set up the cycle of data types --- Byte, Double Word, Float.)

So the instruction above would divide whatever is presently stored in the floating-point processor by the value referenced by ds:flt_123ABC. If there is a 15.0f in there already, it will get divided by, let's say, 3.0f. And we get a result of 5.0f.

I'm curious about the Phaser-B so I'm presently looking for that elusive damage modifier vs shields.

[JanB]

I went to work with the race logos again after I got too trustrated looking for the weapon textures controls.

Anyway, I figured out how to work with the textures in sprites.q3m at least the 16 bit ones. A crude Dominion logo (48x48, 16bit) I made can be seen in the attachment.

I'll try to explain the process through the example of this race logo in SFC3.

At offset 03 5F AE EB of the SFC3 sprites.q3 you'll find the following bytes: 2A 0E 00 00 99 00 00 00 00 00 00 00 00 00 0C 2D 00 00 A7 D7 44 03 FF 00 01 00 these control the Federation race logo. 2A 0E is just a name for this particular logo and I'm not sure what all the other bytes do but I do know that A7 D7 44 03 is the address of the image (in reverse, because little-endian, you'll find it at offset 03 44 D7 A7), 0C 2D (again, this is 2D 0C = 11532) is the size of the image plus its "header" in bytes (if you add that to the offset of the image you get the offset of the next image in sprites.q3).

Now since we do not want to move stuff in sprites.q3 we are going to add a new image to the end of the file and direct the control byte address to it. We can create crude images ourselves even without access to the custom color palette of the sprites.q3 file (see EDIT 2, below). We now to add 22 null characters (00) to the end of sprites.q3 (this will come in handy later). The next byte would be byte 03 61 5C AC so we go back to our 2A 0E control area and change A7 D7 44 03  into AC 5C 61 03. In crude drawing style we just need 48x48 pixels x2 (because 16bit colors take two bytes) = 4608 bytes for the image itself, plus 20 bytes for the header, but the game will want more (probably related to the custom color palette thing), so we actually need something like 4800 bytes, plus 20 bytes for the header. So in the 2A 0E control section we change 2D 0C into D4 12.

Now we must set up the header. Starting from byte 03 61 5C AC we type in: 30 00 30 00 18 00 18 00 00 00 10 00 FF 00 01 00 C0 12 00 00 The 30 00 30 00 part tells the game the image is 48 by 48 pixels, the 18 00 18 00 part tells the game to center the image at its center (24,24), 10 00 tells the game it's a 16but image, 01 tells the game to use some form of RLE compression that happens to work for our scheme (sadly, just choosing 00 doesn't make the game accept normal, uncompressed bitmap images), the C0 12 part just means 4800 bytes will follow the header (if you set this too low the bottom part of the image won't be rendered, it has to be larger than 48x48x2=4608).

We're now ready to construct the actual image. We must select 4800 bytes of data from somewhere in the sprites.q3 file (or any other binary file), copy and paste it behind the header we just made, then turn all the bytes into FF (FF FF makes a pixel black, not the usual 16bit color palette, but we can work with it). Because we've conveniently placed 22 null characters between the original end of the file and the image header the beginning of the image will align with the right side of the screen when we set the number of columns in our hex editor to 96. We can now start to "paint" our image: the first two bytes beyond the header are the pixel in the upper left corner of the image, every row of 96 bytes is exactly one row of 48 pixels in our image. I found that 0F 0F gives greenish color, and 0D 0D a blueish color, these are the only colors I used to create the image in the attachment.

And we're done!

EDIT: I found that FF 30 gives a nicer Dominion shade of purple, replace 0D 0D with it. Also 1F 00 works as deep blue, when you need that for another image.

EDIT 2: I found a program that produces images that can almost directly be put into sprites.q3. GIMP (available for Windows and Linux) allows you to export images as 16 bit BMPs with the X1 R5 G5 B5 advanced option. With compression set to 00 or 01, sprites.q3 will accept this, including the color palette, but you still have to vertically flip the image first and you have to move the color palette generated by GIMP to the back of the data. For a 64x64 16bit bitmap GIMP produces a file of 8330 bytes, you can work on it with a hex editor. The first 54 bytes are a bitmap header that you should not copy into sprites.q3 (which uses the custom 20 byte header header system I explained above), the next 84 bytes are the color palette, you should cut this and paste it at the back of the file. The actual data consists of 8192 bytes. Copy everything except the header (so 8276 bytes and paste it after the custom header you made at the end of sprites.q3. Of course the header should be adjusted for a 64x64 image size, centered at 32,32. The data size should be set to 8276 bytes (so for example change the C0 12 from the above example into 54 20). The compression byte should be set to either 00 or 01, but not 02. The control section (2A 0E in our example) needs to be updated too, so going with our example, turn D4 12 into 68 20.

This should work for all the 16bit images in sprites.q3, and in principle all 8bit images (some of the map icons and buttons, I believe) could be replaced by 16bit images if those are placed at the back of sprites.q3.

The result of this latest successful experiment can be seen in the second attachment, enjoy!

[JanB]

Changing all the 9A 99 99 3E into 00 00 40 40 has an effect on the appearance of Federation phasers in SFC3, thanks for the tip!

EDIT: it ONLY affects Federation phasers, it's caused by the 9A 99 99 3E at 00 44 BA A0 (00 84 BA A0 in IDA).

[JanB]

Well, in SFC3 there are a lot of functions referencing that value, usually multiple times per function. In SFC3 it changes the spread of the constituent color beams that make up a normal phaser. I took multiple screenshots and definitely saw that there are two kinds of color beams: a thin yellowish beam and several thicker orange beams with color
EF5921 (this color was very consistent among the beams), but that code (as well as its little endian equivalent) is nowhere to be found in either SFC3.exe or sprites.q3. They may be using 16bit or 256color colors or they've done something mean like picking a different color and then adding some value to it to get EF5921 (now that I think about it using a 256color color is pretty mean as well, we'd be looking for a single byte of data).

[JanB]

Yeah, it's a pain...

I did just find the range limit for starbase weapons: 00 80 18 44 (610.0f) at 00 44 6D 08, but then again I never looked for it before. Right behind it there is 00 00 B4 43 (360.0f), the range of primary ship weapons.

[TarMinyatur]

Worked on range validation functions tonight. The maximum range of the Light Hellbore and Light Fusion Beam are determined by offsets from the first element in the range table (an array of brackets). Hydran Hornets will fire their newly offset Hellbores at ranges greater than 8.9 if the damage table has non-zero values in it. Hydran Wasps, however, seem to have another layer of code that prevents them from firing their Fusion Beams beyond range 2.9, even if the 4th bracket is enabled.

For the first time, I moved a small chunk of code in Starfleet2CE. It was only one byte downstream to replace a 2-byte command with a 3-byte command. A unused flow control in the subroutine provided room for the tiny expansion. I needed to adjust the chunk's references by -1 byte. Seems to be ok.

Another odd thing in CE... H-Wasp.III's are the only fighters not available in Late Era. To enable them, I reduced their year first available from 23 to 19 in ftrlist.txt.

[TarMinyatur]

I changed the value that is multiplied by 4 to calculate the offset to the desired bracket.

Let's say we're looking at Light Hellbore brackets...

0x1234  HB_Brackets dd  10.0f   // Only the first bracket has a reference to the Hellbore's range validation function
0x1238                    dd  20.0f   // 2nd is at +4 bytes
0x123C                    dd  50.0f   // 3rd is at +8 bytes
0x1240                    dd  90.0f   // 4th is at +12 bytes (Normal limit for Light Hellbores)
0x1244                    dd  160.0f  // 5th is at +16 bytes (Let's say we want this one instead...)
etc.

When we look at that external reference, we'll eventually find instructions to get the data of the 4th bracket, via +12 bytes. It helps to give your charts recognizable names in IDA, like HB_Brackets.

mov  ecx, 4   // Load ecx with 4.
imul  ecx, 3    // Multiply ecx by 3, to get 12.
mov  edx, [ebp+var_4]     // Load some sort of reference.?
movss  xmm0, dword ptr [edx+0DCh]   // Load current range.
comiss  xmm0, HB_Brackets[ecx]   // Compare current range to HB_Brackets[+ 12 bytes].
jb short loc_5678  // Jump to loc_5678 if current range is less than the calculated bracket's value.

loc_5678:
xor eax, eax   // Set eax to zero. Which means the range is valid, it has zero restrictions, and the Hellbore can fire.

So if I change that imul instruction to "imul  ecx, 4" we'll get a result of 16, for an offset of 16 bytes. I do this through HexEdit, and change 6B C9 03 -> 6B C9 04. The new max bracket will be the 5th; Range 9.0 to 15.9.

(Edited to hexadecimal memory addresses)

[JanB]

I can now say with near certainty that sub_500AC3 controls the Federation phaser graphics in some way in SFC3, no other weapons seem to be affected by it. It is a long function, but it does contain the crucial link to 9A 99 99 3E at 00 84 BA A0, the only link to that location that actually affects the Federation phaser beam spread. Changing the only rdata piece that (indirectly) calls this function only affects Federation phasers (the game crashes when you fire them).

[TarMinyatur]

Adam, I haven't found the Point Defense subroutines. I don't know how to stop the AI from using Wild Weasels. Been busy isolating variables...amazing how many systems share a particular 2.0f.

In theory, the AI could be instructed to never fire Phaser 1's and 2's at Plasma unless no enemy is within, let's say, 15 hexes. This would be a great enhancement. The AI should simply assume that a torpedo is fake (let's say 75% of the time) on Admiral level, and ignore players' Psuedoes.

New players (and the AI) can also be vastly helped by changing the maximum range of the Phaser-3/G from 15.9 to 2.9 (or even 1.9). It is a long overdue change. Not even the AI should be so inefficient and reckless.

[JanB]

I didn't get any further on the phaser thing. I've turned my attention to the only other hex-editing side project I haven't completed yet: fixing the "bug" (though from the help menu in campaign mode it seems like they planned it that way, but why?) of SFC3 not showing separate map symbols for DD and BC hull type ships (it also uses the F symbol for shuttles but shuttles never show up on the map so I don't care). The symbols are in sprites.q3. I found that sub_559C84 assigns the ship symbols (it pulls them from sprites.q3 via byte_F7D1E8). This function is told by some other function or something that it should give DD and CL ships (or CA and BC) the same map symbol. Hull types are stored near 00 97 CA 94 in IDA, or 00 54 CA 94 in a hex editor (there is also an identical set of definitions a shrt distance below it, but that doesn't influence anything), which is referenced by sub_6B018D. Sub_6B018D definitely pulls these definitions (from SH until NONE) using a loop, but alas it is also not the function that tells the game to use the same symbols for DD and CL, nor is it the function that tells the game which hull types can be used as ships (so no listening posts, defense platforms, etc...) I cannot just simply turn all destroyers from DD into BIO (which would work in principle, they'd get the "M" map symbol but I can easily change that to the "DD" symbol in the MetaBigShip section in sprites.q3) because I haven't found the function that determines which  ships are available to players and AI in campaign mode (and the vessel library). How can something so simple be so deeply hardcoded...

[TarMinyatur]

Fixed a very old, but never documented, bug tonight. Unique among weapons, OL and SOL Fusion Beams would always do zero damage if fired at range 8.01 to 8.99. The code uses 80.0f instead of 90.0f to enforce a restriction on the methane-breathers' weapon. There was already a maximum range limit for OL, and I've recently enabled one for SOL.

Many years ago, in the early days of EAW, a player (whose name I've forgotten) advised me how to win as Hydran with neither Hellbores nor Hornets, but with abundant Fusion Beams. The strategy involved the frequent use of OL Fusions at ranges greater than 6 exclusively upon the opponent's rear shield. Well, this never worked for me, in part, because I figured 8.9 was as good as 6 or 7 (or better because reinforcement/ECM tended to decrease as the opponent accelerated to get to the safety of range 9+.

Well, now your overloads will be true to range.

If Phaser-3/G's were limited to range 1.9 and tractors grabbed at 1.9 (instead of 2.5), the performance of the Hydran AI would be significantly affected.

[TarMinyatur]

The unofficial 2.671 patch will include the bugfixes that I've posted in this thread.

I believe two enhancements should be included:
Warp Tacs -- Ships at speed 4 can turn approximately 240 degrees per standard cycle. Warp Tacs are helpful if you're low on power or have dropped a WW.
Sane Phaser-3/G's charts -- maximum range of 2.9.

Of course, each can be restored to historical values by changing the floats.

But changing the tractor engagement range is too big of a change to be considered vanilla. Same goes for limiting Phaser-1's and Phaser-2's to range 15.9 and 8.9, respectively, or for reducing the speed of WW's.

I'm wondering, however, about increasing the PD range of Phaser-1's and Phaser-2's, something I discovered how to do tonight. It is difficult to protect another ship with PD phasers unless you're almost in the same spot. If you want your PD to only activate close up, you can hit the PD hotkey when a threat is at range 1.9. Fleets with AMD have a pretty good common defense with little effort, but for those fleets without it, they can struggle. Manual PD is a chore, often impractical at typical game speeds, and it's bugged by the host's ECM.

Many 3v3 battles would have had different outcomes if automated PD was able to reach a little further. T-bombing your wingman isn't ideal, but it has been done when neccessary. All this needs play-testing.

[Corbomite]

I'm all for making the AI smarter about certain game functions, but I am not for doing it by way of limiting the players' options to do it. Phasers work the way they do. Deciding not to fire stupidly is a player decision. Sometimes you do  want to fire a PH-3 at range 15, however rare an occurance it is and regardless of whether it is a good shot or not. If the PD routines could be modfied w/o hampering the live fire options of phasers, then I say go for it.