Hi Hitman,

shouldn't there be a possibility to stop the crash dive somehow? If there is none, I'm wondering what the idea is? Wouldn't this just be a random chance for a career end whenever you press 'c' :06:, i.e., whenever you press 'c' you play a virtual Russian Roulette?

@Stiebler: According to my observations the q-d tank is emptied, but extremely slow when crash dive is interrupted.

In both cases (non-interrupted and interrupted crashdive), different routines write to the q-d tank.

By the way: If you have the address of the q-d-tank, simply add 0x8 and you'll have the address of the "crash dive flag" (a single byte), which could be useful.

I'm tired now and continue during the next days.

Gähn!!!
h.sie

@H.sie:

Thanks for this important information.
I have sent a PM.

@LGN1:
You make a valid point.
The code I have in mind will simply reset the quick-diving tank as soon as the U-boat sinks below 40m.
Therefore, if a player has crash-dive depth set to (say) 20m, the 'crash-dive blues' will be ended as soon as the boat sinks below 40m. Thus, there will be a problem only if the player tries to maintain a depth set to less than 40m, after ordering the crash-dive.
But in any case, if the crash-dive depth is set at 20m, it is probably a simple solution just to allow the crash-dive to settle out before diving deeper. You will have time for that. You may not have time if the crash-dive depth is set to 80 metres.

I believe that I am very close to getting right the code for the solution that I have proposed. Then we shall know if this solution affects the ability to blow ballast, has H.sie has suggested. And we can test other matters, as LGN1 has mentioned, also.

Stiebler.

40 meters
 

Hello Stiebler and h.Sie

The reason for crash–dive in depth less than 25 meters is —for me— simple:

Shallow waters (example: around Britain, raids in ports etc.) + no crash–dive–blues.

Of course, without crash–dive–blues, we can tweak the crash–dive for 300 meters, and interrupt (or restart) at any depth.

So, I don’t understand very well the critical point of 40 meters. If —anyway— I must pass below 40 meters, this solution is not valuable when in shallow waters.

I miss something, yes? :hmmm:

@Stiebler: Yesterday I discovered that under certain circumstances (crash-dive interrupted but q-d-tank not completely filled to 1,0) the q-d-tank indeed goes back to 0.5, but very, very slowly, because a certain routine R continuously writes data into it.

So if you simply reset the q-d-tank to 0.5 once, you risk that this value will be overwritten under the above-mentioned circumstances.

And if you write 0.5 repeatedly, this will interfere with the values from the above-mentioned routine R, which also tries to write other values into the q-d-tank. This can lead to "oscillations".

Since the above-mentioned routine R also writes to other things different from q-d-tank, one cannot simply disable or patch it. Patching / disabling the routine R will only work, if one finds out, if R is currently trying to write into the q-d-tank or not. For this reason we need to work with pointers.

So my approach is a soft-hand-solution by trying to understand how R works and then modify it accordingly, but only if the pointer register currently points to the q-d-tank.

Happy hacking!
h.sie

i want realistic repair and flooding time mode but i dont see no link :doh:
i looked at last page but there are only description ,no link:down:

Open your eyes and read first post on first page carefully (read under "Step3"...)!

Here are the download link: http://www.mediafire.com/?a6j533a02wsf39d

Best regards,
Magic

@H.sie:
Not a problem (I think...).

I found that, by observing the crash-dive flag that you found earlier, the flag is set to false (from true = 1) when either of these circumstances occur:
a) the q-d-tank starts to empty.
b) the crash-dive is interrupted.
When the crash-dive flag is false, the q-d-tank is not emptied at all, and the code is not used.

Using this information, I have now complete code that does everything I intended. (Whether what I intended will work usefully, remains to be seen.)

I need only to fix a simple bug (forgot to reset jump addresses when changing the label at the new address), and I expect to have fully working code.

However, there remains a significant problem:
I am testing for the q-d-tank by asking of each value of ecx at my breakpoint if a filled diving tank is at location [q-d-tank - 0x14].
What happens is that the q-d-tank fills too quickly, before the diving tank is itself filled. After that the q-d-tank/ecx value is not encountered again until the q-d-tank starts to empty at about 40m.
So everything works fine, *provided* that no one interrupts the crash-dive before the U-boat has reached around 40m.
I have an alternative idea to fix this, but first I want to confirm the properties of a U-boat whose crash-dive has been interrupted at 40-50m.

That is tomorrow's problem - if I have time.

@NGT:
I understand your argument perfectly, and perhaps we could make the code run from 18m, not from 40m.
But first, I must test that the guiding principle works.

Stiebler.

Guys I can't understand the instructions.

I have copied my sh3.exe to my desktop but the batch file still says incorrect check sum, saying fciv isn't recognised. I have version 1.4.0.1

Thanks.

Join the club.

The problem is simple: There are about half a dozen different variants of sh3.exe. h.sie's mod only works with one of them.

Yet, they're all the "same" version, 1.4. But not really, as they are all different in subtle ways.

Some sh3.exe's include hooks for the Starforce malware. Newer ones don't, yet are still incompatible with the patcher.

Then you have people who have implemented the "4GB" patch.

Naturally, there's mass confusion.

You have to copy fciv.exe to the desktop, too

Hi NGT,

I think also in real-life you could not crash-dive in shallow water because you needed a certain depth to stop the diving. So, not being able to use the crash dive command in water shallower than, let's say 40m, sounds realistic to me:06:

Personally, I think the 40m 'boundary' would be fine (I think most super-mods have a deeper crash-dive depth than 40m. So, most players would be fine).

Cheers, LGN1

@Stiebler: I have different observations, in the following situation:

1) Order crash dive.

2) When boat has depth of about 20m, interrupt dive by ordering new depth of 40m.

This leads to a very slow but constant empying process of the q-d-tank. During this time the code at Sh3Sim.act+0xA7B7:

fst dword ptr [ecx+08]

constantly writes new values into the q-d-tank. This process takes about 5 minutes, until q-d-tank is 0,5.

Happy hacking!
h.sie

@H.sie:
Thanks for the new info.

But.... I have solved it all!!

First, I have now functioning code that checks for an interrupted crash-dive and writes 0.500 to the q-d-tank. This works well, with *no* depth limitation, but subject to the complicated limitation that the q-d-tank must be full (1.0000) before the code functions. So you cannot interrupt the crash-dive with a new depth until about 20-30 seconds of game time have elapsed. I had written elaborate code to identify the q-d-tank variable and to separate it from the main diving tank.

If the code is allowed to function properly, then an interrupted crash-dive maintains its new depth at slow underwater speed indefinitely. I have tested it, it is true.
Also the 'blow ballast' function works perfectly both with a completed crash-dive and with an interrupted crash-dive. I have tested it, it is true.

So I have a working program. With a lot of heavy code to identify the q-d-tank and its crash-dive flag.

But I have discovered something else!
the q-d-tank is referenced by float [esi+438h].
the crash-dive flag is referenced by byte [esi+440h].

Tomorrow, I shall re-write my code much simpler, and with no timing or depth limitation!

Stiebler.

Tell me about it. I've been following this thread from the start. The other day I decided I couldn't wait any longer and tried to use the patch. Wrong checksum. :damn:

I have a later, budget 'Focus Essential' disc version. No starforce as far as I know, but still, wrong checksum. :wah:

But I have absolute faith in h.sie's abilities and (being an optimist) believe once he's created all the changes he wants, he or Stiebler will turn their efforts to improving compatibility. We can only hope. :D