Sensors

[makman94]

continue the discussion about (visual) sensors (from thread: Sh3.exe and Asdic in shallow waters (http://www.subsim.com/radioroom/showthread.php?t=189367))...

Hitman said:
....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....

that was just a guess that were posted somewhere but never prooved . in game is not happening anything like that. just set at your periscope visual in sensors.dat a value at max range=1km and you will see that nothing is changing ! target continue to be spoted at 13-14 or even 15 km at deep night.

don't confuse the environments with all these . own crew sensors are not 'following' correctly the environment becuase the light factor at sensors.cfg seems to be broken (sensors for ai though seems to 'react' better at light factor in sim.cfg ) . so ,if we get the advantage to can set the own crew visuals during night then it is a piece of cake to create an as much dark environment we want to be in full 'harmony' with the setted by us values at own crew visuals.(thats why i never made totally darked the MEP, becuase no matter what the own crew would always spot ships far away).

one question that still is very interesting is this : why in one specific single mission where the parameters are always the same (positions of ships,amount of darkness,sea state , time...etc) the detection range is ...random ? what makes the own crew spot the target other times to 15km and other times to 4km (in same mission with repeated tests) ?

[reaper7]

continue the discussion about (visual) sensors (from thread: Sh3.exe and Asdic in shallow waters (http://www.subsim.com/radioroom/showthread.php?t=189367))...

Hitman said:


that was just a guess that were posted somewhere but never prooved . in game is not happening anything like that. just set at your periscope visual in sensors.dat a value at max range=1km and you will see that nothing is changing ! target continue to be spoted at 13-14 or even 15 km at deep night.

don't confuse the environments with all these . own crew sensors are not 'following' correctly the environment becuase the light factor at sensors.dat seems to be broken (sensors for ai though seems to 'react' better at light factor in sim.cfg ) . so ,if we get the advantage to can set the own crew visuals during night then it is a piece of cake to create an as much dark environment we want to be in full 'harmony' with the setted by us values at own crew visuals.

one question that still is very interesting is this : why in one specific single mission where the parameters are always the same (positions of ships,amount of darkness,sea state , time...etc) the detection range is ...random ? what makes the own crew spot the target other times to 15km and other times to 4km (in same mission) ?

Which mission are you referring to is it all missions where the target is in the same place? Want to see if I can figure out OllyDebug using the Info Stiebler sent me to track down the U-Boat Visual Sensor.
If I could just figure out where the Sensor Variable is being stored I might be able to do something with it. :hmmm:

[makman94]

Which mission are you referring to is it all missions where the target is in the same place? Want to see if I can figure out OllyDebug using the Info Stiebler sent me to track down the U-Boat Visual Sensor.
If I could just figure out where the Sensor Variable is being stored I might be able to do something with it. :hmmm:

i guess John that everyone can create set up situations at single missions to test sensors . anyway,here is one mission i made for testing purposes :
http://speedy.sh/246jT/test-mission-DetectRange.rar
target is showing the less hull to us at this mission and it is deep night .
run many times the mission and you will see the random detection ranges

[reaper7]

Thanks Mate, helps to be on the same mission for testing purposes :up:

As per my post here in stieblers thread:
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

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

Found the Variable for Depth under keel too but this only updates when the command is Issued, so may not be of use.

"sh3.exe"+001546C4 and 1 pointer offset 1C

Still using the Current Depth and the SeaDepth would suffice to know if the Sub in on the bottom. If Depth<=SeaDepth then apply Sensor adjustment. ;)

Appears the SeaDepth Figure is Bang on if it read 111M then the seabed is 111M unlike the Depth under Keel command which applies an error to the Depth.
So therefore the sub can never dive deeper then the seaDepth value. so then if Subdepth=Seadepth, U-boat is on the seafloor.

[h.sie]

Regarding vampire nights

Using GWX 16km environment, I also was amazed how far my crew and I could see in dark night (sometimes > 10km), while the enemy is completely blind and cannot see me in 200m distance.

While "hacking" the visual sensors for my type VIIF wolfs, I made some discoveries regarding visual sensors: Assume there are the player sub P and two escorts A and B. Every second, every sensor of every ship looks at the other ships. The arrow -> means "looks at".

P->A
P->B

A->P
A->B

B->P
B->A

But: In the code I cannot see, which sensor currently is looking, since the sensor's name (e.g. AI_Visual) is stored elsewhere. Same discovery that Stiebler did with his ASDIC. I can only identify a sensor by its range value, e.g. 30000m for GWX AI-Visual.

At the beginning of every "look-process", first, the distance between the sensor and the current target object is used to calculate a certain variable, which directly affects detection probability, maybe it IS the detection probability. After that, other factors like light, fog and so on modify this variable. Not examined in detail.

Multiplying this variable with a factor 10 will raise detection probability accordingly. Factor 0,1 will lower detection probability.

It would be easy to adjust / modify this factor according to the sun position (day, night, afternoon).

2 problems remain:

1) ATM this modification can only be done for all sensors in common. I cannot differ between different sensors in a smart way - except for the "dirty solution" by identifying them by their range (which unfortunately differs between supermods). AND: While Uboat crew sensors must be made more blind during night, AI-sensors ARE already blind and should be made to see better. So it is necessary to differ between AI-Sensors and Crew sensors. Only dirty solution possible ATM (indentify by range).

2) Even if we can modify sensors in a smart way, the objects are still rendered to be visible for the player in the dark night. This would cause a dysbalance between the crew ability to see and the players ability - which currently is very well balanced, at least in my sh3-installation. I don't know how to change the rendering so that the objects also are made less visible during the night.

[Rubini]

....

one question that still is very interesting is this : why in one specific single mission where the parameters are always the same (positions of ships,amount of darkness,sea state , time...etc) the detection range is ...random ? what makes the own crew spot the target other times to 15km and other times to 4km (in same mission with repeated tests) ?

One of the factors that leave to this behaviour is (in sensors.dat) the max range and precise range. If you make them the same this behaviour is much less noticiable. But itsn't the unique culprite. Also the settings on sensors.cfg give to the whole sensitivity a random behaviour. The major the numbers (sensors.cfg) then more (and random) time to the crew detects something. Some years ago I made a complete revamp of the sensors in a mod "Stay Alert crew" to try to make the crew more alert and quicky on their detection to be in par on what you can see at day/night (obviously in the end was an heroic work to make day/night works well). I don't need to say that the mod never worked as intend for the multiples sh3 installtions out there...

Edited: I made a very good readme that time about how the sensors settings works. Take a look.

[reaper7]

In the code I cannot see, which sensor currently is looking, since the sensor's name (e.g. AI_Visual) is stored elsewhere. Same discovery that Stiebler did with his ASDIC. I can only identify a sensor by its range value, e.g. 30000m for GWX AI-Visual.


Where can you see this Range value for each Sensor within Ollydebug.
I would like to see if I can find anything relating to them. ;)

More eyes looking, you never know. :up:

[h.sie]

@makman: detection ranges indeed are random, since - every second - a detection probability is calculated (from distance, weather etc.) and random numbers are used in order to determine whether object is detected or not. this luckily leads to random detection ranges, otherwise the game would be boring.

@reaper: Set a break at Sh3Sim.act+017012, but use the unpatched one.

[Rubini]

Regarding vampire nights

Using GWX 16km environment, I also was amazed how far my crew and I could see in dark night (sometimes > 10km), while the enemy is completely blind and cannot see me in 200m distance.

While "hacking" the visual sensors for my type VIIF wolfs, I made some discoveries regarding visual sensors: Assume there are the player sub P and two escorts A and B. Every second, every sensor of every ship looks at the other ships. The arrow -> means "looks at".

P->A
P->B

A->P
A->B

B->P
B->A

But: In the code I cannot see, which sensor currently is looking, since the sensor's name (e.g. AI_Visual) is stored elsewhere. Same discovery that Stiebler did with his ASDIC. I can only identify a sensor by its range value, e.g. 30000m for GWX AI-Visual.

At the beginning of every "look-process", first, the distance between the sensor and the current target object is used to calculate a certain variable, which directly affects detection probability, maybe it IS the detection probability. After that, other factors like light, fog and so on modify this variable. Not examined in detail.

Multiplying this variable with a factor 10 will raise detection probability accordingly. Factor 0,1 will lower detection probability.

It would be easy to adjust / modify this factor according to the sun position (day, night, afternoon).

2 problems remain:

