glider66

I've just bought a Tobii 5 and this thread turned up in one of my Google searches, so I thought I'd tack on to the end of it, though it looks as though maybe it was drifting on to the back burner, judging by Merawen not getting any replies to his post. Anyway, here's my initial thoughts, after an initial couple of hours use. I'm a seasoned Trackir 5 user, of about 5 years, and prior to that I'd tried the DIY route with a modified Playstation camera and Facetracknoir. I have to say, back in those days, Trackir was a vast improvment, well worth themuch greater expense, as the software and settings just worked, straight out of the box, unlike my clumsy grappling with the DIY route. I'd tweaked my Trackir settings to quite a convenient setup for me, but I always found the need to wear the passive clip and a baseball hat, or the pro active clip and headphones to be uncomfortable during long sims sessions. So when I found out about the Tobii, just the fact of not needing to wear anything was incemtive enough for me to give it a try. Installation and setup was a breeze as most reviewers have stated, despite my hardware not being within all of the stated limits. I use triple screens, and the main centre monitor is a 50 inch 16:9, but it is within the 33 inch max distance away from me. I haven't managed to get it working in MsFS yet, but a quick flight in XP11 via the FacetrackNoIR plugin was very promising, even without any tweaking at all.

I guess it all depends on where you fly Jacques. Some areas of the world may have more accurate autogen locale specific architecture. Here in rural UK very few buildings are appropriate. Even with Autogen disabled, land contours are faithfully reproduced, so MsFS is using quite a fine mesh to lay the sat photos on. So in rural areas at > 1000ft alt the scenery effect doesn't look flat except where there would be tall buildings or landmarks. I've been using Ortho4xp at 18 and 19 max res for several years now with XP, and it is better than MsFS as long as you're not flying really low. It's quite hard to practice real VFR flights with autogen because although the topography of rivers, railways and roads is correctly mapped, the over-sized buildings and vegetation can mask and dramatically alter the downward appearance in most areas. When I first started mith MsFS I was amazed by the scenery, but at the same time surprised to find quite wide rivers in very familiar flight areas that were in reality quite small streams, almost invisible from even 500ft.

