Topic: Hex Editing of Starfleet executables

[Corbomite]

You can control HET % and bonuses manually through the shiplist.


On another completely different topic:

Is it possible to hex edit a mission?

The HET% is bugged when set low. It actually goes up after a ship suffers a breakdown.

23rd century duct tape is just that awesome! 

Perhaps you could try an experiment where all ships are set at 83% with the recharging HET bonus and at 100% with the two bonus that doesn't. Then HETs become valuable, but riskier after time. Plasma would get a boost out of that (especially on a small map; D2 IDK) and then your slower plasma idea might have more merit to my mind.

And Tar, please don't feel like we are arguing with you or being dismissive about your proposals, but they must be able to stand up to spirited debate or what's the point of posting them?. Some theories need to be well play tested before they can be called good. One person can rarely think of everything when a change is implemented.

Also, since you guys are putting out patches and other tools, sometimes it is hard to discern right away whether you are tinkering or "fixing" for release. Perhaps preface some of your ideas that fit with "This is just an experiment. Try it out".

[TarMinyatur]

Perhaps you could try an experiment where all ships are set at 83% with the recharging HET bonus and at 100% with the two bonus that doesn't. Then HETs become valuable, but riskier after time. Plasma would get a boost out of that (especially on a small map; D2 IDK) and then your slower plasma idea might have more merit to my mind.

That is a good experiment. Wouldn't the values be 83% (regenerative) and 116% (one-time bonus)? Not that it makes a difference, except that your 1st HET can be done at 100% with the 16% Erratic Maneuver penalty in CE.

Then the ship regenerates from 50% to 83% in about 7 turns. HETs would be risky, indeed. 

Also, since you guys are putting out patches and other tools, sometimes it is hard to discern right away whether you are tinkering or "fixing" for release. Perhaps preface some of your ideas that fit with "This is just an experiment. Try it out".

Right, this thread started as hacking, but it developed into the unofficial patches. So I can see how experimental Omega Sector stuff could be mistaken for upcoming material for the regular game. But I'm not going to start a new thread specifically for Hex Editing of vanilla SFC. This topic is about adding options so that players can customize their games conservatively or radically. That will continue.

Look for the 2.678 Patch topic someday. 

[TarMinyatur]

Well, all I want is to make more maps for the Ion Storm skirmish. I was always peeved that they only gave us that tiny map. Barring placing more maps, I'd like to make the one map a medium map.

If you could make an editor that can do simple stuff like change terrain and maps that would go a long way. There are a lot of missions out there that could be spruced up a bit without heavy lifting.

