@SSB: Noone rushes us. Only if you have time and feel like modding.......

AI Torpedos from the past
 

Yes, TheDarkWraith:

http://www.subsim.com/radioroom/show...t=AI+Torpedoes

I think the dive and evade part of SH3 gameplay lacking and could be a huge boost for SH3?What I mean is things like the first dive and the fact that a DD headed towards you pinging as it charges is a very dangerous time for a uboat.I find that it all seems so easy,though this could be because I am in early part of the war.So I ask you guys if its easier then it should be?

Then I think of how it would be if the pinging was accurate and I realize that the actual dive mechanics of the uboats needs to also be altered.

You have a DD charging at you....you order flank ahead to gain as much speed as possible before the main ballast tanks have filled...and your helmsmen are constantly slowing the ship down by applying hydroplanes too early=bad

Your sub starts to submerge and the diesels cutoff and you wait a few seconds for the electrics to spool up=bad

Your now diving at a crawling pace because the game models only the main ballast tank and so its at a slight positive buoyancy=bad

Now Hsie,before you tell me you will not quit your job to model all this:haha:I feel it should be a more joint effort with more people involved.

Some things that could be changed to allow better pinging attacks and hence tension when being pinged.

Have it so that hydroplanes turn at different times for the different uboats so that first it willallow the boat to gain as much speed as possible before entry to enhance its initial dive speed and also make the fact that 25 secs compared to 35secs dive time WAS in fact a huge advantage.

Second is the way the diesels turn off and you wait a few seconds for the electrics to come on.This is way wrong since it was pretty much instantaneous and even done on the surface before the dive starts.In Sh3 they probably did this so that the engines are not constantly switching back and forth under heavy seas.I would think that the signal to dive would be enough though but I have no idea if that can be modeled in.

Third is about modeling in a placebo negative tank.What I mean has to do with Hsie's statement of an idea to model the ship getting heavier under silent running by changing the mass of the boat.I am thinking something like this.Model the initial dive mass to simulate the boat negative tank being filled by making the mass a bit heavier.Then hitting maintain depth equalizes the mass so that its now back to the default slight positive buoyancy we have now.Now here is where it gets tricky....how to model in the slight raising of mass when silent running????


Some more things for more realism in the dive and evade gameplay.Pinging for depth should have a consequence and so be heard by the uboat if its hydrophones are pointed towards you.It gives a slight chance of giving away where you are and adds tension to the mix for the captains.Same thing with blowing negative tank....a slight chance of being heard.

My game sometimes has the SO screaming depth charges in the water and alot of times not.I think this was a very important time for the uboat and when DC's in the water was spoken the boats did emergency manuevers to compensate.

Hedgehogs should be deadly now if the enemy is close upon charging!!!:arrgh!:

I believe that even if the item is invisible it's still detectable (unit wise). Don't quote me on that but I do recall doing some testing in that area many years ago. To make them invisible set the Visible property in the Type 4/100 nodes to 0.

It's not that lead angle isn't calculated correctly. The problem with spawning real torps is that they always point north and are never 'fed' a torpedo solution. They just continue blindly heading north until they hit something or run out of fuel. Even if fired from one of the other cardinal directions they will turn to head north.

One thing I never tried was using acoustic torps. By all rights those should work since even though they would initially head north they should lock onto a sound source and follow it. But that all depends on the FOV of the seeker head for locking onto sounds. I don't know what the FOV is for them and don't recall any parameters for them. Maybe it's 360?

But very small objects are much less detactable than huge objects. So what about a very small sub with very unfriendly weapons.

Privateer tried something similar IIRC. But yes, the smaller the object the smaller the cross sectional area shown to the enemy and thus harder to detect.

EDIT:

the 'problem' with firing real torps could be fixed by feeding the torps the initial heading of the unit/item that fired them. If they can 'get' this info I believe then they could be used.

tdw, thanks for your support here. we need some more skills around here...

:yeah:

In future releases patches you may want to add the following.
Small submarine (type 2A / D) more sway over the navigation on the ocean surface, but larger and heavier submarines.
That the submarine suffered minor damage during the voyage across the stormy weather at sea level.
If the damage is repaired immediately it would not be accumulated over time, which could eventually lead to the sinking of the submarine.
If it is already in the plan to allow the issuance of the abandonment of the submarine should then disable the termination of the mission, campaign, his career as soon as one section of the submarine filled with water.
It is not realistic and a lot of examples from the history of submarine to the contrary that although multiple sections submarine was flooded in undamaged areas of the crew members survived.
There are numerous examples of sunken submarine crew who survived the undamaged parts of their boats to remember the crew of HMS Thetis (N25);