I've tried searching this topic on here and found several previous moans about the Autogen of buildings and vegetation in MsFS being out of proportion and out of context, but nothing mre recent, so here goes..... I've just got into the SDK scenery designer (and really like it - thanks Asobo), and I accidentally discovered the effect of disabling buildings and vegetation autogen over a comparatively large area, (with an exclude polygon). I'd been trying to make a small village on the perimeter of a very rural ex-WW2 airfield look more realistic, but the standard library objects had very few "locale specific" matches for the oldish UK village buildings. Even the church looked like something out of the Munsters Movie, though admittedly it was an improvement over the original three storey block of flats that was Asobo's previous 3D building plonked over it. So I thought I'd clear the decks completely by drawing the exclude polygon around the perimeter of the whole village, and hey presto, the effect was a remarkable improvement. It revealed the high res online satellite imagery underneath with the same clarity as the extensive Orth04xp scenery that I'd painstakingly downloaded for my XP11, (and required it's own dedicated 4tb disc). I admit the lack of 3d buildings wouldn't be so succesful in urban areas with high res buildings, but in rural areas it was far closer to real VFR from even as low as 1000ft. Not only was my house 100% accurate, but even the garden shed and parked car were visible. Whereas with mSFS autogen on (any setting, even ultra), was completely different, and the pig farm up the road had become a luxury hotel ! Here's a split screen shot of the local village, half with Autogen, and half without, and another composite screenshot showing a nearby Solar Energy Field, depicted by Autogen as rows of tiny terraced houses and miniaturised hotels. So is there any way that we can ask Asobo to add a settings tickbox to completey enable/disable autogen of buildings and/or vegetation ? .....and it would be even more useful it could maybe be more specific in keeping default hand crafted scenery enabled, so just avoiding the genuine "autogen". I'm fairly sure that it would have a secondary really useful effect in greatly reducing the bandwidth, CPU, and GPU loading, not having to draw and rotate these hundreds of buildings and trees, and would significantly improve FPS, especially in VR. It would seem to be a relatively easy tweak to implement, since it can be accomplished with polygons in the SDK. I did think of trying to draw a polygon around the UK, but it exceeded the allowed size, then just Southern England, then just Norfolk, but the largest permitted was just about one square mile.

You're welcome Chris. Credit where credit is due. 🙂

I realise this is now an old thread, but I thought I'd resurrect it in case anyone has found it via a search and is considering buying a Fulcrum Yoke. I was certainly reading it with interest myself, to gauge whether to order one myself. I'd heard about them via a post on a Facebook flight sim user group and was impressed with the user feedback. I took the plunge and pre-ordered one on the 18th June, with a predicted two week wait for me to reach the top of the queue for it to be firmed up with payment. I received that email invitation on 4th July, and made the payment, (2 weeks and 1 day later). I received a progress update email on 13th July, informing me that it was in the final process of production and would be despatched shortly. The yoke arrived on Friday 22nd July, 5 weeks after pre-order and 3 weeks after payment, all within the predicted timescales. It works perfectly, with no sticking, and it "bounces" correctly when released from full dive or climb, so the lubrication is fine, though I had taken the precaution of buying a can of PTFE dry spray just in case it had been needed. I've now fitted it to my DOF H3 motion platform and the improvement over my previous yoke is huge. It feels and acts so much more like a real GA yoke. I'd gradually evolved over the years with a CH yoke, then a Saitek, then a Honeycomb Alpha, and now this. The Honeycomb was good, with 90 degree aileron movement, but lacked any roll resistance. Whereas the Fulcrum actually feels as though it's connected to rods and cables. The pièce de résistance though is the much longer and more accurate elevator range, gradually increasing resistance, and total the lack of centre detent. Final approach and flaring is so much easier and more natural, unlike anything I've experienced on a sim before. Most of these small manufacturer specialist flight sim peripherals can't be obtained "off the peg", and involve some risk and delay, but this yoke has exceeded my expectations, and well worth the wait. A very "professional" piece of kit in every sense of the word.

Perfect... 🙂 That's exactly what it was, thanks. I changed the minimum value to 0 for the axis on the Bravo and GVL throttles, and now the hardware lever and software axis are exactly synchronsied in the 3d cockpit window, without needing to add a slope profile or adjust the triangles. I'm really getting into it now, I'm able to leave all of my controllers plugged in that I use for various aircraft, and AAO's automatic assignment per aircraft type lets me hop from one to another without the delay of having to go into MsFS's Control management. To be able to pick and mix various axis and devices as a succinct aircraft "set" is so much better than Asobo's clunky method. ✅✅

Thanks Lorby. ✅ Yes, I tried moving the red triangle to various positions, but that seemed to make the controller's axis to the MsFS assignment's axis even less synchronised. The half range deadspot was still there, and the remaining actual movement was less proportionate. The two controllers that have shown this half range deadzone are my GVL throttle, which has a rotary action with hall effect sensors, and the other is a Honeycomb Bravo throttle with rotary levers, which I would assume are pots, rather than hall effect. Your Axis min suggestion sounds as though that might be it, because of the lever only having any effect after the halfway point. I guess that could be it taking up the minus value range before it gets to 0. I'll give it a try and report back.

I started using AAO with just one of my hardware throttle controllers, a GVL. When I found that I could move the lever halfway through its travel before the assigned axis (vis AAO) in MsFS started to move, I assumed it was caused by it not having very good default calibration. I tried calibrating it first via Window's "Devices & Printers" but it didn't alter the situation. I've now started to assign my other hardware controllers via AAO as well, and I'm getting the same problem with my Honeycomb Bravo Throttle. I've made sure that they're not mapped to two physical devices at the same time. The triangles in AAO for trimming the ends of the movement and the centre point work fine where the physical hardware lever can't reach the ends of the slider in the AAO config, but not for when the lever can move the control over a longer range than it uses in the Sim. (very had to describe this !) I've compensated for the initial deadzone (the first half of the lever range), by altering the profile slope in AAO, but is there a better way to do it ?

Thanks Lorby, the script for the axis control works perfectly, (and now I can begin to see how they work too 🙂) I sorted my throttle deadzone too, (after reading the help file more carefully). I added a profile, (fast increase, then normal), so now the MsFS throttle lever starts to move almost at the same time as I move the axis lever on my GVT throttle control. Your AAO program accurately sees the entire movement range of my throttle, whereas the sim was only starting to respond after it passed the halfway mark.

Thanks Lorby, I completely understand the point about the Volocity's "collective" being an up/down toggle switch rather than a true axis. I did originally think it was certain to be a pair of 'press to hold' switch inputs, one up, one down, since as you say, that's how it's displayed on the stick in the 3D cockpit view. What was confounding that though was the way it was working as an axis using MsFs's built-in control assignments. I'll set it up with your script, thanks for showing it. I had to smile at your expression Volocity "thing" 🙂 I guess it must be the last thing a serious sim pilot would be seen in, but I find it handier for inspecting scenery than the remote drone. (That's my excuse anyway...)

I tried setting my throttle lever to THROTTLE_AXIS_SET_EX1, but it still couldn't move the height control in the Volocopter. I then used MsFs to assign the same lever to the Throttle Axis, and it worked ok. I tried the numbered throttle axis as well in AAO's simulator events, but there was no movement with them either. It would be handy if there was a way to assign it using AAO, because then your nice feature of remembering it for just that aircraft would really come into play, rather than me having to enter MsFs's Control settings interface to change that assignment eacch time I switch to or from the Volocopter, (and any other aircraft that might be so pedantic about needing "Throttle" rather than "Throttle1".

Thanks again for another very prompt answer. I'll give it a try and reply again with the result.

The AAO dropdown list contains Throttles 1 to 4, but I haven't been able to map the specific un-numbered "Throttle" axis with it. I admit it's not an issue with most aircraft, but MsFs seems quite pedantic with that particular axis with certain aircraft, like their "Volocopter" and some helicopters. The Volocopter's flying height adjustment (altitude) works when assigned via the Sim itself to the "Throttle" axis, but not "Throttle 1", or via AAO's "Throttle 1". Is there another simple way to assign it with AAO that doesn't involve coding ? (I quickly get out of my depth with that !)

Thanks for investigating my problem so thoroughly. You've now fixed it completely, and my gauge layouts haven't since missed a beat. They pop up exactly as they were laid out, size and position.

Ok, thanks for the prompt reply again, email sent, with screendumps....