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

[TheDarkWraith]

Originally Posted by gap

- could you make detection chance dependant on veterancy level of the loop unit? This could be a good compromise between the detection percent you have currently coded, and the much lower probability suggested by sober.

Good idea. I can make the veterancy level of the coastal defense a factor in it's loop detection

[gap]

Originally Posted by TheDarkWraith

Good idea. I can make the veterancy level of the coastal defense a factor in it's loop detection

Could you also delay the transmission of loop-detected contacts, when they are outside the visual range of the loop station? (visual sensor on loop units required, searchlights optional). This is for simulating that, in absence of visual evidences, the operator would have needed to check harbors' inbound vessels schedule (or even get in touch with the port's captain office) before giving the alarm. The delay should be random within reasonable limits; the lesser experienced the loop crew, the longer the delay. What do you think?

[TheDarkWraith]

Originally Posted by gap

Could you also delay the transmission of loop-detected contacts, when they are outside the visual range of the loop station? (visual sensor on loop units required, searchlights optional). This is for simulating that, in absence of visual evidences, the operator would have needed to check harbors' inbound vessels schedule (or even get in touch with the port's captain office) before giving the alarm. The delay should be random within reasonable limits; the lesser experienced the loop crew, the longer the delay. What do you think?

Looking over the stock code the veterancy level is already accounted for.

This delay is basically already coded in. The signal strength returned from the function that checks to see if sensor detected any contacts is used in a random number generator. The value of the random number is the final decider as to whether or not unit detected any contacts. If they didn't then there's a game timer that has to expire before contacts are checked again to see if they are detected.

[gap]

Originally Posted by TheDarkWraith

Looking over the stock code the veterancy level is already accounted for.

This delay is basically already coded in. The signal strength returned from the function that checks to see if sensor detected any contacts is used in a random number generator. The value of the random number is the final decider as to whether or not unit detected any contacts. If they didn't then there's a game timer that has to expire before contacts are checked again to see if they are detected.

Yep, but if I got you correctly, the sensor whose detection strenght is currently taken in account (as far as magnetic detection is concerned), is a "boosted" hydrophone, which is not affected by external visibility anyway. What I am suggesting is: as soon as the loop detects a contact, get contact's range and calculate the visual detection time of an hypothetical surfaced contact at the same range (use a small surface vessel or a surfaced submarine as reference for detectable surface factor).

if, given the current external conditions, this time is shorter than loop's detection time, and the enemy contact is surfaced: take no action (the contact has already been detected and reported by the visual sensor probably);

if visual detection time is shorter than loop's detection time, and the enemy contact is submerged: send immediate contact report;

if visual detection time is longer than loop's detection time (no matter if the contact is surfaced or submerged): calculate the detection time difference among the two sensors, and apply an additional delay equal to it;

if, finally, the contact (submerged or not) is beyond loop station's max visual range (on moonless nights or with heavy fog), apply a veterancy related random delay, taking into account the investigations needed for avoiding a fake alarm.

Is this too complicated?

[TheDarkWraith]

Originally Posted by gap

Is this too complicated?

Yep.

Just try out what I made, you'll see it works very well.

When the game iterates over the sensors to see if any detected a contact, the sensor whose signal strength is the highest is the one who detected the contact as far as the game is concerned.

[gap]

Originally Posted by TheDarkWraith

Yep.

Just try out what I made, you'll see it works very well.

When the game iterates over the sensors to see if any detected a contact, the sensor whose signal strength is the highest is the one who detected the contact as far as the game is concerned.

Okay, no problem

[TheDarkWraith]

Working on a new patch to the SHSim.act file that would decrease the attacker's sonar signal strength returned if the attackee is moving slow enough and is close enough to the bottom.

Right now I'm in the discovery phase of the development. I've defined the following variables:
- speed above which signal strength is not reduced at all - 2.0 knots (UpperSpeed)
- speed below which signal strength can be reduced - 1.0 knots (LowerSpeed)
- depth above which signal strength is not reduced at all - 25m (UpperDepth)
- depth below which signal strength can be reduced - max depth for location - let's say it's 40m for this example (LowerDepth)
- minimum signal strength reduction - 20%
- maximum signal strength reduction - 60%

