sadly it reflects the state of the world.. turning upside down. Thanks for checking and posting. Letās keep hoping for improvement (in both the sim and the world).
Itās a real shame more people arenāt up voting the bug but maybe that means there are only a few of us impacted by this. My key concern is that they introduced this when optimising the code and ādonāt want to go thereā in code that is fundamental to performance and they made shortcuts that they donāt want to undo. But that is pure conjecture. Maybe theyāre just busy
Yeah i think they have problems with the legacy FSX code.
Development seems very slow too compared to most other much smaller developing companies. There are no frequent bug fixing patches released. Normally they should be able to fix a lot of the small bugs within a week after they release a sim update, like most companies do.
Itās not their code and some of it is 30 years old. That makes it very hard to overhaul parts of the sim.
Hopefully things will go faster as they fix the old code.
I agree it should be fixed but without any indication from anywhere when it will be fixed, I will continue to use RESET DRONE ROLL mapped to a button to enjoy using the drone camera.
WU8 1.24.5.0 ⦠ok, it is a World Update only ⦠still rolls the cam to the left.
I watched the official Xbox trailer and there are (again) many parts of the video where the cam roll effect did manifest itself.
It would be interesting to learn if the art director(s) for those movies have also noticed this bug ⦠or if (too many) people by now assume ⦠āthat is just the way it is ⦠there must be a good reason for that rollin-left-thingyā
So the next stop on this journey will be ⦠SU #9
I think they are too busy introducing new bugs to fix old ones. Honestly, have they never heard of regression testing? Iām sure Iāll be shot down by people for being overly critical and mean but Asobo need to āget a gripā of their software testing and release procedures. The worry is that they donāt seem to be getting it. Come on Asobo, get control of your software, take your time, do lots of testing and fixing, I think most people would be happy with less frequent, more stable releases, not new features - and new bugs - so often. You have a great vision for the product, but donāt rush so much - you just end up taking away from all the hard work of your talented staff with stupid bugs slipping through all the time.
āMove fast and break thingsā seems to sadly have become the ānew normalā in the industry.
However, in this case I guess I would disagree with you @WebSanity that automated testing would be the answer. This bug (and many others) is in essence a āUIā bugs ⦠and those are always hard to detect in an automated (end-to-end) way ⦠especially when other subsystems (e.g. DX11/12 and GPU drivers etc.) are involved too.
But I would strongly agree with your second point about prioritizing bug fixes over feature additions ⦠especially when it is about core aspects of the engine.
While I do like the āvoteā mechanism I am often puzzled by the aspects (bugs) which the crowd is voting up and which Asobo then seems to focus on.
This cam roll bug is literally āin the faceā of everybody who dares to leaf the cockpit. It is now āaliveā for almost an entire year. Asobo pre-load landscapes and promo videos are full of ācam roll bugā manifestations. It makes me wonder if most people just assume that this is ānormalā.
In essence it seems to be a trivial (classical) 3D matrix cam position issue.
A fix should be really trivial because the āreset cam rollā command works perfectly fine ⦠and so the system knows what a proper horizontal cam position is ⦠and then one simply needs to maintain a separate 3D matrix to track the cams roll-pitch-yaw and prior to rendering each frame the cams view could be recomputed properly by base position plus view direction matrix.
I still think the āregressionā bug is an accumulation of floating point rounding errors ⦠and it got worse then the performance improvements have been introduced (I feel like the bug was always there, but far less visible ⦠so who knows maybe the moved from float64 to float32 ⦠or float16). It seems to me like the fundamentally incorrect cam calculation was there from the very first release.
But then ⦠I am just a goose ⦠that likes to fly around the globe ⦠and I am a happy goose.
Evening my winged friend. Not suggesting automated testing, which as you say wonāt achieve much. What I call regression testing is a mix of a standard sets of tests to run before all releases (which surely Asobo will have) mixed with a carefully chosen set of tests planned and setup after each development to test specific areas that have been worked on and might be impacted by something. Obviously the latter can miss something unexpectedly impacted by an update that you had made, but it helps silly mistakes creeping in.
Something as simple as ātest to make sure the drone works for the external view worksā in my mind should probably me on the former list for every single release. along with a hugely long list of other things!)
The fact that this bug is so obvious to some people and itās appearance after optimisation (or it becoming far stronger as you ponder) makes me wonder if it was a āsacrificeā that was known about but which allows big optimisations elsewhere and has a high effort to get working properly again without losing optimisations, which means it isnāt āhead of the queueā to fix. That is PURE speculation; but if so that would mean that Asbo didnāt just make a glaring error, which I would hope to believe was the case.
Letās just hope they can sort it before we get addicted to it