light_blue_yonder

Hello all, A quick question for all the GTN users who also use Chaseplane/EZCA. Is there a way to change the middle mouse button click on the radio knobs to a left click instead? I use the middle mouse button for camera controls with Chaseplane, which obviously precludes the use of the middle mouse button on the radio knobs. I have taken a cursory look through the code and the f1vc.xml topic, but cannot figure out if the middle mouse click is hard-coded into the .MDL file or it can be altered by the custom .xml file. May lack of familiarity with reading xml code as well as the numbers used make no sense to me without some more documentation. I'm theorizing that it is possible to use the xml code to read a left mouse click on the 3D button, and instead of using it as a "decrease radio frequency" command, translate it as a middle mouse click command. However, as stated before, I don't know if this is possible. Thanks for any inputs!

I have followed every Aerosoft instruction. In fact, if it's limited to an Aerosoft procedure problem, I wouldn't have the same problem between the Airbus and CRJ, never mind Milviz as well. The fact that all other addons work correctly is also confusing me quite a bit.

Yep, everything in P3D is unassigned. In fact, I had to check if assigning axes through P3D also causes the problems. I can't think of anything that isn't done properly. And no, I don't have problems with the PMDG planes.

So, after a few months, my solution was this: Better hardware. Nothing in the configurations and settings were helping, but a system upgrade did help. I still have no idea what suddenly caused the blurry textures, so there isn't really any particular solution I can contribute.

Hello all,I've posted this over on the official LM forum, but decided to post here as well. I'm having a very weird problem with separate throttle axes. This problem happens when assigning axes through P3D or FSUIPC. In a select few aircrafts, I can move the throttle fine when mapping one axis of my Saitek throttle quadrant to "Throttle axis", and it will move both throttles in the aircraft. But if I assign two axis each to "Throttle 1 axis" and "Throttle 2 axis", neither of them moves the throttles in the aircraft. I can get a response, but it seems like the input jumps up briefly to the position of the throttle before returning to idle. I originally thought this was an Aerosoft problem, since I had this issue in their A32X and CRJ. I recently got myself the Milviz King Air, and ran into the same issue. It seems like aircrafts that use a specific way of interacting with the throttles are having problem. I have no problems with the FSLabs A320, PMDG, and RealAir stuff. I have tried DirectInput and RawInput with no effect. Since this appears on some aircrafts but not others, and appears across aircrafts made by different developers, I'm suspecting that the issue stems from something in P3D5. Has anyone seen or heard of anything similar?

I believe that the white line is a result of mesh not loading, which as far as I understand, is part of the same "procedure" as loading textures. I have tried disabling Dynamic Texture Streaming, but my measly 1060 6GB ran out of VRAM all the time, but I will try again with the 6900 XT. I'm not too convinced that the texture streaming is the problem though, since this problem was present in P3DV4.5 as well. I personally never had the stuck loading problems, but limiting the fps did also make no difference for me.

Hello guys, I've had this issue pop up for a while on my new hardware, and asking over on the official LM forum yielded no results. I have the classic autogen not loading/ground texture blurry problem when flying. The strange thing is, no matter how low I turn the settings down with locked 30 fps, the issue does not improve in any way. Even more strangely, this issue exists both on P3D V4.5 and V5.1/5.2 I have tried: - Lowering settings/lower fps limits - Switching SMT (AMD's hyperthreading) on and off - Affinity masks - TEXTURE_BANDWIDTH_MULT and TextureMaxLoad changes - Higher FFTF settings None of these seem to even alleviate the issue in any way. My hardware is: Ryzen 9 5950X running at around 4.8 Ghz stable RX 6900 XT (issue was there on my GTX 1060 6GB as well) 32GB Corsair 3200Mhz RAM I have tried clean install, clearing shader cache, deleting and rebuilding .cfg file; yet even with a fresh install of V5.2, this issue is still there. I'm honestly at my wits end, because it seems like everything I can try I have already tried. Are there any other users with a similar sort of hardware (i.e. relatively low-clocked CPU with lots of cores) that can suggest some setting/troubleshooting steps? Thanks in advance for any inputs!

I've never seen a comprehensive thread on solving this issue, so I will have a go at compiling one here. The problem: in an aircraft (mostly PMDG, it would seem), the split second your main wheels touch the ground, there is a microstutter between 1/4 and 1 second long. Then, you hear the aircraft touchdown, and everything is normal afterwards. The potential solutions to try: 1. For PMDG airplanes, go to PMDG Setup -> Options -> Sounds, and set "preload sounds" to "ALL." "Selective" may also help with touchdown lag, but this hasn't been tested by anyone specifically. 2. Make sure your audio device is processed through a sound card (onboard or add-on) rather than your CPU. Verify this by making sure that your sound device is plugged into a port supported by your onboard audio (lots of mainstream motherboards have one, i.e. Realtek etc.). An example problem in this case is when you plug in your headset through the front port but only the rear ports connect to your motherboard Realtek sound. (These two options should solve your issue, as these are the primary causes of the lag. If not, try these less consistently effective options.) 3. In Prepar3D, go to Options -> Sound, and set the three dropdown menus on the left to your intended audio device (ideally going through a soundcard as outlined in step 2). By default, the existing setting should be <Default XXXX Device>. 4. In older versions, deleting fx_skidmark.fx from the "effects" folder has helped the performance. This file is not directly related to the split second of touchdown, but has helped some users in resolving their issue. 5. If you use an USB headset, try deleting your headset's software. Corsair's iCUE software has been shown to take up CPU usage as well as inducing touchdown lag. Simply uninstalling the software removed the touchdown lag. 6. Various FIBRE_FRAME_TIME_FRACTION settings have alleviated the issue for a few users in early Prepar3D/FSX days, but the effectiveness of this method is debatable.

