Posts by qwerty42

Ultimately, the only person who can decide this for you is you. The rest is just other people's opinions. If you already bought it, reinstall it and try it. In the amount of time you'll wait for other people's responses and reading through their subjective commentary, you could just as well try it out for yourself.

There is 1 new IPACS helicopter. The rest is largely unchanged from 1 year ago, other than some new scenery available from 3rd parties as well as some 3rd party free and payware aircraft too. In performance it will absolutely crush X-Plane. In visuals, it will be better in some ways and worse in others. Same goes for flight models, flight physics, and aircraft selection.

All that said, if you ever found X-Plane in VR to be 'smoother,' I can't think of any possible explanation for that except some kind of issue with your installation or hardware. I own both, have spent hundreds of hours in both, and X-Plane (while great in many ways) cannot touch the smoothness and performance of FS2, period.

Quote from MartinM

Texture Pack Southwest USA is installed

I showing you the difference between my aeroscenery google and the default with the highres pack installed

For me a quite significant difference

Is that gap between your scenery and the default being caused by a mask that was created when you converted your scenery? If so, you might not be seeing the default scenery at its max resolution, making it look worse than it really is.

Have you ever sat in a real plane of that size? You're basically a sardine in a can and it's indeed very cramped by most people's standards. In a Cessna 150 or 172 you're nearly shoulder to shoulder with the other person in the cockpit and touching the door on the other side.

That said, having the IPD of your vr device adjusted correctly can affect the appearance of scale. To me AFS2 feels very accurate in terms of scale.

Jet-Pack (IPACS) I just wanted to say thanks for your consistently helpful and receptive tone on this forum. Even when comments are critiques or criticisms, such as in this thread, and even when they are sometimes incorrect, I don't think I've ever seen you take on a negative or defensive position in responding to them. It's not easy to do that, so just wanted to highlight it and let you know it doesn't go unnoticed.

Quote from Ian C

UPDATE: I've started using raster > extraction > clipper in QGIS to crop rectangles from my Geotiff, thereby avoiding the holes in the data. Each cropped Geotiff needs its own separate TFW file so it's quite time-consuming - but it does work. It also enables me to geoconvert all levels 12-14. Previously I was only geoconverting level 14, which was giving poor results in some areas - even though I had a base layer of level 11 derived from 50 metre data.

That sounds like progress! Nice job! Regarding the mask files for terrain, I just had a closer look at my stuff here and didn't realize before that the terrain height masks don't have a corresponding non-mask file. I was confused by your question about that before because I thought they came in pairs like the orthophoto tiles. So... I have no idea how or if the elevation masks actually do work Based on the limited testing I did before when I converted a whole bunch of elevation, I remember concluding somehow that it did look like they were allowing partial terrain tiles to be built, but I could have been wrong about that. One of these days when I have some spare time I'll dig into it some more, unless you beat me to it

Quote from Ian C

Suppose you geoconverted 2 adjacent areas and the boundary bisected level 15 tiles .....

If your source imagery has data all the way up to the boundary, then it should work just fine. Geoconvert doesn't care if the source images are split across multiple source files, just so long as all of it is there.

But, as an example--if you have two source images that don't quite meet (maybe for some reason there is a 100m gap between the photo data), then a mask file will be created, if masks are enabled. If they aren't enabled, it will skip generating that tile since it doesn't have complete imagery to produce it.

Likewise, if your source imagery ends halfway across a tile, and masks are enabled, geoconvert will create a mask file to let the lower levels show through where your source imagery ends, and you'll still end up with half a tile of orthophoto imagery which displays correctly in the sim.

The orthophoto masks are actually very simple: they are just an extra hidden image layer that tells a converted orthophoto tile where it needs to be transparent. If you're familiar with using alpha channels for transparency in computer graphics, they work a lot like that.

They become confusing because there is so much else going on that it's hard to keep track of all of it (source imagery resolution aka zoom level, geoconvert levels, and the fact that it's not immediately obvious which level you're currently viewing when flying in the sim at various altitudes). And if you've built a bunch of scenery that generated masks, those masks will force any newly-generated scenery of the same level to still be transparent in the same places unless the masks are removed. That can become a very tedious process, so that's why some of us started suggesting that everyone avoids creating mask files altogether.

