[TEC] SH5.exe patches to fix bugs and add functionality

[TheDarkWraith]

Originally Posted by volodya61

Thanks for the explanation.

I see your explanation on sukhoi is incorrect. There are two patch files required for the CO2 bug fix. You need to open TDW_SH5_Patches.s5p and apply Patch 5 (both changes). Then you also need to open TDW_SHSim_Patch.s5p and apply Patch 1 (all 3 changes). Then the CO2 bug will be fixed

[volodya61]

Originally Posted by TheDarkWraith

I see your explanation on sukhoi is incorrect. There are two patch files required for the CO2 bug fix. You need to open TDW_SH5_Patches.s5p and apply Patch 5 (both changes). Then you also need to open TDW_SHSim_Patch.s5p and apply Patch 1 (all 3 changes). Then the CO2 bug will be fixed

Thanks again TDW, but explanation describes changes to both files: sh5.exe and SHSim.act

Look at screen, please:

[TheDarkWraith]

Originally Posted by volodya61

Thanks again TDW, but explanation describes changes to both files: sh5.exe and SHSim.act

Look at screen, please:

ah ok! My Russian is non-existent. Google translate is the only way I can read your language

[col_Kurtz]

Originally Posted by TheDarkWraith

I'll release a modifed torpedoes .sim file that increases the magnetic detonator range of the torpedoes to 4m here soon.

Ayey

[TheDarkWraith]

Torpedo magnetic detonators set to 4m download can be found at bottom of post #1

[volodya61]

Good news, thanks

EDIT: FX update 0.19 has the same files, overwrite them?

EDIT: FX update that's why I thought that the patch for fixing broken magnetic detonator doesn't work for dat-models

PS: And now everything work great

[TheDarkWraith]

Today I finally narrowed down the routine that checks the torpedo impact angle when it collides with an object. I have to say my first reaction to the code was a huge WTF? I'm still trying to digest and figure out what the hell they were thinking. There's a lot of multiplication of fractions into the result that I can't for the life of me figure out why. It should be a simple test of:

for all min and max angles defined:
if max angle < torp impact angle < min angle then get random value. If random value < dud % chance torp is dud

But no, they have this complicated mess of multiplications and taking the cos value of something I have to try and figure out what this mess means.

For testing I set the dud % chance to 100% in the torpedo sim file for every angles defined. That way I know for sure I should have a dud on impact. But stepping through the debugger I always see the code say no dud So for fun I changed the code so that every torpedo impact was a dud. This is interesting: instead of 'dying' and sinking to the bottom it kept bouncing on the side of the ship until it could get by and then just kept going. I got the message that torpedo was a dud also. Not quite sure what to make of that

Maybe you all can help me figure this out:

So game says collision imminent! Code jumps to routine that checks for impact. Impact detected. Now it checks torpedo impact angle:

first thing it does is appears to store the torpedo impact angle on the floating point stack (-0.9527535438537597656 in this case)
next it stores 0.0174532923847436905 on the floating point stack (does this constant mean anything to anyone?)
then it loads the max angle allowed to the floating point stack (90.0 in this case)
then it multiplies these two values together (0.0174532923847436905 X 90.0). Why? Is this trying to convert to radians?
the result of that multiplication is 1.5707963146269321440 (looks like a radian value)
then it takes the COS of that value
result of that is 1.2167964475064260060E-08
then it swaps the torpedo impact angle ST2 (-0.9527535438537597656) with the result ST0 (1.2167964475064260060E-08) so that the torpedo impact angle is at top of floating point stack (result resides in ST2, torpedo impact angle in ST0)
then a floating point compare is performed of ST2 (1.2167964475064260060E-08) against the stack top ST0 (-0.9527535438537597656) and stores the results in the Integer FLAGS (EFLAGS) register
then ST2 is popped from the floating point stack
then if result of compare is below (CF=1 of EFLAGS register) then it increments a counter and loads pointers to the next set of angles. I see a problem here: the other angle of the set is never checked. The only time the second angle (which would be the min angle) is checked is if the floating compare is above (CF=0). Then if the result of that second angle is not below (CF=0) then jump to calculate dud % chance else torp explodes.

