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

[89]

Originally Posted by Rongel

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.

In SH3 magnetic torps do not detonate when strike hull at obtuse angle - saw it many-many times. Magnets only reliably activate when passing under keel.

But, yes, UN-BE-LIEVABLE work, TDW!
You are a one man army

[gap]

Originally Posted by Rongel

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.

Too bad,
it would be nice having magnetic torps premature explosions rate affected by the distance from the magnetic north, as well as duds rate connected with the tonnage of the target ship. Features that probably, as far as SH5 is concerned, have to be dismissed as "sci-fi"

Anyway, brilliant job TDW!

[TheDarkWraith]

Originally Posted by gap

Too bad,
it would be nice having magnetic torps premature explosions rate affected by the distance from the magnetic north, as well as duds rate connected with the tonnage of the target ship. Features that probably, as far as SH5 is concerned, have to be dismissed as "sci-fi"

Anyway, brilliant job TDW!

Those are actually great ideas. All I have to do is find the memory locations that denote these values then it's just a simple matter of adding some assembly code The hard part is finding these memory locations as everything is pointer based so you have no idea what so and so pointer is actually pointing to. The ones that load values onto the floating point stack are easy to track down because you can usually discern what they are from the value they load onto the floating point stack. I have more than 50% of the assembly code for the torpedoes mapped out so I have a really good idea what the game is doing with them.

I really like the idea of magnetic torpedoes dud rate controlled by tonnage of unit...I'm going to concentrate on tracking this one down. Seems very logical that this would influence the magnetic detonator on the torp in real life. I can make a controlled experiment where I know what ship is being attacked and I'll know it's tonnage from it's .sim file. Then when game tells me impact imminent I can search for this tonnage value. If I can find the value and one of the CPU registers is pointing to the object that contains this value then this will be possible to do. One of the registers has to be pointing to the object because the game is constantly computing distance to impact. The only way it can compute distance is if it knows where the torp is and where the object being collided with is located.

[TheDarkWraith]

Been looking into the KGrid CTD problem and found out why it causes the game to CTD: it's trying to dereference a null pointer Great work devs, tell me how in the hell this passed quality control?

[gap]

Originally Posted by TheDarkWraith

Those are actually great ideas. All I have to do is find the memory locations that denote these values then it's just a simple matter of adding some assembly code The hard part is finding these memory locations as everything is pointer based so you have no idea what so and so pointer is actually pointing to. The ones that load values onto the floating point stack are easy to track down because you can usually discern what they are from the value they load onto the floating point stack. I have more than 50% of the assembly code for the torpedoes mapped out so I have a really good idea what the game is doing with them.

I really like the idea of magnetic torpedoes dud rate controlled by tonnage of unit...I'm going to concentrate on tracking this one down. Seems very logical that this would influence the magnetic detonator on the torp in real life. I can make a controlled experiment where I know what ship is being attacked and I'll know it's tonnage from it's .sim file. Then when game tells me impact imminent I can search for this tonnage value. If I can find the value and one of the CPU registers is pointing to the object that contains this value then this will be possible to do. One of the registers has to be pointing to the object because the game is constantly computing distance to impact. The only way it can compute distance is if it knows where the torp is and where the object being collided with is located.

Thank you The Dark Wraith, I had forgot that nearly nothing is impossible for you!

by the way of magnetic torpedoes dud chance, I've read somewhere that magnetic detonators were reliable only on ships weighting 2,000 tonnes or more. Another common problem plaguing german torps from the outbreak of the conflict up to spring '41 was depth keeping related. Premature explosions and impact pistol dud rates too changed in the course of the war. I wonder if the extent of these problems could be made variable also in game, depending on current date.

Some references to known german torps reliability problems:
http://www.uboataces.com/weapon-torpedo.shtml
http://uboat.net:8080/history/torpedo_crisis.htm
http://www.feldgrau.net/forum/viewtopic.php?f=41&t=3261
http://forum.axishistory.com/viewtop...?f=110&t=83029
http://forum.kickinbak.com/viewtopic...tart=10#p10369

[gap]

Originally Posted by TheDarkWraith

Been looking into the KGrid CTD problem and found out why it causes the game to CTD: it's trying to dereference a null pointer Great work devs, tell me how in the hell this passed quality control?

