Topic: Hex Editing of Starfleet executables

[TAnimaL]

I like the idea of a vanilla OP exe update (2553 works as a name well enough). Perhaps a discussion for that is worth a thread of it's own. It should probably kept to the minimum bug fixes (especially since players can now mod it on their own), like the range limitations for phasers and maybe the "corrected" TR beams range brackets.

This weekend I hope to look for the NSM value and anything I can find on ESG Lances.

[Corbomite]

Have you guys found anything in there that points to how the AI accesses things vs how things are accessed by human input?

[TarMinyatur]

Have you guys found anything in there that points to how the AI accesses things vs how things are accessed by human input?

Hex Editing the AI's behavior (trajectories, fire-decisions, target selection, energy management, etc. ) is almost impossible. I would need C++ code to attempt to do it sanely. Strat said (after studying the CE source code) that the AI is a crazy mess.

I can, however, alter the AI by changing the rules for all units. If a Ph3/G (a defensive weapon) is limited to range 2.99, the AI's performance is highly improved. If I swap some warp power for impulse power in the shiplist, the AI is better at energy management. It can't frantically zoom around at speed 31, never charging a heavy weapon. Instead, it might max out at speed 22ish and still charge photons/dizzies/etc.

[[UFP]Exeter]

The code for ce is owned by dyna, not to be released without frey's ok.

now take eaw, source, eliminate q3, update dx8 and the multiplayer, modify anything we want, it becomes sfc4.  sorry so long, but 1 person takes a long time.

[Corbomite]

I can, however, alter the AI by changing the rules for all units.

This is where I have the problem. I was hoping that the firing issues with the AI could be solved independently of human use. We could fix a lot of bad firing decisions that the AI has by limiting their ability to use certain weapons until a better firing solution is presented, but all of that ruins human override capability. If the AI calls could be sent to a unique set of charts though...

[[UFP]Exeter]

ai needs more choices, only certainty is weak spot full spread.

[TarMinyatur]

I can, however, alter the AI by changing the rules for all units.

This is where I have the problem. I was hoping that the firing issues with the AI could be solved independently of human use. We could fix a lot of bad firing decisions that the AI has by limiting their ability to use certain weapons until a better firing solution is presented, but all of that ruins human override capability. If the AI calls could be sent to a unique set of charts though...

I wish ADB had defined the Ph-3 as a range-2 weapon back in 1977. I don't understand how the loss of 0.33 average damage at range 4-8 and 0.16 average damage at range 9-15 is unacceptable.

[TAnimaL]

yes, and asking questions like "Why did ADB do that ?" is a quick route to madness, let me tell you. Suffice to say, it's a different type of game, being a boardgame with no "AI" to speak of.

[TAnimaL]

A little note that might interest someone: while trying to find the value in OP for NSM (35), I changed the "35" that is part of the chain for "game turns" (...90, 60, 40, 35, 30, 25...). When I changed that "35," which is the time in seconds for speed 7 turns, the game would not speed up past 7. I could toggle back down as far as 1, but it wouldn't go higher than 7. interesting,

BTW, none of the four floats of 35  or the lone float for 350 are the NSM explosion. bummer

[TAnimaL]

Well d4v1ks, we do have robot ships already....

There's also monster rules too but  that doesn't really address the issue. In SFB a player can decide to waste firing a P3 at range 9, and there's not that many monsters/robot ships in SFB to worry about. And the rules you mention have a robot ship firing at range 4 or at best distance per turn. our AI is smarter than that, at least

[TarMinyatur]

A little note that might interest someone: while trying to find the value in OP for NSM (35), I changed the "35" that is part of the chain for "game turns" (...90, 60, 40, 35, 30, 25...). When I changed that "35," which is the time in seconds for speed 7 turns, the game would not speed up past 7. I could toggle back down as far as 1, but it wouldn't go higher than 7. interesting,

BTW, none of the four floats of 35  or the lone float for 350 are the NSM explosion. bummer

The game could store the arabic number 35 as an integer using various byte forms. It can be written as two groups of 16 and then a 3 in hexadecimal form:
1-byte = 23 (say "two three" not twenty-three!)
2-byte = 23 00
4-byte = 23 00 00 00

Hopefully it isn't stored as 23 because there could be thousands of them in the assembly code. "23 00 00 00" can be searched for. There won't be many of these 4-byte (32-bit) integers.

[TAnimaL]

I gave up counting the 1-byte "23s" after two dozen, figuring there would be too many; I didn't try (or know to try) 2-byte and 4-byte versions.  Most values for damage and speeds seem to be in 32 floats or sometimes 64 floats, do you think one of those others might be it? Hmmm

Edit: I did a search on "23 00 00 00" - there were about 77 of them.   My understanding of bits/endian/hexadecimal stuff being minimal, should that be reversed in the exe as "00 00 00 23"? Did a search on that too but there were easily 4x as many.

[TAnimaL]

