Posts by nickhod

    2. running with masks off with a stitched image with a transparency. Unfortunately AeroScenery doesn't indicate if it created a stitched image with a transparency.

    As of 0.6 running all the time with masks on should be OK. A stitched image will only have transparency where there's no Google or Bing map tile, i.e. shoreline generally.

    Earlier version were causing GeoConvert to generate masks all over the place due to that cropping bug. With that fixed I've found that GeoConvert is only generating one tile for a level 13 sized square run at level 13 etc.

    Can someone reminds me what the different AFL levels options do? :/

    Best way I can explain it is that say you download a large (level 9) grid square at image detail level 17 or 18, you have a lot of high resolution image data.

    Each TTC file that GeoConvert generates is a fixed 2048 pixels square.

    If you just generated one level 9 ttc file, you're squashing thousands of pixels down into 2048px, i.e. you're losing a lot of detail.

    If you generate level 15 ttc files, you'll have lots of 2048px images, i.e. you're keeping a lot of detail.

    Obviously the question is then "why not just generate level 15 tiles and forget the rest".

    If you're flying higher, you don't need the level of detail you'll get from level 15 tiles, it's wasting gpu, cpu and disk IO to try to render all that. A lower level of detail will give the same experience and be more efficient, maybe level 12 tiles.

    In AeroScenery the "Choose For Me" button implements what IPACS recommends in their wiki, factoring in the tile size and image detail level.

    The first 2 steps seemed to work.

    However GeoConvert did any of the following:

    1) Complete with press key to exit (good)

    2) Hang for 24hrs with no progress and some constant CPU usage

    3) Disappear without finishing or displaying an error message.

    If AeroScenery failed to generate a TMC file, that's a bug, but it's not something I've seen.

    How many squares are you attempting at once? As I can't yet detect when GeoConvert is done AeroScenery is opening multiple GeoConverts at a time. This is less than ideal and does seem to cause the problems you experience due to massive RAM usage.

    For now, a better strategy might be to download, stitch and generate AF files for multiple squares (leave it overnight or whatever), then run GeoConvert a square at a time as a second pass.

    Aside from that GeoConvert is temperamental and hangs, restarts, fails to generate and dies without warning for me also. Sadly not much we can do about that other than keeping mentioning it to IPACS.

    I see. My view is that FSCP is a rapid airport creation tool not a sharing repository for custom made airports. If there was such a tool I'd happily link to it from each relevant airport in the same way you're linking to me.

    Sounds good, and probably best to draw a distinction between the two.

    It's maybe something I'll look at after AeroScenery but I didn't want to "step on your toes".

    Will do. TSCs are auto-generated so no scope for hand edits. Cultivation files are something I considered, though they may also be a good fit with your tool - I did plan to make a simple exclusion generation tool for use with ScenProc. Custom models - LarryLynx offered his models so I plan to add those at some point.

    I suppose what I'm saying is that if I wanted to spend some time on my local airport, creating custom models in 3DS Max, adding cultivation files, manually adding stuff and tweaking the TSC file, then packaging it all up as a zip, it would be great to share that through FSCloudPort. (Although there are probably data transfer cost considerations with that).

    I guess it depends what you consider the scope of FSCloudPort vs a more generic scenery gateway, like the X-Plane one.


    The X-Plane one is very simple with no editing capability. It's a database of airports, with multiple download versions for each.

    Maybe they're two separate sites with two separate functions.

    It would be easier to share out the work if it was PHP - Lotus Domino & HTML+JQuery

    That's a shame. Let me know if you ever consider porting the backend to PHP or NodeJS (or want it ported). You could keep most of the front end code.

    Another thing, is there any support for hand edited TSC files, along with cultivation files and custom models at the moment?

    (Just adding a few Welsh airports currently).

    I'm curious if it's technically possible for someone to implement something like the Garmin G1000 in a 3rd party aircraft?

    Not that I'm volunteering or have the knowledge to do that :) , just whether the ability is there currently or how far FS2 is away from that.

    It's personally my most wished for thing in AFS2, (ATC a close second).

    I'm really not good at remembering this whole commas as decimal points thing am I :D

    If you set it to 0 it should be OK for now.

    I'll do a 0.6.1 release that fixes this (and maybe adds level 12 squares too)

    Yep, I'll add level 12 in the next release, Added it to the list.

    I can't reproduce the 13377(!) tiles issue when I tried tile size 14, zoom 18 and level 14 & 15.

    Let me know the Google Maps link if GeoConvert does this consistently.

    Also there's now an option to "shrink" the TMC tile coordinates. Check that isn't causing an issue, although I can't see how it would get to 13k tiles

    Hi Nick. Yes, its on the list - quite a lengthy list it is though. For now all I can offer is if someone wants to add to an airport they can ask the author to grant them editor access. That's working now. I think before then people want things like more XREF models, better lighting options, multi-airport download, correct scale footprint of an aircraft and choice of textures including grass. Solving the cross-over runway problem would be great of course as would creating taxiways!

    Maybe when / if I get through everything with AeroScenery I can give you a hand!

    What's it written in, PHP?

    Hi Phil,

    Have you considered supporting multiple versions of an airport in the same way that the X-Plane scenery gateway does? (Or maybe you do already).

    Say I want to take someone's airport and add some custom made 3D models, it may be good to show both versions and let the user decide which they want.

    For example, Cardiff Airport for X-Plane, various authors have attempted it

    Version 0.6 is now released

    https://github.com/nickhod/aerosc…s/tag/v0.6-beta

    Lots of bugs fixed in this one.

    - GeoConvert no longer runs if the user stops the generation process

    - Open Map toolbar item now uses decimal point irrespective of system culture

    - Map toolbar items are not enabled if a grid square is not selected

    - FSCloudPort airport coordinates are parsed with a decimal point irrespective of system culture

    - Custom message box form for catch all exception handling

    - Airport markers are now shown correctly when "Show Airports" is pressed if the map has not been moved

    - Database, wokring and SDK folders are now checked for existence on app start

    - UI is locked while tasks are running to prevent collection modified exceptions

    - Recreate raw and ttc folders before running GeoConvert

    - Fixed issue with image tile stitcher where image was cropped to the wrong width

    - Option to shrink grid square coordinates in the TMC file by specified value. Defaults to 0.01. This forces GeoConvert to snap "outwards" to the nearest edge

    - AID files use exponential notation

    - TMC files use more accurate coordinates

    The misalignment issue that crispy136 and Trespassers reported is now fixed.

    This also fixes the "why is GeoConvert generating too many tiles for level 13 and level 14 tiles" issue that TomSimMuc reported

    Under some conditions, the code that crops stitched images was cropping too much. This was mainly noticeable with level 13 and level 14 tiles.

    If you notice any alignment issues with image scenery generated prior to version 0.6, it's probably that issue. The solution is (unfortunately) to stitch and run GeoConvert again. Downloaded tiles are fine if you have those saved.

    I tried it last week-end and I got the parsing issue you just fixed on FSCloudPort aiport coordinates. I was about to send you the patch but you were quicker..

    Anyway, having looked at the code, I found that the stitching process does not run (yet) in parallel when multiple stitched images are generated. I had a little free time, so I played with the idea of implementing it. I attach the patch and the resulting source files for easier review (TileStitcher.cs in particular). Feel free to incorporate this change into your code. On my not-so-fast-computer, on a level 9 area, it went from 14mn41 to 5mn36. So it looks like a worthy optimization.

    That's great thanks, I'll take a look. :thumbup:

    Parallel stitching has been on my list for a while.

    I am a software developer for over 35 years now, and i think it should be an easy task for ipacs to add a

    • command line parameter like -q(uit) / -e(xit) or
    • an option in the tmc-file like <[bool][exit_when_finished][true]> or something like that to do that.

    I think your idea looks like 'crack a walnut with a sledgehammer', so why not ask ipacs, should be an intermediate task for relaxing from r22 development ;)

    Yeah, I talked to IPACS and they are aware of it. I'm hopeful they'll come up with an improved version eventually.

    In the meantime I like a challenge ^^

    Have attached the results of the map 13 sized tile extracted

    Thanks for that. There's nothing wrong with my maths in the AID files, the only difference I can spot it that FEST output is using exponential notation (e,g, "7.15255737304688E-06") whereas I'm not (e.g. "0.00000553205609321594").

    It's possible that the GeoConvert parser is taking the first 16 digits after the decimal marker and so losing precision from my AID output.

    I'll make that change and give this area, with that airport, a try myself.

    As I said, strange that IPACS chose to read in these tiny values rather than calculating internally from lat / lon.

    Looks like the higher the zoom the more accurate the placement of the tiles.

    Interesting result and needs some debugging by any willing volunteers!

    There a few variables here to consider:

    - In the "stitched" directory, the .aero files for each image give the top left and bottom right coords. In my testing, these appear to be pixel perfect. (Testing in the Northern hemisphere anyway).

    - Also in the "stitched" directory, the AID files copy that top left value and also give "steps per pixel". I'm not sure why IPACS went with this vs also taking the bottom right coordinate and calculating the value internally. It seems there there's scope for error. I'm doing a simple width (in geo-coords) / pixels and length / pixels calculation. If I should be doing anything more complex, I don't know what it is.

    - The TMC file there's the lat & lon of of image tile. GeoConvert should be snapping to it's own accurate tile boundaries. The tiles are contiguous so that's not the issue.

    As the issue is more pronounced at lower resolutions, the issue is likely to be the "steps per pixel" value. It seems like it may only be out in one direction.

    A good test might be to do one level 13 size square with Bing in AeroScenery, and try to do exactly the same area with Bing in FSET. Then compare the coords and steps per pixel in the relevant files and see where any differences are occurring.

    I think when geoconvert can be started once, writes some protocol and ends itself with a defined exit code and can then be run with the next area and so on, that would be a wonderful workflow.

    I'm currently looking at the feasibility of internally taking a screenshot of the GeoConvert window every 5 seconds and testing for the presence of any green (as seen in the success message).

    Slightly bonkers but would work.

    GeoConvert is definitely not made for running multiple instances. It's surprising it even works given the RAM usage.

    Just renamed that also. Still no luck.

    I see that folder re-created after my rename. Task Manager shows the process exit after one second before any window appears.
    Thanks for trying to help. Your suggestions had potential. Mystery remains.

    Hi Greg,

    As others mentioned, go to the start menu, type regedit, click Yes to run as Admin

    Go to HKEY_CURRENT_USER > Software > Right click the AeroScenery folder and click delete. (You'll need to re-set your SDK folders etc.)

    Failing that go to the Documents folder on your computer, AeroScenery folder > database folder > rename aeroscenery.db to _aeroscenery.db

    The next version of AeroScenery (5.1) will never fail to start and will always tell you what's wrong.

    I think I've fixed most of these "failed to start" issues in the next version, but being able to copy and paste good error reports will let me fix anything that remains.

    Sorry for the annoyance in the meantime!

    Also, I noticed that uninstalling AeroScenery using Window's "Add/Remove Programs" doesn't delete the AeroScenery folder from "Documents". This makes me wonder if there are more files spread around Windows so I could delete to make a 100% clean installatio

    I don't think my installer uninstalls registry settings yet, that's the only other thing.

    The stuff in the Documents folder is user data, so it leaves that on purpose.

    One or more of your configured directories are wrong and AeroScenery isn't doing a good job of checking them on startup.

    Another issue on the list!

    Go to Start, Type "regedit" > OK Run as Admin > On the left "HKEY_CURRENT_USER" > Software > AeroScenery >

    Check "AeroSceneryDBDirectory" and "WorkingDirectory". Double click to edit them.

    Is there any chance you will be integrating the option of running ScenProc on the finished tiles to extract a polygon map for structures and vegetation to generate cultivation easier?

    Eventually I'd like to have AeroScenery do that itself . If I don't have time to implement that I will look grabbing the relevant OSM data and opening scenProc though.