Topic: Hex Editing of Starfleet executables

[TarMinyatur]

I'm able to exploit this bug feature on a 3xPPD hardpoint. I can fire unlimited pulses as long as I press "Z" on every third pulse. Fire a fully charged 3xPPD, press "Z" when the third pulse strikes (instantly recharging the two status "bars"), repeat. I don't know if wavelock is involved here... If you miss with 3+ pulses the fire hose may be turned off.

If you fire while the 4th pulse is on its way, it's too late. The hardpoint readiness gets reduced by one.

(Also found in SFC:CE.)

[TarMinyatur]

StarfleetOP.exe
---
395BF4: OL Disruptor charge cost // 4.0f
---
3977C0: Disruptor charge cost // 2.0f

Firing rate is once per turn. I haven't found the location of the variable that determines the rate.

[TarMinyatur]

OL Fusions, OL Disruptors, and Heavy Disruptors all use the same variable for charge costs!

This can be overcome by adding 3 new variables and by updating the references within these weapon systems' functions. Something more sophisticated than HexEdit, like IDA Free, would be helpful. Finding functions via HexEdit alone is very challenging.

Anyways, here's the offset of that overburdened variable: 395BF4

Any instruction that refers to this variable (currently containing 4.0f) will include the reference F4 5B 79 00.

How do we determine the reference? For Orion Pirates, we do addition. 0x00395BF4 + 0x00400000 = 0x00795BF4. This must be rearranged to F4 5B 79 00 in the binary. The 0x400000 has something to do with the data segment.

[TarMinyatur]

IIRC, SFC OP handles plasma tracking differently than SFC II.  Any way we can figure out how that works?

It seems that Plasma will always seek the center of its target. They do not obey so-called "turn modes". They can instantly change directions, unlike ships. If Plasma, however, had a tight turn mode, a Plas-D might orbit small models, such as missiles or fighters, instead of striking them.

Plasma is better without so-called "lead tracking". They relentlessly whack that crucial #4 shield. If they tracked some point slightly ahead of center, they'd more often strike the more-or-less expendable #3 and #5 shields.

There may be a variable in the game that can modify the seeking point. If I find it, I'll put it in the database. Pseudo Plasma-R seems to lead-track by about +0.2 from center of model.

[Javora]

It seems that Plasma will always seek the center of its target. They do not obey so-called "turn modes". They can instantly change directions, unlike ships. If Plasma, however, had a tight turn mode, a Plas-D might orbit small models, such as missiles or fighters, instead of striking them.

I remember seeing plasma doing that before when a ship speeds up before the plasma hits a WW and then goes back after the ship.  Something I think Taldren got right.

There may be a variable in the game that can modify the seeking point. If I find it, I'll put it in the database. Pseudo Plasma-R seems to lead-track by about +0.2 from center of model.

I always thought pseudo plasma tracked differently than regular plasma in the game.  Even started a thread about it on the old Taldren forum.  Nice to know all these years later that I was right.

BTW has anyone found the missing marine bug yet?  lol

[TarMinyatur]

From Khoromag's release notes of OP 2.525.

"Marines - Mysterious Marine Loss Fix:
Ships with 32 or 64 marines used to mysteriously lose a marine 7 seconds into the simulation. The bugfix required to correct this problem, which was a floating point rounding error, caused all older game films to be unplayable with the new version of the game."

[JanB]

I've managed to make the ultimate shuttle mod (IDA Pro is fantastic!): every race, from Federation to Neutral now has its own shuttle, they'll look for the following objects in the defaultloadout file:

Federation: Federation Shuttle
Klingon: Klingon Shuttle
Romulan: Romulan Shuttle
Borg: Borg Shuttle
Species 8472: Species 8472 Shuttle
Cardassian: Cardassian Shuttle
Ferengi: Ferengi Shuttle
Rakellian: Rakellian Shuttle
Pirate: Pirate Shuttle
Neutral: Neutral Shuttle