This means if attackee's speed is > 2 knots or depth is between 0-25m then signal strength is not reduced at all. Depth % is 0.0 and Speed % is 0.0

If attackee's speed or depth is between the Upper and Lower limits then:
- find difference between depth Lower and Upper limits - i.e. 40m - 25m = 15m
- subtract attackee's current depth from Lower limit - i.e. 40m - 32m = 8m
- calculate (depth difference - 8m / limits difference - 15m) and subtract this from 1.0 thus getting % of limit range used. Thus the closer you are to LowerDepth the higher the % - this is Depth % (0.53333)
- find difference between speed Upper and Lower Limits - i.e. 2.0 - 1.0 = 1.0 knots
- subtract attackee's current speed from Upper limit - i.e. 2.0 - 1.3 = 0.7 knots
- calculate (speed difference - 0.7 / limits difference - 1.0) thus getting % of limit range used. Thus the closer you are to LowerSpeed the higher the % - this is Speed % (0.7)

If attackee's speed is <= 1.0 knots and depth >= 40m then Speed % and depth % will be 1.0

- calculate difference between max and min signal strength reduction (0.60 - 0.20 = 0.40) - this is DeltaSignalStrengthRed
- get a random number in range 0.0 - 1.0 - let's say random number is 0.39
- multiply random number (0.39) by DeltaSignalStrengthRed (0.4) and add min signal strength reduction to it (0.20) thus getting the signal strength reduction - 0.356
- multiply result above (0.356) by Depth % (0.53333) - new result is 0.18987
- multiply result above (0.18987) by Speed % (0.7) - new result is 0.13291

Signal signal reduction for attacker's sonar is 13.291% for this example

What do you all think about these values? Look good or need different values?

[gap]

Originally Posted by TheDarkWraith

Working on a new patch to the SHSim.act file that would decrease the attacker's sonar signal strength returned if the attackee is moving slow enough and is close enough to the bottom.

...

What do you all think about these values? Look good or need different values?

Your algorithm looks unexceptionable
(though apparently not lesser complicate than the one I had proposed yesterday for the magnetic loop patch )
I have no idea about the constant variables to be applied in the patch though. What about making them user configurable?

[gap]

@ TDW

talking again about the optimal values to be set in your sonar patch, maybe you can get some clues from the comments to this other mod by Stiebler (for SH3). He used a different approach though: rather than varying minimum signal strenght, he varied the minimum surface factor of the sonar sensor.

[TheDarkWraith]

Originally Posted by gap

@ TDW

talking again about the optimal values to be set in your sonar patch, maybe you can get some clues from the comments to this other mod by Stiebler (for SH3). He used a different approach though: rather than varying minimum signal strenght, he varied the minimum surface factor of the sonar sensor.

That's a poor approach varying the minimum surface thing. If that test fails then no contact is detected. My way at least gets some kind of signal strength returned thus enabling a chance for contact to be detected.

[TheDarkWraith]

Stumbled upon how the game decides which contact of a list of contacts detected by a unit is selected as the contact detected. Each unit has a priority number assigned to them. When the game iterates over all the contacts detected the unit with the highest priority value is the contact detected. Always wondered how the game decided this

[Silent Steel]

You are Black Magic

[THE_MASK]

Originally Posted by TheDarkWraith

Stumbled upon how the game decides which contact of a list of contacts detected by a unit is selected as the contact detected. Each unit has a priority number assigned to them. When the game iterates over all the contacts detected the unit with the highest priority value is the contact detected. Always wondered how the game decided this

This IS an awesome find .

[TheDarkWraith]

Originally Posted by sober

This IS an awesome find .

Yes it is. I always wanted the AI subs to target merchants instead of warships first

[Tonci87]

Originally Posted by TheDarkWraith

Yes it is. I always wanted the AI subs to target merchants instead of warships first

Ooh I like where this is going