0.6.1

[kubilus1]

This version will attempt to restore a placeholder set of dirs for each scenery installed when the program is shutdown. This should help keep the order of scenery_pack.ini intact when users run X-Plane without AO running.

What's Changed

• Try to include pytest by @kubilus1 in Try to include pytest #344
• Only on release by @kubilus1 in Only on release #348
• Restore a placeholder dir for each scenery when unmounting. by @kubilus1 in Restore a placeholder dir for each scenery when unmounting. #359
• One unstable package by @kubilus1 in One unstable package #350

Full Changelog: 0.6.0...0.6.1

---

This discussion was created from the release 0.6.1.

[Jeff2122]

Some feedback: I downloaded v0.6.0-1 and it worked great as an upgrade to v0.5.1-3 with no problems at all, using same scenery folder and cache of course. I then played with 0.6.1 pre-release and found it to be fine as well. I will go forward with 0.6.1 for now.

I see 0.6.1 is working toward fixing the dreaded "ortho at the top" issue. I see it changing the folders z_ao_x folders from junctions to folders and back to junctions when you close AO gracefully with CTRL+C then reopen it. This is magic that I didn't know was possible - converting a junction to a folder and back again. Windows is playing along just fine. Anyway, XP12 likes this and does not mess with the scenery_packs.ini file. Of course, it loads the flight without ortho as expected. No CTD either.
But, if you close the server with the red X in the corner like I am used to doing to shut it down, it does not get to the file deposit code and the folders remain broken junctions, which of course XP12 kicks out of the ini file only to be put at the top again next time the programs are started properly in order.
So a new instruction to only close the server via CTRL+C would help the situation, but won't cure it.
Keep it coming @kubilus1, you are doing an excellent job and we appreciate you greatly!

[Jeff2122]

Alright. It started working consistently whether I press the red x or the CTRL+C. I am reaching for conclusions I think. It could depend on how busy Windows is at the instant you click the red X - I tried opening my usual background apps and it didn't make a difference. Will get back if I have something concrete.

[kubilus1]

Not only does closing a command window not send signals, it actually used to send SIGBREAK (or their twist on SIGBREAK) but at somepoint Microsoft changed that behavior. It's just, silly.

0.6.1 will probably stay as 'pre-release' for this reason. The workaround is to not have the cmd prompt window at all, but that will mean rework.

The whole creating a placeholder dir is also really just to help the Windows users, since also that is not an issue outside of Windows.

[Jeff2122]

Yeah I know. You are busting your butt to help us Windows people. I think I'll start working toward a new big NVME drive so I can dual boot Ubuntu.

[Jeff2122]

I don't have the tools to see but I am postitive that Windows is not helping out here. I am seeing different results today. The one that might be some hint is that with CTRL+C exit even that gets interrupted by Windows. In the snap below, the flight tracker remained running after the scenery folder junctions were converted. I will stop playing, I am going to use it for now.

[Jeff2122]

I have had lots of time to play with AO, enough to say that something is wrong with v0.6.x. This version misplaces tiles and what I've been callling the "plaid" tile effect when zooming in and out. Zooming being when you use the period and comma keys, not necessarily mouse zoom.
I never even noticed the problem until someone pointed it out here and on the forum. Not very observant in my old age I guess. Anyhoo, I was happily rolling along with v0.6.1 and handing out advice left and right, until I saw this tile issue. Now I can't unsee it.
A quick synopsis of my testing - My XP12_main and XP12_copy were both originally set up to use v0.5.1-3 and v0.6.x. I then installed v0.4.4 and converted XP12_copy to use that data. Tests were loading random airports in C172, in the US, Europe and Australia, go outside free cam and move in and out to observe the scenery shapeshift. I did not use the same airport twice.
I then swapped all the junctions, adjusted the scenery_packs.inis, and flushed the cache - XP12_main now uses v0.4.4 and XP12_copy uses v0.6.x data. Again random airports, randomly selected at random. At no point did I observe any random tiles or plaid except with versions v0.6.0 and v0.6.1.
So this wasn't exactly scientific but my observance is real, verified, and consistent. I like that there is help to keep the .ini organized in the newer release, but I can live without that to have nice AO scenery.

[Jeff2122]

I have tried seven ways from Sunday to break your code. If you have tests that need to be performed, feel free to call on me. I have lots of time and I enjoy the hobby. I tweak and play more than fly sometimes. You wouldn't be bothering me.

[md11jock]

