[TEC] SH5.exe patches to fix bugs and add functionality

[7thSeal]

Originally Posted by Fifi

Really?? Would it be possible to patch game for fog very ponctual happening, because days and days of same fog overcast isn't realistic at all


No reporting? ---> no please!
Furthermore, all players aren't using Sober best ever fog mod!
% error added? why not!
Precipitations? ---> maybe like for light fog, but anyway it's often precipitations + fog, ingame...don't even recall precipitations alone.
Clouds? I don't see why reducing visi for clouds

Looks like fog will be the main factor and as you pointed out precipitation always includes fog. Light and medium fog seems to be the most common but how much % should it affect?

Night visuals would also be affected by mods as some of us use darker night mods so I'm not sure how that would determine % either.

[BigWalleye]

Distance (range) is usually judged by size and aspect ratio. Fog doesn't affect the perceived size, although it would make the aspect ratio harder to judge. Zeroth order, I'd think that fog would determine whether you could see something or not, but would not significantly impact the range estimate. You wouldn't expect a lookout to see a ship looming out of the fog 1000m away and judge that it was 5000m just because he didn't see it clearly. (Or perhaps you might - allow the first glimpse through the fog to be wildly inaccurate, just an impression of something there, then successive sightings much better.)

BTW, Dick O'Kane recounts numerous instances of completely erroneous range estimates (factor of 5 or more) in clear air under certain meteorological conditions common in the Sea of Ohkotsk.

[THE_MASK]

If i enable all the render patches i get a ctd on clicking on the navigation map icon .

[finchOU]

Originally Posted by BigWalleye

Distance (range) is usually judged by size and aspect ratio. Fog doesn't affect the perceived size, although it would make the aspect ratio harder to judge. Zeroth order, I'd think that fog would determine whether you could see something or not, but would not significantly impact the range estimate. You wouldn't expect a lookout to see a ship looming out of the fog 1000m away and judge that it was 5000m just because he didn't see it clearly. (Or perhaps you might - allow the first glimpse through the fog to be wildly inaccurate, just an impression of something there, then successive sightings much better.)

BTW, Dick O'Kane recounts numerous instances of completely erroneous range estimates (factor of 5 or more) in clear air under certain meteorological conditions common in the Sea of Ohkotsk.

I would think you'd have a visibility estimate during foggy conditions. Like I have 2 miles vis in this fog....or heavy fog..... less than 50 meters...etc. So if a ship appeared ...you'd have a decent guess based off of that ....and judging by the relative size of the ship.

I like the idea of less range accuracy at greater ranges...and would add to the realism for sure! Make you shadow a bit longer and take multiple readings.

[totalrain]

Originally Posted by sober

If i enable all the render patches i get a ctd on clicking on the navigation map icon .

For me it was Render patch 12, "Disables rendering of torpedo line", that caused the Nav Map and Mission selection CTD. All others are OK. This was with Patcher 1.0.83.

I have an nVidea GTX560 graphics card and AMD Phenom II X4 965 CPU.

Everything was working with OH2.1 Full + Patch 2 and your (Sobers) mod list. I didn't sink any Polish ships as it was heavy fog and I play at 100% + Real Nav and haven't had a chance continue with the Baltic Operations mission. I will try with OH2.2 and the latest Patcher when I get the time to play again.

[TheDarkWraith]

v1.0.93.0 released. See post #1

Starting with v1.0.93.0 Revised the randomize nearest visual contact patch. Now the patch takes weather into account (clouds, fog type, and precipitation type)

The weather parameters are accessed via a table of entries for each type. The data is contained in the patch file via variables. It's a number of types of the weather type X 2 table with data for each weather type (clouds, precipitation, and fog): columns are the available types for each weather type (none, medium, heavy, etc). The two rows are distance and percent error to add. If the visual contact's distance is >= distance then game will check the percent error to add. If percent error to add is < 0 then game says you do not see the visual contact. If percent error is >= 0 then this error is added to the current total error. If distance is < 0 then that tells the game to ignore this weather type. I'll detail what the stock values are for all the tables tomorrow.

If the game calculates that you cannot see a visual contact it will display a message in the messagebox denoting so. Message to display (menu entry) is a variable in the patch file. Currently I have it set to 1209 (No visual contact!)

[EAF274 Johan]

Another question: if I want to keep the special ability to reduce torpedo dud chances ("Remove torpedo dud reduce ability"), do I need to leave "Removes other reducing factor from torpedo dud chances" disabled, or can I enable it?