If you already have scenery that was converted with masks enabled and those masks were produced, it means you have some tiles that only had partial image coverage. If those masks then get deleted without removing their corresponding image tiles as well, that's when you'll start seeing the black areas, because there is no data there and the lower levels can't show through it without the mask.

Hmmm... AFAIK, the range from full black to full white in the geotiff directly maps to elevation. But it's not trivial to edit them, because they are 16 bit grayscale images rather than the 8 bit that most people are familiar with, and even using something like Photoshop they aren't easy to work with while preserving the 16 bit data.

My idea, which might be completely wrong, is that if geotiff supports transparency or something like it, and you already know where the 'holes' in the data are, the fix might be to remove those areas entirely from the geotiff. I haven't tested anything like this at all though. I just know that geoconvert is creating masks for terrain, and I think it's doing it correctly--it makes them where you don't have full data coverage within a complete tile.

Regarding masks, I think you've got it backwards, actually. For orthophotos, if you have a masked level 15 tile, then the next lowest-level that exists will show through. In other words, if you have a full level 14 tile and a partially masked level 15 above it, the level 14 tile will show through the masked areas. You only get black regions if you have incomplete tiles and *no* mask for the incomplete area.

The masks only create issues when you try to create adjoining scenery at the same level, because the mask blocks out the area it covers until it's removed, even if you replace the partial-coverage scenery tiles with full coverage.

So going back to the terrain tiles, assuming the masks are working correctly, then for areas that were masked in your incomplete level 15 tiles, you'd just have level 14 terrain data showing through in those places. The trick to solve, is how do we modify these geotiffs so instead of the missing areas showing up as 0 elevation, they show up as something that geoconvert recognizes it needs to mask...

Hey Ian, great work!!! I never tested this myself, but I wonder if you can use those empty voids to create masks for the terrain mesh. I know that Geoconvert generates terrain masks, and assuming they work like masks for orthophotos, you might be able to do this in a way that just shows the lower-level mesh in places where your higher-res stuff is missing.

The trick is, I don't know what geoconvert looks for to create masks with the terrain data. It's not full black, or full white -- does geotiff support transparency? Maybe if you leave those empty spots transparent instead of black, it'll mask them for you...?

This of course creates the issue of partial terrain tiles and masks, but that might be ok if your original dataset isn't going to ever fill in those voids.

Jet-Pack (IPACS) If you do change this, please do it in a way that leaves it as-is for VR, or gives us the option. The crisp HUD lines in VR are one of the differentiating factors that makes your F-18 look substantially better than the payware F-18 for X-Plane.

Quote from Ian C

I'll try the integrity check thing - thanks for the tip.

I do have ORBX True Earth Netherlands - so I guess that could be causing the problem. Also I moved the Netherlands scenery tiles - I don't know whether that's of any significance. I never touched the Netherlands TTH files however.

What does deleting the "main.mcf" do? I have it at the back of my mind that it's a cure for some types of problem - but I can't remember which!

Cheers

Ian

It stores certain preferences and configuration settings, and if it's gone I think AeroFly generates a new one when it starts. I can't remember if joystick mappings are stored in there, so if you try it you might want to back up your old one. Also you'll have to manually re-enter your auxiliary folder location back into it if you regenerate it. I doubt it will make a difference to what you're seeing, but it's so fast to check it's worth a try.

Weeeeird... I have no clue why it would behave that way. Have you tried having steam do an integrity check on your base AeroFly install? I wonder if something is corrupted with one of the default tiles...

Edit: Just had a thought... do you have any extra 3rd party DLC? Like ORBX stuff? I wonder if the load priorities on those are dealt with in a different way and could be conflicting?

Quote from coxo2436

i want to try and do a 5m dem of anchorage but i discovered it is not in .img format do you know how to do it ?

It needs to be a geotiff file, which is a specially encoded tiff, if you're following the youtube tutorial I made. Depending on the format, it might be possible to convert it, but I haven't attempted anything like that. Others may have, but in order to help you they'll need to know what format your files are.

