mSparks

probably not an IXEG problem. there is a bug in the default ILS radios that makes them randomly fault on anything less than a CATIII ILS. I did point LR to it a few months back, but got told to recreate it in the default 737 which I zero idea how to fly, so just rewrote the LOC system for the 744. I did watch most of it. While he is pretty heavily critical, he also describes it as his favorite aircraft of any sim afaict. plus release notes dont tell you much - and no one bothers to read them anyway. I'd describe him as a harsh beta tester - the review he did on the 744 a while ago was really helpful in understanding what issues were important and which werent.... Like I watched his review, and personally none of the criticisms he had would make me say its not a good aircraft that is worth the money. The sounds were phenominal imho, systems wise it is as solid as can be expected from any aircraft for XP12 can be yet. Im not a tubeliner guy (I enjoy testing and devving the 744 10,000 times more than I enjoy flying it from A to B), but this looks like a solid bird no one would be ashamed to have in their hanger to me - going just off what Q8 showed. I just really, really wish we could get more "5 minute" reviews of aircraft & updates. that entire several hours of video (and many similar streams) could have been edited down to a minute and not lost any detail, especially if it referenced a video from earlier versions.

maximum take off weight, hot, humid, high altitude is going to be very close to full throttle (there is probably some margin for pushing it that bit extra at risk of damaging the engine). I guess that will also be why there is the warning it might overspeed at high altitude, because if you transition from a climb needing nearly full throttle to descent needing almost idle, the time it takes to throttle down is going to tend to be fairly significantly slower than required. The mechanical governor in the robis is different from the electronic governors that manage it all by the fuel injection/engine management system (like we did recently in the 744), those can react instantly and with a lot more granularity. I 3D printed mine, been through a couple of iterations now. hoping the next version is a keeper, it just needs minor changes, and hopefully getting force feedback on the throttle robust (it did work but its broken).

But that is also not how the Robi governor works. The governor drives a 1.5Amp motor that rotates the throttle a tiny bit if rpm is less than 102.5% or more than 105.5% (104+/-1.5%, or 102% to 104% depending on who you believe) (R22, R44 is slightly different). not timed it exactly, but it turns the housing at roughly 0.5 revolutions per second. afaik there is no speed control of its rate, its all or nothing. Nearly all the throttle input is done by the throttle correlator That varies the throttle by 70% of its range from collective down to collective up Verify throttle correlation. Set MAP to 22 inches and turn governor off. Without twisting throttle, lower collective to 12 inches MAP then raise it to 22.5 inches MAP. RPM must stay in green arc. That second video suggests maybe it should just be the fast one always....

Yes, it should do that (to an extent). The governor is a small electric motor that turns the throttle housing on a fairly loose clutch. https://robinsonheli.com/wp-content/uploads/2023/03/r22_poh_full_book.pdf OVERSPEEDS DURING LIFTOFF Helicopters have been severely damaged by RPM overspeeds during liftoff. The overspeeds caused a tail rotor drive shaft vibration which led to immediate failure of shaft and tailcone. Throughout the normal RPM range, tail rotor shaft vibration is controlled by damper bearing. However, damper is not effective above 120% RPM. Mechanical correlation can cause overspeed during liftoff if RPM is increased to normal flight settings and collective raised before governor is switched on. Overspeeds can also occur if throttle is gripped too firmly during liftoff causing governor to be overridden. Inexperienced pilots, who are most likely to be nervous or distracted, are particularly susceptible to this type of overspeed. To avoid overspeeds during liftoff: 1. Always confirm governor on before increasing RPM above 80%. 2. Verify governor stabilizes engine RPM near top of green arc. 3. Maintain relaxed grip on throttle allowing governor to control RPM. and CAUTION When operating at high density altitudes, governor response rate may be too slow to prevent overspeed during gusts, pull-ups, or when lowering collective.

thats the current source of the misbehavior in the default imho. the governor (especially in the R22) is never really active, the correlator does all the hard work. Governor only kicks in when the rotor rpm is heading to far out of bounds adding a little or taking a little away (and if you grip the handle too hard you override it completely - I made that mistake once on landing after a very long flight, resulting in the low rpm horn and a fairly panicked "your command, my command" transfer of controls to my instructor)

