No changes ? Nowhere in the network protocol ? I wonder how you know that. I think this is a very simplified version of what’s happening. There are thousands of users online together every day. Sometimes flying together. Suppose MS buys some protocol from Bing and they change that. Can Microsoft impose on Bing that they should support both protocols ? Or three ? or four ?
It is very early for version splits. Too much is still changing, and because of that, the “client callers” should have all the same version. You can’t test version on every packet, that would slow down server side. Also, server side would need to be split in two versions that should BOTH be maintained.
This is a reasonable question… be able to roll back an update that goes wrong. But ask again in a year. Maybe it is too early at this stage to (technically) do this.
The client only needs to be checked once it connects. They can then decide what features are accessible from that point on. No need to check every packet.
You don’t need to maintain two version of the server either, but they would need to allow available services on the servers to be applicable depending on your client version. Just like the planes we have updates for are gated behind a soon to be released client update, if there were a technical reason why a given feature required an up to date client, you make that feature unavailable for those running an earlier release.
This would simplify Zendesk tickets no end. You simply instruct any one logging tickets for an older sim version to update to the latest client, then close the ticket.
Checked once ? Also when the client chooses to run without cache ? Have you ever tried… have you monitored the communitation ? Also in flight ? I wonder (again) how forum members here know so much about the technical details… This week someone opened a topic with a statement about programmers at Asobo not knowing their own source codes. As though this “beta tester” did know far more about these sources. Same with communication protocol and file formats. We don’t know, if a texture format detail is changed, every texture file is updated and you get something like WU3. Gigabytes of data. Now suppose SOME users would NOT do that update… are Microsoft and 4 other companies supposed to keep delivering this small base, afraid of updates, all the old textures, maintain the old database ? Should every third party developer take into account and deliver 2 sets of files ? or 15 sets of the protocol ? I don’t think they will do that.
Simply because the kinds of data doesn’t change really. It just more detailed textures, some new objects etc. But there is no reason to think they rework the whole protocol every time which would make version handling impossible.
MS owns Bing, no need to buy. MSFS doesn’t stream directly from Bing, but has it’s own pre-rendered data in the Cloud (which is what Blackshark etc. is needed for).
Version splits? I’m pretty sure they already do that since they need their own QA to be able to test. It might be a bit quirky, so not polished enough of a process to release to end users, but still there has to be already a versioning in the API that MSFS uses against the cloud.
Basically versioning an API is the FIRST thing you define if you’re doing it right, knowing that you will never be able to ensure that only one specific version is used for all clients.
How long have they been developing the sim already? Such questions really can’t be raised early enough. The later you try to implement such things, the more work it will be.
And as I said, I’m pretty sure they have already versioning in place.
My guess is that the issues are more organisational - how long do you make a beta phase in order to collect feedback, implement fixes etc? How will you be able to make a 1-2 month release cycle if you need a beta which is at least a week long followed by iterations to fix found issues.
These organisational questions are sometimes harder to solve than the technical implementation.
That’s not the point of this thread. It is about a BETA which means users will have temporarily access to one later version until it is rolled out to everyone (mandatory). No need to maintain old databases.
Check once the client connects to the network initially, then disable features on the client side. You wouldn’t need to keep checking every single time the client talks to the servers to see whether it is able to support such a thing. You turn it off on the client side. Why allow traffic out that isn’t going to be supported anyway?
How do you know that. Q: have you studied the BGL file format ? DDS ? GLB ? I did. Because I wanted to know what went wrong after WU3 with some of my favorite community addons.
That does not mean they want extra overhead costs and performance penalty. Don’t forget these BGL-files should be handled dynamically on your PC too… while flying. Complaints about FpS ? go elsewhere
No they don’t. When there is an update it is obligatory. For some of us that is frustrating, but I think that is unavoidable, when you look at the size and complexity of this product. Large parts of the world are on your PC.
Aren’t the in-house beta channels version splits? We all saw that Steam “leak” the other day that showed a hotfix was undergoing testing. I didn’t have that installed yesterday. Did you?
There are. And some 3rd party developers seem already to get access to them as well as it was reported prior SU3.
I’m out here. Working almost my whole life with client-backend and cloud services with various versions in the field, I’m surely not the right one to make assumptions
Depends on the change and the persistence of your connection. When a user connects, that is a TCP connection not guaranteed to maintain in open state. Bing will provide elevation data, programmetry will put things on the proper height. Both are dynamic and both need to run during the flight, when you have Bing and programmetry switched on. Most players have. And protocol is not the only thing to worry about. You will need multiple versions of databases, which is cost and eliminates bandwidth optimizations. Complaints about FpS ? Hickups ? Go to the other topic…
So some of you are saying that this is not doable.
I have no technical knowledge whatsoever but lets say that a new sim/world update is out and I dont want to update since I have the option not to…
I have my data on so I get the following data: weather information, scenery data , photogrammetry and multiplayer.
-Why weather data should be different between the updated version and the old one?
-Scenery data. UK was updated for instance and I choose not to proceed with the update. I quess I am going to be warned that I will not get any data for this particular region and I will have only default data as If I was flying without internet on.
Photogrammetry as well …if something is changed or added during the update I would not get it or I would just have the procedural data.
Multiplayer… I wouldn’t be able to connect with people and friends who have a different version than mine…
As for the changes in the core sim , airplane improvements etc i would just stick with the ones I have.
All I am thinking is that they could say that for all the new changes that come with the new update you wouldnt get any data from their servers.
Beta channels… suppose there are setups for testing things and comparing behaviours between versions, but again… we don’t know that and we don’t know anything about the infrastructure used for that. This is a multi million dollar project. You can try to rewrite the specification, but in the end… you’ll need to comply to THE protocol that is used. If you don’t do that, and change things you need to fork actions for different versions. At this stage they don’t want to do that and I understand. As a software professional I do. This program is still version 1.1 actually. In the methods and versioning I use, anything below a version 2.0 can change on any level. I would say wait for version 2.0 and put the request for optional updates again. Maybe they will allow it somewhere in 2022. But… we don’t know.
NOBODY, literally nobody here in the thread is asking for that. Don’t create strawman arguments please.
We’re talking about a Beta, which is a totally manageable thing. And as a “software professional” (whoever that might be) you should know that.
The fact that they already are doing it in a limited circle just proves my point.
And version numbers are just that - numbers. They by no means mean anything. You could even start from 100 and count backwards if you want.
So if they are doing it for the 3rd party developers , its perfectly doable…
Do the numbers really matter? I mean does it matter if you are doing this for 100 developers or for 2 million customers who dont or do want to update?
The issue is definitely that the Beta for third parties is not done to collect feedback but to allow them to adjust their addons to the new release. So the focus is different than in a public or closed beta test version.
Further the more people you have trying a Beta, the more you need to take care of how and when to gather feedback and how to react on it. You have to be very efficient with how you organize the feedback as it otherwise will get overwhelming very quickly.
These are the organisational issues I talked about earlier and they might by far be more complex to handle. Releasing a version with issues that people reported during the beta phase might end up being even worse for the public sentiment than releasing them without a beta.
The numbers may not matter, but the purpose would. The Beta should only be for those who actually wish to do Beta testing, to improve the product, and ensure that any future release benefits from the findings of that Beta. At some point that Beta would be withdrawn, and you would have to revert to the normal release channel. It shouldn’t be seen as a way of squatting on an old version.
The Beta may also be narrow in scope, and new features or bug fixes would be listed so that you know what to concentrate on.
So I quess that this is not so much of a technical issue but of a practical as well.
But lets say that these updates would not be considered as betas but as optional final updates. The people who install them ,may or may not find any bugs inside. And thank God we have a forum to talk and interact with each other and I as a user decide to install it or not depending on the feedback.
On the developers side they will do the same thing as they do now, again depending on the feedback they will get, they will try to fix the bugs etc, but the difference is that the user will have the option to roll back to the version that worked best for him.
“Please” ? Don’t pretend to be polite when your not. I’m not talking what people ask. And I don’t pretend to know Asobo/MS internals… I’ve some experience distributing client server software, that’s all… Multiple versions are not handy if they are all connected to YOUR server. In the MSFS case, you’re connected to servers of 2-3 partners as well. You think that Bing would worry about MSFS2020 versions ? MS/Asobo are their customer, they pay for it… and you don’t. You pay only once and expect all options. Update and freeze.
All these “beta’s” of yours can be refused by paying customers. If you refuse an optional update (not take the beta), you are still entitled to support. As a result, they would have to support all these versions in parallel. Suppose you have 5 versions in november 2021… not handy…
Would you please provide some proof for that… where’s your link that allows me to sign in and participate in that program NOW ? I’d be eager to do so.