You can change these names by opening the attached SFC3exe with a hex editor and searching for the right string. For example say you have a mod with the Dominion instead of Species 8472: you open SFC3exe with a hex editor, search for the string "Species 8472 Shuttle" (without the parentheses) and when you find it you replace it with "Dominion Shuttle....", where the dots (make sure they are represented as 00) are used as padding to make sure everything in the exe file stays in the right place.

I've attached the new SFC3exe, as a bonus it also sets the default game points limit in skirmish from 65000 to 999999.

Have fun!

P.S. Always make back ups before messing with the game and make sure to credit me (JanB) if you use thise modified exe in your mod.

P.S. Now that we know new functions can be created in empty portions of the exe, basically anything is possible, including adding new weapons, but I'm probably going to leave that for someone else to do.

[TarMinyatur]

Quite interesting using IDA. I like how you can generate a chart to see where things come from or lead to.

Let's see what I find.

Thanks

Adding lots of comments (via the semicolon hotkey) as you go through the data segment is very, very, helpful. Even if you're guessing, a comments are good. A 14.0f should get an "Overloaded Plasma-R energy?" comment, for example.

[TarMinyatur]

The IDA will analyze an .exe thoroughly once. After that, it should load quickly. You don't need to re-run the analysis every time. It stores all that info in a database, like StarfleetOP.idb. You load the "previous" database when you want to look at it and add comments. Use HexEdit to make physical changes, as you've been doing. IDA lists the segment address and the absolute address (that HexEdit also uses) in the lower-left corner. It takes practice to accurately keep HexEdit and IDA on the same page, viewing the same byte. There's almost too much information.

It took me at least a week to make any sense of IDA. It only began to be valuable when I was able to add comments in SFC terms and in regular English right next to the data. Only then, would useful patterns emerge...even though the assembly programming language was almost meaningless.

[Corbomite]

In terms of copying weapons. I was originally going to do the phasers but it appears they are more complicated and It'll be better to copy a stand alone weapon such as the PhA or DisH. Seems like a better idea until I can really grasp all this data.

Phasers will be a bit more involved since they have to be slaved to the capacitor, and a particular set of fields in the shiplist, in order to recognize the weapon as a phaser and change the size of said capacitor to charge it with the full amount of energy required. I suppose you could make a stand alone phaser that isn't slaved to the capacitor (like PH-A and PH-B), but it will go down in the pecking order of weapons charged first with available power, and you will no longer be able to manipulate the charge rate in game.

[Corbomite]

Oh, I thought you wanted to create a new weapon. Try a different texture that isn't bound to fx1. ESG Lance or HDisruptor maybe. Even the Mauler texture would do, but that is tied to fx1 right? I guess you haven't found the Tractor Beam graphic sequence yet?

[Corbomite]

Well, Exeter did tell me that the EAW code is full of dead ends because it appeared that they started to create several systems and features that were either abandoned due to time or were setups for later patches/expansions that never came to light. If OP is the same way, a lot of what you are looking at amounts to so much gibberish; in any language.

[Corbomite]

       

[Javora]

Well, Exeter did tell me that the EAW code is full of dead ends because it appeared that they started to create several systems and features that were either abandoned due to time or were setups for later patches/expansions that never came to light. If OP is the same way, a lot of what you are looking at amounts to so much gibberish; in any language.

OP code should be much cleaner than SFC II for the simple fact that OP only had one physical CD disk where as SFC II had two CD disks.  Likely all of that stuff you are describing were removed to cut costs by eliminating that extra CD.

[Corbomite]

Well, Exeter did tell me that the EAW code is full of dead ends because it appeared that they started to create several systems and features that were either abandoned due to time or were setups for later patches/expansions that never came to light. If OP is the same way, a lot of what you are looking at amounts to so much gibberish; in any language.

OP code should be much cleaner than SFC II for the simple fact that OP only had one physical CD disk where as SFC II had two CD disks.  Likely all of that stuff you are describing were removed to cut costs by eliminating that extra CD.

