I suppose it depends on the person, but I definitely thought it was. It's a very different style than a realistic sim like AeroFly, but the flight physics are actually a great mix of realism combined with pure fun. The 'missions' that you fly are challenging but entertaining, and the graphics are really nice in their own cartoonish way. I got so hooked on it that I played completely through every mission in a couple weeks, but it did take a fair bit of time in total. There are only three different aircraft, but they all have very different flying characteristics and are a nice balance. FWIW, my brother (who is not at all a flight sim enthusiast) also bought it with a lot of skepticism, but after a few days told me it was his new favorite vr game. I think refunds are available on both the Oculus store and Steam now, so I'd suggest trying it and if you don't like it you can always get your money back
...On the other hand, it does allow you to manipulate controls for comfort. So by grabbing the yoke and overly moving back and left the right amount, I can position my arm comfortably on my arm rest with the yoke now being centered.
That is a really great point, and I wonder if IPACS implemented it how they did for that reason. There are certainly pros and cons of each approach. I've already adapted pretty well to its current behavior, but I find the 'rubber-band' style more natural personally. If there's any other Ultrawings players here, I'm curious which control style they prefer.
Thanks Jet-Pack! I really appreciate the time you and the IPACS team take to read and respond to our feedback here in the forum.
And just to back Jeff up (not that it's needed!), I fly with 90 fps in VR with scenery converted at this level, with a 3GB GTX1060 and i5 CPU, all settings at ultra except shadows. AeroFly's performance vs. detail is unmatched by anything else out there.
I've really been enjoying the new VR hands. Honestly, when I first tried them I thought "hmm, this is interesting, but no way will I use this instead of my hardware stick/throttle", but I've been continuing to adapt to them and now might even prefer them to the old HOTAS!
I have a suggestion that I think will make them work better and feel easier to use. There is another VR flight game called Ultrawings, and it also uses a VR-hands approach to flying. IMO, Ultrawings really nailed the issue of keeping your hand aligned to the flight stick, without actually having a real stick to align your hand.
I'll try to describe, but if the devs have access to Ultrawings it'd really be best just to fire it up and see how it handles it. There are two key differences between how it behaves vs AeroFly when using the flight stick:
(1) In Ultrawings, as your hand starts to approach the hard limits of the stick's travel, it uses the haptic feedback of the controller to indicate this. As you get close to the limits, it starts to vibrate, and the vibration increases in intensity until it's at a maximum at the stick limit. If you continue to move your hand beyond the stick limit, it will keep vibrating until you bring it back to where it should be. Your brain quickly adapts to this feedback and soon it's very easy to know where your stick is and how much more travel you've got left.
(2) The other thing that Ultrawings does that I prefer is how it deals with your hand when you take it past the stick travel limits. In AeroFly right now, if I am gripping the flight stick, and keep moving my hand beyond where the stick has reached its limit, when I move my hand back toward the stick again it creates a fixed displacement between my hand and the stick. In other words, if I move my hand left until the stick stops moving and keep going 6 inches further left, when I begin to move my hand right, the stick will now be 'stuck' 6 inches to the right of my hand. It stays like this until you release your grip and re-grab the stick.
Compare this to Ultrawings, which works more like having a rubber-band attached between your hand and the stick. If you keep moving your hand beyond the stick limits in Ultrawings, it will allow you to do so (with the haptic feedback buzzing to warn you), and then as you move your hand back, the stick will stay at that directional limit until your hand re-aligns with the grip again. It is indeed just like having your hand connected to the stick via a rubber band, that stretches when you go too far, but then holds things back together when they re-align.
The problem with AeroFly's absolute displacement offset becomes really apparent when flying aircraft with a yoke instead of a stick. If you aren't paying attention and pull your hand 12 inches to the side of the yoke, and then bring it back while still holding the grip button, it appears that the center of rotation gets way off so that the yoke wildly turns right and left as you move your hand. To fix it you have to release the grip and grab again, and be very careful about keeping your grasp lined up closely to the yoke.
I think this "rubber-band" grip combined with the haptics at the travel limits would also really improve the feel of throttles, where I usually fly gripping them but not actually looking at them. I've had many times where I pulled my hand too far one way or the other and then when I tried to throttle back on landing, I couldn't move my arm back far enough to reach minimum throttle without releasing the grip and grabbing again.
I've been starting to model in some back-country airstrips in the Idaho foothills which can be selected from AeroFly's location map and are smooth enough to land on. Here's an example:
With these airstrips, I'm using Google satellite ortho photos at their highest resolution for the runway textures, rather than using some of the built-in concrete surfaces in the AeroFly library.
The problem I run into is that, in order to smooth the airstrips enough to land on, I have to define them as "...__airport__runway" objects in AC3D. But, AeroFly doesn't let the normal ground texture show through when you define an area as __airport__runway. So in order to still have the correct original texture appear after defining these areas, I have to painstakingly re-map the original texture on top of the "__airport__runway" surfaces, and then also tweak their brightness and contrast so it looks seamless in AeroFly. I've made this work well for 2 back-country airstrips so far, but it would be a LOT faster/easier if I didn't have to re-map the textures when they're already there, just being obscured.
The better alternative to what I've done would be to just define it all as "...__airport__outside" in AC3D, but unfortunately the smoothing provided by that isn't enough for these hilly terrains and the low-res topo mesh, so you end up with stair-stepping and bumps and broken terrain all around if you take that approach.
So my feature request is: can we get an option (maybe in the .tsc file) to make "__airport__runway" objects transparent, the same way as "__airport__outside" objecst already are? This allows us to use the stronger smoothing of the runway algorithm, but still allow the original photoscenery to show up.
Or, another way to do this would be to allow user-definable "smoothing strength" to the "__airport__outside" objects. That way I'd get the benefit of the original photoscenery showing up, but could make the smoothing for the outside area as strong as the algorithm for the runway areas.
I know the AeroFly team is super busy with many other things, so please just add this to the 'we'll consider it if it's easy when we have time' list
Yes, thank you very much to the whole team. I think sometimes it's easy to forget that we pay for the software only once, yet the developers continue providing improvements and updates far beyond the initial sale and we get way more than our money's worth. The AeroFly team is amazing and we really appreciate all your hard work! I really enjoy flying in this sim in VR!
Very nice vogel69! I think people using geoconvert will find this tool *very* useful! Great job!
I think to add a function to generate grid from a .ttc files folder (folder "Images" of the scenery)... may be could be usefull to check if all .ttc files with all level are done.
here a screenshot of the feature (you can hide or show grid for each level):
- Yellow: AFS2 Level 10 Grid
- Red: Level 12 Grid of my scenery "Images" (.ttc files) folder
Yes please!!! This would be really useful! Also, I don't want to get greedy, but if it could also detect masked .ttc tiles and show them in a different color, I think that would also be a really cool feature.
This does not work so easily when you have a combination of RW and VR, i.e. real yoke (mounted at your desk) and virtual hands.
Fair enough. Until some finger-tracking VR gloves or something similar are available, I think we'll have to choose either VR hands or actual hardware controls (or maybe a hybrid with one hand being VR and the other holding a flight yoke/stick).
Not sure if this is a bug per se, but I don't think it was happening before the most recent update. It's not a big issue either, just wanted to get it on the list.
I have throttle, mixture, and prop speed mapped to analog controls (sliders and knobs) on my HOTAS. If I have these set at a certain position in flight, then back out to the main menu, go to the location map, pick a new location, and then re-enter the sim, the position of the throttle, mixture, and prop speed no longer match up with where they're set on my HOTAS. They also don't re-sync to the correct positions until I move each of these control axes fully in each direction, almost like it's recalibrating their full motion.
For example, I'm flying and have my throttle at max, mixture at medium-rich, and prop speed at minimum. I back out to the menu screen, go to "Location", move to a new spot on the map, select it, then back out to the main menu again, and then go to "Start." When I re-enter the plane, the throttle in the plane will be at minimum, and prop speed and mixture will be at max & max rich, even though on my HOTAS they should be set at max throttle/min prop speed/medium mixture. These controls do not start responding correctly until I cycle each of these axes to their limits.
I've noticed something that I do not believe is VR Hands related but only appeared after the latest update.
Coming in for a landing with either glider when you get within a meter of the ground the plane just drops the last meter while the pilot camera position does not.
You end up looking out over the canopy during the run out. Does not happen with the powered aircraft.
Very weird. Can anyone else reproduce?
I've seen the same thing with this one.
I just wheel my chair back a bit from my desk, sorted
I can't help but laugh at this... Maybe I'm not understanding their desk-hitting issue entirely, but isn't this the obvious solution? VR isn't really intended to be used seated at a desk in front of a keyboard like conventional 2D gaming. The virtual world needs space to exist, so you have to make room for it. Adding a non-linear movement ratio to the VR hands relative to the position of your real hands would not only be pretty hard for your brain to sort out, but defeats the purpose of VR, where spatial position is supposed to be preserved to real-world scale. If your hands are hitting your desk, scoot your chair back until you've got plenty of room, and then press the view re-center button, presto, fixed!
Thanks for the update! This feature will probably bring many more users from the VR world to AeroFly.
I have one little issue to report: the toe brakes on my rudder pedals no longer work, as long as my Touch controllers are awake for the Rift. If you go to the controller setup screen it still shows them mapped and responding properly. It appears that as long as the touch controllers are awake and active, it steals the brake control for the analog stick instead of sharing it with whatever else you have mapped to brakes. Definitely a problem if you want to use VR hands + a hardware set of rudder pedals.
I'm assuming you have made sure you have the latest drivers installed for your hardware, particularly the graphics card and have tried adjusting the lens slider located on the underside of the headset - that alone can make a vast difference.
Just wanted to echo this. There is a 'lens adjustment' screen you can go to with the Rift where it shows you green crosshairs and gives you instructions on how to adjust that slider and also make sure it's optimally aligned to your eyes. Having this set properly makes a huge difference in perceived sharpness.
If it's adjusted correctly, the center of your vision shouldn't necessarily look blurry... it should just look like you don't have quite enough pixels there for it to look sharp like a modern phone or computer monitor, if that makes any sense. In other words, the pixels that are there should look sharp, it will just look like there aren't as many as you'd like
I agree with very much with Jeff... after you get used to it you don't really notice lower resolution as much, and for me I could never go back to 2D sim flying. The sense of depth and scale, being immersed in the cockpit, being able to look around in every direction, knowing by eye how far off the runway you are... it's a completely different experience.
The mask dont covered the partielly scenery tiles....the overlapping exist to.
Aero has his own tiles...and at Startpoint in Aero we can see....zoom in... the tile borders from aero. But this, dont help in FSET.
When generated with FSET we have the Probs with overlapping tiles every time.
Only a chancewe have, is, that made a big Ground tile (cpl- Germany) at Detail 4 and compile with max Level 9-10.
After this, compile the next tiles for better view a small tile ( Airport) at Detail 0 and Level 13-14, only one.
That goes...but when you want more tiles after the first procedur.... the same Problems with overlapping tiles comes true.
FSET is not specialy for AeroFS2...
We can work with this, but it is very ticky...
I wish and hope that we become a Tile Tool that bring us the correct Tile coordinates for Aero FS....
Yes, it is the masks that create issues. If you have any tiles that include masks, then you can never add scenery adjacent to those tiles that completely fills the area until you delete the masks and replace the masked tiles with complete ones. Please see my post here where I tried to explain what is going on: Scenery Loading Distance Also the reply further in that thread from Rodeo gives more detail
I haven't had a chance to test out vogel69's tool yet, but as far as I'm aware it does give you the correct tile coordinates for AeroFly. Also, if you look earlier in this thread, I posted an Excel file which will also calculate the exact coordinates for AeroFly tiles at any level, and that one I know for sure works because I've been using it all week Unless I'm misunderstanding what you're saying, your solution already exists.
Edit: Just to clarify, if you're using the excel tool I posted, the workflow is like this: (1) Get the lat/long coordinates of any point inside the area you want scenery for. (2) Enter those coordinates into the tool where it says. (3) Specify the level you want it to give AeroFly tile coordinates for (9-15). (4) If you want a larger area than a single tile, you can add those with the boxes in the input section. (5) Click the big blue "Copy" square, and then in FSET click the "P" button which will paste those coordinates into FSET. (5) Download the area in FSET at whatever download resolution you'd like (e.g. -1 for really detailed areas, 1 for larger areas)
The thing to remember when using this tool is that you can generate complete tiles for any level above what you specify in the tool. For example, if you specify a tile level of 9, then within the coordinates it outputs, you can generate complete tiles of levels 9-15 with no masking/gaps/overlap. If you specify a level of 12, then you can generate complete tiles of levels 12-15, etc.
Thx for that tool.
I haved tested and i see there diffrent boundies between Google earth and FSET.
Or...Geo coordinates calculate the coordinates not correctly.
I see more at future...test go on.
If you're referring to the green colored grid that appears in FSET when you select an area, that grid unfortunately has no relation to AeroFly's internal grid. I think this probably confuses a lot of people using geoconvert for the first time, and maybe should be made clearer in the wiki.
This gets a little confusing, but the reason for all these tools we've posted in this thread is that AeroFly has its own structured internal grid it uses for its scenery tiles, and if you want to use geoconvert efficiently for an area, ideally you'd download only the pieces of scenery that exactly fit AeroFly's grid. This prevents wasted download time, and also prevents needing to use masks for partially-downloaded scenery tiles ('masks' in AeroFly are separately generated files which block out the incomplete portions of scenery tiles, which creates issues of gaps between scenery if you have adjacent scenery areas).
Very cool vogel69! Thanks for sharing this with us, can't wait to give it a test run!
Since this thread is where all this talk began, I wanted to include a link to a tool that I made for Excel that lets you calculate tile coordinates at any geoconvert level really easily. Info and link is here: Image tile coordinates
Hi all, I think having this available in Google Earth will be truly the best solution, but if it's useful to anyone else I made an Excel tool that works similarly too. You can download it here: https://www.dropbox.com/s/zv3c…gridcoords_v1.6.xlsm?dl=1
When you first open it in Excel, it will have a sheet that tells you how to use it. Click the tab at the bottom that says "User Interface" to get to the actual tool.
Here is a video tutorial as well:
The way it works is you can give it any coordinate in latitude and longitude, and tell it what geoconvert level to use (9 to 15 but it works from 0 to 16 actually). It will then calculate the NW and SE corner coordinates of the AeroFly grid cell that contains your coordinate, at the specified geoconvert level.
You can also tell it to add more cells to right/left/top/bottom to expand the area, and the final output coordinates will always be snapped to the AeroFly grid at the level you chose. The purpose of the tool is so that you can download precise areas in FSET without ever having to use masks, and without downloading extra scenery that you don't need if you're working at high detail levels. It also has a button for copying that will paste directly into FSET (note you'll have to enable the macro for this to work). You can also use this tool to precisely repair some of your scenery if (like me) you made a bunch using masks that you now regret!
As far as I know it all works correctly but if you run into issues let me know. Hope it's useful to some of you!
EDIT: link is back up, fixed error with pasting into GeoConvertHelper, double-checked math, protected cells to prevent accidental edits.
EDIT2: V1.2 fixes a compatibility issue with older versions of Excel. Should work for Excel 2007 and newer now.
EDIT3: V1.3 fixes a bug occurring if you gave coordinates that were *exactly* on the intersection points of the AeroFly grid.
EDIT4: V1.45 adds a button that lets you paste coordinates from FSET to the input boxes with one click
EDIT5: V1.5 fixes a pasting error from FSET with certain longitude values
EDIT6: V1.6 corrects for an FSET bug when pasting on systems that use commas for decimal marks (1,00 vs 1.00)