yes, there are lots of "spot on" little but important details in X-Plane helicopters (now), that is one of them. So I had another stab at it. https://github.com/mSparks43/R22_governor/releases/tag/v1 My conclusion is that default is far to aggressive in attempting to maintain rotor rpm, there should be a lot more "slack" in the rotor rpm range and the governor should move the throttle much more graciously. I went back to the maintenance manuals: --maintainance manual at https://robinsonheli.com/wp-content/uploads/2022/12/r22_mm_book.pdf --[[ Verify throttle correlation. Set MAP to 22 inches and turn governor off. Without twisting throttle, lower collective to 12 inches MAP then raise it to 22.5 inches MAP. RPM must stay in green arc (Page 1.9) ]] They got this much right, but then the rate they run throttle changes with the governor on is basically "lock rotor rpm at 53 rads/sec", I watched it spin the throttle from 50% to 100% in a fraction of a second at times - that's the "bump". I instead wrapped it in a dual speed governor that very gently changes the throttle if it goes outside 52.6 - 53.4 and more aggressively if it goes outside 52 - 54 and the prop speed is still going in the wrong direction. Now to do exactly the same for VSLs R44.

bit of fun in the F14D, in VR on linux. Not up to the quality of the other streamers, but inside the cockpit its shaping up great I'll start adding commentary from now on.

Ill add symlinking to my list of "optional extras requiring additional download" for windows. alongside multithreading, spinlocks and modern C support. any word on if/when it will ever support fork() and pathnames longer than 256 characters? since that bash script I posted seems to have gone over your head. What it does is use fuze-zip to create the folders inside custom scenery, where the contents are stored and read directly from zip files on another drive. Gives up to 3x the space for ortho. It was actually msfs put me on to that, one of the guys on discord recorded me a streamed flight (cleaned cache) from scotland to London at Mach in MS. I didn't expect it to do that well. But then I saw that: https://orbxdirect.com/product/gbr-south-xp11 Is "The initial download of TEGB South is 26GB, the installation uses at least twice that and the installed product is 127GB" What I had missed is while the images on their own cant be compressed more, groups of similar images (terrain) can. So while downloading 127GB in less than the time it takes to get from glasgow to london at mach isnt feasible, 26gb is (on a 1Gbps connection like his anyway, and yes I know its different, but I was basing my download requirement estimate on the size of my UK ortho) Now all we need is everything to fall into place such that OrbX can release XP12 versions of their scenery and I can go shopping.

imho, thats just an awful lot of people who wish windows had the kind of functionality baked into default posix based systems since 1963. maybe in another 60 years they'll even be able to symlink directly to zip files like the bash script I just posted....

cant personally recommended it because Ive never needed it, but xOrganiser is the "goto" for managing scenery set up. more detail on exactly what you are seeing would help. All that to solve what xplane does with scenery_disabled https://www.x-plane.com/kb/prioritization-scenery-packs/ and otherwise comes as default with every linux and mac machine for some 50 years and is still limited to file+path names less than 256 characters ... ouch. not sure how you think a rats nest of symlinks saves time tho, less is more when it comes to managing them.

why on earth would you want that 🙄

I literally just started using fuse-zip this week for mounting the scenery folders from zip files (works a treat). here's the bash script I'm using to generate them for anyone interested rm mountscenery.sh for l in */ do echo "${l/\//}" if [ -f "${l/\//}.zip" ] then echo "skipped $l" else cd "$l" zip -9 -v -r ../"${l/\//}.zip" . cd .. fi if [ -d "/home/msparks/nvme/X-Plane 12/Custom Scenery/${l/\//}" ] then echo "no need to mkdir $l" else mkdir "/home/msparks/nvme/X-Plane 12/Custom Scenery/${l/\//}" fi if [ -d "/home/msparks/X-Plane 11/Custom Scenery/${l/\//}" ] then echo "no need to mkdir $l" else mkdir "/home/msparks/X-Plane 11/Custom Scenery/${l/\//}" fi echo "echo \"mounting ${l/\//}\"" >> mountscenery.sh echo "fuse-zip -r -o nonempty \"/home/msparks/Development/Ortho4XP/${l/\//}.zip\" \"/home/msparks/nvme/X-Plane 12/Custom Scenery/${l/\//}"\" >> mountscenery.sh done Mac users can also use archivemount. https://linux.die.net/man/1/archivemount that zips them up and creates mountscenery.sh I can use to mount them. I haven't tested tarballs, but probably will. I presume these are windows symlinks. disappearing from the .ini suggests XP didn't find the folders at some point, that sounds like something funny happening with the symlinks themselves. I'd help more there if I could, but that is exactly the kind of wierd behaviour that made me run a mile from windows stuff. Don't believe so, there has been a fair bit of discussion around potential changes, but I, at least, am not aware of anything. Beware tho, XP12 scenery isn't backwards compatible with XP11, particularly wrt to forestry and vegitation, so maybe its the XP11 install nerfing it?

back baby https://www.x-plane.com/kb/x-plane-12-00-release-notes/#Release_candidate_1206r2

