maybe torpedo got damaged, too, or tube was damaged so that removing torpedo wasn't possible?

For the torpedo tube get so damaged that you cannot even retrieve the torpedo, I guess the uboat would be doomed.

But in sh3, you can unload the torpedo, and after its fully unloaded, you ask the crew to reaload that torpedo on a different tube, its not done. They reaload in the same torpedo tube as it was before.

Does the sh3.exe have the controller for switching to diesel/electric independent from being surfaced/submerged?

Its a very important thing to change.

Apologies if your problem was more complex......
but did you have the Auto-loading box ticked?
If you un-tick this box you can usually choose which tube to load into with simple drag and drop.

Yep, I've tried.

No donut.

already on the todo list

:)

JUST REMEMBERED!

The most important thing to fix (at least in my head, as a sound modder) is to add a trigger to use one ambient sound file when ur submerged, and another for surfaced.

Then, we can start using sounds that fit the situation. No more diesel engine sound when you're submerged. No more crew chatting while having dinner at the same time you're in rig for silent running, being depth charged.

By the way, another trigger for silent running too.

If that can be done, I will work on the sound itself.

...my focus is currently not on sound issues. maybe later.

regarding manual switching between electric and diesel engines when surfaced: this would only make sense if the ememy could hear you better with diesels and worse with electric engines. but in the current state, the enemy doesn't hear you at all if surfaced, regardless of diesel or electric engines running.

h.sie

Hi Hitman,

do you have any sources for the max. speed the periscope could be used? And at what speeds it became useless? I ask because I could not find any real data and there is nothing mentioned in the original U-Boot Handbuch :hmmm: Maybe it's not mentioned because no Kaleun would use it at such speeds because of the higher detection chance?

On a different subject: Can you confirm that the hydrophone could not be used when snorkeling? Do you know the max. sea state at which the snorkel could be used?

Cheers, LGN1

That is a brilliant idea! FM's New Interiors adds diesel sounds to the interior when surfaced, but they have problems. Having a separate Ambient Interior file that runs when surfaced is the perfect solution...if it can be made to work.

Just an addendum to the compressed air consumption when you use crash dive. It seems the amount you need depends on the crash depth in your NSS_Uboat*.cfg file. If you have a deep crash depth more compressed air is used. This makes sense because the pressure is higher when you level out (however, historically the Quick Diving Tank had to be emptied close to the surface).

It's also noteworthy that there is a small gap between the blowing of the Quick Diving Tank and the leveling of the dive planes. So, if you want to dive quickly to a great depth and avoid the crash dive blues in NYGM, you should order crash depth and watch the compressed air dial. As soon as it stops to move (close to the crash depth) you should order the new depth (you might have to correct the compressed air dial in dials.cfg in the menu folder).

In the first version of my snorkel fix I modified the routines which are resposible for the machine telegraph: If the boat is currently snorkelling and I order a new speed which is faster than 2/3 ahead, the speed order is automatically reduced to 2/3 ahead. This worked well.
But unfortumately, that solution was not sufficient, because if you e.g. drive surfaced with flank speed and then dive to snorkel depth, no speed change is ordered and thus the boat will be still on flank speed when snorkelling.

So for my second version I’m programming a routine that checks the speed every 10 seconds when snorkelling. More exactly: There is already such a routine that makes calculations every 10 seconds, and I simply modify it. Every time a speed above 5knots is detected while snorkeling, a WM_KEYPRESS message for the key “2” will be generated, so that the executable thinks the user pressed “2” to order new speed 2/3 ahead. Optimistic that it will work.

Now I’m thinking about how to consider Wind speed / wave height. Possible values could be:

Wind speed 0-5m/s: Speed will be reduced to 2/3 ahead.
Wind speed 6-10m/s: Speed will be reduced to slow ahead.
Wind speed > 10m/s: Snorkelling not possible. Engines will be stopped by the watch routine.

Are these historically correct?

by the way: I think I found out why high time compression leads to numerous problems:

there is an internal master routine in sh3.exe that is executed once per second and recalculates millions of variables: weather changes, detection probablilities, every little fart of the crew. this is no problem for modern CPUs, all calculations are done in a fraction of a second. When time compression is 2x, the routine has to be executed twice per second to give an exact simulation. No problem. Even 64x works, the routine is executed 64 times per second.

But when I chose TC=128x on my average PC, the routine cannot be executed 128 times per second, it is only executed about 100 times. the missing 28 calculations are cancelled, because otherwise program flow would be jammed. When I now rise TC to 1024, the routine can still be executed only 100 times per second, but it should be executed 1024 times. this discrepancy leads to very inaccurate, defective simulation results in some aspects.

I have readed so many books and reports that it's difficult to remember the sources sometimes :88)

Must double check, but IIRC the reference to maximal snorkelling speed comes from Clay Blair's book, and the reference to periscopes from "US submarines through 1945" by Norman Friedman, App. II (Periscopes). Friedman comments the several proposals received by the US Navy from different makers of periscopes and problems encountered, and comments that german subs also had problems when speeding up due to periscope vibrations. In the case of fleet boats this would be even worser, as they had quicker underwater speeds.

Good to know, it's important news. But what aspects do we lose? From what you say the defect should be very big, but do we see any symptoms of it (eg. on 1024) besides the detection problems in game? Are the problems so serious?