1) ATM this modification can only be done for all sensors in common. I cannot differ between different sensors in a smart way - except for the "dirty solution" by identifying them by their range (which unfortunately differs between supermods). AND: While Uboat crew sensors must be made more blind during night, AI-sensors ARE already blind and should be made to see better. So it is necessary to differ between AI-Sensors and Crew sensors. Only dirty solution possible ATM (indentify by range).

2) Even if we can modify sensors in a smart way, the objects are still rendered to be visible for the player in the dark night. This would cause a dysbalance between the crew ability to see and the players ability - which currently is very well balanced, at least in my sh3-installation. I don't know how to change the rendering so that the objects also are made less visible during the night.

Hi h.sie,

Some comments:

1. the rendering issue (your monitor, your files at a once): Hitmann already said correctly that the rendering max distance at night (mainly) is also a matter of adjust on your monitor color/contrast/brightness and also dependent on what environment colors you are using. Almost all supermods try to delivery something already adjusted - but trust me, isn't equall for all because the monitor differences. So, we never will have something working very well for all users.

2. the type of environment 8k or 16km etc (scene.dat, env folder files): this is again making a fubar on the matter. Different fog distance settings, different waves size, different env colors, different sky textures - all this can produce different detections distances and different rendering points.

3. finally the sensors (sensors.dat, sensors.cfg , sim.cfg and AI_sensors.dat) : again we have a lot of different mods and different personal adjust here producing again different detections distances.

By the exposed above we can see that we don't need to delivery a real and total solution for all. What we need to delivery is a working&plausive night uboat crew visual detection. I mean, something that works as the AI_sensors.

We can't forget that the player sensors have two values (the precise range and the max range). To our intention we must use the max range settings.

I will suggest (if possible) to make the mod with two range options (that you could then easily detect on the code - needs to be exclusive non?), lets say: 8650 or 16250. This will be the trigger to the mod find the correct values just for player visual sensors and then make the cut based on the light of the environment.

[Rubini]

Continuing from above...

Then the problems about the moment that the object is rendered and the moment when the crew detects it ( a bit random as we talk above) can be then adjusted on the scene.dat (no hardfix needed) to each mod that wants to use the fix. At first I can't see another solution.

[Rubini]

Excuse me by the followed posts. Hopes that this also could add knowing to the matter.

Yesterday at night I tried this:

1. Made a new settings on my Sensors.dat (16km now) changing my Visual sensor max range from 16000 to 7000 (The precise was also changed from 10000 to 5000). Mounted the file as a Night_sensor_mod.

2. Then, when the night comes I enabled the mod with JSGME in patrol (save/exit patrol/enabled the mod/reload patrol) and continues. All my visual contacts were now very proof and plausive, max detection more or less at 6800m max and I barely also could see the ships on the night horizon at same time (this was for nofog parcial clouds weather). I used 7000 because this is the distance at night that I can start to see things on my Sh3 settings/my monitor for this weather settings.

The idea here is just to try/test how the fix must work. Just cutting the max range setting based on the light of the environment. The fix must do this automatically without the need to save/exit/reload and in a more smooth way as the light goes and comes on the environment. The adjust on scene.dat is easily to be done later (if needed) by each player that want to use the fix (or the big mods can provide it) to match the night max distance visual sensor and the eye detectable rendering max distance.

[MCHALO12]

Hi friends,

I have been working on sensors for the last months and tried to find a realistic solution for the visual sensor of the enemy: surfaced night attacks must be possible, so the detection range at night should be between 1000 and 500 meters in standard conditions (medium waves, light clouds). On the other hand, the daylight detection range should be quite hight (8 to 14 kilometers in good conditions). I edited the files sensors.dat, AI_sensors.dat, sim.cfg and sensors.cfg. After about 200 ingame test with different values, I still haven't found the perfect solution: The sensors of the enemy ships and airplanes now work as intended, but now I am facing problems with my crew....

But first, some of the relationships which are important: the values in sim.cfg seem to affect the AI ships AND the crew of your submarine: a higher "light factor" in sim.cfg makes the enemies see less far in darkness, but so will your crew. In order to compensate this, the "visual light factor" in the sensors.cfg has to be set to a HIGHER value, which will make your crew see better again.
Furthermore, a higher "light factor" in sim.cfg does not only make the enemy see less far at night, it also affects the detection range at daytime (gets a little smaler). To compensate this, "maxrange" and "precise range" in sensors.dat has to be enlarged. With these three values in right balance (which requires really lots of tests) the detection range of the enemy ships can be adjusted. BUT: The sensors are also affected by the competence of the units, which means that many more test have to be done. AND: the "worst case" has to be considered, too: enemy destroyers should also detect you in really bad conditions (wind 15 m/s, heavy fog, clouds). This is where - in my opinion - GWX fails: a veteran destroyer will not visually detect you in the described conditions, no matter how close you get.

Somebody wrote the "visual light factor" in sensors.cfg was broken. I don't know if it is really broken, but it does act weird sometimes... Currently I am trying to make my crew see better again and be more reliable: at the moment, the detection range differs way to much.

As a conclusion, I think the sensor values can not be "set right" for every situation (weather, time of day, competence level,...), but a reasonable compromise has to be found wich again will be different for every type of player. As long as h.sie does not manage to rewrite the code of the sensors (is anything impossible for this brilliant guy? :) ), I think everybody has to find his own "perfect solution" or use one of the already existing. I doubt that giving one solution in the next "Realism fix" while still using the stock mechanics would make the bigger part of the players happy: some people want to have an easy game, other want hardcore realism (like me). Perhaps the better idea would be to rewrite the sensors' code (if possible) in a more traceable way, so that everybody could set their own values?

Best regards, MCHALO12.

[Rubini]

@MCHALO!: take a look here:
http://www.subsim.com/radioroom/showthread.php?t=107989&highlight=workaround

How sensors works and its limitations is already knowing since some years. Sim.cfg and AI_Sensors.dat are for AI and Sensors.cfg and Sensors.dat are for your crew.

What is in discussion here is not to revamp the whole sensors mess. But just give to the Visual Crew sensor a better behaviour based on the light of the environment.

Only this fix will be enough to we have a much better and realistic behaviour of the entire game, belive me.

Anyhow any approach or discussion on the matter is always produtive; take a look on the readme of the link(mod) above...there you have all the sensors settings explained.:up:

[h.sie]

@Rubini & MAkman:

What I can offer in the next time:

I my posts above I've talked about a variable that directly affects detection probability and thus could be used to change visible sensors ability during the night. Instead of making it dependent from sun position by hardcode patch, I can make it e.g. dependent from one of the TDC dials. So you can manipulate and scale it as you like, and find out the best settings for different environment (light) conditions. Then, at the end, your settings can be hardcoded.

What I can't offer:

Doing the environent tests mentioned above by myself.

[Rubini]

Hi h.sie,

Any offer is welcome.

I can make all tests, I'm very interested on this fix, no problems. (I guess that makman can do it also)

Until now I understood that we have two approachs. Correct me if I'm wrong:

1. Your proposal, the variable that affects detection probability. But can you make it specific just for player crew visual sensor?

2. that approach by the max range setting value (the same approach that stiebler is doing on asdic). We can use a know and exclusive value to make things more easy. Let's say 16250, I will then modify my sensors.dat visual max range to 16250 to match your modification on the code and we can start test.

Can you explain the good and bad of each approach? Is one of them more easy to be done than the other?

[makman94]

Thanks Mate, helps to be on the same mission for testing purposes :up:

As per my post here in stieblers thread:


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

Found the Variable for Depth under keel too but this only updates when the command is Issued, so may not be of use.

"sh3.exe"+001546C4 and 1 pointer offset 1C

Still using the Current Depth and the SeaDepth would suffice to know if the Sub in on the bottom. If Depth<=SeaDepth then apply Sensor adjustment. ;)

Appears the SeaDepth Figure is Bang on if it read 111M then the seabed is 111M unlike the Depth under Keel command which applies an error to the Depth.
So therefore the sub can never dive deeper then the seaDepth value. so then if Subdepth=Seadepth, U-boat is on the seafloor.

sorry John but i can't understand your post ! i can't see where is the relation to the vampire nights issue,seems to be off topic (in case that you are talking about the non detection when at sea bottom)

Regarding vampire nights

Using GWX 16km environment, I also was amazed how far my crew and I could see in dark night (sometimes > 10km), while the enemy is completely blind and cannot see me in 200m distance.

While "hacking" the visual sensors for my type VIIF wolfs, I made some discoveries regarding visual sensors: Assume there are the player sub P and two escorts A and B. Every second, every sensor of every ship looks at the other ships. The arrow -> means "looks at".

P->A
P->B