USS Squalus (SS192)http://www.onr.navy.mil/focus/blowba...s/flooding.gif;

USS Tang (SS306 )http://www.navsource.org/archives/08/0830625.jpg.... Kursk.
Successfully managed to emerge the crew, whose submarines were at depths less than 60 meters.
In the case of U-49 type-7b submarine, which is 15.04.1940 god. sunk in Narvik depth bombs from the British destroyers HMS Fearless and HMS Brazen and where a submarine was killed 1 and 41 survived and continued to serve in the Kriegsmarine.
The U-580 type-7c, which is following a collision with his victim boat Angelburg 11.11.1941 god. sank with 12 submariners were killed and 32 survived and continued to service the U-166 type 9C up to 30.7.1942 as when they died somewhere in the Gulf of Mexico.
U-185 tip9c/40 24.08.1943 which is flooded in the Middle Atlantic deep with 3 bombs from Avenger and Wildket where the 29 submariners died and 22 survived the first time but only 14 of them underwent to save U604.
U-284 tipe 7c 21.12.1943 which sank due to heavy damage south of Greenland and all 49 of whose crew members rescued submarine U-629.
U-476 tipe 7c which is 25/05/1944 northwest of Trondheim severely damaged by depth charge with Katalin where the 34 submariners were killed and 21 survivor is picked up by submarine U-990.
U-1013 03/17/1944 tipe 7c/41 who suffered a collision with U-286 in the Baltic with 25 submariners died and 25 survived.
And an example of how a man is strong when it comes to life on U512 tipe 9c which sank 02/10/1942 deep bombs as the B-18a and 51 of whose crew died and only one survived and the only one who spent 10 days in the water fighting for their own life before finally rescued of the American destroyers.
U-250 tip7c 07/30/1944 was hit in the area Diesel-room a deep bomb from the Russian destroyer MO-103 at 27m depth in the Gulf of Finland.
At the last moment the captain and five crew members are from "Zentrale" failing to leave the dying ship and become a Russian POW.
The Russians were soon after dragged to the surface of U-250 and you can see in the pictures below.
Notice the picture in the middle-order the depth charge "open" the body "Diesel room." On the last picture are 5 of 6 surviving crew members.
http://www.sk.rs/forum/attachment.ph...0&d=1243323970http://www.sk.rs/forum/attachment.ph...1&d=1243323979http://www.sk.rs/forum/attachment.ph...2&d=1243323991

yep, sign on that. it always disturbed me, that you loose your whole boat, just cause one section is flooded...nice idea, dude. thanks for that.

Oxygen supply
 

H.sie has recoded his V15G1 oxygen supply in such a way that my Options Selector can alter values on two sliders.

It was during testing that I realised that we have overlooked a component of the oxygen supply to the crew.

At present, the code consists of two components:
1. A renewable air supply, refreshed every time the U-boat surfaces.
2. A fixed air supply from compressed oxygen cylinders, which cannot be renewed when exhausted.

However, the crew of a submerged submarine cannot continue to release compressed air into a submarine to replace the oxygen which has been consumed. The pressure of the air in the sealed hull must keep rising, and at some point there must be a limit which is dangerous to the crew.

There are many U-boat stories, of how the crew brought a U-boat to the surface after a long time underwater, and, when they opened the hatch, the watch crew was nearly blown out of the hatch by the huge pressure in the U-boat hull. I repeat, there must be a limit to how much compressed air can be added to a sealed hull.

Therefore the code needs to take into account, not two, but three factors:
1. The renewable air supply, as previously.
2. The fixed air supply from compressed oxygen cylinders, from which only a certain amount of gas can be taken during each submergence.
3. However, there will remain a large quantity of unused compressed air, which can still be used after the next submergence. That is, after the U-boat has returned to the surface, equalised its pressure with the atmosphere, and then dived again.

The reason I mention items (2) and (3) is this problem, found during testing:
If the compressed air supply is too small (the current situation with V15G1), then it is all used up within 2-3 days of continued submergence, and the U-boat would have to return to base.
If the compressed air supply is too large (an option I am testing with the sliders), then the U-boat can stay submerged for much too long (up to a week).

