There is a timeout for how long the system waits for individual satellite images. You can adjust how long the system waits for high resolution images by adjusting the ‘max_wait’ setting (in seconds) in your configuration file. Lower resolution tiles are used when available as a fall back. The green tile is used as a last resort.
By making this too high you risk introducing lag, stuttering, and delays. However this may need to be increased for users that are far from source servers or have slow internet connections.
The log will log various things, typically info and warnings can be ignored unless other issues are seen.
Failed to find resource '../textures/22304_34976_BI16.dds', referenced from file 'Custom Scenery/z_eur_11/terrain/'.What’s happening is that X-Plane has found a terrain file, but is not finding a linked texture. This could be caused by a few issues:
First verify that AutoOrtho is running and there are no obvious errors shown in a log. If it is running then verify that all the directory links are correct, and consider simply cleaning up and reinstalling scenery from scratch, keeping a consistent ‘Custom Scenery’ directory configured.
If in doubt, re-install the scenery packs.
AutoOrtho checks for metadata for installed scenery packs in Custom Scenery/z_autoorth/**_info.json Where ‘**’ is a shortname for each scenery pack installed. You can delete the corresponding .json file, and re-run the configuration utility and should be able to reinstall the scenery pack
You have to start X-Plane separately from this tool. It’s also best to start X-Plane after starting autoortho so that all new files and directories are picked up.
You may need to specify the SSL_CERT_DIR your particular operating system uses. For example:
SSL_CERT_DIR=/etc/ssl/certs ./autoortho_lin.bin
Note - Possibly fixed in 1.1.0 and newer See Issue #11
Arch and some other systems keep FUSE2 and FUSE3 seperate when it comes to their userspace binaries (the part AutoOrtho calls to mount and map folders). Other systems like Debian based platforms (e.g. Linux Mint, Ubuntu, Etc) just use FUSE3 binaries/libraries for both FUSE2 and FUSE3 support risking breaking compatability for select usecases. Luckely AutoOrtho is not one of these, but this leaves Arch support broken for now. A solution has been identified in a python FUSE support project that expands support to FUSE3 nativly. Until resolved - a Debian based release might be your best bet. The Linux version of X-Plane 12 itself is developed on LTS releases of ubuntu, so that or their Linux Mint counterparts might be a safe starting point if you must have ortho under linux.
Make sure that your /etc/fuse.conf files is set to user_allow_other. You may need to uncomment a line.
You can clear mounts manually with the command sudo umount -f AutoOrtho.
You may need to run this for each remaining mount. The mount command will
list your current mount points.
This is likely due to having a very new version of Python and a package dependency that does not have a pre-built ‘wheel’ binary. Further in that error you will see a link to visual studio build tools that can be installed. You could also try downgrading your version of Python. For instance try uninstalling Python 3.11 and install Python 3.10.
This may be due to Windows Defender real time scanning be enabled. You can temporarily disable this, which should make a difference, but it will be re-enabled automatically.
You can exclude directories, such as `C:\Users.autoortho-data’ or wherever else you installed your download and cache directories.
That is a false positive. Unfortunately, Windows is very dev and opensource unfriendly. You can choose to ignore this false positive or not, it’s your computer. Alternatively, you can run this directly via source.
This is not supported. Use a local NTFS formatted drive.
Please check the issues page of the repository. Before submitting an issue please search for already existing issues for yopur problem, as it may be duplicated. If your issue has not been reported please open a new one and include as much information as possible, for example:
With more information the debugging process will be easier.
After the issue is opened I’ll gladly check it out as soon as my time allows. Keep in mind that this is a side project for me, so support might not be immediate.
Currently this fork still uses kubilus1 base mesh, as such support is not offered for it right now, this will change with the new custom mesh. For now refer to the issues page of the kubilus scenery to see if your issue has been reported and hopefully a community fix has been shared.
As the AutoOrtho Continued name suggests the main idea of this fork is to continue building upon kubilus1’s codebase and to add more features while keeping the program updated with latest technologies, and offer active support to issues that may arise.
This fork currently adds a revamped new UI, more autoortho options such as overriding max zoom, and quality of life features such as new imagery servers and download retries. For more detailed information of the changes of every release please refer to the releases page as detailed changelongs of every release are detailed there.
While the scope of this fork may change over time and soem features might never see the light of day the main things in development right now are:
Things in backlog that are planned be implemented later on (order does not matter):
There is no ETA. And there is also no guarantee of this changes being released at all. Keep in mind this is a side project that is mostly fueled by my free time, autism and hyperfixation. So development times are not guaranteed and are subject to change.
Sure! This is a community open-source project after all, and the more contributions the better. You can create your own fork and open a PR into this repo with code you would want implemented! I will review it and hopefully merge it to keep this project growing.
You can still contribute! Open a discussion with your feature suggestion and maybe someone or me will look at it and implement it if we find it useful or interesting!