Quote from Ian C

Currently I am putting my elevation (TTH) tiles here .....

C:\Users\ian\Documents\Aerofly FS 2\scenery\elevation

Is there any reason why I shouldn't put them here .....

D:\SteamLibrary\steamapps\common\Aerofly FS 2 Flight Simulator\scenery\elevation ?

Obviously I would put them in a separate folder so that I could move them if necessary. The reason I ask is that my C-drive is rather small in capacity. The D-drive would be a much better place for them.

Another question ..... I created a base layer of level 7-9 TTH tiles for a level 7 area north of 60 deg in Norway using 10 m data from Høydedata. Initially I put them in the C-drive location above and found that they didn't show at all in Aerofly. The terrain was completely flat - i.e. it was the default terrain at that latitude. It was only when I transferred them to the D-drive location that I saw the terrain as it should be. I noticed that the default terrain tiles on the D-drive are levels 7-10 only. I assume therefore that levels 7-10 have to be on the D-drive anyway to show up. Obviously it would make sense for me to put all levels (7-14) on the D-drive.

Display More

You can specify an additional path for custom scenery, aircraft, terrain etc. in your main.mcf file located in C:\Users\<username>\Documents\Aerofly FS 2\. There is a placeholder for it in the .mcf file already. You just need to put your folder path there. For example, in mine I have this line:

<[string8][extra_user_folder][V:\aerofly_aux_folder]>

I have subfolders in that extra user folder which match the structure of the default user folder (C:\Users\<username>\Documents\Aerofly FS 2\). Almost all of my custom stuff is stored there, but the main AeroFly install is on my C drive.

I'm not sure what the issue with tiles 7-9 would be... I have some converted at that level up through level 14, but maybe it's not actually loading the 7-9 tiles. Given the coarse terrain resolution at that scale, it might not be noticeable whether or not it loads them, unless it's an area that doesn't already have any terrain mesh at all. If I get some time soon I'll see if I can reproduce your issue with mine.

Quote from theskyisthelimit99

Loving the VR with aerofly fs2.. but i noticed that now (maybe not in an older version), it defaults to split screen view when doing VR on the 2D display..

I'd like to be able to record flights using shadowplay.. so unless there is some other hack to do shadowplay without the split screen, the only way i guess to VR + record as of now would be a way to turn that off?

Is there a way, just curious..

Thanks in advance

I realize this post is really old now, but in addition to the config option mentioned above, if you're using a Rift you can also launch the file "C:\Program Files\Oculus\Support\oculus-diagnostics\OculusMirror.exe" to get a full screen, single-window VR view that doesn't seem to have a noticeable performance impact.

Are you sure it wasn't this issue I warned about on the first page of this thread? Creating terrain heightmaps

AFAIK any tiles with the same name in your custom folders replace the ones that are part of the default install at load-time, the same way the orthophoto tiles do. I don't think a duplicate mesh is possible for that reason.

It's also possible there was some bad value or spikes or something in your data you used to make the mesh. Not really sure, but I can say I have many areas converted from levels 9 and higher and I've only ever encountered issues at the outside boundaries where my custom mesh meets the default mesh.

Quote from Ian C

Just an update on my experience with high res terrain mesh in the USA.

I've managed to get rid of the discontinuities / "cliffs" between adjacent 1 x 1 degree download areas by geoconverting a 2 x 2 block of them together, using a TMC file whose NW co-ordinates are the NW corner of the northwestern-most 1x1 degree area and whose SE co-ordinates are the SE corner of the southeastern-most 1x1 degree area. I put all the IMG files and their corresponding TFW files together in the imput_aerial_images folder. This eliminates all the masked tiles on the boundaries and pushes the problem to the outer boundary which can, of course, be as large as you like. The block could be 2 x 2, 4 x 4 or whatever.

I've also attached a couple of comparison screenshots below. They were taken on the Elwha River SW of Port Angeles, Washington State. The top one is with the high res terrain mesh and the bottom one is with the default mesh. Note in particular the ravine, which is completely absent in the default mesh screenshot and very well defined in the high res shot.

