stacktom / ortho4xp_fsx_p3d Goto Github PK

Higher zoom levels create less files in the texture folder and therefore less mb. The only thing that increases with higher zoom levels is the amount of bgl files in the scenery folder. But those are just 2kb each. Here the number for +49-003 (Jersey):

BL14 689mb texture folder files 16.530 (which is way too much for a tiny island like Jersey)
BL15 371mb texture folder files 8.904 (which is still way too much for a tiny island like Jersey)
BL16 212mb texture folder files 5.100
BL17 126mb texture folder files 3.036

Only using very high zoom levels creates a reasonable memory. If I am going to do just teh South of England, it would be a huge amount of GB at a low zoom level of just 14.

When editing config menu and applying it to the cfg file, the newly generated cfg file is missing these lines:

#FSX_P3D_resample_loc=F:\ortho4xpvm\resample.exe
FS9_resample_loc=C:\ResampleFS9\resampleFS2004.exe
FS9_imagetool_loc=C:\ResampleFS9\imagetool.exe
#ESP_scenproc_loc=C:\Userddds\fery2\Desktop\scenproc_latest_development_release_x64\scenProc.exe
#ESP_scenproc_script=default.spc
max_resample_processes=8
create_ESP_night=True
create_ESP_summer=True
create_ESP_spring=False
create_ESP_fall=False
create_ESP_winter=False
create_ESP_hard_winter=False

After downloading the latest update, I get the following error after 256secs if the download times out.
Attempting to download OSM data from 32, -96.5 to 32.5, -96.0
OSM server MAP rejected our query, new tentative in 2 sec...
OSM server MAP rejected our query, new tentative in 4 sec...
OSM server MAP rejected our query, new tentative in 8 sec...
OSM server MAP rejected our query, new tentative in 16 sec...
OSM server MAP rejected our query, new tentative in 32 sec...
OSM server MAP rejected our query, new tentative in 64 sec...
OSM server MAP rejected our query, new tentative in 128 sec...
OSM server MAP rejected our query, new tentative in 256 sec...
Exception in thread Thread-4:
Traceback (most recent call last):
File "threading.py", line 916, in _bootstrap_inner
File "threading.py", line 864, in run
File "O4_Tile_Utils.py", line 163, in build_tile_list
File "O4_Vector_Map.py", line 44, in build_poly_file
File "O4_Vector_Map.py", line 154, in include_scenproc
TypeError: a bytes-like object is required, not 'int'

Not working it seems:

When Ortho4XP_v130.py is started, the following error appears:

Traceback (most recent call last):
File "***\Ortho4XP_FSX_P3D\Ortho4XP_v130.py", line 11, in
import O4_Imagery_Utils as IMG
File ".\src\O4_Imagery_Utils.py", line 34, in
import O4_ESP_Utils
File ".\src\O4_ESP_Utils.py", line 8, in
from fast_image_mask import *
ImportError: DLL load failed: The specified module was not found.

I have installed Phyton 3.7.9 and the libs include cp37 (successfully). The path specifications are correct. The paths in Ortho4XP.cfg have been adjusted. vs_BuildTools.exe version 2017 installed.

Maybe it is helpful to build a setup.exe file. Otherwise no one knows where and which dependencies are missing.

Jersey misalignment (ZL16)
N49* 12.51'
W2* 11.26'

Corsica misalignment (ZL15)
N42* 2.33'
E9* 24.40'

+51-002 at ZL 16, Bing

It's a common problem that airports are not correctly positioned in FS9 or FSX and therefore photoreal scenery and generic airport don't match. However, with Ortho4FS9 the issue is worse than with FSET. Here at EGVN:

FSET:

And here with Ortho (sorry not the same angle):

As you can see above the misalignment in the Ortho scenery is really bad and then we have a terrain mismatch on top of it cutting through the scenery (at the right).

Just flying for 10 minutes I get 3+ mismatches. ALL airports are very dislocated in the Ortho scenery. So, honestly, sorry to say that, it's no fun. I might do some testing more to see where Ortho4FS9 can be useful, but I can't picture this right now. It's just too bad for my taste.


Same here above: airport totally off and a whole line cutting through the scenery (at the right)

I stopped the testing after 10 minutes. So, I didn't fly the whole test area. I am not sure if you should release Ortho4FS9 as it is right now. I probably won't use it. Sorry, mate.

I keep getting this error. Never had that in the version for FSX. Sometimes it works, but most of the time it doesn't.

Recently I noticed that once I download a tile, a few images appear with white squares inside them because, as the log says, it wasn't possible to obtain part of the image. If I delete these images and start the download again, the script will download the missing images correcly. So I was wondering if it's possible to implement a feature that automatically checks wether or not the image contains the white square and if so, download the image again.

Although seasons are set to false in the cfg file, Ortho4FS9 creates bmp files for seasons.
5 seasons HW, W, S, F, Ss and Lm... dunno what that is. Is this the night texture?