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

[Anvart]

Originally Posted by SquareSteelBar

yep, all right.

I see you got the files already?

In world there are many good friends...

[h.sie]

would a speed restriction during reload of external torps be realistic?

if yes, what speed?

[Sailor Steve]

Originally Posted by h.sie

would a speed restriction during reload of external torps be realistic?

Yes.

if yes, what speed?

Realistically? Zero. They may have slowed to one or two knots, but most likely was a dead standstill.

[Hitman]

REMINDER:

I have been watching this discussion, and I would like to emphasize that we at subsim-com will not allow posting here links to modified game engine files and such. Please if anyone is willing to exchange, give or share such files, do it privately, and forget any idea of posting pre-patched files and such here.

The only thing allowed here are H-Sie's fix files, which are essentially programs that run externally and modify each user's legitimally bought and installed program files -on which he can legally do whatever he wants-, but never affecting the "copy protection" that might exist.

Thanks for observing these simple guidelines, so we can keep this discussion open

[Anvart]

@ Hitman
If you about my posts... i have shown byte edited by 4 GB patch...
... and checksums of files - targets of h.sie's work...

[h.sie]

Thanks, Sailor Steve. Speed restriction could be done in two ways:

A) Disallow higher speeds by program code or

B) Program some penalty if one breaks realism rules (dive or driving too fast during reload).

In the last 2 weeks I spent a lot of time to try to model such penaltys (crew injured or dead, compartments flooded and so on), but only with little success, and: It took a huge amount of program code. So I tend to not continue this way. That means:

1) During reload of external torpedoes speed will be restricted.

2) During reload of external torpedoes one cannot dive, since all diving commands will simply be ignored.

3) There will be a new Command (e.g. Ctrl-C) to interrupt the reloading process, in the case of an alarm or if higher speeds are necessary. After interrupting the reload process, the user has to wait 2-10 minutes. After that, he can dive.

4) No reloading of external torps in bad weather.

Eventually 5) : No reloadings of internal torps when windspeed exceeds a certain value.


This solution restricts the player instead of allowing him to decide if he wants to break realism rules or not and risk some penalty. I am not happy about that solution, but my restricted time does not allow a detailed and realistic modelling of all possible situations/penalties.

Only alternative: The only simple penalty I can offer is to destroy the sub for a certain probability. That means: If the player dives during reload, he risks for a chance of, say, 75% that boat sinks. That's too extreme, I think.

h.sie

[h.sie]

An arbitrary, unused command like

[Cmd348]
Name=WP_Report_damage

or

[Cmd435]
Name=WA_Report_damage

Of course I'll make sure the command is really unused.

[h.sie]

Why automatic interrrupt? I think its better if the player decides if or not to interrupt reloading!

[Stiebler]

@H.sie:
You identified earlier a diving tank and another variable, tentatively thought to be possibly a depth rudder ( = hydroplane). (Seen at code SH3Sim.act + 0x7527, and indexed through register ecx.)

I have now checked out this code, and there appear to be five variables involved, all indexed by ecx. Since there is no way of identifying these by constant memory addresses, I shall identify them by the last three digits of their addresses (these last three digits are probably the same for you too). The values were checked for a simple dive (‘D’-key) from surface, and a crash-dive (‘C’-key) from surface, at TC = 1. I’m using a IXC boat.

xxxxx170: involved in dive + crash-dive. Value reaches a maximum of about +0.5235 in mid-dive, averages zero when at requested depth.
xxxxx05c: value remains steady at 0.0 throughout (dive + crash-dive). However, the calling code leads to:
xxxxx18C: involved in dive +crash-dive. This value rises rapidly from 0.0000 to 1.0000, and presumably represents the memory location of the diving tank.
xxxxx144: involved in dive + crash-dive. Value is frequently the negative value of xxxxx170, but the values differ slightly during the dive. Value averages zero when at requested depth.
xxxxx1A0: involved in crash-dive only. Value rises very fast from 0.0000 to 1.0000, faster than xxxxx18C. It appears to represent (correctly) a quick-diving tank for crash-dives. After the U-boat reaches the crash-dive depth, the value falls very fast to 0.5000.

Comments:
We know already that a crash-dive in SH3 reaches its depth (80 metres here) faster than a high-speed dive to 80 metres. This is obviously modelled correctly with SH3 - well done, devs.
The ‘crash-dive blues’ occurs when a crash-dive is interrupted by changing the depth before the crash-dive has completed. When this happens, the U-boat does not level out correctly, but has a downwards angle. The bug affects all the super-mods, but is particularly noticeable with NYGM.

When a crash-dive is interrupted, the value of xxxxx1A0 does not return to 0.5000, but remains at 1.0000. This is the only difference I have detected (yet) between a completed crash-dive, an interrupted crash-dive, and a simple dive. When the NYGM U-boat is set to slow ahead, after an interrupted crash-dive, it sinks. When the speed is set to half-ahead, the U-boat returns to the depth set by the player when he interrupted the crash-dive. There is *no difference* between the values of the five variables shown above in either circumstance.