A->P
A->B

B->P
B->A

But: In the code I cannot see, which sensor currently is looking, since the sensor's name (e.g. AI_Visual) is stored elsewhere. Same discovery that Stiebler did with his ASDIC. I can only identify a sensor by its range value, e.g. 30000m for GWX AI-Visual. --so if we set a 'unique' value there ,something like 15,838 m , you will be able to 'locate' it ,right ? my point is to create a community sensors mod which will be indepedent from the current supermods . once this is done it will be very easy to each supermod to import our visuals sensors setting (only the visuals) to its files without changing anything else to their rest sensors

At the beginning of every "look-process", first, the distance between the sensor and the current target object is used to calculate a certain variable, which directly affects detection probability, maybe it IS the detection probability. After that, other factors like light, fog and so on modify this variable. Not examined in detail. -- here is a big point H.Sie ! can you 'locate' the procedure that sh3's engine follows to calculate the 'ship spotted' range ????

Multiplying this variable with a factor 10 will raise detection probability accordingly. Factor 0,1 will lower detection probability.

It would be easy to adjust / modify this factor according to the sun position (day, night, afternoon). ---this seems very promising ! at least ,we have a ...hope !

2 problems remain:

1) ATM this modification can only be done for all sensors in common. I cannot differ between different sensors in a smart way - except for the "dirty solution" by identifying them by their range (which unfortunately differs between supermods).--as i said ,my point is to go for an indepedent community sensors mod AND: While Uboat crew sensors must be made more blind during night, AI-sensors ARE already blind and should be made to see better. So it is necessary to differ between AI-Sensors and Crew sensors. Only dirty solution possible ATM (indentify by range).-- i think that this is allready indepedent by devs, sensors.cfg and sensors.dat are for own crew (and we are working on these files) and sim.cfg and AI_Sensors.dat are for ai units

2) Even if we can modify sensors in a smart way, the objects are still rendered to be visible for the player in the dark night. This would cause a dysbalance between the crew ability to see and the players ability - which currently is very well balanced, at least in my sh3-installation. I don't know how to change the rendering so that the objects also are made less visible during the night.---the 'goal' is to reduce the own crew detection ranges (to our wills) during night. then it is easy to dark the environment and make it to become in harmony with the setted visual ranges (haven't ever tried to make it totally darked but i know all the needed points that can give us even a 100% darked env if we want to.just have to give it a shot but i think is doable).of course if we managed to make the units not rendering at all will be even better but is there any idea how this can be achieved ?

One of the factors that leave to this behaviour is (in sensors.dat) the max range and precise range. If you make them the same this behaviour is much less noticiable. But itsn't the unique culprite. Also the settings on sensors.cfg give to the whole sensitivity a random behaviour. The major the numbers (sensors.cfg) then more (and random) time to the crew detects something. Some years ago I made a complete revamp of the sensors in a mod "Stay Alert crew" to try to make the crew more alert and quicky on their detection to be in par on what you can see at day/night (obviously in the end was an heroic work to make day/night works well). I don't need to say that the mod never worked as intend for the multiples sh3 installtions out there...

Edited: I made a very good readme that time about how the sensors settings works. Take a look.

yes Rubini , but if we make the precise and max ranges the same value ...the randomness is not totally eliminated so it must be something else too!in sim.cfg i can see some 'detection probabilities settings' but i can't see anything like that in sensors.cfg
you think that these 'detection probabilities settings' at sim.cfg MAYBE effects all units ?? i mean both own sensors and ai ?
i think that it will help us very much to 'locate' what is cuasing this randomness(wish to be only at cfg's or dat's files) and totally eliminate it during the development of mod.after the finishing of mod we can adjust this randomness back again to our needs.

about your readme there: i had studied it very carefully Rubini ! you were something like my 'teacher' ;)

Continuing from above...

Then the problems about the moment that the object is rendered and the moment when the crew detects it ( a bit random as we talk above) can be then adjusted on the scene.dat (no hardfix needed) to each mod that wants to use the fix. At first I can't see another solution.

you mean by the ObjectsRelativeZmin and ObjectsRelativeZmax at fog distances ,right Rubini ?? or it is more than this in scene.dat ?

Excuse me by the followed posts. Hopes that this also could add knowing to the matter.

Yesterday at night I tried this:

1. Made a new settings on my Sensors.dat (16km now) changing my Visual sensor max range from 16000 to 7000 (The precise was also changed from 10000 to 5000). Mounted the file as a Night_sensor_mod.

2. Then, when the night comes I enabled the mod with JSGME in patrol (save/exit patrol/enabled the mod/reload patrol) and continues. All my visual contacts were now very proof and plausive, max detection more or less at 6800m max and I barely also could see the ships on the night horizon at same time (this was for nofog parcial clouds weather). I used 7000 because this is the distance at night that I can start to see things on my Sh3 settings/my monitor for this weather settings.--don't rely at the distances that you see the objects at your env. this can be 'fixed' by creating darker envs (as much we want). about your setting at max range=7km . this was expected to 'see' ships at about 7km during night(as your setting was 7km) but the problem is that also ,during day , you will spot them at 7km

The idea here is just to try/test how the fix must work. Just cutting the max range setting based on the light of the environment. The fix must do this automatically without the need to save/exit/reload and in a more smooth way as the light goes and comes on the environment. The adjust on scene.dat is easily to be done later (if needed) by each player that want to use the fix (or the big mods can provide it) to match the night max distance visual sensor and the eye detectable rendering max distance.--didn't understand exactly your point here !

....

Somebody wrote the "visual light factor" in sensors.cfg was broken...

this is not polite MCHALO ,
this 'somebody' has nickname and it is makman94
reading more carefully my post you will see that i said ''seems to be broken'' and not that it is broken for sure.
about your post: i did a small test yesterday and i set light factor=500(!) at sim.cfg and light factor=1,6 at sensors.cfg (no other changes). The result is that at deep night (with a mission that target is showing the less hull) ,the ship was spotted at 14.400 m , so the light factor at sim.cfg seems that is NOT effecting the own crew visuals. better check this you too again and confirm
(mission was tested on a clean install of NYGM with only the light factors tweaked and no other mods installed)

@Rubini & MAkman:

What I can offer in the next time:

I my posts above I've talked about a variable that directly affects detection probability and thus could be used to change visible sensors ability during the night. Instead of making it dependent from sun position by hardcode patch, I can make it e.g. dependent from one of the TDC dials. So you can manipulate and scale it as you like, and find out the best settings for different environment (light) conditions. Then, at the end, your settings can be hardcoded.

What I can't offer:

Doing the environent tests mentioned above by myself.

you mean that we can , in real time (during in game) to 'adjust' the value (via the tdc dial-only for our development of mod) and continue our testings without exiting at all ???
this is FANTASTIC (if i get it right) !!! yea,sure this is way cooler tool than i ever expected to have at adjustments !!

don't worry about the testings....i will help as much i can !


@H.Sie and Rubini,

i am doing some tests ,

MAYBE ,there is the chance to avoid the hardcode way .can't say anything more yet for sure.

