Sh3.exe and Asdic in shallow waters [Archive]

Stiebler

11-05-11, 02:41 PM

From October 1944 - May 1945, U-boats with schnorchels patrolled very close to land around the British Isles, relying on the poor detection ability of Asdic in shallow waters, with their fast tides, large rocks and ancient wrecks.

SH3 does not model this failure of asdic in shallow water at all.

I have been looking at the problem, and have now a functioning double-code patch that changes asdic capability according to the depth of the sea. Specifically, the 'minimum surface' (MS) of asdics (original values found in file AI_Sensors.dat') are now changed according to sea-depth in four bands:
Depth > 150m: MS = 100 (m2, metres squared).
Depth >100m: MS = 150
Depth >50m: MS = 200
Depth < 50m: MS = 300.

These changes are not dependent on the year, they will apply throughout the war.

However, for some reason the properties (range, angle, MS, etc) of the asdics are not connected to their names, after loading into SH3. For this reason, I have found it necessary to use a unique value for asdic minimum surfaces, that is, the original value of 100.0 (in NYGM), for identification purposes. But other versions of AI_Sensors.dat use values different from 100.00 (eg GWX, value =0.0).

Therefore I have three queries:
1. Does anyone actually play SH3 around Britain in 1944-1945?
2. Will users be happy to change the minimum surface values of their asdics (only the asdics) to 100.00 in their files data\library\AI_Sensors.dat? It will require manipulation of this data file with a data editor (eg FileAnalyzer, or S3dtor), and the changes cannot be made with a text editor. [Thought: perhaps I could supply these files for stock and GWX as part of the patch-kit.]
3. NYGM has always used the MS=100.00 values, but my other choices of 150, 200 and 300 for decreasing depths are pure guesses. Would anyone be interested in testing this mod, once I have settled the other issues above? It will require a revised SH3Sim.act file, which I can supply, and an extra patch-kit for H.sie's V16A3 patch for SH3.exe.

Otherwise, I shall just keep the mod to myself!

Stiebler.

reaper7

11-05-11, 02:46 PM

HW3

11-05-11, 04:01 PM

Hum...might make bottoming a u-boat a viable evasion tactic like it was in real life.:hmmm:

Gerald

11-05-11, 04:26 PM

A simple concept, avoid shallow water, where there is the issue of a need....

Jimbuna

11-05-11, 05:06 PM

Hum...might make bottoming a u-boat a viable evasion tactic like it was in real life.:hmmm:

Agreed.

Fish In The Water

11-05-11, 08:29 PM

SH3 does not model this failure of asdic in shallow water at all.

I have been looking at the problem, and have now a functioning double-code patch that changes asdic capability according to the depth of the sea.

Sounds very interesting. Would certainly be a most welcome addition. :yep:

postalbyke

11-05-11, 11:56 PM

Could be fun to test... I think I missed parts of it in the technical...
Explain again slowly the meters squared part, please?

I play NYGM so it wouldn't be a stretch...

ETsd4

11-06-11, 04:20 AM

definitely interested.
The meaning of "minimum surface of asdic" is totaly unclear for me.

complutum

11-06-11, 04:30 AM

interested on testing, i'm a GWX user

Stiebler

11-06-11, 05:30 AM

Thanks for the interest, those above.

But no one mentioned 1944-1945, did they? Hmmmm..

'MinimumSurface = 100.0 metres squared':
This means that the asdic must contact 100 square-metres of U-boat hull in order to send a contact-ping back to the transmitting warship. If the value is raised to 300 in very shallow waters, then 300 square-metres of U-boat must be contacted (about 17.5 x 17.5 metres.)

The value in GWX = 0.0. Maybe that explains why no GWX user ever makes it to 1944-1945.

Stiebler.

jean74

11-06-11, 05:57 AM

Hi Stiebler,

If You can realise it, it would be another great improvement ! So far, I think it would make the scapa flow attack more realistic, because when DD detect you in swallow water at long range, it is a realism killing.

Thank you for your work,

Best regards from France,

Jean

LGN1

11-06-11, 07:02 AM

Hi Stiebler,

very good idea! However, I'm reluctant to change any sensor parameter without proper testing and understanding of the relationship between this parameter and the other.

As long as one does not know the real effect of varying the MiniumumSurface value, I think a better solution would be to randomly set the max. height parameter of the ASDIC sensor depending on the water depth. This would be a much better 'controllable' approach.

For instance, for a water depth of less than 50m there is a high chance that max. height of the ASDIC is 60m --> ASDIC will not work in shallow waters most of the time,...

Regards, LGN1

Fish In The Water

11-06-11, 07:38 AM

The value in GWX = 0.0. Maybe that explains why no GWX user ever makes it to 1944-1945.

No wonder there's nowhere to hide.

Zero meters of hull contact and yet still detected... Well that seems fair. :haha:

HW3

11-06-11, 09:08 AM

I've actually made it to the end of the war in GWX but, it sure wasn't easy.:eek:

LGN1

11-06-11, 09:31 AM

No wonder there's nowhere to hide.

Zero meters of hull contact and yet still detected... Well that seems fair. :haha:

Well, maybe SH3 takes some default value if the variable is set to zero :06: As long as we do not fully know how the value enters the detection algorithm it's useless to speculate about the value of the variable.

Regards, LGN1

PS: Just to give an example. IIRC, in SH4 modders created a visual sensor with a NEGATIVE value for the surface parameter and in this way could create a sensor that could 'see' the submerged sub.

Jimbuna

11-06-11, 10:20 AM

I've actually made it to the end of the war in GWX but, it sure wasn't easy.:eek:

Same here and I suspect a good many others.

Stiebler

11-06-11, 12:21 PM

LGN1 said:
I'm reluctant to change any sensor parameter without proper testing and understanding of the relationship between this parameter and the other.

As long as one does not know the real effect of varying the MiniumumSurface value, I think a better solution would be to randomly set the max. height parameter of the ASDIC sensor depending on the water depth. This would be a much better 'controllable' approach.So far as I am aware, the only result of changing the minimum surface area is to change the ease with which the target is acquired by asdic. You may be right, that a value of 0.0 will be replaced internally by a default value; it certainly happens for one of the U-boat mass measurements, I forget which.

However, it is impractical to use maximum heights of sensors because they can vary. Remember that the name of the sensor is not associated with the data, therefore it is essential to tag the asdic minimum surfaces with some unique value. (0.0 is not unique here, incidentally.)

I've done a lot of testing with current asdic sensor values today, and they seem to be quite good. In shallow water (<50m deep), the escorts can still locate a VII U-boat with minimum surface=300, although they lose contact fairly quickly. But that is what we want.

Another factor is that probably the tiny type XXIII will NOT be located by asdic in shallow water. And that is correct too (more or less).

Stiebler.

makman94

11-06-11, 01:10 PM

Wow Steibler that is amazing. I would definitely be Interested in this for U-Boot_HAHD.
This would suit perfectly the TypeII as they are perfect boats for in the shallow's which we are basing our first Release on.
I'll get Makman94 to talk to on this matter as hes currently looking into sensors for our Mod.
:salute:

EDIT: Hi Mate sent you a PM on this :) Would be happy to test ;)

