Sensors

[Rubini]

Originally Posted by makman94

....

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.

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

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

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

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

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

[reaper7]

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

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]

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

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.