Jump to content

TravelRunner404

Members
  • Posts

    412
  • Joined

  • Last visited

  • Donations

    0.00 USD 

Reputation

630 Excellent

Profile Information

  • Gender
    Male
  • Location
    Denver, CO USA

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Recent Profile Visitors

2,635 profile views
  1. My guess is that FSL is like a lot of these developers where it’s just a shop of one to three programmers with an idea and vision who manage a bunch of contractors and do most of the work on their own. The first plane is a labor of love and commitment. After that growing into a real business that can find a sustainable business plan to support growth or to level up is a coin toss. FSL probably got close to moving up bc of their success but never pushed to actually grow and likely mismanaged it. Eventually they regress back to three or four core programmers who finished out the Concorde but no real desire or acumen to manage growth so you get these slow two people not even full time development updates over years.
  2. Everything about the main thread limitation makes perfect sense to me (not a programmer though). However, do we think we will see less limitations with the mainthread in MSFS2024? Or will it be the same?
  3. I swear Asobo could release a patch that says, removed bold font from settings menu option and the thread will without hesitation include… Did anyone notice a reduction in cloud quality? DLSS seems worse! Noticing new stutters on final at <insert ICAO>. Followed by four pages of people not seeing it, another two pages of bickering over how to be happy and another four pages of people making statements about how their opinion matters. Anyway, update seems the same to me. No noticeable changes on PC for me.
  4. Seat movers aren’t bad. I used the NLR seat mover in VR for awhile and it adds to the immersion for sure. The downside is that your controls don’t move so it was always a little weird to bank right and be reaching left for your controls. However, you don’t need a lot of actual travel in the motion so once it’s dialed in you can trick your brain well enough. The other problem with the NLR seat mover was the price tag and that constant clicking and unclicking as you move around. Motion shouldn’t be as loud as that thing is for $3k USD.
  5. I haven’t tried the beta yet, and Matt was pretty clear that there is no change to aircraft like the PMDG737, however, I read this section above as a more accurate ground contact model was implemented and there is an additional soft ground collision model for tires that can be implemented. It seems like bullet point 1 is what people are seeing in the 737 and other aircraft and bullet point 2 is a level up from that. At least that’s how it reads to me.
  6. Yes, it is a little long, but I like to use scripts to automate some of the simple checklist items. When I land, or arrive at the gate, or before taxi, I like to focus on the big ticket items and have the little things automatically done for me. In general it works even if that's not what the script function is fully intended to do. Cockpit lights are a big one especially in VR. Most planes have quite a few light switches, so I use a script to dial in the exact settings I like. Simple push of a button and I have perfect cockpit lighting. Additionally, is there a way to suppress an axis based on a variable? This would be great for autothrottle in planes like the Maddog. I would love the ability to have the throttle axis only working when the autothrottle is turned off.
  7. I am trying to figure out the best way to complete multiple actions in a script before the next action happens. There are variable lengths for how long each action takes depending on the switch position. For example in the Leonardo MD82 I cannot simply set the light switches for instruments and flood lights to an LVAR and have the brightness level I want. The MD82 requires you send a number to a specific LVAR and a mouse click or wheel scroll happens in the cockpit. What I do is read the light switch LVAR. That tells me the position, say it reads 20. I then know the number of clicks in which direction I need to set the lights to the position I want, let's say 10 is the correct brightness. I have the script do some math and the LVAR moves by 2 for each click, so I know I need 5 clicks to the left. I use iterate in the script and it works perfectly. However, I don't know how many clicks I will need each time I run the script. The problem is that there are about 10 light switches in the cockpit. I run the calculation and if statement for each switch. However, the switches start iterating on top of each other. This eventually floods the cockpit and some of the clicks get lost. Is it possible to have the script wait until the iterations are done before moving to the next script? I can use (WAIT:xxx) and guess the number of ms but it's dynamic how long each switch takes. I tried the loop function but that is very slow. See below for how I have it set up now. Each one on their own works great. However, they start to flood and work over the top of each other. 10·(L:CM1_panel_light_knob1,·Number)·-·2·div·sp0· l0·0·<=·if{·l0·-1·*·iterate{·8192·10·+·(>L:CM1_lateral_event,number)·(WAIT:250)·}next·}· els{·l0·iterate{·16384·10·+·(>L:CM1_lateral_event,number)·(WAIT:250)·}next·}· (WAIT:250)· 4·(L:CM1_panel_flood_knob2,·number)·-·2·div·sp1· l1·0·<=·if{·l1·-1·*·iterate{·8192·13·+·(>L:CM1_lateral_event,number)·(WAIT:200)·}next·}· els{·l1·iterate{·16384·13·+·(>L:CM1_lateral_event,number)·(WAIT:200)·}next·}· (WAIT:250)· 2·(L:CM1_panel_flood_knob1,·number)·-·2·div·sp2· l2·0·<=·if{·l2·-1·*·iterate{·8192·12·+·(>L:CM1_lateral_event,number)·(WAIT:200)·}next·}· els{·l2·iterate{·16384·12·+·(>L:CM1_lateral_event,number)·(WAIT:200)·}next·}· (WAIT:250)· 10·(L:center_panel_light_knob1,·number)·-·2·div·sp3· l3·0·<=·if{·l3·-1·*·iterate{·8192·34·+·(>L:radio_event,number)·(WAIT:200)·}next·}· els{·l3·iterate{·16384·34·+·(>L:radio_event,number)·(WAIT:200)·}next·}· (WAIT:250)· 6·(L:center_panel_light_knob2,·number)·-·2·div·sp4· l4·0·<=·if{·l4·-1·*·iterate{·8192·35·+·(>L:radio_event,number)·(WAIT:200)·}next·}· els{·l4·iterate{·16384·35·+·(>L:radio_event,number)·(WAIT:200)·}next·}· (WAIT:250)· 4·(L:center_flood_light_knob1,·number)·-·2·div·sp5· l5·0·<=·if{·l5·-1·*·iterate{·8192·37·+·(>L:radio_event,number)·(WAIT:200)·}next·}· els{·l5·iterate{·16384·37·+·(>L:radio_event,number)·(WAIT:200)·}next·}· (WAIT:250)· 90·(L:fgcp_light_knob1,·number)·-·2·div·sp6· l6·0·<=·if{·l6·-1·*·iterate{·16384·20·+·(>L:fgcp_event,number)·(WAIT:200)·}next·}· els{·l6·iterate{·8192·20·+·(>L:fgcp_event,number)·(WAIT:200)·}next·}· (WAIT:250)· 40·(L:fgcp_light_knob2,·number)·-·2·div·sp7· l7·0·<=·if{·l7·-1·*·iterate{·16384·21·+·(>L:fgcp_event,number)·(WAIT:200)·}next·}· els{·l7·iterate{·8192·21·+·(>L:fgcp_event,number)·(WAIT:200)·}next·}· (WAIT:250)· 10·(L:ovhd_panel_light_knob1,·number)·-·2·div·sp8· l8·0·<=·if{·l8·-1·*·iterate{·8192·78·+·(>L:overhead_event,number)·(WAIT:200)·}next·}· els{·l8·iterate{·16384·78·+·(>L:overhead_event,number)·(WAIT:200)·}next·}· (WAIT:250)· 4·(L:ovhd_flood_light_knob1,·number)·-·2·div·sp9· l9·0·<=·if{·l9·-1·*·iterate{·8192·79·+·(>L:overhead_event,number)·(WAIT:200)·}next·}· els{·l9·iterate{·16384·79·+·(>L:overhead_event,number)·(WAIT:200)·}next·}· (WAIT:250)· (L:ovhd_pull_dim_switch1,·number)·0·==·if{·536870912·66·+·(>L:overhead_event,number)·}
  8. This is awesome. As someone who switches back and forth in VR I love it. 1. Each time I want to use a different plane, i.e. profile, do I need to go in and generate new buttons? Or can I have a different webFIP for each? And have it load with the specific plane? 2. Trying to get it to a decent size in VR required me to about scroll my finger off. Is there a way to set the size easier? 3. Adding one more thing…the images don’t seem to appear after I exit, come back and restart the computer. The gauges seem to work but the buttons don’t. I have to exit everything and generate again for it all to appear. Again…I think this is great.
  9. They are increasing the DLSS image quality, not reducing it. There is a gap between DLSS Quality Setting and full TAA where some people can find a sweet spot that improves their displays. Not everyone is CPU limited. 4k with less than a 3080 can easily be GPU limited for a GA flyer. VR is GPU limited for most people. The 5800x3D easily hits 60 FPS in everything but the Fenix at most non large airports, but the GPU if it's not a 4090 can limit you around 50 FPS in regional airports. DLSS Quality can lock at 60 FPS in those situations but the aircraft displays suffer. You have too much head room with DLSS quality and this hack allows you to create a setting between DLSS quality and full TAA.
  10. The way I understand it... DLSS renders at a lower resolution, that means GPU do less work. GPU create more frames. Quality DLSS setting is 67% and Performance setting is 50% of your monitor's original resolution. DLSS renders at this lower resolution which is easier on the GPU. DLSS adds some pixels based on an algorithm, which in turn makes the displayed image look more like 100% resolution. Cool. That's DLSS. 67% of your pixels at Quality setting are rendered by the GPU and 33% are added with the algorithm. There is a gap between 67% and 100%. If you want to slide an extra setting in there you can hack it by increasing the SecondarySacling. This is no different then that TAA slider where you can render at 200% (or 2.0 secondary scaling). If you up your scaling by 50% your base resolution is now higher. DLSS takes 67% of that new base resolution and does DLSS things. However, you effectively created a DLSS setting we can call Quality++ which is say 85% of your monitors resolution. Therefore your avionics are now 18% sharper and you are still rendering 15% less so you get some performance. You upped the DLSS percentage, thus you are rendering at a higher resolution but adding less DLSS AI pixels.
  11. All this is doing is rendering at a higher resolution. You won’t get the DLSS benefits for performance but if you prefer the AA and lower shimmering then you can do this. If you open the developer mode you’ll quite clearly see that the 2.000 scaler just doubled the resolution. Your instruments look better because the base image resolution is double but you are losing some of the performance of DLSS. In SU11 you can choose DLSS with DLAA so it won’t render at a lower resolution but your FPS won’t improve like they do with DLSS-Performance. The instruments will look like they do at full resolution because they are full resolution.
  12. For what it’s worth I swapped a 5900x for a 5800x3d and it was absolutely 10-15 FPS better. All I did was take the CPUs and swap them in my system. I had a 3090 in the case and did my tests at Ultra 200/200. Naked sim, except for a few airport add ons and WT G1000. All marketplace installs. I posted my results in a couple places. I was in it for one thing and one thing only…MSFS performance. Worked for that but my understanding is that for general productivity it might not be the best. I am tempted to see if it holds up in DX12 with the better multi core optimization, but swapping CPUs is a bit of a chore for me since I don’t have a test bench or anything.
  13. All of the testing I did and listed was in 4k with a 3090. The Mainthread was on average 20ms for the 5900x in developer mode and with the 5800x3d it dropped to 14-15 ms. I saw 10+ FPS in pretty much every scenario on the ground. However, it doesn’t lock a perfect 60 so panning left and right will do the same drop and increase. If you lock it at 30 FPS it’s just straight green in that developer window with the occasional yellow from the GPU. If you plan on loading up track ir and having a Tom Cruise in a dog fight seizure of left to right movements with your head i doubt it will be perfectly smooth unlocked from a sync’d fps.
  14. In VR my GPU is 99% on the Varro Aero and I max out at 35 FPS usually with some help from open XR toolkit.
  15. I flew the PMDG DC6 and performance is still noticeably better with 60 FPS VSYNC, but I didn't take stats. The thing is without being able to truly hit 60 FPS the swings are still there. It's pretty much an additional 10-15 FPS clearance. I am sure if I left the 200/200 Ultra settings as is, used my parked planes only settings, I could probably never find a scenario where I am under 30 FPS. So smooth all the time all over the world with 30 FPS VSYNC. That's good enough for my 3-5 hours a week of simming. But with the 5900x that drop below rwasn't really happening either because the clearance was also enough. The big benefit for me is getting the processor out of the way for VR. The extra 10-15 FPS is just enough to leave me consistently maxed on GPU, which is usually 35 FPS or so. But honestly, the 12900k level, the 5900x, etc. should be enough unless someone wants to die on that hill that a fluctuating FPS between 40-55 is better, and in that scenario, the 5800x3D I think will be noticeably better.
×
×
  • Create New...