i will fully gladly help Stiebler (if he want or need any help-tests) as much i can in sensors part becuase i believe that correct working sensors is the number one in list for having a 'realistic' gameplay (as far we can achieve )

@Stiebler : Excellent idea the asdic in shallow waters !!! as long as you are in this part in .exe ...please have a look at the 'vampire nights' issue (own crew has very large visual ranges during nights .tweaks at light factors at sim.cfg and sensors.cfg doesn't 'help' much to 'beat' this). so , i believe that a selective sensors project (meaning the game 'reads' other visuals during afternoon and other during deep night ) will solve the issue and will be an 'evolution' at final gameplay. if you have the will ...just have a look at it,i believe that it worths the effort !

bye

Rubini

11-06-11, 02:08 PM

i will fully gladly help Stiebler (if he want or need any help-tests) as much i can in sensors part becuase i believe that correct working sensors is the number one in list for having a 'realistic' gameplay (as far we can achieve )

@Stiebler : Excellent idea the asdic in shallow waters !!! as long as you are in this part in .exe ...please have a look at the 'vampire nights' issue (own crew has very large visual ranges during nights .tweaks at light factors at sim.cfg and sensors.cfg doesn't 'help' much to 'beat' this). so , i believe that a selective sensors project (meaning the game 'reads' other visuals during afternoon and other during deep night ) will solve the issue and will be an 'evolution' at final gameplay. if you have the will ...just have a look at it,i believe that it worths the effort !

bye

I seconded that. Fully agrre with makman94. A tweek/fix on visual sensors is a must have, a real necessity for sh3. We already have gone so far in mods but that vampire nigth view is yet a total immersion killer and irrealistic.

Now, coming back to the main issue here, great work Stiebler! Looking forward to this new mod. PM me if you yet need beta testers.:up:

LGN1

11-06-11, 02:16 PM

Thanks a lot for the reply, Stiebler!

If one has to touch the AI_sensor.dat anyway, one could enter values for maxheight that would allow an identification :hmmm:

Anyway, while thinking about it, I remembered that for some sensors the value from the sim.cfg file is used if the value is 0. For sonar this is 100 m^2 in GWX. However, the other sonar parameters differ from NYGM, so it's important for those not using your mod with NYGM to (maybe) adjust the value.

Regards, LGN1

reaper7

11-06-11, 02:23 PM

This is going to be another great addition to Sh3 :up:

Were sensor ranges effected by weather in real life, if so maybe its possible to do similar to h.sie WIP Torpedo duds fix by applying decreasing range by waveheight :hmmm:
And also as mentioned above with the Vampire Vision of players U-Boat (Sensors.dat) and the AI Visuals (AI_Sensors.dat) could these be decreased as light levels dropped.
So there would be different values applied to Visual sensor for Dawn, Day, Dusk, Night and possibly Fogy conditions. :)

Any changes required to files for your Mod to work, will be Included with the U-Boot_HAD Mod to maintain compatibility with your work :up:

Rhodes

11-06-11, 06:32 PM

Same here and I suspect a good many others.

Ideed! I love the idea since normally I tend to patrolling the UK waters for realism/immersion and got mix results like, a few times I detect the destroyers but they pass and do not find me. If one manages to detect me, there is no way to escape it, plus the shallow water= kaput!

Fish In The Water

11-07-11, 02:14 AM

Well, maybe SH3 takes some default value if the variable is set to zero :06: As long as we do not fully know how the value enters the detection algorithm it's useless to speculate about the value of the variable.

I hope you're right. Otherwise, on the 'surface' it doesn't look good. :03:

Stiebler

11-07-11, 10:16 AM

I was sufficiently interested in whether GWX substitutes a 0.0 Minimum Surface contact area by default with another value, that I checked it.

I ran single mission Convoy PA69, set in 23 Feb 1944. A quick check on the mission file showed two escorts, both of type COBathhurst. Another check in the Sea folder for COBathurst (.sns file) shows that they have asdics 147A fitted in February 1944.

Then I checked through my code intercepts while running the single mission. Sure enough, in the code-subroutine where the original stored values from AI_Sensors.dat are moved into the asdic memory area for each warship as it is spawned, I could detect the distinctive data (ie, Minimum Range all the way down to Minimum Surface) for the GWX 147A asdic, as listed in the GWX AI_sensors.dat file.

The Minimum Surface value was still 0.0 at the point of transfer. So this really must be the value used.

Does this information change the views of any GWX players for the Minimum Surface values that I intend my asdic mod to install according to sea-depth?

Stiebler.

Stiebler

11-07-11, 10:23 AM

Rubini

11-07-11, 11:32 AM

Rubini

11-07-11, 11:49 AM

Sorry to insist on the matter, hopes that for a good cause.:D

To make a mod for visual detection issue is probably just a matter (but I don´t have any thin idea on how to make it or the probably hard time to make it) to find the sensor visual max distance memory location (as you did for asdic) and if the enviroment is day left it as is, if is dusk cut it to 2/3, if night just cut it to a 1/2 or 1/3. Perhaps could be also need to make it to Ai visual sensors ... (but Ai visual sensors at night is already more responsible on sim.cfg/Ai_sensors.dat than the uboat crew ones).

Excuse me again to stay on this matter.:oops:

Cheers mate!

h.sie

11-07-11, 11:59 AM

Rubini

11-07-11, 12:34 PM

@Rubini: Since Stiebler isn't interested: I already offered makman via PM some days ago, that I'll look into the vampire night sensor issue, since I already "hacked" the visual sensors for the VIIF wolfs. But for this big project, I need time and energy. If it's me to do the job, patience is needed. But I don't want to hinder others to start to play with the sensors.
Hi h.sie,

Thanks to look on this.:up:
We have all the time mate!

The truth is that we (i can for sure speak for a lot of ppl here on the followed matter) like very much and we are very thankfull on what you and Stiebler have done, you both knows that.

And we also know (because a lot of us are also modders...well at this time probably any sh3 player already made at least one tiny mod!:DL) that any mod work is a very time consuming task and that the main and primary ingredient is ourself motivation.

Every time that i write something here I spent a lot of time reading my post to try to not be so much that type "please do this, please to that" because I know how hard is this work (and believe me, with my english limitations is yet more hard to express myself:damn:). So, like I said, excuse us if sometimes seems (just seems!) that this entire community are now over you both!:D

Fish In The Water

11-07-11, 12:40 PM

I was sufficiently interested in whether GWX substitutes a 0.0 Minimum Surface contact area by default with another value, that I checked it...

The Minimum Surface value was still 0.0 at the point of transfer. So this really must be the value used.

Does this information change the views of any GWX players for the Minimum Surface values that I intend my asdic mod to install according to sea-depth?

Very interesting findings...

Before I answer your question, I feel I should provide a bit of background to set the proper context. I'm a long time GWX player who has a love/hate relationship with the mod. Yes I said 'hate,' but not in the classic sense as my criticism doesn't come from a place of malice or spite but rather from a desire to see it better.

On the one hand I think certain parts of GWX are absolutely wonderful, whereas a few others I find quite appalling. That being said, the good far outweighs the bad and so I continue to play.

All of which brings us to your question. If your findings are correct, then I would have to place this in the 'appalling' category. I say this as an individual who has long enjoyed 'realistic' sims as opposed to what I would call uber AI sims.

Speaking in general terms, if the goal is to emulate the historic conditions of the Battle of the Atlantic then I would say the player should be given about a 25% chance to survive. This strikes me as both eminently fair and realistic.

This being the case, one has to ask why the perception (as you indicated in your previous post) that hardly anyone ever makes it to '44 or '45 in GWX? (And I'm not debating whether this perception is real or not, merely that it strongly exists in many people's minds).

That being said, in my mind, a minimum surface contact area of 0.0 in no way reflects what could be termed 'realistic' in any sense of the word. As much as I enjoy (and continue to play GWX), I have to be honest and call this a regrettable instance of uber AI-ism.

I would hope your mod will more accurately reflect a reasonable surface area to be contacted as a prerequisite prior to detection. :ping:

makman94

11-07-11, 12:58 PM

For those interested in day/night modification of the visual sensors:

I have passed on the relevant code information to Reaper7, who wishes to explore this issue further, and also to H.sie.

In my opinion, the combination of visual sensors (U-boat/enemy) is already good in NYGM, so I have no interest in developing a new mod myself. The sensors for NYGM were created by Observer a long time ago. Observer was/is a real-life American ex-submariner.

Stiebler.

hello Stiebler,
i have sent you a single mission to see the 'problem' by yourself .date of mission is 10/1939 so visual sensors are on priority.run the mission many times to get an idea of the detection range that own crew is spotting the target(just start your engines and wait).there is the need to run many times the mission becuase the detection range is random(!!??)(this is ,also , a big question: why this detection is random as all the settings are always the same in this specific mission?). also, the target is setted that way so showing its less hull in a last effort to minimize the detection range but... the 'vampire nights' issue also exists in NYGM (tested on a 'clean' install of NYGM with no other mods enabled) . this is not a fault of Observer, who have made a brilliant work on sensors (as far my knowledge on sensors adjustments allows me to say), but it seems that the whole light factor for OWN crew visuals is broken (it works though for AI visuals).
as i have spent countless hours trying to 'heal' this issue via the .cfg files ...all my attempts-tweaks-combinations didn't 'work'! i am convinced that this issue can't be solved via .cfgs but i will be very 'huppy' if it is prooved ,at the end,that i am wrong and there is ,indeed, a combination at .cfgs files that is solving the problem and avoid the hardcode way !

@Rubini: Since Stiebler isn't interested: I already offered makman via PM some days ago, that I'll look into the vampire night sensor issue, since I already "hacked" the visual sensors for the VIIF wolfs. But for this big project, I need time and energy. If it's me to do the job, patience is needed. But I don't want to hinder others to start to play with the sensors.

hello H.Sie,
i have replied to this via pm and i am really thankfull to you and looking forward to start a project like this !

Hi h.sie,

Thanks to look on this.:up:
We have all the time mate!

The truth is that we (i can for sure speak for a lot of ppl here on the followed matter) like very much and we are very thankfull on what you and Stiebler have done, you both knows that.

And we also know (because a lot of us are also modders...well at this time probably any sh3 player already made at least one tiny mod!:DL) that any mod work is a very time consuming task and that the main and primary ingredient is ourself motivation.

Every time that i write something here I spent a lot of time reading my post to try to not be so much that type "please do this, please to that" because I know how hard is this work (and believe me, with my english limitations is yet more hard to express myself:damn:). So, like I said, excuse us if sometimes seems (just seems!) that this entire community are now over you both!:D

couldn't say it better !
100% agree to all these :up:

ps: @Stiebler : i want to ask sorry for hijacking this thread with a theme for visual sensors . this is the last post i do here ,so if there is interest we can open a new thread and continue there .

reaper7

11-07-11, 01:18 PM

Hi Stiebler got your PM and thanks for the info - hope I can figure my way around OllyDebug and find the relevant info :DL.

Was at work today and had a thought that may be of Interest to you to add to your Asdic code.
It would be possible to make the sub harder to spot by ASDIC's when stopped and on the bottom by making MS = 80 or some relevant amount.

This would be great to add to the Defensive tactics when trying to escape destroyers when the sea floor is above crush depth.
Just bottom out and hide. ;)
I already have the Variable for subspeed and could find the variable for depth under keel. So if both variable = 0 then MS = 80 ;).