need to make more tests , i am having some 'good' results but need to locate either if ambientlightcolor(at envcolors during night settings--this is very 'powerfull' value that effecting the detection ranges) is responsible,either if some extreme values i am using at sensors.cfg are responsible.(light factor=500 seems to making -need to make more tests,not sure yet- completely 'blind' the crew .this is good becuase it 'shows' that factor is working but i remember that trying to reduce it to lower values like 200 or 100 the crew is starting having view again but this is getting suddenly and vampire visual is back at all its glory.maybe there is a value ,even using demicals digits, to find a factor ,something like 98,5 or 198,5 -haven't locate yet where the 'change' is happening- and manage to have a 'logical' detection range during deep night.)
i will let you know if this 'leads' to anywhere.

[Rubini]

....
yes Rubini , but if we make the precise and max ranges the same value ...the randomness is not totally eliminated so it must be something else too!in sim.cfg i can see some 'detection probabilities settings' but i can't see anything like that in sensors.cfg
you think that these 'detection probabilities settings' at sim.cfg MAYBE effects all units ?? i mean both own sensors and ai ?
i think that it will help us very much to 'locate' what is cuasing this randomness(wish to be only at cfg's or dat's files) and totally eliminate it during the development of mod.after the finishing of mod we can adjust this randomness back again to our needs.

Oh...our bad english!:DL
Makman, yes I tried to say exactly this, making both settings the same don't fix the random side (just make it small). The visual detection point is given by a formula that uses the sensors.cfg parameters (not in sim.cfg), that probably also have some random value in its formula. But I guess that we can't find it (the randomness) or only with hexhardcoded (h.sie) it perhaps could be found.
Anyway I think that its irrelevant (randomness) for what we want to fix. It will be not a problem to our tests IMO.

....
you mean by the ObjectsRelativeZmin and ObjectsRelativeZmax at fog distances ,right Rubini ?? or it is more than this in scene.dat ?
Yes, exactly!

....
@H.Sie and Rubini,

i am doing some tests ,

MAYBE ,there is the chance to avoid the hardcode way .can't say anything more yet for sure.

need to make more tests , i am having some 'good' results but need to locate either if ambientlightcolor(at envcolors during night settings--this is very 'powerfull' value that effecting the detection ranges) is responsible,either if some extreme values i am using at sensors.cfg are responsible.(light factor=500 seems to making -need to make more tests,not sure yet- completely 'blind' the crew .this is good becuase it 'shows' that factor is working but i remember that trying to reduce it to lower values like 200 or 100 the crew is starting having view again but this is getting suddenly and vampire visual is back at all its glory.maybe there is a value ,even using demicals digits, to find a factor ,something like 98,5 or 198,5 -haven't locate yet where the 'change' is happening- and manage to have a 'logical' detection range during deep night.)
i will let you know if this 'leads' to anywhere.
Crossing fingers...but can I bet 2 beers that it will not solve the problem?:arrgh!:
Just kidding but IIRC 2 years ago I tried to mess with this and don't be able to have a good adjust of the whole thing at the end. But you knows, sometimes we try again and we achieve it!

[makman94]

Crossing fingers...but can I bet 2 beers that it will not solve the problem?:arrgh!:
Just kidding but IIRC 2 years ago I tried to mess with this and don't be able to have a good adjust of the whole thing at the end. But you knows, sometimes we try again and we achieve it!

...only two ?? ok...here is the deal ...one takes the mam ( mam=meat..etc , i hope that you are not vegetarian! ) and the other one takes the glou-glou (glou-glou=drinks). no.... limits to both of them !

back to topic: the ambientlightcolor(at envcolors) is very powerfull value Rubini ! i discover it by...accident (!) and maybe is the ONLY ONE value that sh3's engine is taking in consideration for understanding the 'night' ! i am telling you this becuase when i messed with it (long time ago!) i discovered that at same mission(time,sea state...etc) ,different values at ambientlightcolor were giving different detection ranges. but it was this randomness thing that it doesn't let me say it for sure (i mean that it is the only value for engine to understand the 'night' and not the sun's position).

thats why i am saying that will help us a lot to find and totally 'eliminate' the randomness! will get it back at the end...it is not big deal after the completion of mod.

edit: this idea just came: lets create an envcolors.dat which has a totally darked (0,0,0) ambientlightcolor value during sunny DAY and see if the detection ranges are reduced like it is night! if this is happening then my 'theory' about the sh3's engine reading the 'night' maybe is correct !


i will keep trying to locate a value at light factor ...you never know ! (i am trying this from time to time ,when i want to 'kill' some time, from the first moment that i started tweaking the sensors but i forgot about where i was !:DL) . maybe there is this value...(not very optimistic though...)

[Rubini]

OK, 3 beers! :D But if ou really solve the vampire night vision, well, we will need to share that 1Ton shippment of brazilian beer between you and h.sie!

Looking forward mate!:up:

[reaper7]

sorry John but i can't understand your post ! i can't see where is the relation to the vampire nights issue,seems to be off topic (in case that you are talking about the non detection when at sea bottom)

Hi yes mate - was referring to the sea bottom.
Sorry though the thread was for all sensor investigations :oops:
Posted this info in other thread where it may be used :up:

Hope you have success with the ambientlightcolor :salute:

[Stiebler]

Could I suggest that, while H.sie is looking into the code side of things, he could perhaps try to cure the very irritating multiple 'ship spotted' reports that you obtain repeatedly as a ship (usually a warship) comes in and out of sight in light mist. Light mist is nearly always the cause.

One possibility would be simply to put a fixed time interval (game-time) between these reports. It really does not matter if the watch-officer fails to report every ship in a convoy as a consequence.

Stiebler.

[h.sie]

@Very short answer, since very busy: Yes, makman94, you'll be able to change the value 'online' during gameplay. This makes testing much easier.

But: I'll start to do this after having finished with my current 'project'.

[makman94]

Hi yes mate - was referring to the sea bottom.
Sorry though the thread was for all sensor investigations :oops:
Posted this info in other thread where it may be used :up:

Hope you have success with the ambientlightcolor :salute:
good morning John,
sure the thread is for all sensors (if this interests) but i wasn't sure if you were replied to me mate and was trying to understand the 'connection' to visual sensors . all cleared now

@Very short answer, since very busy: Yes, makman94, you'll be able to change the value 'online' during gameplay. This makes testing much easier.

But: I'll start to do this after having finished with my current 'project'.

good morning H.Sie,

whenever you are ready :up:
we don't have 'time' limits....the slower ...the better !

[Sailor Steve]

we don't have 'time' limits....the slower ...the better !
Best advice ever where any kind of work is involved.

In the words of science-fiction writer Robert A. Heinlein: "They didn't want it good, they wanted it Wednesday."

Alternately, there is an old model-builders' saying: "If you don't have time to do it right, when will you have time to do it over?"

[Stiebler]

Earlier, I suggested:
while H.sie is looking into the code side of things, he could perhaps try to cure the very irritating multiple 'ship spotted' reports that you obtain repeatedly as a ship (usually a warship) comes in and out of sight in light mist. Light mist is nearly always the cause.

One possibility would be simply to put a fixed time interval (game-time) between these reports. It really does not matter if the watch-officer fails to report every ship in a convoy as a consequence.I believe that I have now a hard-code working fix for this tiresome problem.

No need for H.sie (or anyone else) to waste time on it.

Stiebler.

[reaper7]

Earlier, I suggested:
I believe that I have now a hard-code working fix for this tiresome problem.

No need for H.sie (or anyone else) to waste time on it.

Stiebler.

:yeah: Thank you Stiebler, another great fix. Just keeps getting better and better :arrgh!:

[Fish In The Water]

:yeah: Thank you Stiebler, another great fix. Just keeps getting better and better :arrgh!:

Second the motion. Many thanks for another long sought solution! :salute:

[makman94]

Earlier, I suggested:
I believe that I have now a hard-code working fix for this tiresome problem.

No need for H.sie (or anyone else) to waste time on it.

Stiebler.

thats very nice new Stiebler :up:
finally , you got this sorted ?

one question is : what if one more ship from totally other direction(not a unit of the allready spotted convoy) appears in short time?



@Rubini : the ambientlightcolor is NOT doing the trick at day (i am talking for this: edit: this idea just came: lets create an envcolors.dat which has a totally darked (0,0,0) ambientlightcolor value during sunny DAY and see if the detection ranges are reduced like it is night! if this is happening then my 'theory' about the sh3's engine reading the 'night' maybe is correct !)
....BUT i discover that by setting ambientlightcolor to 0-0-0 at night (without changing anything else at NYGM's visual sensors) i am getting MUCH MUCH better results !
i haven't made any tests the last week (becuase i am spending my free time for u-boot-hahd stuff) but i am almost sure that ambientlightcolor (and probably all other 'lights' during night like the 'SunReflectColor') if reduced (to zero if necessery) are giving 'good' results ! need to make more tests ,all that i am saying here are something like 'observations' and not facts .
try it ,without changing anything at your sensors settings ,reduce to zero the ambientlightcolor and SunReflectColor during night and tell me : are you getting better results ?

[makman94]

Best advice ever where any kind of work is involved.

In the words of science-fiction writer Robert A. Heinlein: "They didn't want it good, they wanted it Wednesday."

Alternately, there is an old model-builders' saying: "If you don't have time to do it right, when will you have time to do it over?"

The first one is very good SS :DL,

....BUT....for the second one...:hmmm:...i am wondering : thats what the builders are saying....the truth is that even if they had all the time of the world to do it over ....very few of them will do it...right !! point is : start something right no matter what.
if it is finished...then ok,if not...then maybe later someone else take it further :up:(Leonardo da Vinci was the one that never ...finished anything of his brilliant ideas ? am i right ?)

[Rubini]

thats very nice new Stiebler :up:
finally , you got this sorted ?

one question is : what if one more ship from totally other direction(not a unit of the allready spotted convoy) appears in short time?



@Rubini : the ambientlightcolor is NOT doing the trick at day (i am talking for this: edit: this idea just came: lets create an envcolors.dat which has a totally darked (0,0,0) ambientlightcolor value during sunny DAY and see if the detection ranges are reduced like it is night! if this is happening then my 'theory' about the sh3's engine reading the 'night' maybe is correct !)
....BUT i discover that by setting ambientlightcolor to 0-0-0 at night (without changing anything else at NYGM's visual sensors) i am getting MUCH MUCH better results !
i haven't made any tests the last week (becuase i am spending my free time for u-boot-hahd stuff) but i am almost sure that ambientlightcolor (and probably all other 'lights' during night like the 'SunReflectColor') if reduced (to zero if necessery) are giving 'good' results ! need to make more tests ,all that i am saying here are something like 'observations' and not facts .
try it ,without changing anything at your sensors settings ,reduce to zero the ambientlightcolor and SunReflectColor during night and tell me : are you getting better results ?

I tried it some days ago but no luck. The results continued inconsistents, just small better than before. I never get that good result as if we had a real fix on the visual sensor.

BTW, IMO, too dark nights in game will make the game (in ours houses) unplayable in normal conditions - i mean, during daytime, night with lights on, etc. So, I am not sure that using a so dark nights in game as unique solution (if it works) for vampire nights is a good solution. Will perhaps fix something but will narrow the game environment options to the players.

[makman94]

I tried it some days ago but no luck. The results continued inconsistents, just small better than before. I never get that good result as if we had a real fix on the visual sensor.



hello Rubini ,

i made some more extensive tests and the results are DEFINETELY much much better with AmbientLightColor and ReflectLightColor setted to 0-0-0 (just for the testing purposes) .

i created a new mission with the target 'showing' us all of its hull (AoB=90) for being as easily as possible spoted . i have send you this mission (and something more) to test at your yahoo mail ,make a check there !

here is the results of my tests as for the detect ranges:

i run the same mission 10 times
on pure NYGM installation (no mods enabled and no tweaks at NUGM's files):

1. 8400 m
2. 13900 m
3. 10200 m
4. 13300 m
5. 14100 m
6. 12200 m
7. 13600 m
8. 13000 m
9. 11900 m
10. 10400 m

then i run the same mission again 10 times but with AmbientLightColor and ReflectLightColor setted to 0-0-0 and here are the results at detect ranges:

1. TARGET NOT SPOTED AT ALL !
2. 7900 m
3. 5600 m
4. TARGET NOT SPOTED AT ALL !
5. 2600 m
6. TARGET NOT SPOTED AT ALL !
7. TARGET NOT SPOTED AT ALL !
8. TARGET NOT SPOTED AT ALL !
9. 200 m
10. TARGET NOT SPOTED AT ALL !

so , as you can see , the AmbientLightColor and ReflectLightColor are definetely giving better results !

BUT i think that it is absolutely NESECCERY to start by locating what is causing this randomness to detect results and ELIMINATE this randomness during the development - tests (see the second pack results...there is one 7900 m !!!). that way ,we will be able then to have secure results as for the 'effectivness' of AmbientLightColor, ReflectLightColor and light factor's at cfgs files

check your pm at yahoo mail , i am very curius to see your results :up:

BTW, IMO, too dark nights in game will make the game (in ours houses) unplayable in normal conditions - i mean, during daytime, night with lights on, etc. So, I am not sure that using a so dark nights in game as unique solution (if it works) for vampire nights is a good solution. Will perhaps fix something but will narrow the game environment options to the players.

thats one other story that needs a lot of discussion Rubini ! point is this: are we after 'realism' ?...becuase if the answer is yes then you must not be able to see your nose during deep night (no moon nights). now, if you don't like the 'hardcore' dark envs then you (the player) will be able to see the ship at large distances....

[h.sie]

@makman: I've found the code dealing with crew sensors. Different from my first statements, crew sensors do not use the same code as ememy sensors - they use completely different code! Not understood until now how it works.

If still desired, I'll try to add an ability to manually scale up/down the detection probability during gameplay. And I could also try to bypass the influence of random-numbers on detection in order to make influences more visible.

Don't know what is possible. Not very optimistic.

[makman94]

@makman: I've found the code dealing with crew sensors. Different from my first statements, crew sensors do not use the same code as ememy sensors - they use completely different code! Not understood until now how it works.

If still desired, I'll try to add an ability to manually scale up/down the detection probability during gameplay. And I could also try to bypass the influence of random-numbers on detection in order to make influences more visible.

Don't know what is possible. Not very optimistic.

yes H.Sie , i understand that it must be a 'hard' one but i just wish you the best of luck on this . i can't help ,although i really would like to could,on executables so i only wish the best of luck to you and Reaper (i really trust this guy,he is very dedicated and very serious on his work !!) .

about the probability of detection : i don't think that is needed a tool for 'scaling' this up or down . i really would like a tool that TOTALLY ELIMINATE the randomness (if possible of course). yes , this tool would help a lot during the development of mod and ,at the end, if the mod is complete we can enable back again this randomness(altered by us as it would be located) at values

[reaper7]

@makman: I've found the code dealing with crew sensors. Different from my first statements, crew sensors do not use the same code as ememy sensors - they use completely different code! Not understood until now how it works.

If still desired, I'll try to add an ability to manually scale up/down the detection probability during gameplay. And I could also try to bypass the influence of random-numbers on detection in order to make influences more visible.

Don't know what is possible. Not very optimistic.

That's great news. Hope you have luck getting this working via Hardcode.
I could possibly do an external script that will alter the distance detected influenced by the time of day if its not possible to hardcode it.
I would need to find the line of code that stores the variables for detection range. Haven't tried it yet - will wait to see how you get on (Hardcoded would be a better solution) :up:

Again great work H.sie ;)

[LGN1]

Hi,

I don't know whether it's of interest, but here is an old post from OLC about visual sensors, light factors,...

http://www.subsim.com/radioroom/showpost.php?p=949608&postcount=1091

Cheers, LGN1

[makman94]

Hi,

I don't know whether it's of interest, but here is an old post from OLC about visual sensors, light factors,...

http://www.subsim.com/radioroom/showpost.php?p=949608&postcount=1091

Cheers, LGN1




I have FANTASTIC news guys !!!

@LGN1,this post of OLC was a real treasure ! the post of OLC 'showed' me that i hadn't setted to 0-0-0 :damn: the third (and seems more critical of all) environment 'light' !

so , i setted also the sunlightcolor to 0-0-0 and the results of 10 runs of my previous message's mission are :

1. TARGET NOT SPOTED AT ALL !
2. TARGET NOT SPOTED AT ALL !
3. TARGET NOT SPOTED AT ALL !
4. TARGET NOT SPOTED AT ALL !
5. TARGET NOT SPOTED AT ALL !
6. TARGET NOT SPOTED AT ALL !
7. TARGET NOT SPOTED AT ALL !
8. TARGET NOT SPOTED AT ALL !
9. TARGET NOT SPOTED AT ALL !
10. TARGET NOT SPOTED AT ALL !

OLC gave also another great tip ! that the reflectlightcolor is NOT effecting the visuals ,so i setted sunlightcolor and ambientlightcolor to 0-0-0 BUT i maxed a lot (not till higher max) the reflectlightcolor !
the results of 10 runs of same mission are :

1. TARGET NOT SPOTED AT ALL !
2. TARGET NOT SPOTED AT ALL !
3. TARGET NOT SPOTED AT ALL !
4. TARGET NOT SPOTED AT ALL !
5. TARGET NOT SPOTED AT ALL !
6. TARGET NOT SPOTED AT ALL !
7. TARGET NOT SPOTED AT ALL !
8. TARGET NOT SPOTED AT ALL !
9. TARGET NOT SPOTED AT ALL !
10. TARGET NOT SPOTED AT ALL !
(see the pics of these settings....my crew hasn't spot the target ! neither ,of course my own boat is spotted---don't pay attention at colors ...are just for testing purposes)
http://img684.imageshack.us/img684/3485/40316462.png

what does all these means ???
that he have a SOLUTION for the vampire effect ! a very CAREFULL selection of colors (intensity and RGB) at sunlightcolor and ambientlightcolor during night will give us the desired detect ranges for own crew ! and then we can SAFELY enlight the ships-sub as much we want via the ReflectLightColor and make them to come in harmony with the environment !!.of course ,this is something that must be done to each ones envcolors.dat

@H.Sie, i think that this is a perfect solution to vampire effect ! need ,of course , to create the envcolors.dat to see it 'working' in game but i am very optimistic that it will 'work' for sure !!
in this case,if you manage to create this tool that will eliminate the random probabilities at detect ranges we will be able to set these colors giving us the desired detect ranges !
i really believe that we are very close to fix it without the need of the 'hardcode' way!

=======

[h.sie]

@Makman: I would not be that optimistic.

In 2008, I followed the development of OLC environment. OLC spent months to fine-adjust the light intensities of his environment in order to have realistic enemy sensor behaviour at daylight and at night (surface attacks possible). The light intensities are the heart of his work.

If you now adjust these light intensities to match your requirements for crew sensors, the enemy sensor adjustment could get worse.

I fear it won't be possible to adjust the env color / intensity to have both: well-adjusted enemy AND crew sensors at daylight and at night.

But hopefully I'm wrong. Good luck !

[reaper7]

Hi H.sie do you know the location of the variable that is used for the 'Enemy Spotted' call i.e. the Range to nearest contact that has the random variance adjusted. :hmmm:

I've been able to find the Actual Distance to nearest contact 'From the Sh3sim.act' but its giving a random memory location each time so I can't read/write to it using my method.
Sh3sim.act+16E26 - Code :mov [edi+000000A0],edx

[Rubini]

....

thats one other story that needs a lot of discussion Rubini ! point is this: are we after 'realism' ?...becuase if the answer is yes then you must not be able to see your nose during deep night (no moon nights). now, if you don't like the 'hardcore' dark envs then you (the player) will be able to see the ship at large distances....

I can´t agree with you here Mak. I never saw any game with night so dark that you can´t see anything. I want realism, but I also want some fun, some playability. Deep dark nights is out if my interest because this is at first a game and I want to play it. As we know the broken sh3´s visual sensor at night give you so much irrealistic detections, this just need a fix, not need to be a very realistic one. You also know that with a reasonable ( just this) dark nights in sh3 you will not be able to see ships so far and i guees that this is enough for our intentions. It´s then just need to adjust what you can see with the new sensors (hardfix) detections night distance and we will have a really new game behaviour at night!

My vote, my ask, continues to be to a hard fix on player crew night visual sensor.
I´m ready to help h.sie in any test.:yep:

I don´t have NYGM installed on my system to make the tests that you asked me. But if it works, it will work at the stock game too. I will have a look and let you know my results:up:

[h.sie]

@reaper:

I use a single mission with one ship at 16km distance, coming slowly into my direction.

If you set a breakpoint at sh3.exe + 0x118F03, you can see a (float)variable on the stack at [esp+10]. This could be something like a detection probability. As long as its value is very small, the ship is not detected. If now distance gets smaller, this value rises, and suddenly jumps up to high values (currently don't know why). In this moment, the ship is detected, reported and shown on the nav-map. If I force this value to 0 by a little hack, the ship is never detected, even if its very near at daylight.

[reaper7]

@reaper:

I use a single mission with one ship at 16km distance, coming slowly into my direction.

If you set a breakpoint at sh3.exe + 0x118F03, you can see a (float)variable on the stack at [esp+10]. This could be something like a detection probability. As long as its value is very small, the ship is not detected. If now distance gets smaller, this value rises, and suddenly jumps up to high values (currently don't know why). In this moment, the ship is detected, reported and shown on the nav-map. If I force this value to 0 by a little hack, the ship is never detected, even if its very near at daylight.

Thanks H.sie this sound like just the variable I've been searching for. Like wise I've been using a singlemission by Makman for sensor testing.
And the Range location I posted above appears to activate exactly at the contacts max detection range (The circle shown when you click on the contact on the Nav-map at Easy Realism settings).

So I would Imagine the variable you found is 0 upto this point and then rises in a logarithmic fashion the closer you get to the contact (Same way the Stadimeter works for range finding) :hmmm:. That would explain why the value appears to jump to high values all of a sudden.

So using both of these Instructions my thinking of a solution would be to NOP the Instruction that write to the (sh3.exe + 0x118F03) so no value is sent to the memory location.
Then using the Instruction for distance to nearest contact (Sh3sim.act+16E26) we can send a large value to the sh3.exe + 0x118F03 location whenever we want.
So in essence we could send the value for different ranges for different stages of the day.

So if its dark send the large value (To activate the contact spotted routine) when the range to contact is between 1200m and 800m.
Like wise if its bright out then send the Large Value when target is between 20Km to 16Km out etc.


EDIT: Just looked at the code you posted (sh3.exe + 0x118F03) and this is the same value as the (Sh3sim.act+16E26)
So the variable on the stack at [esp+14] = Range to Contact while on the [esp+10] = Detection probability

Edit2: While the range to contact is read in at (sh3.exe + 0x118F03) from (Sh3sim.act+16E26) its not constant variable keeps reading in from other areas too. so jumps all around when breakpoint not set. So (Sh3sim.act+16E26) is a better solution for range as it value is constant updated for range only.
Not sure how to use Ollydebug to find [esp+10] to see the variable you refer to ??

[h.sie]

@reaper: Yup, try that out. That could already be a solution. In the meantime I try to understand how the variable is calculated.

[Hitman]

Originally Posted by makman94 http://www.subsim.com/radioroom/images_acpb/buttons/viewpost.gif (http://www.subsim.com/radioroom/showthread.php?p=1789927#post1789927)
....

thats one other story that needs a lot of discussion Rubini ! point is this: are we after 'realism' ?...becuase if the answer is yes then you must not be able to see your nose during deep night (no moon nights). now, if you don't like the 'hardcore' dark envs then you (the player) will be able to see the ship at large distances....


Well, yes and no. Yes it is true that sailing on a dark night you might not see the bow of your own ship, but the reason is that you see it pitched against dead black water. However, if you watch an object that is taller than you and is against the sky, that is a different thing and the ambience light might at least show you its silhouette -even if only by contrast.

I can't explain that, I have experienced it when sailing at night but it is difficult to describe. Simply consider two things of huge influence:

1) The ambient light level in the air

2) What you pitch the object against, i.e. the background.

The effect is quite weird because from a high merchant's bridge you would actually be able to spot an uboat at some distance because it is silhouetted against the sky, but as soon as it comes close, you are higher than him and will see it against the black water -where you don't stand a chance of spotting it even if very close!

I guess this is impossible to translate into the game :damn:

[reaper7]

@reaper: Yup, try that out. That could already be a solution. In the meantime I try to understand how the variable is calculated.

Added a second edit to the post above.

[h.sie]

@reaper: the variable I talk about of course jumps frequently, because it is located on the stack, that means it is a procedure-local variable with restricted lifetime and will be overwritten frequently as soon as the procedure ends. But this isn't really a problem and can easily be solved. I still prefer patching sh3.exe, because the whole code for crew sensors is located there: range, precise range and so on - the whole crew sensor algorithm! will take some time to understand it. But that's the fun part of it. Additionally, patching the Sh3Sim.act file is more difficult since one needs to write position-independent code and take care for relocation fixups (DLL !).

But I don't want to influence you and your ideas - since I am never 100% sure whether I see things correctly. Thus, let us try two different approaches. This is better than none.

I want to do as few changes to the sensor algorithm as possible. My first attempt is simply to multiply the detection probability variable with a certain value (1.0 (= no change) for day - and maybe 0,1 (= more blind) for night).

[reaper7]

@reaper: the variable I talk about of course jumps frequently, because it is located on the stack, that means it is a procedure-local variable with restricted lifetime and will be overwritten frequently as soon as the procedure ends. But this isn't really a problem and can easily be solved. I still prefer patching sh3.exe, because the whole code for crew sensors is located there: range, precise range and so on - the whole crew sensor algorithm! will take some time to understand it. But that's the fun part of it. Additionally, patching the Sh3Sim.act file is more difficult since one needs to write position-independent code and take care for relocation fixups (DLL !).

But I don't want to influence you and your ideas - since I am never 100% sure whether I see things correctly. Thus, let us try two different approaches. This is better than none.

I want to do as few changes to the sensor algorithm as possible. My first attempt is simply to multiply the detection probability variable with a certain value (1.0 (= no change) for day - and maybe 0,1 (= more blind) for night).

Thanks for the info h.sie, still trying to figure out assembly and ollydebug. Only used to directly interfacing to sh3s memory locations.
So your insights are a great learning tool. Your method in most likely the best one with the multiply by a percentage by time of day to reduce contact distance for target spotted. :up:

[h.sie]

@Makman: I have a working hack that completely removes the randomness from visual detection. That means: As soon as the detection probability variable exceeds a certain, user-defineable threshold value, the ship is detected by the crew. This allows very detailed and easy analysis of the environment parameters influence on detection probability.

But it will take some time until completion......

[reaper7]

Sounds great, I think I'll leave this in your hands mate and concentrate on other avenues. Look forward to testing it :up:

[makman94]

@Makman: I would not be that optimistic.

In 2008, I followed the development of OLC environment. OLC spent months to fine-adjust the light intensities of his environment in order to have realistic enemy sensor behaviour at daylight and at night (surface attacks possible). The light intensities are the heart of his work.

If you now adjust these light intensities to match your requirements for crew sensors, the enemy sensor adjustment could get worse.

I fear it won't be possible to adjust the env color / intensity to have both: well-adjusted enemy AND crew sensors at daylight and at night.

But hopefully I'm wrong. Good luck !

i think(not sure) i understand what you mean here H.Sie ,
you are talking for realistic enemy sensors behaviour ,right ? if yes then this is not problem becuase the light factor for AI seem to work ok .... i mean that i also had established the enemies visuals detect ranges with no problem at my visual sensors mod.
if i got you right you are 'worring' that if we 'fix' the own crew visuals (with light-colors adjustments at env) then this will effect(-mess) the enemies visuals also. well ,this is nothing to worry about becuase with the working light factor for AI (at sim.cfg) we could remake them more blind or more 'good' looking during night if we wish.
why i say ...''could'' ?
becuase all these(adjustments at ight-colors of environment) has no meaning after my last tests . my last tests shows that even the MINIMUM adjustments at sunlightColor and ambientlightcolor (..1-1-1 to both) are giving back totally random detect ranges .
some results with the 1-1-1 settings are :
1. 4400
2. 3000
3. 10500
4. 6800
5. 1400
6. NOT spoted
7. 4800
8. 4900
9. 7200
10. 3100
11. 12400
12. 3500

so i think that i will give up with the 'idea' that solution is at adjusting sunlightColor and ambientlightcolor values .
my thoughts so far is that the whole 'random' system is exactly where the game is suffering . this 'randomness' has no logical meaning at all ! (above pack of results ...min=not spoted and max=12400m).

so yes H.Sie a tool that totally eliminate this randomness will become very handy to 'understand' what is going on with the tweaks at sunlightColor and ambientlightcolor values , at sensors.cfg and at sensors.dat and we will be able to see if they have , indeed, any effect (and how much) in game.




I can´t agree with you here Mak. I never saw any game with night so dark that you can´t see anything. I want realism, but I also want some fun, some playability. Deep dark nights is out if my interest because this is at first a game and I want to play it. As we know the broken sh3´s visual sensor at night give you so much irrealistic detections, this just need a fix, not need to be a very realistic one. You also know that with a reasonable ( just this) dark nights in sh3 you will not be able to see ships so far and i guees that this is enough for our intentions. It´s then just need to adjust what you can see with the new sensors (hardfix) detections night distance and we will have a really new game behaviour at night!

My vote, my ask, continues to be to a hard fix on player crew night visual sensor.
I´m ready to help h.sie in any test.:yep:

I don´t have NYGM installed on my system to make the tests that you asked me. But if it works, it will work at the stock game too. I will have a look and let you know my results:up:

you don't understand me Rubini ! i don't try to convince anyone that dark envs are the best ! everybody have his own tastes and that is absolutely fine with me . i will create my env as i like it and you can have yours as you like it .
what i (tried) told you is that if you go for a non dark env then the ships will be vissible so your crew will see them ! i don't understand what you are running after : ships to be vissible but your crew not spotting them ? if you don't want ships to be visible you have to darken your env,more dark env,,shorter spoting distances.....i can't think any other way.

Well, yes and no. Yes it is true that sailing on a dark night you might not see the bow of your own ship, but the reason is that you see it pitched against dead black water. However, if you watch an object that is taller than you and is against the sky, that is a different thing and the ambience light might at least show you its silhouette -even if only by contrast.

I can't explain that, I have experienced it when sailing at night but it is difficult to describe. Simply consider two things of huge influence:

1) The ambient light level in the air

2) What you pitch the object against, i.e. the background.

The effect is quite weird because from a high merchant's bridge you would actually be able to spot an uboat at some distance because it is silhouetted against the sky, but as soon as it comes close, you are higher than him and will see it against the black water -where you don't stand a chance of spotting it even if very close!

I guess this is impossible to translate into the game :damn:

yes Alberto , i understand what you mean and MAYBE is not impossible !
have a look at this reflex map (just a very fast made one to understand the idea):
http://img69.imageshack.us/img69/5742/example1g.png

as ship is 'getting' into the black(not necesseraly 100% black) area and if we assume that the ship will be darked enough (to 'match' this black area) then will be very hard noticable by player . fog adjustments on far look sea maybe also help to do the 'trick'. maybe is...doable !
of course , players must 'forget' the free cameras...etc

@Makman: I have a working hack that completely removes the randomness from visual detection. That means: As soon as the detection probability variable exceeds a certain, user-defineable threshold value, the ship is detected by the crew. This allows very detailed and easy analysis of the environment parameters influence on detection probability.

But it will take some time until completion......

that GREAT H.Sie !! :rock:
completely removes the randomness ???.....just FANTASTIC !!!!
take your time mate,when you get it ready....immediatelly send it over !!

[h.sie]

@makman: I'll give you the fix as soon as it is done, maybe 1-7 days.

The randomization works as follows (with some simplifications to make my description easier):

On a regulary basis, let's say every second, the detection probability p for a (currently undetected) object (in sensor range) is calcutated, based on the distance and environment parameters. Lets assume, it's dark and the distance is 15km and thus we get something like p = 0.000005.

Now, every second, a random number r between 0.0 and 1.0 is created. If r is smaller than p = 0.000005, then the ship is detected (and p is automatically set to a very high value, because detection probability for an already detected object is very high, of course).

According to the randomness, the moment when r < p occurs (detection), can happen at a distance of 15km, but it can also happen at 3km. But it is very unlikely at 15km and becomes more likely, the smaller the distance and the higher p is.

I agree with you that the influence of the random numbers on detection is unrealistically strong. I would expect a smaller distribution of detection ranges than the game gives us.

I offer to work on an hardcode fix that does the following:

1) reduce influence of randomness on detection range

2) make crew visual sensors (question: also periscopes?) more blind at night

[makman94]

@makman: I'll give you the fix as soon as it is done, maybe 1-7 days.

The randomization works as follows (with some simplifications to make my description easier):

On a regulary basis, let's say every second, the detection probability p for a (currently undetected) object (in sensor range) is calcutated, based on the distance and environment parameters. Lets assume, it's dark and the distance is 15km and thus we get something like p = 0.000005.

Now, every second, a random number r between 0.0 and 1.0 is created. If r is smaller than p = 0.000005, then the ship is detected (and p is automatically set to a very high value, because detection probability for an already detected object is very high, of course).

According to the randomness, the moment when r < p occurs (detection), can happen at a distance of 15km, but it can also happen at 3km. But it is very unlikely at 15km and becomes more likely, the smaller the distance is.

I agree with you that the influence of the random numbers on detection is unrealistically strong. I would expect a smaller distribution of detection ranges than the game simulates.

I offer to work on an hardcode fix that does the following:

1) reduce influence of randomness on detection

2) make crew visual sensors (also periscops?) more blind at night

just make something 'clear' for me H.Sie,
is the tool we are talking about(for the tests) TOTALLY ELIMINATE the propability ?
if not....can you make one that TOTALLY eliminate the propability ? this is the best (outopic) for checking adjusting values . we need a tool that our crew will spot ALWAYS at SAME distance the target if we change nothing at parameters.

[makman94]

....

2) make crew visual sensors (question: also periscopes?) more blind at night

