Topic: Hex Editing of Starfleet executables

[TarMinyatur]

The Marine Combat chart in Community Edition (and probably OP) has the data for the X-axis switched with the Y-axis.

The correct 2D array is 10x6 integers.

Marines
#  |-------1d6--------|
1:   0, 0, 0, 0, 1, 1
2:   0, 0, 1, 1, 1, 1
3:   0, 1, 1, 1, 2, 2
4:   0, 1, 1, 2, 2, 2
5:   1, 1, 2, 2, 3, 3
6:   1, 1, 2, 2, 3, 4
7:   1, 1, 2, 3, 4, 4
8:   1, 2, 2, 3, 4, 5
9:   1, 2, 3, 4, 5, 5
10:  1, 2, 3, 4, 5, 6

The flawed chart, rearranged to 10x6, works this way:

Marines
#  |------1d6-------|
1:  0, 0, 0, 0, 1, 1
2:  1, 1, 1, 1, 0, 0
3:  1, 1, 1, 1, 1, 2
4   2, 2, 0, 1, 1, 1
5:  2, 2, 2, 2, 3, 3 // 5 boarding parties benefit from this chart...
6:  0, 1, 1, 2, 2, 2 // ...while 6 boarding parties are relatively penalized
7:  3, 3, 4, 4, 1, 1
8:  2, 2, 3, 3, 4, 4
9:  5, 5, 1, 1, 2, 2
10: 3, 4, 4, 5, 5, 6


The average damage of both charts is similar, but the repaired chart removes some oddities. On the high end, a group of ten marines will cause 1, 2, 3, 4, 5 or 6 casualties instead of 3, 4, 4, 5, 5, or 6. Anyway, at least the chart  will be working as intended in 2.674. The effects of capture, however, still need a lot more work.

[d4v1ks]

Ideally, the 86 or 87 should always be represented as an 86 or 87. I changed an Intel opcode there, not a countable variable. Converting 0x86 to an unsigned byte 134 or to a signed byte -122 is just asking for trouble.

The following offset entry is what I'd like to see:

6902D: 1umb // Capture enabled = 86, Capture disabled = 87 // 86

The editor would display it as an unmodified byte.

Ok, so this morning i took a look into that feature.
It introduces a new type (opcode) and a number base (binary, octal, decimal and hexadecimal).

So if you wish to add an offset with a opcode, base 16, you should write something like:

1234 : 1 op // True (9A), False (BC)               or                    1234 : op // Opcodes: (78/9A)

(op type use base 16 by default, all the others default to base 10.)

In this case the UI will show the opcode in hexadecimal and only accept an value that exists on the description. The values must be declared there (it makes no diference how you do it), but must be enclosed between parentheses.

So, theres a lot of options right now.