scenery_packs.zip
I've noticed on version 6 that when I build a simlink to the scenery files for custom scenery files, an extra one is built with a "_bkp" added in the scenery.ini file. I know this usually denotes some kind of backup but windows says it can't find it. AO is running good but just curious where it might come from and if I can delete it in the scenery.ini file. I use Link Shell Extension program and the back up is not on.
SCENERY_PACK Custom Scenery/z_autoortho/
SCENERY_PACK Custom Scenery/z_ao_na/
SCENERY_PACK Custom Scenery/z_ao_na_bkp/
SCENERY_PACK Custom Scenery/z_ao_sa/
SCENERY_PACK Custom Scenery/z_ao_sa_bkp/
Thanks.

[kubilus1]

Why would you build a symlink to 'custom scenery' when 0.6.x mounts directly to custom scenery?

As for the backup folder, system detected an existing folder and I'm uncomfortable having this auto delete stuff since there is no way of know what/why that is for.

[md11jock]

Thanks for responding. I've used Simlinks to keep the main Custom Scenery Folder as pristine as possible. Makes things easier to change.
I must be missing something here as the behavior is different as in the past.
I will endeavor to understand if I need to rethink this.
Trying to understand if I can use Simlinks at all in this version and if so, which files to link. Thanks again !

[md11jock]

I figured out the error of my ways. Since the files are mounted when AotoOrtho starts, the separate simlinks were causing the duplicates.
Thanks again. Loving this amazing piece of work !!!

[kubilus1]

Oh sure, yeah that makes sense. The symlinks are showing up as some kind of pre-existing directory. Yeah version 0.6.x should make this not as necessary since you can now in a built in way store your scenery wherever (including on NAS!) and AutoOrtho will mount in Custom Scenery appropriately. I can't really think of any reason to use shortcuts or symlinks going forward.

[md11jock]

It's working well now. Thanks again.

[Ertzwert]

I can get it working
tried 05 .. had to go back to 04
try 06 but hangs on
INFO:aostats:STATS: ID: {'cur_mem_mb': 30, 'chunk_miss': 6, 'req_ok': 6, 'bytes_dl': 98930}
pls advice thank you
autoortho.txt

[SimOld73]

0.6.1 has resolved the issue where the ortho scenery was deleted from the scener_packs when XP was run by itself but the problem addressed in #368 still exists. The same as with the previous version I can get autoortho to run by changing the debug mode to True. Attached are two log files with identical flights, one with debug mode False the other with Debug mode True. Hope these help you in finding the problem with the error loading the scenery package.
autoortho_False.log
autoortho_True.log

[Ertzwert]

Thank you for your reply
I did DEBUG=TRUE in the autoortho "config"

Thankx for advice

[TinkerNZ]

Hi [kubilus1], Thanks for the continued updates and changes to improve things for the Windows users.
As feedback, v0.6.1 pre-release works very well with the use of the 'placeholders' and in my case (when previously v5.1 gave me serious grief) this pre-release is very successful. Suggestion is to run it via a shortcut with Admin (elevated) rights and use WinFsp.
I am currently testing a new version of xOrganizer which will accommodate the placeholder/mount point variances without throwing up an error. So I suggest updating v0.6.1 for general release might be a good idea and steer Windows users away from v0.5.1 altogether.
Cheers, TinkerNZ

[Ertzwert]

0601 is not working for me
050 was not working either
going back to 044
autoortho (2).txt

[SimOld73]

