[TEC] GWX SH4TerrainEX Information!

[astvitaliy1982]

The problem has been fixed) These are different pixels in neighboring squares.
I figured out why they were there.
Let's say we are building a new lake on a piece of land that consists of three horizontal squares 1,2,3.

It is in this sequence that they should be inserted into the game. If you put them 1, 3 and then 2, then squares 1 and 3
copy into their data a section of square 2, which at that moment is still land. And because of this appears
this error.


In my case, I put 1 and 3 squares because 2 was not ready yet. Now it's fixed)

A classic mistake with a classic solution... I'm going to hang myself...)))

[propbeanie]

Originally Posted by Jeff-Groves

look at his undersea.dat.
rocks are above sea floor level in that!

I don't just make this crap up you know.

If you are referring to my comment on the screen grab, I was referring to the phenomenon where if the camera is below the floor, but looking across a "valley" at another stretch of sea floor, it can look like that. This is not the best screen grab for illustration, since I do not have a deep enough valley close enough to be fully visible, but you can somewhat see the sea floor a bit in the distance



That was grabbed while beneath the sea floor terrain line, of course. Moving up in "elevation" just a pinch, and it looks like



Too much murkiness in the PH harbor area...

Originally Posted by astvitaliy1982

The problem has been fixed) These are different pixels in neighboring squares.
I figured out why they were there.
Let's say we are building a new lake on a piece of land that consists of three horizontal squares 1,2,3.

It is in this sequence that they should be inserted into the game. If you put them 1, 3 and then 2, then squares 1 and 3
copy into their data a section of square 2, which at that moment is still land. And because of this appears
this error.


In my case, I put 1 and 3 squares because 2 was not ready yet. Now it's fixed)

A classic mistake with a classic solution... I'm going to hang myself...)))

I do not understand where the problem comes in there with that work sequence astvitaliy1982, unless you are re-assembling the BFD/BFI yourself. If putting ZHF files and folders in the Terrain / Data folder, the game should re-assemble things properly, and only run into that issue if you edit within the 6-pixel border areas of adjacent squares, and don't match the edits in the neighboring square. ??

[Jeff-Groves]

I get what was done.
All 3 sectors were not adjusted and tested properly.

Now I'm working on a way to have 010 check the 6 pixel boarder areas around any given RAW file/files.

So the script would read the 1st 6 lines of 601 bytes each.
Then read the next 6 bytes then skip to the last 6 bytes of the lines until we reach the last 6 lines which would read them start to end.
That would give us the border information for a RAW.

Run it on all sectors touching? You'd have a table that would not need slight color guessing.

I did check sectors in the area in question but I looked at the upper and lower sectors!
Not the left or right sectors.
Doh!


Another thing I'm working on is to change the UI of the program to allow a bigger image when using it.
Also trying to change it so that damned header information is removed when exporting from the ZHF files.

[astvitaliy1982]

If I understand the situation correctly, then the error "with a pixel" occurs when I start the game with ready-made squares
ZHF 1 and 3 (figuratively speaking). When the game has already loaded them onto the map. I think if I didn't load them into the game
if I had finished square 2, and then loaded three finished squares into the game at once, this error would not have occurred ...

[Jeff-Groves]

Correct.

[propbeanie]

Originally Posted by Jeff-Groves

I get what was done.
All 3 sectors were not adjusted and tested properly.

Now I'm working on a way to have 010 check the 6 pixel boarder areas around any given RAW file/files.

So the script would read the 1st 6 lines of 601 bytes each.
Then read the next 6 bytes then skip to the last 6 bytes of the lines until we reach the last 6 lines which would read them start to end.
That would give us the border information for a RAW.

Run it on all sectors touching? You'd have a table that would not need slight color guessing.

I did check sectors in the area in question but I looked at the upper and lower sectors!
Not the left or right sectors.
Doh!


Another thing I'm working on is to change the UI of the program to allow a bigger image when using it.
Also trying to change it so that damned header information is removed when exporting from the ZHF files.

I like the idea of "a table that would not need ... guessing"!!! The header info change would be a bonus! My 010 Editor stands at the ready. I am sure it would appreciate a competently written script, unlike the krapp someone I know all-too-well currently tries to feed it...

[astvitaliy1982]

Average depth indicators in the game:



This is how the depths look in Photoshop:



Dogger Bank in SH3



Dogger Bankr in SH4



Dogger Bank in SH4 game:





-------------------------------------------------- --------------------------------------

English Channel in SH3:



English Channel in SH4:




The English Channel in SH4:



-------------------------------------------------- ------------------------------------

North Sea in its upper part:

In SH3:



In SH4:



-------------------------------------------------- ----------------------------------------

Wilhelmshaffen in SH3:



Wilhelmshaffen in SH4:



Wilhelmshaffen in SH4:



-------------------------------------------------- -----------------------------------------



Unfortunately, the filter in the Navigation map of the game does not show us much. Still, I impose
on the map texture in Photoshop, "Median" filter. I lose a bit of depth detail,
but this is a necessary measure to ensure that the isolines of the depths on the game map look smooth. If a not to do this, the result is a map in which there are many square depressions and pits one pixel in size.

[astvitaliy1982]

P. S. I will not replace the fjords of Norway. I'll leave what was.

[Jeff-Groves]

Originally Posted by propbeanie

I like the idea of "a table that would not need ... guessing"!!! The header info change would be a bonus! My 010 Editor stands at the ready. I am sure it would appreciate a competently written script, unlike the krapp someone I know all-too-well currently tries to feed it...

Writing the Script to check RAW files now (in my head at the moment).
1. It will ask for 2 RAW files to compare.
2. It will ask the direction of 1st RAW file to check. N, S, E, or W.
3. It will then compare the border areas of both files.
If N is selected for RAW 1, The Southern border of RAW 2 will be scanned.
And so on for given directions.

[propbeanie]

That sounds very sensible! Paint me in as a guinea pig!

[Jeff-Groves]

I'll probably allow you to do an auto 'fix' if pixels don't match.