Jump to content

Aamir

Commercial Member
  • Content Count

    1,282
  • Donations

    $0.00 
  • Joined

  • Last visited

Everything posted by Aamir

  1. I think you'd be surprised how quickly an A320 can stop IRL with max manual and a light load.
  2. I can tell ya this much - circuit breakers are infinitely more complex to add than an interactive checklist. The latter can be accomplished in about a week. The former, probably 3-6 months depending on how much inherent complexity the aircraft already has. If background system logic is "simplified" then add rewriting all that code on top so it actually functions correctly, which takes you into the "years" side of things.
  3. Please bear in mind all I said was "appropriately gusty" - in this case I mean severely gusty, something I imagine in the real world you will encounter probably a handful of times over your entire career. This, for obvious reasons, can happen more often in MSFS than the norm.
  4. Correct, there is one exception you can observe on the Fenix as well - which is when the conditions are appropriately gusty and the ATHR is oscillating a lot attempting to keep VApp. Then the recommended course of action is to disconnect ATHR and handle it yourself.
  5. A support ticket with a general description as above and your logs attached is a good place to start - but I would also give it a go with display sync ticked off. Display sync doesn't play nice with RivaTuner, MSI Afterburner, or Frame Gen mods - so eliminating those is also a good place to start if you do really want to use it.
  6. Have you sent in a support ticket?
  7. We've seen a lot of speculation around the textures being the 'culprit' for bad performance since Block 2; so far our investigation has found several code-side items leading to poor performance on some systems, which we be doing our best to address. On the other hand, we've yet to find a scenario where lowering our already very low texture memory usage makes a measurable impact for any of those reporting lower performance than Block 1. To this end here's some hard numbers to help visualise just how efficient Block 2 is in terms of resources: PMDG's 737 has 421 cockpit textures totalling 709MB, of those 4 are 4k. Fenix A320 has 142 cockpit textures totalling 271MB, of those 4 are 4k. To put the above into perspective, the default A320 NEO as shipped uses 235MB of textures for the cockpit - we're using just 36MB more. In fact, Block 2 actually falls within the stringent memory requirements to be shipped on XBOX if we so wished. Beyond textures, our drawcalls are significantly reduced compared to Block 1, and in-line with other aircraft even though we have a significant amount of extra interactive items such as nearly 300 circuit breakers. Our cockpit is a little under 4000 drawcalls 'at scene' compared to the 737 which has about 3700 'at scene' - there's not much in it. When you get towards CPU-intensive aspects of the art like bone animations, we're also doing pretty well here, using 238 bones to the 737's 396. Ultimately, numbers are meaningless if the performance isn't there, but I wanted to clear up any misconceptions that we've just "thrown more polygons and textures" at the A320 for Block 2 - the reality is in almost every measurable way we've done the opposite, and utilised some seriously innovative tech to bring that level of visual quality whilst keeping within the aforementioned XBOX budget. Beyond the bigger code-side performance bugs, we're continuing to investigate every aspect of the product to make little nip and tucks to eek out as much performance as we can across a variety of systems.
  8. Brakes are particularly interesting to me. I worked out that someone would need to do 7 landings per day, for 365 days straight - before the brakes need to be replaced - that context makes me think of implementing these things.. differently 😃 Or, alternatively, someone doing 1 landing per day would wait 7 years before replacing the brakes, provided they never missed a single day in those 7 years. Either/or.
  9. Planning on this and more - but it's a long term plan and with some other spice thrown in. With that being said, no promises as usual 🙂
  10. Ehhhhh I'm not so convinced on this being the value add most seem to think - I like the general concept, but we've sort of done it in our own way. My viewpoint on this is that - realistically speaking, a line pilot and aircraft aren't going to "meet" very often. As a line pilot when you're done with the day's sectors you'll come back to another aircraft in the morning, at least in the case of short-haul aircraft like the A320. This aircraft is going to be in a "flyable" state by the time you get to it, i.e Oil is not low, tyres are "OK", so on so forth. What we've done is add some "persistence" in a way that aligns with the realistic use case of the airplane. So you come to the aircraft each initialisation with randomised engine oil, brake mass, so on so forth. These will get "used up" as you go on. If you're lucky your oil levels are good on start, and things are OK if you fly 2-3 sectors. If you're unlucky your oil is low and you'll need to call maint to sort it when you land on one of your sectors, or on a turnaround somewhere. For most other areas the failure system is MTBF - so it will fail "realistically", randomly. Obviously the aircraft are quite robust and reasonbly reliable - so it's rare, but definitely not impossible to have something or the other break. The combination of both of these things, I feel, gives you the best representation of the line pilot/aircraft experience in terms of "stuff to watch out for".
  11. I think this is now fixed - at least in scenarios like this - will roll out with the next update over the coming days.
  12. So, here's an interesting tidbit from debugging this with some users in Discord. Give this a go - if you've disabled any audio devices in your Windows audio settings, go ahead and renable everything - you don't need to change anything besides renabling them - let me know if they start playing? Autobrake on the Airbus targets a deceleration rate - not a fixed pressure. It will vary braking to achieve this. If you use reversers, it will simply use less brake pressure - net result is the same assuming you land on the exact same spot. You can check this in the landing app where you see a very marginal decrease in braking distance with reverse applied. EDIT: Just checked and I believe Boeings do the same thing re deceleration rate, so in theory on both you should see little to no difference with rev on/off.
  13. Thanks 🙂 Just the mod, FG in sim is ok.
  14. We are tracking the performance issues and sent out some builds to affected users earlier today to assess which direction we need to go. Will push this through ASAP for those of you that are suffering from degredation - but I will also caution this may not be a magic fix for every single configuration and setup - but we're actively taking in various reports and acting on them, so if the next version doesn't quite do it - keep us in the loop and we'll keep working on it. We're using some state-of-the-art modelling techniques to increase visual quality without increasing memory usage or drawcalls, but as we're the only ones really utilising these aspects of the SDK, there's a lot of 'first time' discoveries being made about the effect on some systems. With time we will improve it.
  15. Thing is, if this isn't running your EFB is likely cooked too. So something weird is going on. We're looking into it though.
  16. Hm, weird one - but I know Ben from our team who is responsible is tracking and attempting to fix these issues. I'll double check with him. The spawn issue we know about, trying to recreate and fix but it's a slippery one. DEST data is a correct prompt, I'm guessing you've uplinked your winds and not overwritten the already inserted wind data in the APPR page - it's reminding you to update the wind with an actual entry as opposed to an uplinked one.
  17. We changed the default render method to the "most performant" on an average of PCs - but there are always cases where it doesn't work as well - so your old settings aren't applied. You'll have to reset them if you want them. For example, it can crash if you use MSI afterburner - I can't tell yet what causes it but I know it does cause crashing. As does RivaTuner. Both of these do not play nicely with DisplaySync. The frame-gen mod is also breaking it. Not sure how, again.
  18. Try disabling display sync as an option in the Fenix App, and select Alternate Renderer.
  19. Do me a favor and DM me the ticket number, I'll look into this personally for you.
  20. Did you turn on automatic crash reporting?
  21. Okay, first recommendation I have - uninstall the product, reinstall it with defender turned off - it can sometimes just outright delete files and do some generally odd things. Then add exceptions for the Fenix folders and try again. There's a how-to here: https://kb.fenixsim.com/efb-showing-as-blank The other thing to do is use the Alternative renderer. I'd start there before I mess with Defender.
  22. Do you have an anti-virus or something like that running? Windows defender, even.
  23. A couple of things to try - untick Display Sync and tick "Alternate Renderer" - failing that a set of log files and a support ticket would be the next go-to.
  24. Hey! This sounds like something we got a good chance of solving, but only with your help - these crashes are quite sporadic and getting logs from someone is always valuable in figuring out how to fix it. If possible, could you send your logs in so we can take a look at fixing this for you? Thanks!
×
×
  • Create New...