As you can see this will always jump to torpedo impact! Something is wacky here and I'm just not seeing it...

It needs to be coded so that it's checking the min and max angles before jumping to next set of angles. This way if the torp angle falls within the min and max angles then the dud % chance can be calculated. With the code as it is it never even checks the dud % chance thus we never get any duds

[gap]

Originally Posted by TheDarkWraith

first thing it does is appears to store the torpedo impact angle on the floating point stack (-0.9527535438537597656 in this case)
next it stores 0.0174532923847436905 on the floating point stack (does this constant mean anything to anyone?)
then it loads the max angle allowed to the floating point stack (90.0 in this case)
then it multiplies these two values together (0.0174532923847436905 X 90.0). Why? Is this trying to convert to radians?
the result of that multiplication is 1.5707963146269321440 (looks like a radian value)
then it takes the COS of that value
result of that is 1.2167964475064260060E-08
then it swaps the torpedo impact angle ST2 (-0.9527535438537597656) with the result ST0 (1.2167964475064260060E-08) so that the torpedo impact angle is at top of floating point stack (result resides in ST2, torpedo impact angle in ST0)
then a floating point compare is performed of ST2 (1.2167964475064260060E-08) against the stack top ST0 (-0.9527535438537597656) and stores the results in the Integer FLAGS (EFLAGS) register
then ST2 is popped from the floating point stack
then if result of compare is below (CF=1 of EFLAGS register) then it increments a counter and loads pointers to the next set of angles. I see a problem here: the other angle of the set is never checked. The only time the second angle (which would be the min angle) is checked is if the floating compare is above (CF=0). Then if the result of that second angle is not below (CF=0) then jump to calculate dud % chance else torp explodes.

As you can see this will always jump to torpedo impact! Something is wacky here and I'm just not seeing it...

What the heck is that?

man, you are the Watson & Crick of hex code. Sometimes I wonder if even a single bit of devs code will be left, once you will get this game completely debugged...

anyway, trying to answer to one of your questions, 0.0174532923847436905 radians is almost 1 deg, so you could be right in stating that they wanted to convert the angle in radians. Don't ask me more, as I don't understand much of this mess.

[TheDarkWraith]

I think I understand the problem now with the no duds. We specify the torpedo angles (min and max) as first quadrant coordinates (between 0 and 90 degrees) in the torpedoes .sim file. The game calculates the torpedo impact angle as a true north angle. For example: I placed a NLL ship out 2000m due north from my sub. My sub was @ heading 0. The NLL was @ heading 90. I fired a torpedo at it. When the game said a collision happened the angle it reported for the torpedo impact angle was -0.992 or 172.75 degrees. This 172 degrees is being compared to the min and max torpedo angle values we specified. As we specify those min and max angles as first quadrant coordinates the result will always be torpedo impact (no duds). I have to somehow convert the torpedo angle the game computes into a first quadrant coordinate.

What I'm thinking of doing is taking the absolute value of the torpedo angle reported. This will ensure the angle is always somewhere in quadrant 1 or 4. Abs(-0.992) is 0.992 or 7.25 degrees. Then subtract that value from 90 to ensure value is always in first quadrant (90 - 7.25 = 82.75 degrees). Now that value can be compared to all the min and max torpedo angles specified in torpedoes .sim file.

Let's see what happens if torpedo angle is 260 degrees (glancing blow): 260 degrees * 0.0174532923847436905 = 4.54 radians. Cos(4.54) = -0.1715. So we'll say game reports impact angle as -0.1715. We take the abs of it and get 0.1715. COS-1(0.1715) = 1.3984 radians. 1.3984 / 0.0174532923847436905 = ~80 degrees. 90 - 80 degrees = 10 degrees. Thus the angle the torpedo makes with the plane of the ship's side is 10 degrees. Now we can check for duds

