Realism- and gameplay-related hardcode fixes for SH3.EXE

[Stiebler]

Regarding the variables: They change almost everytime you load a new game, since they are allocated dynamically.

True. But I thought they would be relative to a xxxx(0)000 boundary. Pity they are not.

[Edit:] And thanks for the code idea. I shall try to find the relevant code.

Stiebler.

[Tessa]

Originally Posted by h.sie

E.g. the flooding level of the front torpedo room needs a pointer of 12th order. (pointer that points to a pointer that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer, that points to a pointer that points to the variable)

But: Instead of finding a pointer and changing the variable referenced by that pointer, I suggest to first try to find and modify the code that writes the variable. So you don't even need a pointer.

h.sie

To write code such that it requires such a massive array of pointers is either severly careless coding, or the result of a recursive function where the 12th iteration gives you the number you need. Sorry that my knowledge of machine code is limited, but might I suggest you look at what the other pointers are linked to? I agree that using such a complex function is not very efficient, it may be done out of some necessity.

[h.sie]

It's common for modern 3D games, which are programmed object oriented with many objects including other objects and so on.

Class Submarine - contains sections - containing subsections - containing machines - containing damage counter.

Compiling/Linking the example above leads to a pointer of at least 5th order.

[Hitman]

@Stiebler and H.Sie

This is excellent news!

I hope that better comprehension of the tanks model for the game can help both making a better Anti-Humming-Bird mod, and a feature I think would be worth adding:

- A % random chance of crash dives getting out of control, as it happened in real life, with a risk of getting below crash depth and crushing. Ideally more probable with greener crew, but this would probably be too complicated.

[h.sie]

Funny: The more progress I, or better WE, make the more wishes arise. To be honest: After fixing the crash dive blues (together with Stiebler) and after progging the external torpedo issue, I really plan to PLAY a sh3 career for the first time. I don't even know if I will like this game.

[Silent Ace]

See how easily and realistically performed control ballast tanks in the next little game-http://www.purely-games.com/unusual_submarine_game.html
Similar simulator at the Museum of Science and Industry in Chicago-http://www.msichicago.org/whats-here...nce-challenge/
Something like this implemented in GWX and NYGM would be a major step toward realistic management of U-boat.

[h.sie]

@Stiebler: I discovered an Crash Dive Flag (Byte) which is 1 only during crash dive and 0 otherwise, this could be used to control / fix the fast-dive-tank.

Simply writing repeatedly 0,5 into the memory won't help, since the program will repeatedly overwrite it again, so we'll have some dirty oscillation, which could result in a helicopter instead of a submarine. so it will be necessary to do some re-engineering and find the right code (the phyisical model behind that all) to fix. I'll also look at it in the next days. Really interesting.

[Stiebler]

@H.sie:

Your previous post acknowledged with thanks.

It is necessary for me, once again, to try to discover which memory locations are associated with the quick-dive tank, as I try to discover the code associated with this tank. Ho hum.



Stiebler.

[Stiebler]

@H.sie:
Is the crash-dive flag cancelled (=0) after an interrupted crash-dive?

If so, the programming solution should be fairly simple. Check the flag, and always set the quick-tank variable to 0.5000 if the flag is cancelled.

Doubtless this 'simple' solution will not work, or will become more complicated.

Stiebler.

[h.sie]

@Stiebler: For code finding purposes, I often look into the stack. The return adresses in the stack tell me, which routines called my routine, and so I often find the code I search for (stack trace). Also, the stack contains the arguments of the function calls, which also can help.

I'll be able to sit in front of my modding PC in 2 days. Unfortunately.
So I don't remember all details of this flags behaviour. But one can find it easily.

h.sie

[h.sie]

@Hitman: On the other hand: if we manage to fix the crash dive bug, we can easily add a certain chance that the crash dive ends on the ground of the ocean.

[LGN1]

Hi all,

when we discussed the compressed air topic I realized that you consume compressed air when you order a crash dive. My assumption was that the compressed air was used for blowing the quick diving tank. When you interrupt the crash dive this does not happen. Maybe this can help you to solve the crash dive blues 'Give the order' to blow the quick diving tank?

Originally Posted by Delareon

Shouldnt it be possible to reload them all times? (at heavy seas only when dived maybe).

Originally Posted by h.sie

@Delareon: This is not a dumb question. It's a question that has to be discussed before I start programmming this. LGN1 wrote something about this topic earlier and via PM to me. Either we search the post or LGN1 is so kind to repeat what he knows regarding this question. Or any other historical information welcome, too.