This is hard to interpret. Is it possible that that xxxx170 and xxxxx144 can be hydroplanes/depth-rudders, and the difference in water flow over them at different submerged speeds causes a gain or loss of depth? That is how hydroplanes are intended to function. But in that case, why is there not a severe angle on the hydroplanes at slow underwater speeds, when the boat is sinking, but wishes to rise?

Stiebler.

[Delareon]

Originally Posted by h.sie

Eventually 5) : No reloadings of internal torps when windspeed exceeds a certain value.

Because of RL i missed a lot of the discussion here so maybe i ask a dumb question, but anyways: Why no reloading of internal torps at certain wind speeds?

Shouldnt it be possible to reload them all times? (at heavy seas only when dived maybe).
I only had a short experience inside of an Submarine for tourism purposes at the coast of mallorca when the sea was quiet so i have not really a clue how heavy seas feel inside of an sub but i was thinking that u dont feel any waves at a certain depth. So reloading while submerged should work always from my opinion. Dunno if a depth check while in heavy seas is an easy task for u h.sie but my early (or late) wish for christmas is to have an depth check when wind reaches a certain value and allow reloading of internal tubes when deeper than 30m for example

[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.

[h.sie]

@Stiebler: Great findings, which could help us to eliminate the crash dive blues.

xxxxx170 indeed is the value of one of the hydroplanes. in a different code section it is multiplied with a cartain value, so that we get values between -30,0 and +30.0 what are exacly the values shown in the gauges in the control-room and which are the current angles of the hydroplane.

The other hydroplane has different sign, that means: If both hydroplanes are up, one has the value +0,52 and +30,0 (degrees) and the other has the value -0,52 and -30,0 (degrees). This also irritated me.

xxxxx1A0 is very interesting and in my opinion the starting point for deeper research in order to locate the cause of the crash dive blues. What about manually setting it back to 0,5 after an interrupted crash dive? If that works, we can fix the according code to set the value to 0,5 instead of 1,0 after interrupted dive.

h.sie

[h.sie]

@Anvart: In my opinion the kaleun (the player) is the person who decides whether to interrupt reloading or not. the watchcrew and the sonarman are only functional crew members without military authority. their job is to support the kaleun with information.

By the way: If I trigger one of these unused commands: nothing happens. No crew animation. So they really are unused. Or do you mean: for further use e.g. for some other mods which maybe could use them for animations??

[Stiebler]

@H.sie:
Yippee!! The *cause* of the ‘Crash-Dive Blues’ is solved!!

If you restore the value for the quick-dive tank at xxxxx1A0 (see my earlier post#866 http://www.subsim.com/radioroom/show...&postcount=866) to 0.5000 after an interrupted crash-dive, then the U-boat regains full operational stability at slow speeds and at high speeds.

Specifically, if the crash-dive is set to 80 metres (default), but you change the depth setting to 40 metres as soon as the U-boat is underwater, then the U-boat descends to 40 metres with xxxxx1A0 variable still set to 1.0000 (should be 0.5000 if the crash-dive had completed). If you now set the speed to standard, the U-boat maintains its depth. If you set the speed to slow ahead, the U-boat sinks slowly.

If we now change manually the xxxxx1A0 variable to a value of 0.5000, the U-boat maintains its depth at 40 metres. If it has sunk already to 50 metres, it returns to 40 metres and levels out.

I discovered something else. The quick-dive tank ‘empties’ quite quickly as you crash-dive, so a crash-dive interrupted at 60 metres has variable xxxxx1A0 set to a value of about 0.65 (not still at 1.0000). When this happens, the U-boat sinks more slowly at slow speed than it sinks when interrupted at 40 metres.

These tests done with a crash-dive (‘C’-key) from surface, at TC = 1, using a IXC boat. ‘Interrupted crash dive at nn metres’ means: ‘As soon as the U-boat is below the surface, click on the dive gauge at nn metres’ (where ‘nn’ = 40 or 60 in the examples above).

One irritating problem: I thought that the variables described here and in my last post would be constant in their last three digits. They are not. I had to work them all out again for these new tests.

So how do we fix the ‘Crash Dive Blues’ by setting the quick-tank to 0.5 after an interrupted crash-dive? One solution would be to set it to 0.5 when the hydroplanes are about zero (say 0 +/- 0.005). However, I think this will be quite difficult to code, since, once the U-boat has ended its interrupted crash dive (and is steady at high underwater speed, or is sinking at slow underwater speed), the calls in code to Sh3Sim.act+0x8527 become much, much less common. Something to think about. Incidentally, most of the variables I mentioned earlier are called from subroutine SH3Sim.act+0xAEB3. The quick-tank variable is called from elsewhere, but intercepted at +0x8527.

Stiebler.

[h.sie]

@Stiebler: Great. One step nearer to the solution.

Regarding the variables: They change almost everytime you load a new game, since they are allocated dynamically. That's the reason one cannot use absolute adressing. One needs a correctly initialized pointer instead. Sometimes, pointers are of high order (pointer that points to a pointer that points to the variable) and difficult to built, but I can help you.

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