Topic: Hex Editing of Starfleet executables

[Corbomite]

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.

Not surprising. It also checks for model size files being compatible. Ion storms cause damage, so even I put a suggested sameness of textures in my Read Me when playing in multi with others to prevent any tactical difference, even if it only visual. We are finding that skybgnd-mono is used for quite a few things here and there. The weird part is that they have four textures that are basically the same thing, but only seem to use two that I can find. The others must be called somewhere, but I can't place where.

[Javora]

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.

Wouldn't that be used at the end of a match to determine prestige points or battle stats?

[Corbomite]

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.

Wouldn't that be used at the end of a match to determine prestige points or battle stats?

True, that might be where the debriefing screen gets it's info, but I don't know why it would need to know that some obscure missile ran out of gas and disappeared. I'll check if this goes forward. There are already a few glitches.


d4v1ks - Most times all CRC listed files have to match for the server and all players wishing to join. If the server and everyone on it have the mod it should be ok as long as it always gives the same random neb/ion storm to players in a unique mission together. This may not be possible, but choosing one of each for the server and having everyone pick it would again line things up.

[d4v1ks]

Yes... in singleplayer it works fine, but in multiplayer it refuses to work sometimes...
Well, the random nebula function is 45 bytes long. So i just need to find another place to insert it if is that the case...
Or maybe is the memory buffer where i allocated the result. Had to overwrite something...
Resources are limited.

[TarMinyatur]

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.

SFC Community Edition does not write to WeaponDamage.txt. I don't see how this text file is crucial to Dynaverse campaigns for EAW or OP. It would cause noticable lag as this file is opened, written to the harddrive, and closed 8 times on each player's machine as two Dreads exchange close-range missile fire.

Wouldn't that be used at the end of a match to determine prestige points or battle stats?

Unlikely. It was probably used in debugging Seeking Weapon shifts. Taldren disabled these shifts for multiplayer.

[d4v1ks]

Good news...

I was able to isolate the place where the nebula is loaded (skybgnd-mono.bmp).
There are other 3 references to the same texture in the game.
If you know where they are used maybe we can give it their own texture.

Writing a function in assembler was is probably the most painfull thing i did these last times...
The exe is a static object! Can't expand it or edit it easily.
Had to highjack a "push offset" (5 bytes) and turn it into a call to a fake function with 1 argument. Luckly the "call offset" is also 5 bytes length.
Now keeping the stack pointers, registers and flags all in place and healthy, saving, loading arguments and executing calls to c++ rand and sprintf was a nightmare.
The program i used to do it is not an editor per se, and didnt wanted to save/update the changes sometimes.

In the end, i still removed the 2 functions that write a log into the WeaponsDamage.
Till now, i didn't had any issues while playing missions in multiplayer or when the missions ended.
All seems ok.

Resuming...

the textures will be saved in ".\Assets\Textures\SkyBgnds\"
and named "0.bmp", "1.bmp", etc

The funny part is that this function, in c++ code, would take 5-10 minuts to write and test...
So i dunno if i will have courage to do something like this soon.

[Corbomite]

Good news...

I was able to isolate the place where the nebula is loaded (skybgnd-mono.bmp).
There are other 3 references to the same texture in the game.
If you know where they are used maybe we can give it their own texture.

That is good news. We know what two of the calls are, I told you those. Sometimes they use them so subtly that it's hard to tell what they go to.

[[UFP]Exeter]

bitmap should be 6 files

[d4v1ks]

Found another use for the "skybgnd-mono.bmp" texture...
Maybe it is better to split them rigth now. Make an entry for the shields, other for the black holes, and let the last reference as it is...
This will cover all the texture references in the executable...
I will do it in a sec...

[Corbomite]

Oh good find! Now I know why those suckers are square! I can fix that. If you can isolate Black Holes and Shields man o' man can we make improvements!

[TarMinyatur]

Starfleet2CE.exe

I found the variable that determines Phaser Efficiency vs Plasma. It is initially set to 0.25d. Doublechecked everything and the customizable variable works. Plasma is easily thwarted in normal SFC with 50%+ efficient Phasers vs Plasma Torps. You can starcastle if you can't phaserboat. 20% to 30% is reasonable.

I also found those peculiar Plasma Damage Brackets. You'll be able to adjust the decay rate for all the plasma types. Unfortunately many of the damage multipliers are shared with unrelated functions, so it will take time to isolate them. But the brackets for Plas-R, S, and G are easy to edit.

Modded Plasma-"R" (Plasma-R2?)
Damage after traveling nominal hexes
0-10 = 50
11-15 = 45
16-20 = 40
21-25 = 35
26-28 = 20
29-30 = 10
31 = 1

or

Modded Plasma-"R" wave (Plasma-W?)
Damage after traveling nominal hexes
0-10 = 5
11-15 = 10
16-20 = 25
21-25 = 50 
26-28 = 25
29-30 = 10
31 = 5

endless mods...