As Delareon has written: the idea was to allow reloading internal torpedoes in case of a storm only submerged, i.e., if there is a storm and you want to reload internal torpedoes you have to dive.

See our old discussion on page 52 and my comment there:

http://www.subsim.com/radioroom/show...&postcount=771

Cheers, LGN1

[Stiebler]

@H.sie:
The crash-dive routine is as follows:

The quick-dive tank is filled very fast. In order to see the filling, one has to make a break in the code at Sh3Sim.act+0x8527 immediately after pressing key 'C' (for crash-dive).

The relationship of key variables is this:
hydroplane (A) = (relative 0)
hydroplane (B) = hydroplaneA + 2C
diving tank = hydroplaneB + 1C
quick-dive tank= diving tank + 0x14
I've verified these relative values over four different cold starts of SH3 now, but you have to identify one of these starting variables first.

The quick-dive tank starts at 0.5000 (not at 0.0000, as I thought previously), and rises to 1.0000.
At a depth of about 35-39 metres (it varies even with the same IXC U-boat), the quick-dive tank starts to empty slowly.

The code which empties the quick-dive (q-d) tank is a subroutine called from Sh3Sim.act+0xB002, and located at Sh3Sim.act+0xA690.

This subroutine is called *only* to empty the q-d tank, not to fill it. The subroutine is NOT called after an interrupted crash-dive at 40-45 metres. Hence, the q-d tank never gets emptied (ie, restored from 1.0000 to 0.5000). It may be partially emptied, depending on what depth was reached before the crash-dive was interrupted.

When the U-boat is floating level at a depth of 40-45 metres (interrupted crash-dive), the only calls to Sh3Sim.act+0xAEB3 are to the hydroplanes. Otherwise, Sh3Sim.act+0x8527 provides a break-point for calls to hydroplanes and to the q-d tank.

Therefore it appears that the code needed to handle an interrupted crash-dive (to restore the q-d tank to a value of 0.5) is going to have be quite brutal. We could set a flag when the q-d tank fills to 1.0000 (occurs while the U-boat is still on the surface), check flag and depth and hydroplane status, then restore the q-d tank.

I think all three of these tests are going to be needed wherever, or however, the code gets implements (although your crashdiveflag that you reported earlier could replace the 'q-d tank = 1.0000' test.)

The big problem is this:
After an interrupted crash-dive, and if the player goes to speed = slow, the hydroplanes both have a steep up angle (about 0.5 for the front planes, and nearly as much for the rear hydroplanes), yet the U-boat continues to sink. Therefore the method of checking hydroplanes only works at high underwater speeds.

We need some new way of checking for an interrupted crash-dive, and I think this requires knowledge of depth plus something else. A crash-dive to 80m can be interrupted if the player clicks on the depthgauge for 40m, 80m or 120m, so it is necessary to check only that the depth is below the surface (>10m). But what is the 'something else'?

I suggest the simple test:
IF depth > 40m AND q-d tank value = 1.000
THEN q-d tank = 0.5000

That should resolve all problems, is easy to code, and we know that the q-d tank will be emptied to 0.5000 below 40m anyway! The only potential problem is that the U-boat will now sink less quickly to the crash-dive depth - but it will be safely below the surface. (Implement in code at or near Sh3Sim.act+0x8529.)

In fact, possibly (?) we can even remove the test for the q-d tank - implement the code whenever the depth falls below 40m however the player chooses to dive.

Stiebler.

[h.sie]

@Stiebler: I'll look into it this evening. Higher priority than external torpedoes.

My ideas are similar, but we may not forget the blow ballast. If we permanently force q-d-tank=0.500 when depth > 40m, then a blow ballast would not work as intended (provided blow ballast affects q-d-tank, but I think so).

h.sie

[LGN1]

Originally Posted by Stiebler

I suggest the simple test:
IF depth > 40m AND q-d tank value = 1.000
THEN q-d tank = 0.5000

That should resolve all problems, is easy to code, and we know that the q-d tank will be emptied to 0.5000 below 40m anyway! The only potential problem is that the U-boat will now sink less quickly to the crash-dive depth - but it will be safely below the surface. (Implement in code at or near Sh3Sim.act+0x8529.)

In fact, possibly (?) we can even remove the test for the q-d tank - implement the code whenever the depth falls below 40m however the player chooses to dive.

Stiebler.

Hi Stiebler,

nice work The first version, however, might be problematic for people that have a less deep crash-dive depth in their cfg files so that their q-d tank value is already smaller than 1 at 40m I think one should keep it in mind that different people/mods have different crash-dive depths.

Cheers, LGN1