That is just your opinion, in my opinion seeing the same coloured sunsets all over the world are “simulation breaking”. Also just because there are more serious issues (I agree with that) it doesn’t mean they cannot look to improving this feature, after all they’ve been adding features over certain bug fixes since day one so why change that working philosophy now?
As much as no doubt we all want the bigger bugs fixed, the simulation still needs to move forward with new features as well as improvements to current features.
That’s right, it’s my opinion. But you have to keep in mind that there are a not an endless amount of people working at Asobo, so you have to prioritize what is really important and what is not - and sorry, a minor graphical shortcoming is by far not as important as problems in the flight model.
Yes exactly, that’s why there will soon be MSFS 2024 and that’s where these things belong. Just like improvements of the flight model.
But this is also exponentially easier to do than fixing the flightmodel.
You always have to look at cost vs benefit. Here, the benefit seems pretty large, judging by both people’s reactions here an elsewhere on the internet. The cost seems pretty low, judging by the fact that it is literally modded right this second, you can find details elsewhere on the internet because we are not allowed to talk about it here.
And no, I’m sorry but I don’t buy the argument that to make it really accurate it impacts the whole rendering and whatever. Let’s say that’s true, we don’t need things to be perfect straight away.
Perfect is the enemy of good. Let us have good first. Updating these values is good. Worry about perfect for MSFS24.
It seems not to be that easy. The images and tests above show that there are still graphical oddities (e.g.: the excessive green tint, …) which can not be mitigated by the given parameters.
So the argument with the cost vs benefit might also be in question.
In general, you are maybe right, but in SW development you very often want to do things right the first way, otherwise you can easly end up with a SW patchwork unmaintainable → see current MSFS, hence we get MSFS 2024
So I’d like to see the perfect in MSFS 2024 and would like to not see folks of Asobo wasting time (they can spend better elswere) to shoehorning the thing into MSFS 2020 (even if it is work worth of just a few minutes )
They will have to support both products either way, or do you reckon they stop with 2020 sim updates until 24 is out? This won’t be perfect until it had been through beta testing, so better to release something sooner rather than later. People are anyway testing it out already, they are just not allowed to provide feedback here.
People working on graphics are not working on the flight model, IMO and according to the number of votes/posts here this feature request is very important to a lot of people
I assume both of you are not working in the field.
A 3D Engine is never the grafics alone, in fact the physics usually is very tight tied in - you do not have a grafics engine and a physics engine per se - you have a 3D engine handling both (and much much more … but this is as whole other topic).
So basically a 3D engine programmer can handle grafics stuff aswell as physics stuff. Only if it comes to very specifc things you need experts (which is of course true parts of the flight model, but not for everything).
But let me make it more generic: the engineer working on this is a resource costing some amount of mony when he is working on improving e.g. the athmospheric handling. This money then can not be spent on other more important stuff (there is also alot of this sort of stuff in the grafic part - only if you insist to keep the imaginary boundary between grafics and physics )
Even if it is the same component does not mean every resource can work on everything with the same speed and quality.
I know this wishfull thinking from management, but in reality you have individuals with different skills and if those with e.g. physics and lightning speciality are occupied by e.g. clouds, you won’t drag in some scenery caching fans to work on sky color. Simply because it would be inefficient.
This looks great! There are a lot of tweaks that could be done with the lighting engine, unfortunately for us VR flyers all these lovely cloud colors will be totally overexposed due to another problem, which is how metering is implemented. That bug here: https://forums.flightsimulator.com/t/implement-a-metering-system-better-suited-for-vr
You must be reading a different thread to me. The suggestion was made 3 weeks ago and Asobo have already logged and acknowledged it and told us there will be an update in the upcoming live dev Q&A. That may well be a record quick response, I really don’t know what else was expected? A hot fix pushed to all servers within 5 working days? Not realistic at all.
The only resistance I’ve seen here is from moderators against posts that talked about editing the binary executable and as someone who’s done that many times it’s clear that stance is 100% correct. Average users should not be anywhere near editing a binary image, it’s well outside the skillset of most people. Even editing an xml file is a struggle for a good number of users, the outcomes from incorrectly editing a binary are much worse.
Let’s give Asobo a reasonable chance to implement this before we start accusing them of ignoring it.
If it took five minutes to implement, or however long it took to do using the other method, I don’t see why it couldn’t be done sooner rather than later. Knowing how easy it was to do, whatever QA processes they would need to put it through would likely take longer than the actual implementation.
Without derailing this thread, I’m in agreement with you. I’ve made a few posts recently on a couple of issues that we might call “low hanging fruit” or QoL improvements that would be greatly beneficial that aren’t overly complex to implement or fix.
When looking at the bug report and/or wishlist “stack” one has to prioritize what the potential resource and risk impact of implementing/fixing the various items listed.
To me, a significant number of little issues cured/implemented would be of great benefit than just hyper focusing on one majorly complex issue.
Of course, others are absolutely in their right to disagree.
I know when many of us say an issue is an “easy fix” a number of people point out that software development is never easy and that we don’t really know how easy it would be.
These are true statements, but I will refer them to how quickly the fix and associated toggles were implemented in SU13 beta for the infamous “white dot” bug. Both the fix and the toggles work and didn’t break anything else in the process.
I’d think there are a significant number of other issues that could be handled in similar fashion if the powers that be just said, “please do so.”
When the Code of Conduct mentions ‘Sharing ways to alter the sims code or files’ this includes discussing or linking other sites showing how to do this. By mentioning these you are by definition ‘Sharing ways’!
Hopefully this will get brought up at the next Dev Q&A. It will be interesting to get Asobo’s take on this. At the very least it would be great to see it considered for MSFS2024.
I’m not sure when the next one is, but I rather feel these are going to get watered down content wise as we approach 2024, and development for 2020 slows.
)
)