i think that both must 'follow' the same formula for detection

ok some very detail should be that when sub is on surface and scope is extended should give at scope more 'vissibility' than crew but on the other hand when sub is submerged with scope extended then this should give to scope less 'vissibility' than crew . thats why i believe that a good copromise should be to 'follow' the same formula
[max zoom at scope (x6) is close to bino's historic zoom (x7,1) so i am 'dealing' crew and scope as having the same zoom power]

[reaper7]

@makman: I'll give you the fix as soon as it is done, maybe 1-7 days.

The randomization works as follows (with some simplifications to make my description easier):

On a regulary basis, let's say every second, the detection probability p for a (currently undetected) object (in sensor range) is calcutated, based on the distance and environment parameters. Lets assume, it's dark and the distance is 15km and thus we get something like p = 0.000005.

Now, every second, a random number r between 0.0 and 1.0 is created. If r is smaller than p = 0.000005, then the ship is detected (and p is automatically set to a very high value, because detection probability for an already detected object is very high, of course).

According to the randomness, the moment when r < p occurs (detection), can happen at a distance of 15km, but it can also happen at 3km. But it is very unlikely at 15km and becomes more likely, the smaller the distance and the higher p is.

I agree with you that the influence of the random numbers on detection is unrealistically strong. I would expect a smaller distribution of detection ranges than the game gives us.

I offer to work on an hardcode fix that does the following:

1) reduce influence of randomness on detection range