Is it fixable?

[TheDarkWraith]

Originally Posted by gap

by the way of magnetic torpedoes dud chance, I've read somewhere that magnetic detonators were reliable only on ships weighting 2,000 tonnes or more. Another common problem plaguing german torps from the outbreak of the conflict up to spring '41 was depth keeping related. Premature explosions and impact pistol dud rates too changed in the course of the war. I wonder if the extent of these problems could be made variable also in game, depending on current date.

Depth keeping problems and heading problems are already modeled and working correctly. Premature explosions based on wave height is also modeled and working correctly. You specify these parameters in the torpedoes .sim file. These parameters are specified via date ranges.

Originally Posted by gap

Is it fixable?

Nearly impossible to fix. This is the main pointer for the KGrid map. Everything else related to the KGrid map is based on it. I have no idea what it's actual memory address should be

[gap]

Originally Posted by TheDarkWraith

Depth keeping problems and heading problems are already modeled and working correctly. Premature explosions based on wave height is also modeled and working correctly. You specify these parameters in the torpedoes .sim file. These parameters are specified via date ranges.

Good!
some more remarks:

- afaik magnetic detonators were more prone than impact pistols to premature detonations;
- magnetic detonators were generally not as sensible as impact pistols to the angle of approach of the torpedo to the target. According to one of your previous posts, this is correctly modelled in game. Nevertheless, due to the fact that magnetic detonators were sensible to the change of magnetic fileld over time, rather than to its absolute value, torpedoes aimed to the stern of target ships had an higher probability to fail detonating, because of the reduced differential speed. In order to model it in game you should compare the vector of the torpedo with the one of its target.

Originally Posted by TheDarkWraith

Nearly impossible to fix. This is the main pointer for the KGrid map. Everything else related to the KGrid map is based on it. I have no idea what it's actual memory address should be

Okay, we will live with it, but shame on ubisoft for it

[LemonA]

Originally Posted by TheDarkWraith

Been looking into the KGrid CTD problem

So KGrid is the Kriegsmarine Grid on the maps i assume.
What are the problems with the Kriegsmarine Grid? Never heard of the KGrid CTD.

[TheDarkWraith]

Originally Posted by LemonA

So KGrid is the Kriegsmarine Grid on the maps i assume.
What are the problems with the Kriegsmarine Grid? Never heard of the KGrid CTD.

Exactly what you know, it CTDs the game when you try to turn it on.


Finally found the initializer function that's called when the toredo is launched. This function sets up the torpedo with all the data it needs (values from .sim file, current depth, etc.). There is a conversion factor being used on the speed settings that I can't figure out:

0.05149993

Every speed setting specified in .sim file is multiplied by the value above. Does this value mean anything to anybody?

[gap]

Originally Posted by TheDarkWraith

Finally found the initializer function that's called when the toredo is launched. This function sets up the torpedo with all the data it needs (values from .sim file, current depth, etc.). There is a conversion factor being used on the speed settings that I can't figure out:

0.05149993

Every speed setting specified in .sim file is multiplied by the value above. Does this value mean anything to anybody?

maybe this:

1/10 knot = 0.051(4) m/s

[THE_MASK]

The large grid map squares on the navmap are exactly 10 times larger than the smaller ones .

[gap]

Originally Posted by volodya61

1/10 knot = 0.0514 m/s - maybe this looks better?

EDIT: but 1/10 knot = 0.05144444 m/s, not 0.05149993

yes, I mistyped it. And yes, this conversion factor doesn't equate exactly the figure found by TDW, but it is the best match I've found so far.
Thanks Volodya

[TheDarkWraith]

Originally Posted by gap

yes, I mistyped it. And yes, this conversion factor doesn't equate exactly the figure found by TDW, but it is the best match I've found so far.
Thanks Volodya

Ok, but why 1/10 knot? Why the 10 knots? Why not 20 knots? Understand where I'm coming from? Maybe Sober has the best explanation with the large squares being 10 times larger but it still doesn't make sense to me

The SH Worlds are 1/10 scale.

.1 meters = roughly 1 meter when you check 3D models

So you'd need to scale the speed settings since they are usually close to real life speeds.
This figure you found would scale and convert real knots to scaled (1/10th ) meters per second.

That's my thought.