Oh yeah, I remember now. Isn't 84 one of the gates that goes both ways after you pass the door into the "outside corridor" between the departure lounge and the actual jet bridge? Like, basically gate 84 really only just allows you to use 83 or 85 jet bridge? P.S. Man, I didn't realize how long it's been since I last stepped foot in the actual US departures area. The last couple of times have both been a midnight departure from the "International" area.

I personally really recommend redeeming your key on Orbx Direct and install via Orbx Central. It's so much more convenient. https://www.yvr.ca/en/passengers/navigate-yvr/terminal-maps This might help you. Go down to the interactive map, select "US" under "TERMINAL" and you can see where gate E85 is. According to the real life chart, the parking spot is just called "85," in the same location as gate "E85." You can download FltPlan Go (free with real life charts for Canada and US) and see for yourself. I don't know if "85" exists in the scenery though; I haven't checked, but I would hazard a guess that it is there.

Possibly, although I doubt it since the bright night problem has been a thing since FSX. That's fixable by shaders like TomatoShade, so I don't think that's exactly the same issue.

It's a matter of personal taste, I guess. At 02:00 PM, you would expect the ground to look like how it is at the extreme left side of the screen. It should be bright, but not "washed-out" in color. If you look at the ground between the two reflective areas of water, you can see that the ground is so washed out it has no "depth" feel to it. Yes, there isn't any real depth because it's just a flat polygon, but in previous versions, it FEELS like it has depth. That's the main problem.

Orbx Central, like regis9 said. I believe it's also configurable ONLY in Orbx Central as well. I just bought it from FSimStudios and redeemed the key on Orbx Direct and downloaded from there, so I don't know if FSimStudios include a configurator in their installer. I own and still use their really old Calgary scenery which works in P3DV4... kind of. Lighting is tragic and sometimes downright broken, but it's still the best Calgary scenery I can find out there. Compared to YVR though, it is not good. It's pretty amazing to see how much they've progressed, and that's actually what I look for when I buy scenery. It's not necessarily what they are already doing; it's more about how is it compared to what they were doing this time last year. That's why I buy scenery from guys like FlyTampa, ImagineSim, FSimStudios, and moving away from FSDT in terms of scenery (GSX is still freaking amazing though). P.S. FsDreamTeam scenery is still good, it's not like they took a step back suddenly. It's just that a lot of the effects they use in their scenery "feels" really outdated for my personal taste.

I'm a bit late to the party, but just picked up this scenery to upgrade from the very out-of-date and somewhat inaccurate FSDT version. I thought, well, I need to turn off some eye-candy and just accept a few fps loss on my 6700K and 1060 6GB, but no. That's not what happened. I disabled some usually fps-intensive stuff like static airplanes and the floating logs in the river, and I gained (that's right, GAINED) 5-8 fps compared to the FSDT scenery. Best part? There's no longer that frame drop at around 1.5 mile final because of the day FSDT uses Addon Manager to handle scenery loading from the VAS-limited FSX days. I spent some time with the interior turned on and went to all the spots I used to go spotting in real life, and boy did that bring back some memory of back when I lived there. Overall, it's a solid 15 out of 10 for me. Well worth the money. P.S. It also blends in with Orbx FTX PNW better than the FSDT version because of the slightly interesting color theme choices FSDT made, but the difference is relatively minor. As it stands, I see the FSDT version, in its current state, as way overpriced compared to the benchmark this version sets. The only advantage I can think of with the FSDT version is the SafeDock system at the gates, but you can customize a gate to have SafeDock anywhere with GSX regardless of the scenery anyway.

Yeah, I've only found a couple of posts as well. I think it's a lot less noticeable as soon as you start getting clouds in the sky. I'll go over to the LM forums and ask, since there's no post specifying whether this is a known problem and/or if there's a workaround.

I know this is an issue that has been brought up before, but it didn't seem like anyone stated whether there is a solution. It revolves around the terrain being overly reflective (almost looking like it's covered in smooth ice). In the screenshot, you can see how incredibly obvious it is with the terrain looking like a smooth surface with the autogen sticking out like a sore thumb. This is with DETAIL_TEXTURE=1 in the .cfg file, but as far as I understand, this is irrelevant regarding this issue. The screenshot is taken with EA on, but EA off produced a similar result. The result is most pronounced at higher latitudes (such as this shot taken over YVR looking southwest) during the winter seasons around noon (such as this shot taken at 14:03 local time) when the sun is bright but low. Is there a fix/setting for this problem, or is it a case of having to wait for an update that tunes this reflection differently?