Does anyone see any probems in my thinking and/or math?

[ETsd4]

Originally Posted by TheDarkWraith

next it stores 0.0174532923847436905 on the floating point stack (does this constant mean anything to anyone?)

yes.
1°= pi/180 rad = 0.0174532923847436905

[col_Kurtz]

Originally Posted by TheDarkWraith

Torpedo magnetic detonators set to 4m download can be found at bottom of post #1

Tested Historical mission with unfortunate Cimmaron. Depth max - 12meters 3 times in a row. I broke she in a half again Superb!
At first time each of three torps blowed up. Next time, two times blowed up. And the last test two times again All with external view.

Thanks a lot TDW!

[TheDarkWraith]

alright I finally figured out the needed code to get the duds working It was close to what I posted above

Now there is something else odd for the duds. Once the game decides that the torpedo impact angle falls within a min, max defined set then it goes to calculate the dud % chance. Now how it does it makes no sense:

(these are notes from my debugger)
Gets a random value to compare with torpedo random chance of being a dud
Load the random % chance of being a dud (as defined in sim file) into XMM1
Multiply the % chance of being a dud (XMM1) by 0.4544053 (what is this constant and why is it needed?)
Multiply that result (XMM1) by 0.1507767 (what is this constant and why is it needed?)
Multiply that result (XMM1) by 1.0 (what is this constant and why is it needed?)
converts a signed doubleword from EAX to a single-precision FP value in the low doubleword of the destination operand. The upper 3 doublewords are left unchanged. Stores in XMM0
Multiplies XMM0 by a constant of 0.003051851 (what is this constant and why is it needed?)
compares the low-order single-precision FP values in XMM1 and XMM0. ZF, PF, and CF are set according to the result. OF, AF, and AF are cleared. The unordered result is returned if either source is a NaN (QNaN or SNaN).
Result of this check. If before then torpedo impact, if after then dud (always before thus torpedo impact instead of dud!)

So now I'm trying to figure out what these constants are and why they are needed. A dud should be a dud right? I mean if the game says torpedo impact angle falls within min,max values it should retrieve the % chance of dud and get a random value. Compare the two values. If % chance <= random value then dud, if not then torpedo impact

[TheDarkWraith]

Updated SHSim.act patch to fix the no torpedo duds available at bottom of post #1 (Updated sim patch to fix the no torpedo dud problem)

I changed the game code to be the torpedo is a dud if it fails the random value test. I have no clue what that other BS of multiplying by all those other constants was for.

You'll like what I did with the torpedo when it is a dud (for those that are impact type)



EDIT: spotted a possible bug. The magnetic detonators will still detonate. Looking into it...

EDIT2: there's no code for even checking for duds on magnetic torpedoes (that I can find). Maybe because magnetic detonators are reliable? Maybe it was only impact type detonators that could be duds (due to angle they collided with unit)? Maybe I need to add some code that can make the magnetic detonates have a random chance of being a dud?

[Rongel]

Originally Posted by TheDarkWraith

EDIT: spotted a possible bug. The magnetic detonators will still detonate. Looking into it...

EDIT2: there's no code for even checking for duds on magnetic torpedoes (that I can find). Maybe because magnetic detonators are reliable? Maybe it was only impact type detonators that could be duds (due to angle they collided with unit)? Maybe I need to add some code that can make the magnetic detonates have a random chance of being a dud?

Great stuff TDW!

I think that it's like that with the other SH games too, impact torpedoes cause only duds and magnetic torpedoes cause only premature explosions. And the premature explosions work already like they should, rough seas make them detonate. So in my opinion this is not that critical issue.

[Sartoris]

Yet another major breakthrough! Thank you, TDW!