If you people have time, maybe you can test this new version a little, to see if you can discover any bugs, loading and saving diferent types, number bases, rows and columns combinations. As it edits directly your *.exe, you will want to test it!
The format is:

            Offset : [[Rows x ] Columns] Type [Base] [ // [Description] [ // [Tooltip]]]

[ ] = Optional arguments
Offset = hexadecimal memory address
Rows/Columns = Must be numbers above 1
Type = b (int8), ub (uint8), c (utf8 char), op (byte), s (int16), us (uint16), u (utf16 char), i (int32), ui (uint32), f (32bit float), l (int64), ul (uint64), d (64 bit float)
Base = 2 (binary), 8 (oct), 10 (decimal, default), 16 (hex)

(op requires a description with valid values, enclosed between parentheses, to work.)

In theory, it should work with little and big-endian machines...

 

[TarMinyatur]

Thanks for enabling the opcode type, Carlos.

I found a minor problem...

177EA7: op // Phaser-3 PD vs Non-Plasma, first bracket (0) or other bracket (4) // 0

The type-tester will allow a "3" because it happens to be in the description. I can change Phaser-3 to Phaser-III to avoid the arabic numeral.

Perhaps only values that are enclosed by parentheses should be valid for opcodes, such as (0A, 0B, 0C) or (0, 4).

[d4v1ks]

177EA7: op // Phaser-3 PD vs Non-Plasma, first bracket (0) or other bracket (4) // 0

The type-tester will allow a "3" because it happens to be in the description. I can change Phaser-3 to Phaser-III to avoid the arabic numeral.

Perhaps only values that are enclosed by parentheses should be valid for opcodes, such as (0A, 0B, 0C) or (0, 4).

Its a good idea. Yesterday, i don't even had thought in this kind of problem.
So, i added your ideia and fixed it.
Thank you.

----------------------------------------------------------------------------------------------------------------------------

SFC Editor 1.3.3 http://1drv.ms/1zE7Dvr

I think the program is stable by now.
A new option was added to the format:

            Offset : [[Rows x ] Columns] Type [Base] [r] [ // [Description] [ // [Tooltip]]]

[ ] = Optional arguments
Offset = hexadecimal memory address
Rows/Columns = Must be numbers above 1
Type = b (int8), ub (uint8), c (utf8 char), op (byte), s (int16), us (uint16), u (utf16 char), i (int32), ui (uint32), f (32bit float), l (int64), ul (uint64), d (64 bit float)
Base = 2 (binary), 8 (oct), 10 (decimal, default), 16 (hex)
r = Restricted mode. The values are limited to the values enclosed by parentheses in the description.


For example, with this new format, the following 2 lines are equivalent:

    1234 : 1 op // (A1, A2, A3, A4)
    1234 : 1 ub 16 r // (A1 to A4)

Changes (v1.3.3):
    - The way how the UI validates data at the moment is a little different. Values are only validated when you leave the text box (when it loses focus). The application will hold until you introduce a valid value in the box.
    - When the UI loads the offsets in the file text, if it finds some problem it will still load, but it will disable that text box (will appear as a grey box). It can happen when you try to load a char (utf8 or utf16) that is not supported (charcodes <= 31), or when you try to load a restricted type with a value that is not declared in the description, or when you try to load an offset out of range.

[TarMinyatur]

I found a bug with the new version. The first parentheses must be followed by a space, otherwise that adjacent value will hang the application.

Bugged...
06902D: op // Capture Enabled (86) , Capture Disabled (87) // 86

But this is OK...
06902D: op // Capture Enabled ( 86) , Capture Disabled (87) // 86


 

[d4v1ks]

Fixed 

ps: I also added 2 new notes to the end of my previous post.

[TarMinyatur]

Excellent. You've created a great utility, Carlos. Everything seems to be working properly.

P.S. I've updated the offsets.txt for 2.673 to take advantage of the enhanced value-checking functions of the SFC Editor 1.3.2.

The file now includes descriptive tabs, such as "Missiles", instead of the number 12 or something.

[d4v1ks]

Made a little cosmetic update to SFC Editor.
The purpose was to make offsets' descriptions, in restricted mode, be more readable.

For example, now instead of adding a line to "offsets.txt" like:

0 : ub r // Photon Range (0, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 13)

You can just write:

0 : ub r // Photon Range (0 To 13)

And it will force the user to choose a value between those 2 numbers.

Happy modding. 

[TarMinyatur]

Please test this Unofficial CE 2.674 Beta.

Attempts to capture fighters should result in this message: "Cannot beam to this target."
All units that have the "NT" special role in shiplist.txt should continue to be immune to transporters.

Try to capture or beam spare parts to and from planets, shuttles, probes, missiles, etc.

EDIT: 2.674 Beta crashes. The AI tries to capture fighters even though I have made it impossible to do so in one subroutine. Another capture function must be involved. I haven't found it.

[JanB]

JanB,

So I messed around with sub_41C983. Changing the 04, 08, and 12 to 00's. It made the heavy phasers appears like traditional phasers. But the Phasers colors remained the same. Only the appearance changed to that of regular phasers.

I think you have to edit sub_41C271, but to be honest I've had mixed success with this whole thing it in SFC3 (it doesn't work for all weapons: it worked splendidly on the shield inversion beam but when I tried it on the phaser I changed the shape of photon torpedoes instead), so it's not the whole story.

I solved the problem for my own purposes by exploiting the "BlueLight=1" trick (only exists in SFC3), and changing the coding in sub_41C726 (SFC3's equivalent of sub_41C271) to apply the effect to uneven numbered phasers and the normal phaser effects to the even numbered phasers, this got me 5 blue phasers and 5 orange ones, with both groups having one starbase weapon.

P.S. somestimes the values you have to change are referenced as flt_123456, so they are actually located outsode the function.

[EschelonOfJudgemnt]

So, what, now you guys have a cool widget so no more updates?

Some of us were enjoying reading about what you were trying to change!
 

[TarMinyatur]

EoJ,

Unfortunately, one gathers the low-hanging fruit quickly. Climbing a massive tree, while nearly blindfolded, to reach the laden branches does indeed take a while.

I am presently vexed by the AI's attempts to capture, which results in an unpredictable, but eventual, hung window. I'd prefer a crash to desktop -- it would be easier to fix!

[JanB]

I'm still trying to figure out how to get separate ship symbols on the map for destroyers and light cruisers (or heavy cruisers and battlecruisers) in SFC3, but I'm probably not going to solve that one...

I did figure out how to change slow phasers into fast phasers in SFC3. I found the function that sets the kind of medals each race gets during their campaigns (but you're limited to fed, kling, rom or borg medals). I looked for stuff that could make more than 4 races show up in the vessel library and have more than 4 races be able to buy ship systems and bid on ships during campaigns but I couldn't find those functions.

Oh and I found out how to run SFC3 on Windows 8.1 (you have to download d3d8.dll and place it in the game's main directory, if you then set windowed to 1 in the sfc.ini the game runs under Win 8.1).

I'm winding down my efforts on this, it's taking more and more time to find interesting stuff and I've accomplished most of the things I set out to do when I started hex editing the game (like I said, I probably won't be able to fix the ship symbol thing, and I knew from the beginning it would be next to impossible to add more players or raceslots to skirmish mode or to make fully functioning campaigns for more than 4 races and it turns out I was right).

[Corbomite]

The AI does indeed seem Boarding Party happy. The marines go out (even to fighters, monsters and other non H&R/Capture elegible targets), but I'll be damned if I know what they are doing. I can't remember losing one system to an AI H&R raid... ever. They aren't there to capture either as that would show up in the Security MFD.

[EschelonOfJudgemnt]

I'z jus teasin' ya guys!

Keep up the good work!!!
 

[TarMinyatur]

E8 = opcode to call another function
E4 24 0D 00 = relative starting address of that function (not including the 5 bytes for this instruction -- E8, E4, 24, 0D, 00)

D24E4 + 5 = D24E9 ; Total displacement

Look for a function starting at +D24E9 bytes (+861,417 bytes in decimal) from the address of the caller.

After that function is called and resolved, the next instruction to be executed will be the line that follows "call sub_4EE92F". I say "and resolved", because the function at +D24E9 bytes will probably call other functions, which call other functions, which call other functions...

[JanB]

Adam, I change function calls by copying the oine of the cursor call, then placing the cursor on that line and then edit->patch->program->assemble, copy paste into the window and change the function number, then click ok. This will automatically fill in the correct bytes.

Congrats on the weapon colors, but before you go copying functions, etc... (when you do copy a function you have to adjust most of the calls because the locations will be off) check for crosslinks: for example I got the fed phaser to use the rom disruptor beam shape, but with the phasers' texture and functions, so I could change the color of the fed phaser but then when I played against Romulan ships the moment a Romulan disruptor was fired all Federation phasers changed to the Romulan disruptor color. This was in SFC3 but similar stuff could happen in SFC:OP as well.

[TarMinyatur]

I noticed in Orion Pirates that a standard (or overloaded) Phaser-X cannot be manually fired at a Plasma torpedo. It isn't a very serious bug, but it is odd.

[Corbomite]

OL Phasers can't be used for PD, but they work on normal setting. I've never tried firing normals manually.

[Corbomite]

Tar, try cycling the PD hotkey between normal and OL after setting the phasers to OL. I've noticed that X-Phasers on normal won't initially fire as PD when set to OL and just turned off once.