Posts by nickhod

    This becomes highly visible where default IPACS textures are poor.

    For instance, my Caribic scenery (Petites Antilles) requested me to generate Level 7 too, otherwise Level 9 scenery pops up in the distance when flying GA from an island to the next one, even as low as 5'000ft (default IPACS textures are scattered with clouds).

    That's interesting, thanks.


    I take another look to see what I can do to generate level 7 output. As you say, it could just use level 9 areas as input.

    There are so many different threads on this forum about AeroScenery that I'm sure you can't see them all. I made a post earlier today but it got sucked up into a previous post that I made a few weeks ago so I'm sure you would never see it. I am going to post it here and delete the other one.

    Would it be possible to add Grid 7 to your outstanding AeroScenery program?


    Unfortunately not. When I started Aeroscenery, I based the level 9 size on being near the size of a Ortho4XP grid square which I had used before.

    Quite a lot of things in the app depend on that base size of level 9, and it would take some work to change that.


    I know it's a few more clicks, but you can still select 16 level 9 squares at ZL15, build them with GeoConvert at level 9 only, and you'll have a large area, quickly created, without using much disk space.


    I must admit I don't know the altitude cutoffs where Aerofly displays a certain level of scenery (i.e. at what point would it show the very basic default level 7 scenery over the level 9 scenery described above - if at all).

    As I only fly GA I never reach it, or maybe it will always use a minimum of level 9 if available.

    I noted that most add-on scenery includes a minimum of level 9.


    I will take a look at the blank pixels in USGS scenery though. I thought that one was fixed.

    If you have any questions or tests that you want me to run, I would be glad to help. It really is hard to make these VR HMD choices when we can't try them on. I bought mine from the HP store for $499 (the consumer version ) with the idea in mind that if it just didn't work well for me, I would send it back for a full refund. My previous HMD was an Odyssey+ so I had all the WMR software and knew how to best set it up.

    Thanks for the review.


    $499 is a great buy. We're paying $732 over here in the UK, so it makes the decision that bit harder.


    I'm due to go to the USA in April on business so I'll keep my eye open for any deals then.

    I've been trawling HP Reverb reviews. This one seems to sum up what a lot of others say


    - Amazing resolution. Fixes SDE. Where all headsets need to be eventually.

    - Pretty bad optics

    - Very small sweet spot

    - Not great tracking


    I think I give up on my search for a perfect 2nd gen headset for now. (Until I change my mind). Talk about 1st world problems.


    I just tried the Cosmos at RAF Cosford, in a C172 on Aerofly. Yes it was a little crisper than my Ody, but no great step forward and the contrast was lower. I think if i get anything of the current crop it needs to be the Reverb.

    Good to know. Also saw another YouTube review panning it. Shame.


    I think it's either the Reverb or nothing for me too.


    Enjoy Cosford if you're there for the Sunday!

    Just watched the video accompanying that review.



    Some people in the comments are saying that the poor sweet spot might be due it being incorrectly positioned on his head.


    The tracking and controller battery life might be fixable in software and firmware, so I'll keep an open mind until some more reviews are in.

    I really did want to like this headset!

    Oh dear... No good in dim light, light leak from flip up design and my guess is you'd lose FOV too. HP Reverb nudges ahead. The reviewer does speak highly of the Index sweet spot but I really don't want to invest in lighthouse tracking - we don't need it for flight sim.


    https://uploadvr.com/htc-vive-cosmos-review/


    Sigh. I had high hopes for the Cosmos; sounded perfect on paper. 2 - 3 hours battery life for the controllers is terrible.


    For me, it's probably between a HP Reverb and just waiting for something better. Valve Index is too expensive and I don't want to have to mount lighthouse base stations.

    Are you creating a flight plan with waypoints in the 'Navigation' screen?


    In the Cessna I just move my head a bit closer to the moving map, or zoom in with the control knob.

    I find it easy enough to see if I'm following the green line of the planned route.

    I have a 64 bit Access SQL database (or something similar - I don't recall the exact wording) already installed. Did this come with AeroScenery?

    No, nothing to do with AeroScenery. The database used and code to access it is all self-contained.

    Hi, I seem to be getting this error on startup with both the MSI and ZIP version...

    It's failing to create and open an SQL lite database in your Windows "My Documents\AeroScenery" folder.


    Why that should be case, I'm not sure. Try running as Administrator to see if it's a permissions issue?

    Delete anything already in "My Documents\AeroScenery".


    (Use the zip version in the first post of this thread).


    "D:\work" is where the source file was that the exception is generated from. (I should be catching and handling that exception with a more friendly error message).

    Does the name of the map need to match the name of the bitmap?


    I don't know how fussy the IPACS exporter is, but you see this in the example airports.



    I've never used the diffuse / ambient amount controller as you have. Not sure if that makes any difference.


    Do the ambient maps in the Kingman and Oceanside example airports work as you'd expect?

    If I have well understood the Life project from Jeff the path of vehicles movement can only be created manually under 3DS Max for now. It is the manual side that bothers me (in addition to the license of the proprietary 3D software). In the long run, could these paths be created automatically, for example from the OSM route network?

    There are two things going on here, one is the routes for vehicles to follow, and the other is whether to render roads on top of ortho photo roads.


    Aerofly should definitely implement vehicle routes from OSM data. Given how well the animations work in Jeff's demo, with minimal performance impact, it's probably not a huge leap to read these animation paths from elsewhere. Seems like a relatively easy win to me.


    As for whether to render roads on top of orthophoto roads, I've never thought that roads in X-Plane look particularly realistic. Being vector, they're well detailed if you get close, but they generally stand out like a 'sore thumb' against the ortho backdrop. The asphalt, concrete and tarmac used on roads come in so many different shades that it never matches well.


    I noticed that the on the MSFS 2020 trailer video the roads show vehicles moving on top of high-res orthophotos. They haven't tried to render the roads as geometry.

    I’d like to be able to search for an airport

    This is really needed. Several times I know I want to fly from an airport but, in the case of unfamiliar airports, don't know exactly where it is.


    I end up taking off the Oculus, using Google Maps to find the airport, putting the Oculus back on then trying to zoom to the same region.

    The location map is a nice interface, but it needs an airport search box.

    Are you using a multi-material assigned to the ground plane, then assigning different vertices to different sub-material IDs (usually with vertex painter).


    I think the wiki is wrong there. The screenshot shows the polygon being set to material ID 2, which is the runway material.


    Maybe post the diagram from the Slate Material Editor (not the classic material editor) so we can see what's going on?


    If I remember correctly, Aerofly is fussy with material bitmap naming, and I think the files have to end with _color for ambient and diffuse.

    That's why for me an xml editor style would slow things down, I'm just not used to reading xml code. But if you're used to it I see that it might speed things up for you. and that's a good thing. The only issue that I would see is: how do I add comments and how do I indent parameters in a block form, e.g. like for aerowings. Usually I do " 1.0 0.0 0.0 " for the string, with leading and trailing white space, which might look weird in xml.... but in tmd block form it works great: [ 1.0 0.0 0.0 ] looks more like my c++ code ( 1.0 0.0 0.0 ) and without that it looks too cramped and isn't easy to read [1.0 0.0 0.0 ]. This makes a difference after 8 hours of work. In Jeremy Clarkson's voice: "Whitespace gooood. No whitespace baaaad." 8o^^


    And on top of the readability... I wonder how do you "ctrl+s", "alt+tab" + reload in aerofly then? I imagine you would have to compile your xml back to tmd first and that takes a couple more clicks or key strokes I guess? Unless you hook it up to your IDE commands. And I sometimes do that 10x a minute, so even the "ctrl+s" and "alt+tab" already gets annoying.

    I think you're right that it depends what you're used to. In my professional work, if I'm not in a C#, Java or Typescript file, I'm in an XML or JSON file. Your brain learns to scan what you see all the time.


    Splitting the project up into multiple files was the main driver for this utility and definitely helped a newbie like me get a handle on all the individual parts that make up a plane. In any dev project I'd take small self describing files over one huge file.


    The TMD file felt like an intimidating slab of unfamiliar markup to me, but if you edit them day in, day out, I can see why it wouldn't seem like that.


    On those other things


    Comments / White space


    I only needed to go from TMD to XML once. After that it's only XML to TMD.

    Nothing is reformatting the XML so I can use XML comments, white space, line breaks in attributes as I need.

    The extra spaces or line breaks for vectors work fine.


    Reload Workflow


    Yesterday I sent an hour coding a "watch" command that writes the TMD when any included XML file is changed, which removes having to remember to run the convert action each time.


    Short hand version


    I'd argue that using "off the shelf" markup languages makes sense as everything can process them and everyone is familiar with them.

    Your example is most similar to YAML, which could also work well here, along with JSON.

    (I understand that the TMD format is good as an output format as it's so easy and quick to parse).


    It may be the case that no one else needs this utility as they are OK with TMD, but it's definitely helped me out.