[TheDarkWraith]

Originally Posted by EAF274 Johan

Another question: if I want to keep the special ability to reduce torpedo dud chances ("Remove torpedo dud reduce ability"), do I need to leave "Removes other reducing factor from torpedo dud chances" disabled, or can I enable it?

You can enable it. That's why I made it a separate patch

[THE_MASK]

Tried to open the EXE with patch 93 . Randomise nearest visual contact distance . Change 2 . Reason . Bytes read does not equal bytes expected by patch .
Can anyone else get it to work ? Is it a problem on my end ?

[Echolot]

EXE with patch 93 . Randomise nearest visual contact distance . Change 2

No error here.

[gap]

Originally Posted by TheDarkWraith

If anyone has any ideas on improving the latest patch (randomize nearest visual contact distance) don't be afraid to speak up...

something which I find annoying is that hydrophone estimated ranges (and now visual ranges) are totally random. Ask many ranges to closest target in a row, and you will get numbers as 10,700, 11,000, 10,800, 10,500, etc. which makes range reports to look totally silly.

I wonder if you could store somewhere the last range estimation, and the time that it was estimated at. Every time we ask for a range, your code should calculate elapsed time from the previous estimation. Let's define some variablen:

RE = new range estimation
RE0 = last stored range estimation
TE= time elapsed from the last stored range estimation
TE0 = minimum time for a new range estimation

• if TE < TE0, or both target and U-boat are stationary, than output is RE0;
  
• else, calculate RE:
  • if target is closing:
    • if RE < RE0, output is RE;
    • else, output is RE0;
  • if target is moving away:
    • if RE > RE0, output is RE;
    • else, output is RE0;

TE0 should be a function of target's speed and range: the slower the speed and the longer the range, the longer the time for estimated range to change. Variables are reset if closest target changes.

Another, probably easier method to do the same could be by comparing exact ranges. In this case the variables involved would be:

RE0 = last stored range estimation
R0 = exact range relative to the last stored range estimation
R = current range

if RE0 and R0 are empty variables (no previous contact estimations for current closest target), then calculate range estimations according to your current code. Else, new range estimation should be equal to:

RE0 * R / R0

What do you think?

Originally Posted by TheDarkWraith

ok, I know how to get all the data related to fog, precipitation, clouds, wind heading, and wind speed.

Any chance for this other idea to be implemented:

http://www.subsim.com/radioroom/show...88#post1886488

[BigWalleye]

Gap, that sounds like a good idea, although IMHO it sounds like a lot of coding work for a small gain in realism. You could also use a Kalman filter to converge the range estimates. "Course, I'm not doing the work, so I shouldn't complain. Would be nice to have.

Your linked post regarding degrading the quality of ship IDs I really want to second! Have longed for this. BTW, on American ships, at least, the skipper customarily viewed the target through the periscope and reported salient features to the identification party, which then made the call. Or the lookouts would report (after the fact) what features they had observed. Final ID was typically not done RT, and the ID party seldom saw the target. Simulating this accurately could get complex and seems to call for a completely new approach. But anything that makes the ID function less Godlike and more error-prone would be a big improvement. TDW, would you consider this for a future fix?

[volodya61]

Originally Posted by gap

Any chance for this other idea to be implemented:

http://www.subsim.com/radioroom/show...88#post1886488

Yeah, it would be just great if this idea will be implemented

[gap]

Originally Posted by BigWalleye

Gap, that sounds like a good idea, although IMHO it sounds like a lot of coding work for a small gain in realism.

You are probably right about the complexity of coding it. But I wouldn't call it "a small gain in realism" as it would make the reporting officer to behave as a sentient being, instead of a stupid random numbers generator

[TheDarkWraith]

Originally Posted by gap

You are probably right about the complexity of coding it. But I wouldn't call it "a small gain in realism" as it would make the reporting officer to behave as a sentient being, instead of a stupid random numbers generator

What I'll add to the code is having it remember which unit the game used for the nearest visual contact distance. I'll also store the actual distance to the unit along with last random distance calculated. Then if player asks for nearest visual contact the code will check to see if the same unit is found, if so then it will check actual distance to see if it's changed some amount (I'll make that a variable in the patch file). If the distance changed >= variable amount then calculate new random distance. If distance changed < variable amount return last random distance calculated.

How's that? I don't want anything too complex. I just wanted something to get rid of the perfect range estimate every time you asked for nearest visual contact.