Add to CE offsets.txt
63B990: 1f // Plasma-R 1st range bracket // 0.3548 ; 11/31
63B99C: 1f // Plasma-R 2nd range bracket // 0.5161 ; 16/31
63B9B0: 1f // Plasma-R 3rd range bracket // 0.6774 ; 21/31
63B9C8: 1f // Plasma-R 4th range bracket // 0.8387 ; 26/31
63B9D4: 1f // Plasma-R 5th range bracket // 0.9355 ; 29/31
63B9E4: 1f // Plasma-R 6th range bracket // 0.9677 ; 30/31
63B998: 1f // Plasma-S 1st range bracket // 0.4231 ; 11/26
63B9A8: 1f // Plasma-S 2nd range bracket // 0.6154 ; 16/26
63B9C0: 1f // Plasma-S 3rd range bracket // 0.8077 ; 21/26
63B9D0: 1f // Plasma-S 4th range bracket // 0.9231 ; 24/26
63B9E0: 1f // Plasma-S 5th range bracket // 0.9615 ; 25/26
63B9A0: 1f // Plasma-G 1st range bracket // 0.5238 ; 11/21
63B9BC: 1f // Plasma-G 2nd range bracket // 0.7619 ; 16/21
63B9CC: 1f // Plasma-G 3rd range bracket // 0.9048 ; 19/21
63B9DC: 1f // Plasma-G 4th range bracket // 0.9524 ; 20/21

The values for the brackets should increase from one to the next. Giving a 4th bracket a value less than the 3rd bracket is not going to crash the game. It is just difficult for a person to follow the flow. You can give the first bracket a value of 1.0, and the torpedo will not degrade as it travels -- same as a missile.

[TarMinyatur]

Starfleet2CE.exe

I noticed a redundant 360 degree arc in the code. So I renamed it "RMLR" for Rear-firing Mauler to do a test. Then I altered the starting position to 190 degrees and the ending position to 170 degrees (measuring counter-clockwise). After that I updated the bitmap with Paint, Gimp, and dropped it into Sprites.q3 with the Q3_Editor. It works.

[d4v1ks]

Starfleet2CE.exe

I noticed a redundant 360 degree arc in the code. So I renamed it "RMLR" for Rear-firing Mauler to do a test. Then I altered the starting position to 190 degrees and the ending position to 170 degrees (measuring counter-clockwise). After that I updated the bitmap with Paint, Gimp, and dropped it into Sprites.q3 with the Q3_Editor. It works.

You have a good eye for those little details.
Good work.

[Corbomite]

Starfleet2CE.exe

I noticed a redundant 360 degree arc in the code. So I renamed it "RMLR" for Rear-firing Mauler to do a test. Then I altered the starting position to 190 degrees and the ending position to 170 degrees (measuring counter-clockwise). After that I updated the bitmap with Paint, Gimp, and dropped it into Sprites.q3 with the Q3_Editor. It works.

OP has a bunch of extra arcs coded, but they have the wrong pie slice on the display when showing the arc. Maybe I should look into doing them right.

[TarMinyatur]

I figured out the mysterious third float in the arc function. It is the midpoint of the arc. I guess this is for AI purposes because a player doesn't care about the midpoint of an arc with such precision.

I noticed errors in the midpoints for RW, FLL, RRP, SFBR, and SFBL. Perhaps the AI will do better with accurate information.

Here's an attached picture of the common "FA" arc. Orion Pirates may use the number 8192 to indicate 360 degrees. OP does not directly use degrees.   

[TarMinyatur]

Starfleet2CE.exe

Why not make the neglected arc "120" fully customizable for your favorite mod?

For example, the "MLRX". Start 10, End 350, Midpoint 0. This gives a Mauler-ish weapon a 20-degree arc instead of a 10-degree arc (the default for the conjectural MLR). The FRRX, FLLX, and KFX's rear-firing sectors get 20 degree coverage. LS an RS are actually 200-degree arcs, not 180 as you would expect. (Orion Pirates uses a 20-degree arc for the Mauler and a narrow 10-degree arc for the ESG Lance.)

So here's a look at the SFC_Editor in action...

[Nemesis]

I figured out the mysterious third float in the arc function. It is the midpoint of the arc. I guess this is for AI purposes because a player doesn't care about the midpoint of an arc with such precision.

There is one weapon where that is important - the Attack Probe. 

[TarMinyatur]

I figured out the mysterious third float in the arc function. It is the midpoint of the arc. I guess this is for AI purposes because a player doesn't care about the midpoint of an arc with such precision.

There is one weapon where that is important - the Attack Probe.

Attack Probes are 360 degree weapons in SFC. Always have been, right?

[TarMinyatur]

I really wanted my SFBL and SFBR to be a little wider. Same degrees as FA/RA.

This is a neat find. Ty. If I feel a little better today I will try to find in via Hex in OP.
And btw. I love the RMLR. Only bc in my TNG shiplist; I have always believed the Cardassian had a purposes for that funny pitch fork butt on all their ships. Would make an excellent arc for a special weapon if they are being chased. Thanks for the find/creation of the RMLR.

I think I'll set the defaults for the custom arc to MLRX, because the MLR doesn't have a bitmap pie in CE -- an incorrect bitmap gets drawn. I have already updated the sprites to provide the MLRX with accurate bitmaps.

I bet OP has these redundant but functional arcs too: "180", "120". No shiplist or ftrlist has these as entries.

---

This is what you're looking for, Adam?

[Nemesis]

I figured out the mysterious third float in the arc function. It is the midpoint of the arc. I guess this is for AI purposes because a player doesn't care about the midpoint of an arc with such precision.

There is one weapon where that is important - the Attack Probe.

Attack Probes are 360 degree weapons in SFC. Always have been, right?

Unless I'm mistaken though they can be fired any direction they can only hit dead ahead.