Sensors

[makman94]

Originally Posted by reaper7

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

As per my post here in stieblers thread:


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

Originally Posted by 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. --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 ?

Originally Posted by Rubini

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'

Originally Posted by 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.

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

Originally Posted by 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.--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 !

Originally Posted by MCHALO12

....

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)

Originally Posted by 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.

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]

Originally Posted by makman94

....
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!
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?
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]

Originally Posted by Rubini

Crossing fingers...but can I bet 2 beers that it will not solve the problem?
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 !) . maybe there is this value...(not very optimistic though...)

[Rubini]

OK, 3 beers! 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!

[reaper7]

Originally Posted by makman94

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
Posted this info in other thread where it may be used

Hope you have success with the ambientlightcolor

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

Originally Posted by reaper7

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

Hope you have success with the ambientlightcolor

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

Originally Posted by 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'.

good morning H.Sie,

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

[Sailor Steve]

Originally Posted by makman94

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]

Originally Posted by Stiebler

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.

Thank you Stiebler, another great fix. Just keeps getting better and better

[Fish In The Water]

Originally Posted by reaper7

Thank you Stiebler, another great fix. Just keeps getting better and better

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

[makman94]

Originally Posted by Stiebler

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

Originally Posted by Sailor Steve

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 ,

....BUT....for the second one......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 (Leonardo da Vinci was the one that never ...finished anything of his brilliant ideas ? am i right ?)

[Rubini]

Originally Posted by makman94

thats very nice new Stiebler
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.