Mission maps are, for lack of a better word, compressed. This makes hex-editing them a pain. You can add nebulae reliably (it's one character), or rocks but the results are not always what you expect. I think you can add ion storms to a larger map. I don't remember the character for ion storms...but it'll be in the tiny map.

[Corbomite]

Ion storms are weird. Apparently you can lay down one, a few or a ton like in the stock script. There are smaller ones in the Coop Ace script and Karnak used a few placed ones in some of his scripts. I don't know how they get them to clump. Perhaps each ion storm overlaps it's neighbor just a bit.

[Corbomite]

And your tinkering got me thinking and I might try going the other direction an make plasma speed based on size with sort of a drone feel.

R = Speed 32 - Extra large warhead, slow speed and excellent duration.

S = Speed 36 - Large warhead, medium speed and good duration.

G = Speed 38 - Medium warhead, fast speed and moderate duration.

F/I = Speed 40 - Small warhead, very fast speed and low duration.

X = Same as stock and I say it's just an up-jumped F Torp which explains it's speed, lack of special settings and early decay rate.

D = 45(ish, maybe faster, I'll have to play around) - These suckers are useless against fighters right now if they are flying away from the torp, which is a lot. Drones will die a bit faster, but since they fire too many anyway and the drone is obliviously flying to it's doom, it doesn't really affect that much on that front.

EDIT: I knew something didn't sound right. F and G torps are speed tied. I'll have to think some more.

[TarMinyatur]

Corb, if you reduce the speed of a Plasma torp, you have to increase its endurance. I don't think that data has been found in OP yet. Or maybe it does so automatically? I forget.

If I make a speed-18 PlaS in Community Edition, it will burn out at range 13. So I need to increase the endurance from 26/36 to 26/18. That 26 in the numerator is the SFB range in hexes (25) plus 1 to account for SFC's 0.99 typical range extension. That 18 in the denominator is the custom speed. Then you literally get a half-speed PlaS. Stationary targets just have more time to sweat.

The variables to find will be:

X = ~24.1/40 = ~0.6025
R = 31/36 = 0.8611
S/E = 26/36 = 0.7222
G = 21/36 = 0.5833
F/I = 16/36 = 0.4444
D = 16/36  = 0.4444

[Corbomite]

The plasma ranges are in the OP Editor, but the 3rd and 4th brackets say they are they same (both 15.9). Is that right? Why would you need two inputs for the same range value?

[TarMinyatur]

If you don't have these entries in your OP offsets.txt, here you go:

397A50: 1d // Plasma-R endurance {range/speed} // 0.8611
397A48: 1d // Plasma-G endurance {range/speed} // 0.5833
397A40: 1d // Plasma-F/I/D and Dro-D endurance {range/speed} // 0.4444
397A38: 1d // Plasma-X endurance {range/speed} // 0.6200
397A30: 1d // Plasma-S/E endurance {range/speed} // 0.7222

Lots of shared stuff. The 16 hexes (for 15.99k) would apply to Plasma F, I, D and the bugged Dro-D.

So if I want a true SFB Plasma-R, I would decrease the speed to 32 (320.0) and increase the endurance to 31/32, which is ~0.9688. If I don't do this, the PlaR will run out of gas at about 27.5k instead of 30.9k.

[Corbomite]

No, I mean in the editor the description says if you want 15.9 to use a 3 in the field. Then it says if you want 15.9 to use a 4. Why does it need two integers that do the same thing. Why not just use the 3 all the time?

[TarMinyatur]

The Plasma types each have a magical internal ID.

R = 0
S = 1
G = 2
F = 3
I = 4
D = 5
X = 6
E = 7
Dro-D = 40

Then they are assigned incrementally to a range via a table.

.text:0041E5F2                 db    0   ; R ; +0 bytes       
.text:0041E5F3                 db    1   ; S ; +4 bytes
.text:0041E5F4                 db    2   ; G ; +8 bytes
.text:0041E5F5                 db    3   ; F ; +12 bytes
.text:0041E5F6                 db    3   ; I ; +12 bytes
.text:0041E5F7                 db    4   ; D ; +16 bytes
.text:0041E5F8                 db    5   ; X ; +20 bytes
.text:0041E5F9                 db    1   ; E ; +4 bytes

These numbers on the left are used to find the correct offset. They are multiplied by 4 to calculate the displacement for each Plasma type in a "jump table". Each offset is 4 bytes apart. So PlaR jumps to the first offset (+0 bytes). PlaS jumps to the second offset (+4 bytes), the same as PlaE. PlaF and PlaI jump to the same offset at +12 bytes. Etc. 

It is highly confusing. These calculated offsets are links to locations within the function.

.text:0041E5B6                 dd offset loc_41E164   ; +0 bytes, jumptable 0041E15D case 0 ; PlaR
.text:0041E5BA                 dd offset loc_41E26E    ; +4 bytes, jumptable 0041E15D cases 1,7 ; PlaS,PlaE
.text:0041E5BE                 dd offset loc_41E1B8    ; +8 bytes, jumptable 0041E15D case 2 ; PlaG
.text:0041E5C2                 dd offset loc_41E1F9    ; +12 bytes, jumptable 0041E15D cases 3,4 ; PlaF, PlaI
.text:0041E5C6                 dd offset loc_41E201    ; +16 bytes, jumptable 0041E15D cases 5,40 ; PlaD , DroD
.text:0041E5CA                 dd offset loc_41E243    ; +20 bytes, jumptable 0041E15D case 6 ; PlaX

[TarMinyatur]

And your tinkering got me thinking and I might try going the other direction an make plasma speed based on size with sort of a drone feel.

D = 45(ish, maybe faster, I'll have to play around) - These suckers are useless against fighters right now if they are flying away from the torp, which is a lot. Drones will die a bit faster, but since they fire too many anyway and the drone is obliviously flying to it's doom, it doesn't really affect that much on that front.

I isolated and implemented speed-64 PlaD tonight. This feels proper. SFB be damned. 

PlaF and PlaI still use speed 36. There's no technical reason PlaD can't go faster (or slower) for a mod.

If you want to try it out, put these lines in your OP offsets.txt, Corbomite:

397F30: 1d // New! Plasma-D and Dro-D endurance {range/speed} // 0.4444
1E203: 2op // New! Plasma-D and Dro-D pointer; old (40 7A); new (30 7F) // 30 7F

You'll need to overwrite the pi filler for the initial endurance value. Then adjust the pointer to find it downstream.

I assume you'll check it for default behavior as I did. After that, set the PlaD speed to 72.0 and the PlaD endurance to 0.2222 and you've got double speed, but regular range and damage. Or you could do speed 45.0 and 0.3555 endurance. Or any speed entry, such as 64, that has endurance of 16/speed, which is 0.25 in this case.

[Corbomite]

Once I figure out what all that means I will try it.

[TarMinyatur]

StarfleetOP.exe
I found a possible conflict in the OP offsets.txt.

39E5D4: 1f // Transporter range x10 for Raiding, Capturing, and beaming items // 59.999

Two functions read this data. Only the first one is related to transporter range.

Add these lines to OP's offsets.txt:

39E5E8: 1f // Data isolation from transporter range. Change to 59.999. // 59.999
11BD59: 1op // New pointer for isolation. Change (D4) to (E8) // E8

These have been added to the revision of StarFleetOP.txt. Found in the SFC:OP HD stickied post.

This will alllow you to create a 59.999 for that second function -- which appears to be unrelated to transporters. This function might be for the AI's Phaser-1, such that it prefers 5.99k. Just a wild guess, at this point.

[Corbomite]

You should really just collect these and release a new offsets.txt.

[TarMinyatur]

Tar, do you have a copy of the OP offsets and if you do have you been systematically updating it as new things develop.

I have decided to primarily work on Community Edition. Unless someone has a specific question about OP, I'll rarely be looking at a game for which the source code has been forever lost. CE has the potential to incorporate the best of OP...and it's burdensome to duplicate my efforts on OP (or triplicate them with SFC3). Perhaps it is selfish, but I don't have unlimited time to devote to EAW/OP/SFC3 -- which I don't play.

I'll add the new offsets for an updated OP offsets.txt. It won't be part of an executable/graphics patch. Offsets.txt has the potential to be updated at a much greater frequency than .exe patches as TAnimaL and others find associations between data and game mechanics.

[TarMinyatur]

You should really just collect these and release a new offsets.txt.

Done.
https://onedrive.live.com/redir?resid=AA9122667945A037!334&authkey=!AMRavJ5zzUlJtNE&ithint=file%2ctxt

With the latest patch, Carlos has cleaned up the installation. So now there is a new folder for tool assets called SFC_Editor in the root folder. The generic "offsets.txt" has been given a more descriptive name, "StarFleetOP.txt".

The path will be something like C:Games\Orion_Pirates\SFC_Editor\StarFleetOP.txt

[d4v1ks]

Fear not, i still got some energies for SFC OP.

Today i went a little beyond the common hex-editing and wrote an entire function for OP that enables it to choose randomly a "skybgnd-mono" texture from a path.
I limited it to 15 atm, but it can be any number you wish.

The path will be: ".\Assets\Textures\skybgnd-mono\"
And the they will be named: "0.bmp", "1.bmp", etc

To get space for that function i had to remove something from OP.
So i decided to remove the 2 little functions that write a log into "WeaponDamage.txt".
As it seems, each time you fired something, the program would open that file, append something and then save. That could cause some lag, so i traded this feature for that one.

[Corbomite]

Wow!!

So this does this in game each time you go into a nebula?

I believe that WeaponDamage.txt is probably a leftover dev tool like vollyinfo. I have never understood why we needed that file. Play will tell however.

[d4v1ks]

So this does this in game each time you go into a nebula?

Yes, it is random.

Edit:

The function generates a random number and then loads the exact texture, by name, when you start the game.
It looks like it continues to use the same texture while you play a campaign...

[d4v1ks]

It looks like that there is a connection between the mission scripts and the old "skybgnd-mono.bmp".
So a copy still has to be present in the standartd "textures" folder, when the scripts check it.
I figured it out when testing the client against the server. The game refused to join a campaign without the old texture in that place.
Have to take a better look in this.