So to add to your Original Figures
Depth > 150m: MS = 100 (m2, metres squared).
Depth >100m: MS = 150
Depth >50m: MS = 200
Depth < 50m: MS = 300.
DepthUnderKeel=0 Speed=0 MS=80

If your Interested in adding this to the code I'll send you the OllyDebug Code and memory locations. :up:
Sorry for making more suggestions, just excited by your discovery :D

LGN1

11-07-11, 02:33 PM

reaper7

11-07-11, 02:59 PM

Concerning the influence of the sea floor: From my knowledge the influence of the sea floor on the detection probability varied a lot depending on the nature of it. At the moment it seems that you would always gain from the sea floor :06: Any plans to make this random so that sometimes you benefit from the sea floor and sometimes you don't?

Regards, LGN1

Agreed if this was possible to do then the variable would have to be random applied so as not to be always a sure thing.
Just wish this was within my expertise to figure out, but I got nowhere today trying to figure out OllyDebug, having no experience with Assembly doesn't help. :-?

U-Falke

11-07-11, 02:59 PM

This mod will be a great adition! I play the period 1944-45, believe me, it's the most interesting time to play the war.
Also, on IRON COFFINS the thermal layers are constantly said to hide the sub.
I sugest you skilled modders consider implement this also !!!! :yep:

Hitman

11-07-11, 03:13 PM

2. Concerning the influence of the sea floor: From my knowledge the influence of the sea floor on the detection probability varied a lot depending on the nature of it. At the moment it seems that you would always gain from the sea floor :06: Any plans to make this random so that sometimes you benefit from the sea floor and sometimes you don't?

That's correct, I know it well from playing Dangerous Waters! Mud bottom absorbs the pings and returns no echo, rock reflects a lot. The uboat hull reflects the ping, so the rock bottom actually hides it better because it gives a lot of false return, while mud outlines the hull echo return in the sonar against a echoless background.

Also, on IRON COFFINS the thermal layers are constantly said to hide the sub.
I sugest you skilled modders consider implement this also !!!! :yep:

Thermal layers are already in the game, and SH3 commander has a feature to put one at random at mission start. However, it will stay fixed all the time, so it could be nice if though code one could add changing thermal layers :up:

Hitman

11-07-11, 03:27 PM

So, you don´t have vampire night view (uboat crew) on NYGM? I know that NYGM have different visual sensors for AI ships but uses the same (stock) for uboat crew. The settings for visual uboat crew sensors are in Sensors.dat and in the Sensors.cfg as you know.

