Yes, without any meaningful documentation, we are left to guess at how things are supposed to work.
This is especially an issue with many of the available controls where the description is merely a repeat of the command name. And quite a few of them appear to be slightly renamed duplications and I have no idea what differentiates them. How hard would it be to publish a meaningful list of what all these commands do. It has to exist somewhere.
Aviation and aviation-adjacent studies are already extremely complex. It takes hours and hours of training, education, and, realistically, evaluation for people to come away with a solid understanding - and even then, it’s usually limited to the types of flying you are doing.
Then you have a sim that attempts to interface with all things aviation, so complex already, but made moreso by the fact it simply can’t do everything 1:1. So it stands to reason that various elements of the sim are designed with one of three intents - the direct emulation of reality (such as moving a yoke moves the ailerons), a workaround (like pushing a key moves the trim wheel in x units), or it’s completely going its own way in a manner that may or may not be clear.
The problem is we don’t know which is which. We can deduce in many cases, but we simply don’t know what they’re trying to do in most others. And when the latter is the case, is it a software limitation, a resource limitation, or is it an intentional implementation completely misapplied/misunderstood by either party? As you say, lack of documentation and communication is the crux of the frustration.
If something were to say “this is how we intended it to work,” we could give much better feedback as to whether or not it’s doing what they intend or whether it’s outright wrong (for example, increasing the altimeter setting in the Kollsman window decreasing the indicated altitude on the altimeter). So again, we don’t even know if it’s oversight or intent - it’s basically Schrodinger’s bug, and that’s a big problem.
Yesterday I gave it a go in my curiosity to land in AP mode in LPFR with beautiful clear skies at day time.
Well my plane landed right in the water at the side of the airport in the ocean.
At least still up in the right position.
Next time I should better give it a try with a Seaplane on LPFR with AP.
Also, from the ground up to the air I seen several times that I just stopped against a wall. There was some bug in the throttle. It looked like an noise dosimeter.
Certainly, I am already done with any AP, also in flight, I might go right on the ground vertically full down unexpectedly.
That is one of things that always bothered me, no list, only after something gets fixed, it is in notes.
We are not able to force/change anything, it is just how that business operates.
All we can do is wait and hope for the best, right?
It remembers me this experience in MSFS with my mayor brand shiny motorbike brand new out of the shop.
2miles out in direction home, I had luckily a mobil phone in my pocket on a sunshiny Saturday with a full tank.
It stopped.
I went home with a taxi.
Yeah, I am about ready to sign off on this waste of time. It is just too frustrating to use the simulation as is. I ran another flight in 2024 and the 787 and it ran OK, just slow on landing and I know that people with better boards than I have the same problem, but heck I have a 8GB board and it cannot run a standard airliner correctly?
About to put the controller on the shelf.
It is so shortsighted to be less than correct about the ads and have tons of disappointed users telling their stories. We have to use Windows, but not this software.
As I have said, I used to do this professionally and I never put more into the code than the hardware could run comfortably. I ran a research simulator for over 20 years and you had to have immersion… so I backed off the details until it ran fast and the pilots were happy. Give a pilot a bunch of stutters and they are outta there.
Hello, I’m new on these forums and after quick search I’m still bit confused and am wondering if I should report bug via Zendesk or rather here on forums. Thank you
Please submit bug reports to the appropriate subsection of the Bug Reporting Hub subforum. When submitting a bug, please be sure to fully complete the bug report template.
Obviously what the interviewer was asking was “at what point do you triage what’s left and decide it’s time to ship anyway”. Though “acceptable bugs” is an oxymoron, it’s also important to recognize that a development effort can’t go on forever - and at some point you have to decide if the color of the user’s mouse pointer being the wrong shade of pink is worth holding up a release for.
However, when I attempted to rephrase the question as “at what point is it acceptable to stop and release, even though there might be some bugs left?”, the interviewer refused so I decided that this wasn’t the job for me.
Perhaps I’m being idealistic, but - IMHO - the job of software QA, (and especially that of the senior QA engineer/analyst), is to be both the standard-bearer of corporate quality and integrity AND help the development team avoid creating bugs in the first place. (A lot of my job was attending developer code and design reviews, pointing out things that would get them in trouble later on.)
I would beg to suggest that there needs to be a critical review of MSobo’s software quality culture and policies as the current software’s release is obviously lacking and they way they’re handling bugs is equally unacceptable.