Sh3.exe and Asdic in shallow waters

[makman94]

Originally Posted by Stiebler

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 !

Originally Posted by h.sie

@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 !

Originally Posted by Rubini

Hi h.sie,

Thanks to look on this.
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!) 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). So, like I said, excuse us if sometimes seems (just seems!) that this entire community are now over you both!

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


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]

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

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.
Sorry for making more suggestions, just excited by your discovery

[LGN1]

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 Any plans to make this random so that sometimes you benefit from the sea floor and sometimes you don't?

Regards, LGN1

[reaper7]

Originally Posted by LGN1

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 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]

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 !!!!

[Hitman]

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 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 !!!!

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

[Hitman]

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

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

[Rubini]

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]

Originally Posted by LGN1

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]

Originally Posted by LGN1

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 Any plans to make this random so that sometimes you benefit from the sea floor and sometimes you don't?

Regards, LGN1

^

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]

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 (see, e.g., the effect of the negative surface value in SH4).

Regards, LGN1

[Fish In The Water]

Originally Posted by LGN1

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.

[Stiebler]

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]

@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]

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

Originally Posted by reaper7

I have found the Variable for Sea-Depth and its a Static Address too 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,CRun timeProps>::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