As a non-coder, I would say this is why we need to proceed carefully. There are values that can be easily changed thru SFC_Editor, like weapons damage & range charts; this is where most modding will likely happen. There are values that would be useful to change, like the phaser limiters being discussed, but the choices for changing calls or rdirects seem dangerous, so maybe should be kept out of the UI for SFC_Editor?? So if something like Adam's idea for a OP vanilla 2553 exe is created, then there's a version of offsets that would look at the correct places for a value in 2553 that's not in the stock 2552, maybe.

Adam, what effect on weapons did you notice when you changed the top speed? I was playtesting in a exe with a top speed of 50 and didn't notice any, but I wasn't looking for weapon changes either.

[TarMinyatur]

Tar, when you modify a function to look for an argument in another location you literally append, for example 4 bytes to the EXE itself, and then redirect the pointer to there, right?
For example, if the exe is 1000 bytes long you make it 1004, and then you redirect the offset to that place?
Cause, i don't understand how redirecting something to other address' inside the exe could be safe. How you know that particular offset is not part of something important?
(I'm talking about the perspective of people editing that value in the SFC editor).

I have no idea why Starfleet executables have redundant data for the double-precision float value of PI so frequently! All these data are ignored -- according to the Interactive Disassembler and playtesting. No functions ever read them. Some functions, however, read the single-precision floats for PI to draw circles, calculate circumference, define arcs, etc. If the .exe didn't have any free space, I wouldn't be able to isolate shared variables. Any change to the energy cost of a Plasma-S, for example, would always affect 5 other systems. It would be a hopeless situation. I cannot successfully change the size of the .exe, Carlos. If I did, every pointer would point to the wrong data.

My guess is that the compiler, by design, uses 64-bit PI as easily identifiable "filler" to allow a programmer to modify a program at the Assembly level if the higher level language (C++) just doesn't work as desired. So each 8-byte PI filler gives me a place for two new floats. Then I update specific references to find this new data. Any unknown function will still read the default data and the game will run fine. My method is as safe as possible with the tools I have -- as reliable as modifying C++ code directly. I can make precise changes, but they are always unsophisticated. Essentially, I tell the CPU to read this singly-referenced number instead of that overloaded value. There is no good reason for Photons and Plasmas to share a variable, except to reduce the size of the file, I suppose.   

[TAnimaL]

I didn't notice any shield=non-existence issues with high speed but I'll run some tests soon. I changed both the "top speed" and "speed gauge bar" to 50, with some modified non-Xships capable of doing that wiht no problem. Some of us, and I think you included, like the "no turns above 31" side effect, although HETs are still possible, as is fighter launching (something not possible in SFB. Well, it is, but the fighters blow up  ).

Lances - I hoped for something like a mini-chart of "16 16 16 16 16 16" for a damage table, no such luck.

[TarMinyatur]

Found the logic that controls the Phaser-G2's maximum range. By default, it uses the Ph-2's max range limit. I added an offset to allow the SFC_Editor to assign another phaser's limit to the Ph-G2.

StarfleetOP.exe offsets.txt
E3B0D: op // [2.554] Ph-G2 uses max range of Ph-1 (1C), Ph-2 (14), Ph-3 (0C), or Ph-4 (05) // 14

[TAnimaL]

Great job Tar! So, this will be another thing for the "updated" OP exe, since, as I understand it, the E3B0D op you list doesn't exist in the 2552 OP, jes? Cool tho to have that oprion now

(Wow, I really got learn IDA)

Adam, my wingmen and/or AI opponents all stayed @ 31 or below. If my ship A is at speed 45, and I switch control to ship B, ship A slows down to 31 or less. Bit of a bummer but you can create some different tactical situations tho.

[TarMinyatur]

TAnimaL, this should work for 2.552. I didn't create a new float here. I made the distance of the Ph-G2 jump modifiable, so it can land at Ph-1, instead of Ph-2, for example, and read the default value of 750.0f instead of 500.0f.

But with 2.554 you can customize the max range limits for Ph-1, Ph-2, Ph-3, and Ph-4 and then pick which one you want to share with the Ph-G2. Unfortunately, there is no room in the code to give the Ph-G2 its own independent value.

[TarMinyatur]

Adam, the logic jump for the Ph-G2 is within a phaser-specific function. It uses a signed 1-byte displacement value, (00 through FF), which means it can be modified to hop a maximum of 127 bytes forward or 128 bytes backward. I don't think it can leave this particular function and enter another, such as an adjacent Disruptor function. There'd be no problem if the jumps were "far" -- 4-byte absolute addresses like 0x001234AB which can reach anywhere in the program.

I like your idea. There could possibly be a way to do it... 

[TarMinyatur]

Lances - I hoped for something like a mini-chart of "16 16 16 16 16 16" for a damage table, no such luck.

I've been looking for it too. Found some curious data in a logical location.

offsets.txt
456410: 1f // ESG Lance bracket, range x10 // 70.0

But I don't know where the range limiter is yet. It should be 69.9f or 69.99f or 69.99d, but it could be 69.98987f or another odd value.

Adam, have you been able to fire the ESG Lance at ranges greater than 6.99k?