2) make crew visual sensors (question: also periscopes?) more blind at night

Well worked out h.sie, that explains the changes in memory variable I was seeing. :up:

just make something 'clear' for me H.Sie,
is the tool we are talking about(for the tests) TOTALLY ELIMINATE the propability ?
if not....can you make one that TOTALLY eliminate the propability ? this is the best (outopic) for checking adjusting values . we need a tool that our crew will spot ALWAYS at SAME distance the target if we change nothing at parameters.

I think what H.sie is suggesting would be better than totally eliminating randomness, to reduce it to very small amount. (currently to large a random variance)

So during a dark night your crew in stock (Made up figures) could detect a contact anywhere between 1000M and 5000M.
With a reduced randomness that could be changed from 1000M to 1500M.
Whereas if eliminated altogether they would always detect at 1000M.

That small random figure would make for more realistic human observation and not be to robotic in nature.

[makman94]

....
That small random figure would make for more realistic human observation and not be to robotic in nature.

i am talking for the tool that we will use at developing the mod John !
of course the randomness will be getted back AFTER the completion of mod !
i agree with you that we need some little randomness for realistic purposes BUT we don't need it for testing purposes.

[reaper7]

i am talking for the tool that we will use at developing the mod John !
of course the randomness will be getted back AFTER the completion of mod !
i agree with you that we need some little randomness for realistic purposes BUT we don't need it for testing purposes.