The real situation is that you need a large supply of compressed air, so you do not have to return quickly to base, but you can only use a limited amount from this large supply during each submergence.

This could be coded by a limit on the amount of air that can be withdrawn from the gas bottles during each submergence, with a maximum limit that can be taken during each patrol.

One can imagine it thus:
For every patrol, the U-boat has (say) 10 bottles of oxygen. It can only open one bottle during each submergence.

I hope that is clear.

Whether this is worth all the coding trouble is hard to say. However, at present we have the tricky situation that the compressed oxygen supply can only be too small (won't allow 18 hour submergences), or too large (will allow extended patrols underwater). There is no middle way, unless the amount that can be taken in each submergence is limited.

Comments, please.

Stiebler.

In original sergbuto's Wolfpack mod, cannon, which simulated of "torpedo shot", had the geometry with visibility flag = 0...
For accuracy in terms ... in game there are AI torpedoes ... but there are no launchers for these torpedoes, with the exception of human sub(s) (wpn_SubTorpedoSys).
What is it "always point north"?
If you use for generation ("launch") of torpedo controllers as WhaterInteraction or ParticlesGenerator, you will receive orientation of torpedo as in its settings in chunk Type 4/100 - Rotation: Y = 0.0, since these controllers do not transmit (not inherited) orientation of object, which generated that torpedo.
Why? Because these controllers are designed to work with particles/effects where the inheritance of orientation is not needed.
lol... If you do not like the "North", you can choose any other such as Y = 1.24... ;)
And, AI Torpedo (controller amun_Torpedo and so on) will not work properly if the torpedo will be have the parent object (or in other words, if this torpedo will be child object). Example: torpedo generated by ParticlesGenerator.
...
And all this was known even before you were born on this forum... :03:

@Stiebler: Only to make sure I understand things correctly:

You suggest a restriction of the usage of the compressed O2 supply to a certain amount (to, say, 10% of the total compressed O2 supply) for every dive-session?

I must admit that your arguments regarding air pressure in the boat sound plausible to me!

But I also ask myself: Is it worth the coding effort?

Reason: Since there is no gauge (and no code at all) for air pressure in the boat, I need to code a statesmachine for LI-warnings:

-"High pressure in boat,Sir"
-"Very high pressure in boat,Sir"
-"Very very high pressure in boat, we have to surface!"
-"Aaaaargh!" and so on.

It also must be programmed what happens if the boat does NOT surface when very high air pressure in the boat. Crew dying? Game over? I could program a nice CTD as discipline for the player.

I feel helpless - especially since all O2-programming is and has been based on more or less assumptions.

Did you get any answer from your friend you consulted days ago?

@Stiebler:

Additional note:

The changes you suggested require to implement a totally new 3rd component to the game: the air pressure in the boat (what also requires to code what happens when pressure is high, very high, too high and so on).

Consequently, one should then also model the CO2 in the air as the 4th component (including coding all the situations that can occur when CO2 is too high and so on).

LGN1's and my initial idea was to implement a 2nd component to get an coarse approximation of reality, knowing, that it is still not exact, but better than stock sh3 with only 1 component. Now you suggest a 3rd component. I remember someone in the thread asking me to model CO2. Then we have 4 components. You have seen the code for the 2nd component. Numerous lines of assembler, ALTHOUGH the situation is very easy:
If (O2 in air too low) THEN {Use O2 supply}. - Nothing more had to be considered.
But the 3rd component "air pressure" is much harder to program, reasons see above.

I'm not saying that I won't do that, but at the moment I'm tired of O2 modding.

For all those who don't like the current O2-Supply solution, I offer to simply enlarge diving times (especially for the XXI) in case they disabled the O2-supply mod: TypeII: 60h / Type VII: 72h / Type IX: 80h / Type XXI: 150h.

@SilentAce: Already on the todo-list.

@H.sie:

No need for lots of new messages about air pressure.

We require only a restriction on how often the compressed air can be used. Use a timer (hours only). Then LI announces: "limit on compressed air reached - we must surface!"

[Edit: The real problem, as stated above, is that the coded U-boat compressed air supply must always be too big or too small. If it is too big, the U-boat can stay submerged for a week or more. If it is too small, the U-boat cannot cross the Bay of Biscay safely, as per orders. I don't care about the air pressure. I used the air pressure as an example of how the real U-boat had the performance that it had underwater. We need to mimick this performance by a simpler route.]


It will be a few weeks before I get a reply from my 90-year-old friend.

Stiebler.