Isn´t possible to correctly adjusted the vampire night uboat crew using neither the Sensors.dat or sensors.cfg without messing with day visual sensitivity and so on. This is an old well knowing issue that never was fixed.

Probably NYGM (as it is in GWX) just have a heavy settings on the light settings but this is for sure messing with day and (even worse) evening/dusk sensibility too. This was too tested a lot some years ago and nobody found a real magic setting that solve the problem. When you raise these settings your crew continues to make visual detections at maximum range, just delayed a bit more, but as it is random, not so rarely it detects at 16km at night!!

Since the 16km mod this annoyance is much more noticiable (in 8km isn´t that bad). What the big mods did was then try a compromisse between settings on the above files, visual section, but this is far from good or realistic.

If you have the time try a second look on the matter, testing the max/usual visual detections by the uboat crew in game at day, dusk and night. You will see that at night the crew can visual detect ships at much more high distance than it will be plausive. (to not say a totally irrealistic).

Well, i´m here only trying to atract your attention and, perhaps, the desire to work on this issue :DL, but obviously I/we can understand and I agree that we/you/anyone just want to work at first on issues (mods) that are interesting for ourselfs...sh3 is an endless work for modders, you know.:arrgh!:

The vampire vision bug was more or less solved; it was the periscope sensor, seeing through its casing (Remember sensors in SH3 are not hampered by objects) what cause that effect. As we know, SH3 uses a chief sensor, the one with most range at any time, so when night fell and the crew switched to night mode and their vision decreased, the periscope sensor did NOT and could still see very far away, telling the crew there was a ship, and the crew yelled "Ship spotted" to your annoyance. Setting the periscope sensor to the maximum desired night detection range cured the problem more or less -and explains why you can't easily lock ships at more distance ... the lock is lost because the sensor loses them.

Having said that, the real problem with the SH3 visual sensors is that it is calibrated with regards to time of day and to some degree to environmental darkness, but NOT to rendering. What I'm saying is that the perfect sensor would be one where the crew NEVER can detect something that actually is not rendered on screen by your videocard, or at least not rendered with a minimum colour contrast (So that you can actually spot the difference and outline the target, making crew spotting it realistic enough). Multiply this for the virtually limitless configuration of player screens/gamma settings, and you get the picture!

It is almost impossible to please everybody, and actually I always thought that the modders should add a simple contrast card graphic stating "For this sensor mod to work convincingly, set your monitor so you can actually differentiate between the 3rd and 4th grey scale squares" or whatever.

I have no idea if Stiebler can identify the code that renders a ship on screen, (It could theoretically be detected by using a mission in perfect weather and aproaching an stationary target that is outside visual and rendering range - 20 kms in SH3) but if somehow the spotting of it could be blocked unless it is rendered on screen, then we could have taken a step in the right direction.

Oh, and if you guys want to continue discussing this, I suggest we open another thread so as not to hijack the original one :up:

Rubini

11-07-11, 03:43 PM

Hitmann,

Just a quicky reply to not continue to hijack the thread: I can´t agree with you that periscope sensor is the culprite. I have tested this several times, for example setting mine (periscope sensor) to 2km maximum and continues to have 16km night vision detection sometimes. And when in periscope depth with it raised, my maximum detection is then about that 2km that i setted. The fix for vampire night view is very simple (obviously in it´s idea at least ) - just cutting the max visual sensor distance on memory based on the light of the environment (from midday to midnight) and its done.

Fish In The Water

11-07-11, 04:31 PM

Maybe a parameter has no influence if other parameters have certain values... And since so many paramters enter a sensor's performance equation, I'm sure there are quite a few paramter sets to obtain a certain result.

Perhaps, but you seem to be arguing from the unknown to the known. On the one hand, we have actual empirical evidence (as presented by Stiebler), while on the other we have what appears to be unsupported suppositions.

If we start from the unknown, we are hardly in a position to disqualify that which is known.

Stiebler presented a set of findings and then posited a question based on those findings. In my view, the time and effort involved in arriving at the data merited an honest answer rather than an attempt to disqualify the premise.

I'm convinced that modding sensors is one of the hardest things you can do because of all the parameters involved and the dependencies. Therefore, I regard it as absolutely necessary to test thoroughly. And I'm quite convinced that GWX has been tested well.You may well be right. Furthermore I concede you may well be in a better position than I to judge the testing quality of GWX. While this may all be true, it still amounts to indirect knowledge.

The only knowledge we have that is direct is a surface contact variable of zero and the generally held assertion that hardly anyone makes it past '44.

While I readily admit this may only be a part of the picture, for the time being it's the only part we have to go on. Hence I can either speak from that which we do know or I can let the question go unanswered for lack of a complete picture.

In this case I chose to do the former, mainly out of deference for the effort Stiebler put in to investigate.

Jimbuna

11-07-11, 04:48 PM

Hi,

just two comments:

1. I know I repeat myself, but I would never judge a sensor's performance by a single parameter value without knowing the whole equation for the sensor's performance. Maybe a parameter has no influence if other parameters have certain values (e.g., you can create a fatigue model based purely on morale or stamina and in this case the stamina/morale (respectively) coefficients have no influence). And since so many paramters enter a sensor's performance equation, I'm sure there are quite a few paramter sets to obtain a certain result.

I'm convinced that modding sensors is one of the hardest things you can do because of all the parameters involved and the dependencies. Therefore, I regard it as absolutely necessary to test thoroughly. And I'm quite convinced that GWX has been tested well.

2. Concerning the influence of the sea floor: From my knowledge the influence of the sea floor on the detection probability varied a lot depending on the nature of it. At the moment it seems that you would always gain from the sea floor :06: Any plans to make this random so that sometimes you benefit from the sea floor and sometimes you don't?

Regards, LGN1

^ :up:

The sensors function was not my area of responsibility (as opposed to weather parameters), therefore do not take the following as a definitive answer.....

Many of the changes put into GWX are inter-dependant on many other lines of code/information and I can assure you LGN1 is very correct when he states "GWX has been tested well".

Having said that, I am more than happy to see this debate (regarding GWX) explored to the nth degree and would even offer my services in testing any alterations/alterations to file or files.

My one concern would be that it may fubar something else within the mod file structure.

*Meant in a positive context*

LGN1

11-07-11, 04:52 PM

Fish In The Water

11-07-11, 05:05 PM

Hi Fish In The Water,

I didn't want to say anything bad about Stiebler's work. I also don't doubt that the value is zero. The only thing I wanted to say is that one should be really careful with drawing conclusions from a single value.

Regards, LGN1

Fair enough, I think that's a valid point. We certainly don't have the whole picture, so I wouldn't advise coming to a definitive conclusion just yet. I'm merely commenting on the direction the early evidence seems to be pointing. Truth be told, if contrary evidence arises, I'd be more than willing to revise my position accordingly. :sunny:

Stiebler

11-08-11, 04:27 AM

I take LGN1's point that the sensors are probably the result of a complex mixture of several factors.

This must be especially true of visual sensors, where weather and fog will always be a factor, and the night/day distinction will be complicated.