:up: Got ya, yes for a test tool it should be set for 0 to help with the environmental setup.

@h.sie In your testing have you seen a way to set the Initial detection range or can you set a certain range to yield a very high probability factor.
Eg to set anything from 1000M to 0M to very high and any thing from 1001M up to low probability.
In order to get past the stock detection range.

[h.sie]

@makman:

- yes, totally elimination of randomness for testing purposes).
- and reduction of randomness for final mod.

@reaper:

- Currently I can only use the detection probability p as a trigger for detection. Say, if p > 0.01, a ship is detectd. This always happens at the same distance, when I eliminate randomness.

[makman94]

@makman: yes, totally emimination of randomness (for testing purposes).

...PERFECT !!! :rock:
whenever you are ready !! :yeah:

[Rubini]

Bump!

Any news at night visual sensors issue hard fix? :06:
I will reinstall my tools and modded Sh3 on my new PC this weekend (after some months away from sh3) and this is the most important issue that is not yet fixed, IMHO.
I will have some free time and will be happy to test/help on this fix.:up:

Salute mates!

[h.sie]

Makman and me are working in the background. :)

I wrote a hardcode fix that makes detection probability visible as a value for makman, and I also totally removed randomness from detection probability, so that the influence of environmental parameters on detection probability can now be analysed much easier. Results are now 100% reproduceable, that means, an enemy ship will now be detected at exactly the same range if one does several tests with the same mission. Saves a lot of time, since no more statistic experiments necessary.