Hey Ian, this looks fantastic! Nice job, and glad you were able to figure out how to do it. It makes a huge difference in certain areas. One of the nice side-effects of this is that it also makes the satellite orthos look better, because they get properly stretched over the terrain shapes instead of being distorted over flat ground.

For those with rudder pedals that have stiction that makes it hard to be precise, I really recommend getting some NyoGel 767a, cleaning the old lubricant off of them, and then using a light coating of this in its place. I have the Thrustmaster pedals and they were terrible before doing this...they would stick a little and then jump large distances when broken free. The nyogel is a damping grease and it prevents that large friction difference between static vs kinetic movement. It also creates a nicely damped resistance, not quite as good as a hydraulic linkage but still far superior to the stock 'feel' of the pedals. It works nicely in throttles too. It's probably a little too resistive for a short joystick, but it'd probably work great with a joystick converted to a long handle too.

Edit: just be warned, this stuff is extremely sticky and is hard to get off of your fingers or fabric, so be very careful applying it...use gloves and some kind of applicator you can dab it on with, then cycle the controls many times to smooth it out. Start with a tiny amount and add more as needed...it doesn't take much.

Quote from lenidcamper

I found that with 16 gig of memory more than 2 concurrent GeoConvert instances are thrashing away in the page file.

So I doubt more than 2 instances are actually gaining any performance benefit over dual instances run sequentially.

Eight concurrent instances eventually cause a pagefile crash.

Hopefully v1.0 of AeroScenery will have some configuration for MaxConcurrentGeoConvert instances.

/Stu

Yup. And if you do max out your memory, you will get MUCH better performance from geoconvert if your OS installation is on a fast SSD (preferably two two of them striped in raid) instead of an old spinning HDD because of that page file utilization.

It sounds like you might have multiple controls mapped to your yaw for the helicopter. Unfortunately it's not obvious when this happens in AeroFly but it can happen. To fix it, click the axis assignment with your mouse (the same way you would if you were assigning a control axis to it) and then press the delete key on your keyboard. Do this several times, because if you have multiple inputs assigned to it, it will only delete one of them each time you do this. Then click on that axis one more time, and move the control you want to use to re-bind it.

Quote from nickhod

Thanks for the info. I haven't looked at this fully yet, but it's on my list before I release the next version.

I'm either calculating the just the hex tile name wrong, or the hex tile name and the lat and lon wrong. I'll let you know what I find.

Thanks, curious to know what you figure out. I won't deny the possibility that there's an error in my spreadsheet, since it's an ugly translation of programming code into spreadsheet logic, but I have previously converted some pretty huge areas from levels 9 thru 15 using it and FSET and never noticed any tile offset problems between the various levels. I've also compared the coordinates my spreadsheet calculates to the level 9 coordinates that GeoConvertHelper calculates, and they've agreed to 12 decimal places (if you account for the .1 degree inward offset that GeoConvertHelper automatically adds in). It's not a guarantee it's right, but if it's not then I'd suspect it may be an issue with the original code snip Rodeo posted...

Quote from nickhod

...

The hex numbers are derived from the lat and lon, so those also being incorrect makes sense.

...

Hey Nick, I could be wrong and just taking a wild guess here, but if you're calculating the filename hex from the lat and lon decimal degrees values that might be the problem. The size of the tiles in terms of degrees latitude are not uniform as you get further north or further south of the equator. For example (assuming my spreadsheet is correct), a level 9 tile is ~0.70 deg 'tall' at the equator, but only ~0.11 deg 'tall' at the north pole. If you've assumed uniform spacing and are converting from degrees to hex from that, it might explain the issue...?

If you did port all that code from my excel sheet (ugh!), and this really is the problem, you can get the grid coord numbers directly from rows 26 & 27 and rows 46 & 47 in that spreadsheet on the 'DONT_EDIT' tab. They are the number of the tile before it is converted into lat and long decimal degrees. Note that I split them into NW corner and SE corner (because of the area expansion feature I had in that spreadsheet) so you may need to offset them by 1 before converting to hex.