The debug mode is in the .autoortho file. C:\users\xxxx\.autoartho where xxxx is your computers name.Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: Ertzwert ***@***.***> Date: 9/8/23 1:37 AM (GMT-07:00) To: kubilus1/autoortho ***@***.***> Cc: SimOld73 ***@***.***>, Comment ***@***.***> Subject: Re: [kubilus1/autoortho] 0.6.1 (Discussion #366) Thank you for your reply where to activate the debug mode ? in the autoortho config ? Thankx for advice —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[crisk73]

[Win] For me the only way to get 0.6.1 working in leaving the placeholder is to run AO as Admin. But this leads to XP often not being able to find the z_ao_xxx mount so it closes. The same happens even if XP is run as Admin.

[Ertzwert]

my solution for that problem was just to go back to 0.4.4
no problems with that version
The only thing is that all the z_ao_xx had to be downloaded again
It would be easy if in the autoortho config the possibility exist to point to the previous downloaded files

[TinkerNZ]

With v0.4.4 there already is the option in the config file to set the 'NoClean = true' which stops AO from deleting the downloaded scenery pac install files.
And this worked fine for me with v0.4.4 , however since v0.6.0 onwards this settings appears to be ignored by AO and it deletes the file regardless. I have already reported/commented on this, but so far no fix.
The last downloaded scenery files with v0.4.4 appear fully compliant with the v0.5.# and v0.6.# versions. As opposed to the v0.4.3 and earlier ones which are not usable (in case you saved them, but not usable anymore)

[SimOld73]

0.6.1 to get passed the error loading scenery I have changed the .autoortho file debug mode from Fasle to True I had previously attached the autoortho log files using the Debug mode False and True. I am attaching them again along with the XP log files hoping this will help you find the problem.

autoortho_False.log
autoortho_True.log
Log_XP_AO_Debug_False.txt
XPLog_AO_Debug_True.txt

[rayw45]

Yes I am getting the same results with either Dokan or WinFSP. I have to make debug = True else I get the unable to run file usual error when my selected flight gets to the Reading New Scenery stage. SO cannot use AO unless debug = True is set, but this surely will cause some slowing down to the smooth ruining of XP12 with AO. I clearly would like to switch this debug off and still be able to use AO 6.1 so is there any fix for this in the pipeline yet ??

I run XP12 in Windows 10 with my PC spec i5 10400F, 32GB DDR4 RAM, GTX 1080Ti 11GB graphics card carefully overclocked and stable.

BTW many thanks SimOld73 for that workaround as at least I can now fly XP12 with AO 6.1 and indeed still using my huge AO cache folder originally created with AO 4.4. So that saves seeing all those millions of cached tiles having to redownload mid flight again with the resultant in flight pauses.

[md11jock]

Greetings all,
I've been running 6.1 with no issues in the continental US. Yesterday as I entered the southern area of Alaska, I started getting alot of the following entries in the Command window:
"INFO:getortho:Loading file Chunk(8066,19392,BI,16,12) not a JPEG! b'' path: M:/AuAo/.autoortho-data\8066_19392_16_BI.jpg"
There basically wasn't any scenery except out of focus terrain until I got to Juneau..
The program kept running.
I'm curious as to what this may be as I fly in Alaska and Western Canada a lot. I'm using the default map source. Do I need to re install the scenery with a different one? Thanks.

[TinkerNZ]

Hi, interesting you experienced this just as I also (running v0.6.1) have noticed severe terrain issues at various Alaska locations and I did wonder if this was due to limited quality of the 'na' scenery base pac further North. How ever my last flight was over Sproat Lake on Vancouver Island and there I had serious terrain errors (visually) with what looked like underlying mesh being incorrectly placed below other terrain. The result was that shorelines where water had land outlines clearly visible below the water resulting in some really weird visuals. Never seen anything like that before.
When I switch back to AO v0.4.4 the issue completely disappeared. Unsure where to start looking for the breakdown which causes this. Is it the overlays? Or is it the base pac?
For now I'm back with v0.4.4 as v0.6.1 output is not really useable. ( although v0.6.1 runs OK or so it seems)

[md11jock]

Thanks for the reply. Much appreciated!

[Jeff2122]

I'm on 0.6.1 and having good luck. Need to check Alaska but Canada seems OK.
Before you go too far, can you try switching from Dokan to WinFSP (or vice versa as the case may be) and reload? I had been using Dokan for 3 days with no problems, but loaded EGPB and saw the mixed up tiles. Switched to WinFSP and problem was gone on reload.
The other variable is your data source. You might also try another data source next. I use either BI or Firefly. YMMV.

[md11jock]

Do you have to uninstall WinFSP to use Dokan?

[Jeff2122]

No. If you download the .msi file for both, just install both. One or the other can be used, but both can live on the the system no problem.

[md11jock]

Thanks Jeff2122

[md11jock]

Just tried Dokan and there was no difference. Going to setup another XP copy running 4.4 as a backup in case I screw up my main sim.
Thanks again all.

[Jeff2122]

I'm finding the same thing: Dokan vs WinFSP doesn't seem to matter. Still futzing around. I see the error "Cant use scenery at" and crash, I have just restarted AO and XP in order and it loads sometimes. I don't have enough experience to pinpoint anything but I suspect the data source server did not deliver the needed data in time and XP pooped out. The next time I hit it right and it loaded. I am guessing 100% here so let's keep observing and reporting. It's all we can do.

[Jeff2122]

Yeah man, when you get around to it of course. I am sad that so many ppl have problems with 0.6x. It has worked since day one for me. Went back to 0.5.1 for a short time to demonstrate they were interchangeable, but 0.4.4 is long gone for me.

[Jeff2122]

I can't find a provider that has scenery for Unalakleet (PAUN). That is one of my go to areas so I guess AK flying with AO is out for now. Firefly is the only provider that loaded, and the scenery earned a grade of D. All others rated F-.

[md11jock]

I updated my win 10 64 bit pro to KB5030211 and KB5030180 this morning and now neither my 4.4 or 6.1 will even start. The command window briefly opens and then closes. XP12 starts fine.
Tried to download new and kept getting virus warnings on 4.4 although the defender scans were fine. I'm sure this is a windows issue but haven't seen this since this sort of thing since Win 7. Going to check the windows logs but wanted to mention it in case it crops up for others. Thanks

This may be the error:
The application-specific permission settings do not grant Local Launch permission for the COM Server application with CLSID
Windows.SecurityCenter.SecurityAppBroker
and APPID
Unavailable
to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

I don't know the meaning here so I'm trying to research it.

[md11jock]

I've been trying to chase this and it seems the error I quoted above isn't related. Actually, there are no events logged when I try and start the program. Still digging as I'm dead in the water right now.

[md11jock]

I finally got 4.4 running by going through the registry and deleting any AutoOrtho or AuAo 4.4 and 6.6 reference I could find. 4.4 is running and rebuilding the scenery files as we speak. Once I see if it actually works in the sim. I'll check 6.1.

[Jeff2122]

I am also running 0.4.4 and 0.5/0.6 on separate XP installs. I can now go back and forth with a little tweaking here and there to check and use any version. They are all acting similar so far, but 0.4.4 seems to get most of the data correct on the first try.
I am still in experiment mode so will report back anything interesting.
All of these problems reported here and other places are related to the data source quality and download speed, and some timing mixed in from Windows interrupting tasks, and a bunch of other shenanigans that we have yet to put our finger on. It is a fun hobby regardless.

[SimOld73]

For now I also went back to v0.4.4.  I use xOrganizer to keep the ini organized.  If I want to run XP 12 without running autoortho I disable the autoortho scenery in xOrganizer and re-enable then when I want to run autoortho.  The disable function is part of the scenery_packs file and if this was programmed into autoortho you would not need the junctions in 0.6.x. You could use the 0.4.4 scenery folders and enable them when you start autoortho and disable them when you stop autoortho. Then XP 12 would run with or without autoorthoSent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: Jeff2122 ***@***.***> Date: 9/17/23 11:04 AM (GMT-07:00) To: kubilus1/autoortho ***@***.***> Cc: SimOld73 ***@***.***>, Comment ***@***.***> Subject: Re: [kubilus1/autoortho] 0.6.1 (Discussion #366) I have had lots of time to play with AO, enough to say that something is wrong with v0.6.x. This version misplaces tiles and what I've been callling the "plaid" tile effect when zooming in and out. Zooming being when you use the period and comma keys, not necessarily mouse zoom. I never even noticed the problem until someone pointed it out here and on the forum. Not very observant in my old age I guess. Anyhoo, I was happily rolling along with v0.6.1 and handing out advice left and right, until I saw this tile issue. Now I can't unsee it. A quick synopsis of my testing - My XP12_main and XP12_copy were both originally set up to use v0.5.1-3 and v0.6.x. I then installed v0.4.4 and converted XP12_copy to use that data. Tests were loading random airports in C172, in the US, Europe and Australia, go outside free cam and move in and out to observe the scenery shapeshift. I did not use the same airport twice. I then swapped all the junctions, adjusted the scenery_packs.inis, and flushed the cache - XP12_main now uses v0.4.4 and XP12_copy uses v0.6.x data. Again random airports, randomly selected at random. At no point did I observe any random tiles or plaid except with versions v0.6.0 and v0.6.1. So this wasn't exactly scientific but my observance is real, verified, and consistent. I like that there is help to keep the .ini organized in the newer release, but I can live without that to have nice AO scenery. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[md11jock]

I have a very similar setup - using two installs of XP12 with 4.4 and 6.1on SSDs. Just have to change the scenery install directory before running.
I'm on Windows 10 Pro 64. I have never used X organizer but am very comfortable playing with the scenery.ini files.
Getting essentially the same behavior with the errors I posted above. Spoiled rotten on 4.4
Looking forward to the next release.

[crisk73]

At the moment versions 0.6.0-1 are givig me two main problems: 1) sometimes the z_ao_eur folder fails to mount with XP shutting down upon detecting the missing folder; 2) I'm having the pictures misplaced throughout the tile, but only upon the first loading of the area, as the subsequent loading is fine. Thanks

[Jeff2122]

I have reverted to using v0.5.1-3 which uses the same data arrangement as v0.6.x so no rebuild necessary. Try it, you'll like it.

[crisk73]

True, v0.5.1 works flawlessly. Thanks!