There was also a weird effect on detection probability - caused by the direction the crew looks. The devs maybe wanted to model the influence of the sunlight (one cannot see well when looking into the sun) but this effect also is present in full strength, if no sun is visible, and even at dark night. This effect I also (temporarily) disabled for better analysis of the other environmental parameters.

Makman is now doing some analysis with the fix. I think he'll contact you.

[Rubini]

Makman and me are working in the background. :)

I wrote a hardcode fix that makes detection probability visible as a value for makman, and I also totally removed randomness from detection probability, so that the influence of environmental parameters on detection probability can now be analysed much easier. Results are now 100% reproduceable, that means, an enemy ship will now be detected at exactly the same range if one does several tests with the same mission. Saves a lot of time, since no more statistic experiments necessary.

There was also a weird effect on detection probability - caused by the direction the crew looks. The devs maybe wanted to model the influence of the sunlight (one cannot see well when looking into the sun) but this effect also is present in full strength, if no sun is visible, and even at dark night. This effect I also (temporarily) disabled for better analysis of the other environmental parameters.

Makman is now doing some analysis with the fix. I think he'll contact you.

Very good news h.sie!
I will wait manos' contact while I install all my old sh3 stuff.:up:

[makman94]

attention...attention ! (...like the announcements from the loudspeakers :DL)

when i started tweaking the visual sensors long time ago i couldn't even imagine the huge mess that existed IN them !
when i opened this thread i wasn't sure if something good could ever come out...
anyway, i am here now guys ...just to tell that the community is about to get in 'meet' soon with the most important and needed (IMO) mod ever made for sh3.
i have never seen a more 'well made' mod than this one....and the task ,be sure, wasn't easy at all !

it took more than 7 years to see it happening but
it is not only the vampire effect that is totally beaten (....yea nights will be nights at last in sh3) but much MUCH more than this that you will soon see.

there are some things (mostly adjustments) left to be taken care but i am more than sure that all will be overtaken !

thanks to H.Sie and Rubini , we have almost managed to 'win' 100% the challenge !
without doupt ...that was one of my best 'moding days' with you two guys (the other are with my team mates at u-boot-hahd project)
thank you guys !

[Dani]

This are great news!

Will this mod be so universal so can use it over any env. mod ?

[reaper7]

YES!!!!!!!!!!!!! Great excitement among the underwater predators (Not just us U-boats Kaleuns)

http://s3-ak.buzzfed.com/static/imagebuzz/web02/2009/7/6/17/excited-crocodile-32715-1246917566-3.jpg

Well done on this monumental fix - The three of you have just solved one of SH3's greatest bugs that has plagued its use during the darker hours of the campaign. :yeah:

[ETsd4]

(....yea nights will be nights at last in sh3) but much MUCH more than this that you will soon see.


Hard to believe that we get finally realistc lights at night.

True night ... with no moon and sky is cover by clouds =>
http://1.bp.blogspot.com/_74xsaE5pCdo/Rtgb9buxcOI/AAAAAAAAA8k/yUlB_Sl30ZA/s400/0700830%2B002.jpg%20

Picture-comment: "The anchor light was all that was visible last night on this 26' Chris Craft, on a tow from Blakley Island to Anacortes"

Yacht has a distance of 50-100(?!) m.

[makman94]

This are great news!

Will this mod be so universal so can use it over any env. mod ?

yes !

Hard to believe that we get finally realistc lights at night.

True night ... with no moon and sky is cover by clouds =>
http://1.bp.blogspot.com/_74xsaE5pCdo/Rtgb9buxcOI/AAAAAAAAA8k/yUlB_Sl30ZA/s400/0700830%2B002.jpg%20

Picture-comment: "The anchor light was all that was visible last night on this 26' Chris Craft, on a tow from Blakley Island to Anacortes"

Yacht has a distance of 50-100(?!) m.

i am 'hardcore' user like you and probably at my own private environment will create 'hardcore' dark nights.
but point here when we say ''night will be a night '' in a video game means that the visual distances will be reduced .with this mod we can reduce now as much we like the visual distances and yes ....even to a point like your pic is showing .
till today ,we were able to create so dark enviros like your pic but the problem was that sensors wasn't properly fuctional.
the goal of this mod is exactly this ....properly fuctional visuals !
so ,if you are willing to create so dark nights...this mod will make your sensors working great even to these 'extreme' nights.
but don't forget that it is also a game....and everybody would like to see something during night (even if this is not so realistic)

[makman94]

YES!!!!!!!!!!!!! Great excitement among the underwater predators (Not just us U-boats Kaleuns)

http://s3-ak.buzzfed.com/static/imagebuzz/web02/2009/7/6/17/excited-crocodile-32715-1246917566-3.jpg

Well done on this monumental fix - The three of you have just solved one of SH3's greatest bugs that has plagued its use during the darker hours of the campaign. :yeah:

lately i see the u-boot-hahd team has 'gone' to....zoo ! :D

yea...its a great - evolutionary fix !
this guy H.sie ....is a magician !

[h.sie]

I would call it 'nice' instead of evolutionary.

[reaper7]

Yes 'nice' in a evolutionary sort of way :03:

[CaliEs]

nights will be nights at last in sh3)

New moon
http://img.xrmb2.net/images/422564.png