Yes, I do understand that, and he is orders of magnitudes more knowledgeable in this area. However, he developed this software for P3D back when some of the newer V4 SDK tools are not available to him. That's what I'm trying to see if I can do. I don't have a problem with the aircraft as it is, and I'm perfectly able to fly it as it is. (Perfectly able to fly it, not able to fly it perfectly. 😆) I'm just trying to mess with it a bit just for the sake of it making it a tad bit better for not good reason other than I have time and RealAir is no longer in business. I'm actually curious if anyone has looked into RealAir's coding and knows of their system somewhat, since I have no clue where to start other than the aircraft.cfg and that isn't doing me much good.

Yes, I did try that. Here's the problem I found with that: If I increase it by enough to have a 12s spool time, then the max %NG and max torque will be higher than default. Not by much, but since I don't understand the P3D system well, I don't know what else may be messed up. In other words, it's exactly as you stated. Doesn't fix the problem much, but a little bit better as a compromise. What I'm trying to do is essentially trying to reverse-engineer RealAir's code, which is next to impossible for someone like me without some guidance.

To reply to my own topic, yes, it is a limitation of P3D. I'm now using the iniB TS preset for TomatoShade with extended cloud shadows and the relevant Tomato Optimization for the fixes. This makes it much more acceptable than the previous R&D preset I was using.

The Turbine Duke has been a long favorite of mine, but the turbine lag is becoming a bit bothersome after wading into X-Plane recently. Since RealAir is no longer in operation, there is probably not going to be a fix for the programming based on old FSX limitations. I'm thinking of using this summer quarantine time to get into coding. Here's my question: How easy is it to alter the engine values for the aircraft? I tried to use the new fuel flow table in P3D V4, but it just messes up the max %NG value and the max torque slightly. How feasible do you think it would be to code a custom model for the engine to bypass the flawed P3D system? I'm assuming it's basically impossible for someone with very little coding experience and next to no understanding of the P3D system. But as long as I can be pointed to a place to start, I can start messing around with no real end goal. EDIT: Altering the fuel_flow_gain to anything other than 0.051 results in the max %NG increasing from the default 102.0 to 102.5 and the max torque to increase from the default 1300lb-ft to 1320lb-ft. This leads me to believe that there is a custom coded engine model that relies on the value being 0.051. EDIT 2: I managed to restore the default max torque by redefining the max torque to a lower value in the aircraft.cfg, but the %NG problem remains. This doesn't make sense to me, since the fuel_flow_gain is defined based on N1, why does changing it alter the N1 value. If N1 is the independent variable in manipulating fuel flow, why does changing fuel flow make it act like an independent variable that changes N1?

I've been exploring some new FPS-intensive times of day after some new-found performance through the anti-aliasing settings, and I noticed something quite strange. I always fly with Active Sky, and I've been flying in some fully overcast skies at sunset. However, I've noticed that all buildings (custom scenery and autogen) still light up pink/orange as if it's sunset on a clear day. This happens with or without TomatoShade. I do have cloud shadows enabled and draw distance on "high". Is this a known limitation of P3D still? (I know it was back in the V2/V3 days.) Or am I just messing something up in my settings?

I had an issue where I was missing some highway lights by installing Orbx Pacific Northwest after installing OpenLC North America. I fixed it by installing OpenLC again. However, I don't know if this pertain to your specific issue since I don't have UTX, and you have *all* highway lights missing and I only had *some* missing. I believe the Orbx configurator is for different light textures used as "autogen" street lights, and should have nothing to do with highway lights since those are based on the roads. If anything, I would suggest checking your scenery library order, and failing that, running the UTX install/configurator again. *Technically*, Orbx Global Base and Buildings HD should do nothing to your UTX vector data, but it wouldn't be the first time P3D's acted weird.

This is a bit of a late response, but thank you to everyone for their input. I exchanged for another set of CH pedals, and the problem is still there. However, it is far, far less pronounced and is pretty much negligible. For now, the CH pedals will do just fine, it gets better once it's used a bit and I got used to the forces required eventually. The spacing is an issue for me, where I feel the discomfort in my legs even after short periods of use, but trust me, a real-life Cessna 152 isn't exactly comfortable either. I can see the Saitek spacing being better, but I can't confirm it since I've never used it.

Totally understand, I just can't wait to have it. Once I've tasted it in the NGXu, I want it in the 777 as well. 😆

I haven't bought into V5 (and probably won't before seeing FS2020, if I'm honest). In V4 though, I find PMDG to be quite FPS-friendly, based on my experience with the 777 and 737 NGXu. The one that hits hardest is FSLabs, but even that is only 1-2FPS lower than PMDG.