caused by only raytrace reflecting what is rendered to the screen, rather than the whole scene. Given You'd be running at 3fps if they did much more..... Also what GPU do you have? I'm getting 60fps in VR on an RTX3070 and pretty high settings, its absolutely sublime. Its difficult to say this without sounding insulting, but... just in case you hadnt thought of it Stay in the cockpit maybe? Lord, grant me the serenity to accept the things I cannot change Courage to change the things I can And the wisdom to know the difference. Which is why RTX silicon is "game changing". The problem now is the widespread adoption of the silicon chips capable of doing it, not the software to do it. ETA 5 to 10 years. At least there is an ETA now, back in 2018/2019 the most we had to look forward to now was maybe getting 60fps with existing graphics.

It is unfortunately correct that it is a limitation of SSR with no known fix or workaround. XP11 uses cubemaps, different technology, different limitations. the main ones being cubemaps can't do any of the reflections in The way cubemaps work is to render the entire scene multiple times for each reflection you want - so two different reflections = 50% less fps. This is opitimised by excluding a lot more than just a spot in water reflections where the aircraft obscures the "view". Complaining about this one is very king Canute. SSR is better, its not perfect, the issue you highlighted has no known fix, so the only way it can get fixed is if you to create your own tech demo showing it fixed and sell it to the entire software industry. ___ While Raytrace is generally "raytracing everything" - you can see what that means for yourself by installing https://store.steampowered.com/agecheck/app/1089130/ The concepts are gradually being adopted bit by bit for difference aspects of graphics engines, screen space reflections and volumetric clouds are two example of that bit by bit. But until almost everyone has a graphics card capable of running Q2RTX at 200fps in 4K, a full raytrace pipeline is never going to be profitable.

I think so. Although it might only be the new loading screen. the "feel" has subtlety changed.

reading again what I wrote, I wasn't particularly clear, so I'll try again and be more precise. For the actual R44 the school taught a "10 point" check list to remember by heart right before before going into a hover (after the actual check list is complete) 1. Friction 1 confirm off 2. Friction 2 confirm off 3. confirm panel all lights out 4. check temps and fuel guages (really check, they sometimes test you do this one by pulling a breaker just before lifting off) 5. center cyclic 6. confirm area clear 7. confirm engine and rotor speeds, 8. left pedal about 2 or 3 inches forward of right pedal 9. find close reference point 10. find distant reference point Then lift collective slowly into hover, left skid low. (been 6 years since they taught me that, not 100% sure I remembered everything correctly..... 😞 ) when you get the pedal input correct there is no pedal input needed, it gracefully lifts stably into a hover, I've never managed that in X-Plane, it always needs some pedal variation very shortly after take off - which is what I meant by "there is something not quite right in the behaviour there, not really worked out what" I suspect it is governor behaviour related (which I already posted my attempts at resolving other governor issues somewhere in here, but the one I am currently using is still not perfect), such that throttle input is changing when it shouldn't.

there is something not quite right in the behaviour there, not really worked out what. In the 44 you set left pedal about 2 or 3 inches in before lift off and it more or less stays there into the hover.

just as a maybe. have you tried deleting/renaming the shader cache.... (general belief is this wont help, but I am reasonably sure it has fixed wierdness for me, and the new one has come back different than the old) renaming is better because then you can A/B test.

I was breath taken for a second that someone may have actually thought of something XP doesn't do or hasn't tried yet. But all I found is one of the things it does best 🤣 Whats missing from @mjrhealth and @GoranM replies however is just how "WOW" WED is. There are a lot of people who "just" use WED and enjoy building things with it. The other one you can use for the things WED doesn't do is JOSM https://josm.openstreetmap.de/ You can import "patches" (including terrain alterations) from that via Ortho4XP, I use that for the small lakes in:

I would not want to be your co-pilot when you explain to the passengers you have to make an emergency landing because you saw some bizarre looking clouds.

40 to 50 seconds here. I suspect you might be using a filesystem like NTFS from 1993, or worse, FAT from the 80s

I would say fps dropping 50% when you pop out the window is not something to expect. Finding the exact cause goes a long way to helping fix it, but the reply you get from the bug report form will be the best source of info on what they know already, or they will request additional info if they dont know and cant recreate it.

report form is here https://www.x-plane.com/x-plane-bug-report-form/

The benefits of zink are multifaceted. Its not just AMDs sketchy drivers or maintaining long term support for old code. Although they are both very good reasons for them adopting it. MacOS only supports openGL version 2.1 in plugins for example (maybe 2.4, smth very low) - this is why skyscapes couldnt be written for XP11, zink gives plugin authors the latest and greatest version of opengl on mac. Vulkan needs more code just to get in a position to draw something than most plugins have code, plus all the different hardware related complexities. Zink gives authors a common graphics API to work from for all platforms where LR can be responsible for fixing hardware support and testing. (So plugin authors that dont have a windows or mac device can still write quality plugins for all platforms) There is probably a few more, but it is as much about extending the capabilities available to plugin authors as it is about keeping old ones going.