LRBS

I suggest that you consider the following points. Water has a greater thermal capacity than air. On air, you don't have moving parts and any tubing. But you have a warranty. When dealing with water, it's possible to experience pump malfunctions and leaks. Not so many instances but something of no issue at all with air. When using water to cool a computer, the temperature is lower than when using air and the fans do not have to work as hard. Specifically, in your case, only 5.2 GHZ air would be a consideration. But it will make a difference if you decide to let the CPU exceed 5.2.

I see, I have my FPS locked @ 50 on a 4 K monitor, no OC, actually MOBO limited not to exceed 90C and -0.05 undervolt. I'm using DX11 TAA, render scaling @ 170 (6527/3632), and had initially LOD 200, then I went to LOD 350 and back to 200. Due to high render scaling at 170 (on my PC) raising LOD did not make a big difference. At LOD 350 I lost 5 FPS and smooth even 45 FPS. With Inbuilds. As I stated, my focus is on smooth performance and clear visuals rather than chasing high FPS, benchmarks, or overclocking. Additionally, I only make a few adjustments to the Nvidia control panel.

Just an observation, I have 13900K on my PC, and also I have access to a 13900KF. From my observation (4K monitor with RTX 4090 water cooled) with KF I can notice a +5 FPS and a few lower temps (between 4 to 6 degrees), but again I find overclocking unnecessary. In my case, I'm looking for fluidity and stability. As an example at JFK with ultra settings using PMDG or the Airbus I can get 55-60 FPS without any issues at all. Temperatures wise K will give me 65 C while KF will be around 60 C.

As previously stated, overclocking can result in high temperatures which can lead to thermal throttling, increased fan noise, and unstable performance causing stutters. Many 13900 users have found that under-volting improves performance and eliminates stutters even when using ultra settings. At this time, it would be best to avoid using DX12 as it is still in beta and may cause visual issues in certain cases. After the upgrade, you will actually see what is all about. This individual provides helpful information. By making minor adjustments in CMOS, you can achieve similar results without needing to delve into excessive detail.

Could you please clarify which version of ReShade you are referring to and if there are any tutorials available? I have attempted to use it before, but have not had any success.

Very interesting indeed. As you mentioned after touchdown relief valves will open and will equalize cabin pressure with the outside. I am confused about the video because it seems like the door is fully open at a 90-degree angle, but also I don't understand why the outside view is not moving. The other two issues I have is one that the A321 doors don't open outward, actually, they pop out a few inches and then they slide alongside the fuselage. Another important point is that the aircraft doors cannot be opened when the cabin is pressurized, particularly for this Airbus the approach speed range is between 130 to 155 KTS Vref. It is virtually impossible for anyone to open the door in these conditions. However, additional information is required as the current statement is not entirely accurate.

I've been using xenviro2020 and have noticed some pros and cons compared to MSFS wx. However, I think it will take some time to achieve accurate weather depiction. One thing I've consistently noticed with xenviro2020 is that during thunderstorms at the same wx location and time, you can see lightning and thunder while MSFS struggles with this. Furthermore, the visuals in relation to the SA are significantly different, as seen in the pictures at https://flightsim.to/product/xenviro2020. For example, on slide 2 of 8, the prevailing visibility is 6000, while in MSFS, it's not even close. Slides 5, 6, and 7 of 8 show BKN082, while MSFS is more likely to show OVC. On slide 8 of 8, MSFS shows clear skies, while the metar shows SCT 018. Ultimately, the key factor is how ASOBO/MSFS engine creates all the cloud formations, types, and visibility. When they open up the wx to other parties and include an RVR option, we can expect some real improvements.

I am having difficulty understanding this RSR and what is behind his resistance to fixing issues that are so obvious in each model. There have been some persistent bugs with the 737 since its initial release that still have not been addressed. It is simply inconceivable that the real/consultant pilots operating the 737 failed to identify and report these technical malfunctions. A/P is very rough in banks and not so much in pitch. While in A/P (LNAV) before/after each waypoint will bank L/R aggressively 2 or 3 degrees before settling down and visible spikes in FD. This should be a smooth transition without any jumps to that magnitude. Issues with turn anticipation. Clock, MCP displays (digits) will not dim making it unpleasant/unrealistic during nighttime. The airplane is very light in controls like a light twin, with almost no control load/feel. Yes, it is a game, and impossible to create a real replica, but there are developers that managed better/plausible flight characteristics. I can understand why people are eagerly awaiting updates for EFB, 777, and 747. However, I have noticed that some obvious bugs have not been fixed despite the considerable amount of time that has passed. This raises concerns about the quality, quality control, and direction of PMDG's products. The other alarming issue is if you raise complaints about these bugs on their forum, messages get deleted and if you write a ticket the answer (if any) is that "a few users has reported this but it is not reproduced in our systems". Total no interest to troubleshoot the problem.

Bob's statement regarding the US is accurate, but it's important to note that there are differences in terminology and regulations when it comes to international flight operations in countries such as the UK, UAE, and China. A helpful resource for navigating these differences is the AIP. For instance, airlines often have specific guidelines for these countries, outlining differences in ATC communications and procedures. To ensure safety and prevent any mishaps, we receive documentation before each flight that serves as a reminder of these distinctions. I forgot to mention that this applies to both SID and STAR.

I don't understand why you would involve yourself in these accusations. Is it necessary for me to share my work history, both past and present? What is the motive behind this unfounded attack? This is why I call this toxic environment.

At the moment, despite being in beta, this appears to be a promising platform. The team has acknowledged and is actively addressing any bugs that arise. However, I am confused about the concept of "civility" when members are resorting to name-calling.

Can I be of any assistance to you?

Let's avoid name-calling and be respectful toward others. It might be helpful to take a break from the keyboard and remember to use good manners.

I acknowledge that there has been a significant miscommunication, and I apologize for any misunderstandings that may have occurred. While I am willing to provide any assistance I can based on my availability, I do not feel comfortable doing so in this toxic environment. I suggest communicating through a private message and continuing the conversation via private email if feasible.

I appreciate your insightful advice. Although Matt's work is appreciated, there are currently significant bugs that need to be addressed. I didn't mean to criticize his programming knowledge. I simply pointed out some bugs he may not have noticed and questioned how one can do their job with incorrect information. It's discouraging to witness individuals becoming upset simply for having discrepancies pointed out to them. And @btacon really it is not necessarily to behave like a child. I did not insult you.