We have absolutely no way of knowing that, but it is a good hope to have.

[Javora]

I remember Eric Bethke bragging about that shortly before OP's release.  Something about cleaner tighter code that allowed them to fit OP on one disk.  That's how I would do it anyway.  Seems like there were extra models to IIRC.

[Corbomite]

Yeah I remember that too, but I always thought he meant that they saved space by giving all of the pirates the same Flintstones interface. 

[TarMinyatur]

Nice work, Adam! I wonder if the Heavy Disruptor's ability to leak through shields is inheritable by other systems. I think I saw a 0.1667 in there. That might be the fraction that bypasses the shields.

I finally figured out the Plasma and Missile speeds for CE tonight.

Plasma uses one of the 32.0f constants. There's a "hidden" +4.0f modifier too. So to get a Speed-32 torp, you need to set it to 28.0f.

Medium and slow missile speeds are odd too. They use signed bytes, which then undergo addition (+8 for slow, +4 for medium) and multiplication by ten.

If you set that byte to 0xF4 (-12), your slow missiles will travel at a speed of -4.0. They don't fly backwards, but they do flee from their targets. Quite amusing.

[JanB]

After testing it; it appears to be the 149.999999f value. It must be shared with others systems.
The phasers don't penteate shields. After a shield is knocked out by regular fire any subsequent weapons fire bypasses all other remaining shields. Doesn't matter how the vessel maneuvers or where you fire from. If the damage roll intended on hitting the target, usually shields, it bypasses the shields and strikes the hull.
The first time I changed the value, I changed it to the further phaser 1 setting which is 760.0f then I removed all changes, then tested it at ph2 limit of 500.0f. Same result. Idk what type of other systems could have bee affected. This one was just noticeable.
Oh well. So much for hoping I could changed the ph3 into a klingon Disruptor beam. Ehh.

Using IDA you can figure out how to create a new variable in some empty spot and point the phaser function to it.

Has either of you had any luck in getting IDA to read something useful from the sprites.q3 file? For me it doesn't recognize any functions or variables, except when I force analyze but then it just produces garbage (trying to interpret strings as functions, etc...) I really want to figure out how and where the exe uses stuff from the sprites file, but so far no luck. I did find out that a lot of the "names" (both words such as "metabigship" and terms such as 57 01) in the sprite file are meaningless (you can change them and nothing happens so they're not crucial to functions and are not locations), which leads me to believe the sprite file is almost all data with no, or a very small number of functions, meaning the exe does all the work.

[TarMinyatur]

Adam, I believe the best way to learn is to directly solve a problem in Orion Pirates. Let's give Overloaded Fusion Beams their own variable for charge cost. They currently share that variable with Overloaded Disruptors. You can't change one without affecting the other. We want to remove this limitation.

The shared variable is stored at 0x395BF4.

Let's find a spot for our new OL Fusion variable...

Using IDA, .rdata:00795BF8 looks good to me.

Using HexEdit, I overwrite those 4 bytes for our OL Fusion Beams as "00 00 80 40". (While I'm there, I can overwrite the next 4 bytes to whatever I want -- such as "00 00 00 00".) The new data has a segment address of 0x795BF8. (Its HexEdit address is 0x395BF8.)

Now I need to find the instruction that loads the shared data. I can search IDA for this series of bytes: D9 05 F4 5B 79 00.

The "D9 05" opcode means "load the value found at" the following address. In our case, it's F4 5B 79 00, the shared segment address in little-endian form. There are only two search-results (out of 38) that make sense for Fusion Beams. One is definitely for setting the charge cost, the other might be for setting the total energy, and thus the rate of fire is mysterious.

Using HexEdit, I modify the instruction at 0xDE898 from D9 05 F4 5B 79 00 to D9 05 F8 5B 79 00.

I'll see what this does...

...Tested in-game. My OL Fusion Beam's charge costs were indeed set to the value of the new variable. They still, however, took one turn to charge. I don't yet know how the instruction at 0xDE990 affects the game.