However, I guess (without any evidence) that the asdics are coded much more simply than the visual sensors. Night/day is irrelevant, fog is irrelevant, wind speed has a negligible effect, Asdic range is simply ON/OFF, depending on the distance of the U-boat. U-boat depth is certainly important, but that is modelled already by the angle of beam. Sensitivity for the particular type of asdic is a constant.

Sea-depth is also important, and is not modelled. If Minimum Surface is changed for asdic, it is difficult to imagine what adverse effect it might have on other variables for the asdic sensor. What other variables are there?

The idea of introducing a *random* on-off effect for changes in Minimum Surface has been introduced. Technically, this is very easy to add in code. However, there remain two issues:
1. The code is called at millisecond intervals, so in order to have any meaning the random factor would have to be sampled every game-hour or thereabouts.
2. What exactly would the random number mean? For example, if the code says that there is a 20% (or an 80%) chance of changing the Minimum Surface value, what does it mean? That there is a 20 (80)% chance that the U-boat is next to a rock rather than next to soft mud?

In fact the presumption is already made in my code that, at shallower depths, you are more likely to be moving next to something that confuses asdic (a rock, a wreck, a shallow tidal flow). So, in my opinion, the changes in Minimum Surface reflect *the average* of these random changes already.

Another suggestion, that to sit on the sea-bed without moving should provide further protection, is a good one, and perhaps this can be modelled with a further increase in Minimum Surface for asdics. However, in real life the idea of sitting on the sea-bed was to pretend to be a rock or wreck, it had no effect on the function of asdic. So perhaps we can think of a better way to implement this new idea. (Already, you will be safe from detection by hydrophones.)

Stiebler.

h.sie

11-08-11, 04:55 AM

@Stiebler: In my 1Sec-Controller routine, you can install a counter. Everytime the counter reaches a certain value, e.g. 3600 = 1 hour, you can trigger a random event (new random number = new sea ground)

reaper7

11-08-11, 01:07 PM

As posted In the Sensors thread: http://www.subsim.com/radioroom/showthread.php?t=189425

May be of use If you do wish to do something with the sub on bottom :up:

I have found the Variable for Sea-Depth and its a Static Address too :D Compared to usual DMA address with Pointers.

SH3Collisions.act+20550

Appears the SeaDepth Figure is Bang on if it read 111M then the seabed is 111M
So therefore the sub can never dive deeper then the seaDepth value. so then if Subdepth=Seadepth, U-boat is on the seafloor.

This is the Memory address for the Sea Depth at subs location and is always spot on.
So u-Boat can only dive as deep as this variable.

Here is the OllyBegud info on it

Sh3collisions.act

0096C4CA fstp dword ptr [00980550]

0096C4CA - D9 1D 50059800 - fstp dword ptr [TRuntime<CObjectRemains,839234899,sController,CRuntimeProps>::rtClass+8C] CheatEngine Further Info

Memory Location 00980550 (Float value)

I also have the address for Depth Gauge if needed for this :if(depthgauge=Seadepth) then onseafloor=true

:up:

LGN1

11-08-11, 05:07 PM

Hi Stiebler,

I agree, that the number of parameters which influence the ASDIC sensor's performance is probably considerably smaller than the number for the visual sensor. Still, I think it's better to use the Minheight parameter (identification can be done via changing the value in the sensor file to a unique value beforehand) because we are very confident about its exact meaning and, more importantly, it does not 'interact' with the other parameters' values. Therefore, using the Minheight parameter should make the mod more compatible with other super-mods.

Regards, LGN1

Fish In The Water

11-08-11, 06:33 PM

Asdic range is simply ON/OFF, depending on the distance of the U-boat...

Sea-depth is also important, and is not modelled...

The idea of introducing a *random* on-off effect for changes in Minimum Surface has been introduced.

Obviously you're either in range or out of range, so a cut and dry distinction seems fine here. That being said, I would hesitate to apply the same principle once we get into the realm of depth and environmental considerations.

In this realm I would resist the urge to use absolute values and try to implement a variable percentage instead. I say this because I have a hard time wrapping my head around the idea that any combination of conditions could somehow render your profile temporarily invisible. Reduced yes, but invisible no.

As a result I would only use 'on/off parameters' (such as Minheight) as a last resort. Better to continue to explore the possibility of variable changes to minimum surface.

In fact the presumption is already made in my code that, at shallower depths, you are more likely to be moving next to something that confuses asdic (a rock, a wreck, a shallow tidal flow). So, in my opinion, the changes in Minimum Surface reflect *the average* of these random changes already.This would be my approach as well. The failure to model depth, and the inclination in certain supermods to slash environmental handicaps, (such as wave factor), does a disservice to real life conditions and puts the player at a decided disadvantage.

I would far prefer a tough asdic based on its own detection ability rather than an artificially pumped up version that depends on a muted sea.

In summation, I like where you're going with this and I would encourage you to try and stay the course. :salute:

Stiebler

11-09-11, 03:52 AM

@H.sie:

Many thanks for the information about your 1-second code routine. I was not aware that loops with longer call-times could be made from it.

@Reaper7:

Also many thanks for your information. Interesting to see that you discovered the sea-bed depth in collisions.act. I have never looked there. I found sea-bed depth in SH3.exe (I can't remember whether I sent the details to you; ask me by PM if I forgot).

@LGN1, Fish-in-the-water:
The method of selecting how best to reduce the U-boat profile to asdic with code is evidently proving to be difficult.

My instinct is to stick with the method I am using (Minimum Surface), for two reasons:
1. I am lazy, and also I have already tested the Minimum Surface code which seems to be effective.
2. If I tag all the MinHeight asdic sensors with the same unique value, which has to be done first in the AI_Sensors.dat file for every super-mod, then the original values, which vary a lot for each asdic even within the same super-mods, will all have to be altered to the same values. But the original idea was that different asdics should have different search beams, so this detail will be lost to the game.

Trivial detail:
I have noticed that the asdic sensors in AI_sensors.dat are identical for stock SH3 and GWX, although other sensors vary.

Stiebler.

Fish In The Water

11-09-11, 06:13 AM

My instinct is to stick with the method I am using (Minimum Surface), for two reasons:
1. I am lazy, and also I have already tested the Minimum Surface code which seems to be effective.

Never thought I'd be in favor of laziness, but in this case I'm all for it. :03: But seriously, if the tests have gone well then it seems appropriate to proceed with what promises to be the most realistic, effective and preferred method.

2. If I tag all the MinHeight asdic sensors with the same unique value, which has to be done first in the AI_Sensors.dat file for every super-mod, then the original values, which vary a lot for each asdic even within the same super-mods, will all have to be altered to the same values. But the original idea was that different asdics should have different search beams, so this detail will be lost to the game.This being the case, I would consider the certain loss to outweigh any probable gain. It seems very counter productive to negate the distinctions between various equipment types primarily for the sake of gaining better cross-mod compatibility. In my opinion, it's a price that's too high to pay.

Trivial detail:
I have noticed that the asdic sensors in AI_sensors.dat are identical for stock SH3 and GWX, although other sensors vary.Interesting...

I'm going to give them the benefit of the doubt and suggest they probably had (what they considered to be) a good reason for this. Still I find it curious that environmental factors, (such as the ambient noise of rough seas), were discounted considerably even while asdic settings (as established by the devs) were apparently upheld.

Interesting how the GWX folks seem to have concluded the devs got it so right on the one hand and yet so wrong on the other. Perhaps, at the risk of speculating, they discovered they were unable to obtain the results they were looking for merely by manipulating the asdic settings alone.

If this is the case, then I can understand why they opted for a sea that produces a negligible level of noise, even though I disagree in principle with such a decision particularly when other key elements, (such as depth charge disturbances) are already lacking an active model.

Hitman

11-09-11, 09:51 AM

If this is the case, then I can understand why they opted for a sea that produces a negligible level of noise, even though I disagree in principle with such a decision particularly when other key elements, (such as depth charge disturbances) are already lacking an active model.

Maybe to increase the contrast for the depth charge disturbances. It could be that the game sets the sonar sensitivity starting from the background noise or whatever ... the only thing that you can tell with a bit of certainty is that in this game the "real life" values will not work as intended. If you want to achieve realistic results, you have to put here and there some unrealistic values. :hmmm:

reaper7

11-09-11, 10:30 AM

@Reaper7:

Also many thanks for your information. Interesting to see that you discovered the sea-bed depth in collisions.act. I have never looked there. I found sea-bed depth in SH3.exe (I can't remember whether I sent the details to you; ask me by PM if I forgot)..

Hi Mate, yes I found it in 5 places but the one in Sh3collisions.act is the original one and the rest are updated from that one.
But it is the most accurate one updating before the others (Not that there is two much difference) also it is a static address which is not to common in Sh3 :03: so its locating in memory is always the loading address of SH3Collisions.act plus 20550. :up:

Fish In The Water

11-10-11, 03:15 AM

... the only thing that you can tell with a bit of certainty is that in this game the "real life" values will not work as intended. If you want to achieve realistic results, you have to put here and there some unrealistic values. :hmmm:

Sad but probably true. Which seems to bring us back to testing, testing and more testing due to the limitations of the game engine.

Still, if I had my druthers, I'd much rather see a 'more realistic' mod that actually takes factors such as depth and turbulence into account by reducing minimum surface contact variables. This is what caught my interest in this thread to begin with, and is quite frankly, why I continue to follow it. :sunny:

Leitender

11-18-11, 08:37 AM

Stiebler

Second post, first to correct an old sailor...:oops: I hope you don´t mind.

I also did many testing with minimum surface (MS). At a value auf 100m² the boat is just to be seen when in 90° bearing to the dd. According to what I read many times this is imho too weak, so I lowered the MS to 50m² for each aktive sonar in AI_Sensor.dat. Result: At 0° resp. 180° bearing I wasn´t found, however at 150° resp. 210° at close distance he caught me up. For me that fits to the tactical advice to show its narrow silhouette.

Regarding the maximum height value I´d like to say that the AI-DDs don´t only use the asdic sensor to get a firing solution for their DCs like in real life, but also use the passive sonar as a data supplier. If you set maxheight=-50, the DDs will use their hydrophones - and nothing ist won for your coverage.

Apart from that I would like to take my hat off to you for all the work you did for the community. Respect!

By the way, I was also amazed when I discovered that die GWX-sonar values correspond to the stock-ones. Only the values of NYGM3.5-AI_Sensors.dat obviously correspond to real values. But they suffer from another theme. But this could be discussed in another thread.

PS:

I ran single mission Convoy PA69, set in 23 Feb 1944. A quick check on the mission file showed two escorts, both of type COBathhurst. Another check in the Sea folder for COBathurst (.sns file) shows that they have asdics 147A fitted in February 1944.
When I checked the sensor settings, i realised a delay in the DD´s fitting with the sensor. E.g. my V&W should have a 138P passive Sonar from 01011943, but it was´n mounted until 02071943 (?) So maybe your COBathurst hadn´t a 147A either?

Regards

Fish In The Water

11-18-11, 01:48 PM

By the way, I was also amazed when I discovered that die GWX-sonar values correspond to the stock-ones. Only the values of NYGM3.5-AI_Sensors.dat obviously correspond to real values.

This came as a real eye opener to me as well. Sensing something to be amiss, I had long since looked into the relationship between various sensor variables and their in-game implementation. As a result of these inquiries, I adjusted the settings away from the stock/GWX levels and found the level of realism to be far more satisfying.

A year or so later, I happened along this thread which held the promise of taking these findings even further. At this point I'm still looking into it, but thanks for the input and I'd be interested to hear your views in regard to "[suffering] from another theme." Perhaps via PM if not in another thread. :yep:

Jimbuna

11-18-11, 04:24 PM

This came as a real eye opener to me as well. Sensing something to be amiss, I had long since looked into the relationship between various sensor variables and their in-game implementation. As a result of these inquiries, I adjusted the settings away from the stock/GWX levels and found the level of realism to be far more satisfying.

A year or so later, I happened along this thread which held the promise of taking these findings even further. At this point I'm still looking into it, but thanks for the input and I'd be interested to hear your views in regard to "[suffering] from another theme." Perhaps via PM if not in another thread. :yep:

Most interesting

Stiebler

11-19-11, 03:43 AM

@Leitender:

Many thanks for your feedback on sensors use.
When I checked the sensor settings, i realised a delay in the DD´s fitting with the sensor. E.g. my V&W should have a 138P passive Sonar from 01011943, but it was´n mounted until 02071943 (?) So maybe your COBathurst hadn´t a 147A either?Yes it had a 147A, because I saw the characteristic details of the 147A properties loading at my code interception point.

Stiebler.

Leitender

11-19-11, 04:25 AM

I'd be interested to hear your views in regard to "[suffering] from another theme." Perhaps via PM if not in another thread. Fish_in_the_water

Although this is not directly related to the thread´s inital topic about shallow water asdic, it may also be interesting, because the matter ist how sensors, especially active sonars work. So hopefully Stiebler won´t get too angry about the capturing.

The main reason, why I was so astonished about the GWX-settings was because I read this huge and wonderful made, really impressive manual, in which, among other things, the functionality of the sensors was described. There I could find this very descriptive graphic:

http://jproc.ca/sari/asdic_patterns_b.jpg

Obviously it´s taken from a very helpful site with a lot of historical stuff. If you take a look at this graphic, you may see three of our different active sensors: 123A resp. 128A, the so-called searchlights, 144A as the "Q"-type deep looking asdic and finally the 147A, called "Sword".

Having read the information in this site about asdic, it seems to be that pre- and early-war type 123 or 128 were used during the whole war and new upcoming systems like "Q" and "Sword" were attached to the vessels as add-on.

Unluckily in SH3 the single asdics weren´t attached but replaced by later versions. There is only one node "N01" for all systems in the ship´s sns-files as well as in the dat-files. This is the crux!

As in NYGM the sensor settings are adapted to the historical values, but replaced one by one, the DDs have in fact at all the time just one asdic system with its single limitations in range and bearing, whereas at least the latewar-DDs should have two or even three asdic systems and thus covering a much wider field.

Therefore in principle the stock (and GWX) settings - in which btw the only difference between the types of asdic is a growing range - represent the technical progress in underwater ASW more then NYGM, although the values aren´t historical accurate.

But... who wants to go back to stock settings of 2005, after all that research, all that blood, sweat and tears... exactly: noone. :DL So the solution is we have to generate a second and a third node in the sns and dat-files to get our sensors alltogether. This is the line at which I stay at the moment and I´m not sure if it works. Only one thing I do know: It´s a lot of work. Again. But I will do that, becaus I´m - insane. :damn:

Stiebler

You´re very welcome. I really appriciate your great work. Unbelievable, how much work is done by you for the effort. Btw. I was sure that this equipment delay was typical i.e. normal for every type because I read about that effect at another place. Odd.

Fish In The Water

11-19-11, 02:51 PM

Unluckily in SH3 the single asdics weren´t attached but replaced by later versions. There is only one node "N01" for all systems in the ship´s sns-files as well as in the dat-files. This is the crux!

But... who wants to go back to stock settings of 2005, after all that research, all that blood, sweat and tears... exactly: noone. :DL So the solution is we have to generate a second and a third node in the sns and dat-files to get our sensors alltogether. This is the line at which I stay at the moment and I´m not sure if it works. Only one thing I do know: It´s a lot of work. Again. But I will do that, becaus I´m - insane. :damn:

Very interesting indeed. This certainly provides a lot of good food for thought especially in terms of setting a general direction for further exploration and testing. Daunting workload aside, it strikes me (at first glance) as an avenue worth pursuing.

I couldn't agree more about not wanting to go back to 2005. Surely the time has come to move on and apply all the knowledge obtained in the interim to develop a more 'realistic' community standard. Progress marches on and it would seem counter productive to cling to the past.

Thanks for sharing your thoughts. I'll definitely be giving this some serious consideration as I continue to seek a sensor solution that takes the game to new heights. :yep:

Fish In The Water

11-20-11, 04:28 PM

@Stiebler:

Sorry it's taken so long to reply with test results, but I wanted to make sure I had a good baseline (with NYGM and the new asdic mod) before posting.

From what I've seen so far, I'm very encouraged as to both the added realism and effectiveness of the asdic mod. After running a number of shallow water tests, it seems to work exactly the way it should work, (with little to no detection with limited surface area and positive detection when the area increases).

It takes me back to my AOD days when you could effectively evade the dreaded ping by struggling to maintain either the bow or the stern in the enemy baffles. IMO, this is a vital area of realism that has been sadly lacking in SH3 until this very time.

For this I wish to sincerely thank you as you have truly made an invaluable contribution to SH3. Needless to say this mod will be a staple in my game going forward. Quite frankly, it's the best I've seen (in the sensor department), and I look forward to where it may lead from here. :salute:

LGN1

11-20-11, 04:48 PM

Hi Stiebler,

do you have any plans to make the effect random? As discussed earlier in this thread, shallow water does not always result in a poor ASDIC performance.

Regards, LGN1

Stiebler

11-21-11, 04:35 AM

@Fish-in-the-water:
Many thanks indeed for such comprehensive and encouraging feedback on the shallow-water asdic mod.

@LGN1:
I agree with you that shallow waters provided erratic protection against asdic detection. Hitman also made the same point earlier.

However, my answer in #43 above still stands, concerning use of random number changes, and repeated below for others who may not have seen it:
What exactly would the random number mean? For example, if the code says that there is a 20% (or an 80%) chance of changing the Minimum Surface value, what does it mean? That there is a 20 (80)% chance that the U-boat is next to a rock rather than next to soft mud?

In fact the presumption is already made in my code that, at shallower depths, you are more likely to be moving next to something that confuses asdic (a rock, a wreck, a shallow tidal flow). So, in my opinion, the changes in Minimum Surface reflect *the average* of these random changes already.As stated previously, it would be very easy to introduce a random change if a strong enough case can be made. I should like to see more experiences from other players with the current system before making new changes. U-boats operated in shallow waters with the confident belief that shallow waters would protect them. They were ordered to make use of local shallow effects, such as fast running underwater streams or tides to aid their protection. They could not have had such confidence if their asdic protection suddenly disappeared, randomly and unpredictably.

Perhaps I can quote from one of my own books, the report of Nollmann (U 1199) when he returned to base after a patrol off the north-east coast of Scotland. The report was later transmitted by BdU to all U-boats at sea on 5 December 1944:
'Experiental 193 [Boat has operated 30 days in AN01.]
"Shallow water is best protection against search gear. Boat was not intercepted, and we felt completely safe on the bottom. Schnorchel completely tested, 50 days submerged without surfacing. I have a feeling of complete superiority with the schnorchel... " '

Stiebler.

LGN1

11-21-11, 04:33 PM

Hi Stiebler,

thanks for your reply. What I had in mind is to have a probability that, e.g., every two days the shallow depth effect is switched on or off randomly so that the player never really knows whether he's safe or not.

From what I've read many commanders considered shallow waters dangerous and tried to stay away from it. I don't remember who it was, but I think there is a quite impressive report from a sub commander in 1940 who was depth-charged in shallow water and reported that the destroyers always knew where he was (IIRC, Der Teddy Bar always quoted this report in connection with early-war ASDIC performance) :hmmm: Having this report in mind, I find it strange if shallow water is less dangerous in SH3 than deep water.

On the other hand, the submarine commander's handbook (http://www.hnsa.org/doc/uboat/index.htm) mentions shallow water, too (57.) It says that shallow water can be indeed quite safe. However, it seems that this depends heavily on the area where you are. The question is whether the commanders back then knew where and when it was safe :06:

I guess as long as it's not possible to have the effect dependent on the area, one has to choose either to a) neglect the effect (stock SH3) or b) have the effect everywhere (your mod). Both choices are not really realistic.

Regards, LGN1

Fish In The Water

11-21-11, 05:56 PM

@LGN1:

First up, thank you for taking a balanced look (with sources from both sides of the issue). :up:

In regard to your 'strange' feeling that shallow water should be less dangerous than deep in SH3, I would like to mention the following. Firstly, it seems to me, it would primarily be safer in terms of a greater degree of sonar 'scattering' which is bound to occur due to the increased proximity of the bottom.

Secondly, it seems in reality to be just as dangerous if not more so due to the limited room for manoeuver. Throughout my tests, if I failed to maintain a low surface exposure (even for a moment), I was quickly detected and just as imperiled (if not more so than if I had been in deep water).

Furthermore, the 'scattering' I spoke of occurs from both the surface and the bottom as well as from small objects in the water. All three of these factors seem analogous to all regions so I have a hard time understanding how a random aspect would improve realism in this instance. :sunny:

LGN1

11-22-11, 03:44 PM

Der Teddy Bar about NYGM Tonnage War 2:

"... Shallow waters were a very dangerous place for the u-boats, yes there were sound detection difficulties, but compared to deep water, shallow waters were very dangerous.

With the AI now more actively using the ADSIC shallow waters are now very dangerous. It is not impossible to survive 1 maybe 2 escorts with skill and some luck when in shallow waters of 50 metres or less, but more often than not, you will find that it will end tragically..."

The full post is here:

http://www.subsim.com/radioroom/showpost.php?p=260503&postcount=1

Regards, LGN1

Fish In The Water

11-22-11, 09:44 PM

He goes on to say:

"With ADSIC the key to minimising your chances of detection will be minimising your profile, stern on or bow on is key."

This seems to fit quite nicely with the 'MinSurface' variable approach which (as has been pointed out previously) appears to be completely lacking in other super mods.

As for the two passages you cited, I really don't see an issue with either of them as I've already stated my belief that shallow waters are more dangerous than deep primarily due to the lack of available depth.

He's already acknowledged the sound difficulties, and at the risk of repeating myself, in my tests I found it quite challenging to try and maintain a profile that was low enough to avoid being successfully pinged again.

If the player remains committed he can manoeuver for a period of time without detection, but eventually (usually within a few minutes), the DD's search ark becomes such that you are unable to turn quickly enough to avoid sufficient exposure.

At this point depth charges are soon in the water once again and the time available for a 'flank knuckle break' is limited due to the shallowness of the water. If that's not dangerous then kindly explain to me what is. :hmmm:

Stiebler

11-23-11, 03:44 AM

As Fish-in-the-Water says, your freedom of manoeuve is limited at shallow depth. U-boat commanders always demanded of the designers that the boats should be able to dive deeper, because a deep boat had more time in which to turn as the depthcharges sank slowly.

Shallow waters are certainly more dangerous for a U-boat than deep waters, *after* the U-boat has been once located. But it is harder to locate the U-boat initially.

The quotation from DTB refers, I believe, to the well known incident reported by Topp, when his IIA boat was located at shallow depth in 1940 to the north-west of Britain, and was hunted for many hours while stationary on the sea-bed. By chance, his U-boat had settled into a small deep channel on the sea-bed, so that the the boat was protected by the high banks on both sides. Because the boat was stationary (to conserve power), and also in a position where it could be detected by asdic, the attacks were very precise.

I cannot think of another example like this, until 1945, when asdic was more refined, and the Squid depthcharge device was fired automatically with settings from the asdic.

Stiebler.

LGN1

11-23-11, 03:19 PM

Thanks for your replies, Fish In The Water and Stiebler!

With my previous post I just wanted to point out that it was a big improvement when the NYGM team improved the ASDIC capabilities and therefore, IMHO, it would be bad to go back (to the 'Glingon Cloaking Device' as DTB has called it).

However, from Fish In The Water's reply and tests I conclude that Stiebler's new mod does not revert the situation, i.e., ASDIC still works quite well even in shallow water. So, everything is fine :up:

Just one more question:

@Stiebler: Do you know how DTB could influence the amount of ASDIC usage by the escorts? Did he just increase the detection probability by ASDIC so that the escorts get more contacts with ASDIC and therefore, will use it more? It's my understanding that all units can only use one sensor at a time and switch quickly between the sensors until they have a contact with one sensor. The units will then use this sensor until contact is lost :hmmm:

Regards, LGN1

Stiebler

11-24-11, 03:45 AM

@LGN1:
Re Increase of asdic influence:
It was Observer who made the changes, but DTB certainly knew what had been done - unlike myself, who never thought it necessary to ask at the time, although I performed a lot of the testing.

It's my understanding that all units can only use one sensor at a time and switch quickly between the sensors until they have a contact with one sensor. The units will then use this sensor until contact is lost.This may indeed be true, I regret that I do not know.

Inspection and comparison of the AI_Sensors.dat file with stock SH3 shows that most or all parameters for each of the several asdics have been altered in NYGM. Also some of the parameters in sim.cfg. One particularly important change was to provide a 'dead area' (no detection) for asdic behind the warship's stern, in order to mimick the propeller noise behind the escort. Also, another dead area was provided when the escort was within 100-200 metres of the warship (ie, loss of asdic as the warship began its attack run). Neither of these last two changes were available in stock SH3.

Stiebler.

Fish In The Water

11-24-11, 04:56 AM

One particularly important change was to provide a 'dead area' (no detection) for asdic behind the warship's stern, in order to mimick the propeller noise behind the escort.

Any idea how this was implemented? The only thing that comes to mind is possibly adjusting the 'detection cone' via the Min and MaxBearing variables. Or is there some other approach that's more effective? :hmmm:

Also, another dead area was provided when the escort was within 100-200 metres of the warship (ie, loss of asdic as the warship began its attack run). Neither of these last two changes were available in stock SH3.I take it this can be achieved by setting MinRange to say 100 meters to mimic the real life loss of contact just prior to depth charging. Again this is just a semi educated guess :D, so if I'm way off base here I'd appreciate a little course correction. :yep:

andqui

11-25-11, 01:25 PM

If I'm using GWX, could I just use the NYGM parameters for ASDIC for more realism, or would that have unintended side effects?

Fish In The Water

11-25-11, 09:33 PM

If I'm using GWX, could I just use the NYGM parameters for ASDIC for more realism, or would that have unintended side effects?

That's basically what I did and it worked out quite well. The main factor is to make sure the values in the AI_Sensors.dat file and the SIM.cfg file are 'on the same page'. If they work together (i.e. align properly) then you shouldn't experience any nasty side effects. :sunny:

Stiebler

11-26-11, 08:04 AM

@Fish-in-the-Water:

Dead Area behind the propellers.
Sorry, I don't know how this was implemented.

Dead area as warship approaches sub.
As you say, this is achieved by changing MinRange to 300m (I thought 100-200m from memory, earlier, but it is 300m).

Stiebler.

Fish In The Water

11-26-11, 09:30 PM

Dead area as warship approaches sub.
As you say, this is achieved by changing MinRange to 300m (I thought 100-200m from memory, earlier, but it is 300m).

Very good, that helps. Thank you! :salute:

Leitender

03-13-12, 03:06 AM

@Stiebler:

Sir,

at first i would like to thank you very much for sharing your thoughts and your whole work with the community. Personally i follow every discussion with you und every post from you because i know you are somenone who loves that game and which posts are really worth to be read.

Also with this thread. As i want to implement h.sie´s v.16B and your new addon, i wonder if you (or anyone else) made some experience with your chosen MS-values in the meanwhile. I ask because longer ago, i made a test with this value: My boat stood in a perpendicular course to a destroyer (can´t remember distance) and although i showed my broadside, ASDIC didn´t recognize me at a MS=100², which in result meant a total dysfunction, at least in this trial. I then reduced MS to 75 and at last to 50m² and the result was i was recognized when in perpendicular position, but when i showed the DD my narrow side (bearing +-30deg) ASDIC lost contact. Confident about this result, I used from then on MS=50m².

Now i like to use your addon. But since you wrote about a "unique" value for MS which you have used to identify whether this MS-parameter works or not, i wonder if your mod is linked to this explicite value or if it also works e.g. with my favourite 50m². In general this mod is a great idea an i would really miss it within my game if it wasn´t usable with my settings.

So i would really be glad to gather some words about this from a great modder.

Yours sincerly

Leitender :salute: