This should have no impact on career mode though. At least if you select your base on any default airport without addons.
A ton of my liveries from 2020 are not appearing in the configure screen on an airplane on 2024. Despite me manually looking at the ported content and I see liveries listed. Uggg. Very incomplete and tedious to manually track and compare.
Wonder if it’s part of the whole streaming debacle. Just let us download the game locally if we want! It’s our problem or choice or benefit to figure out our storage options. Streaming is a poor idea
I have now installed 2024 on two PCs. No way I’m going back to 2020. The world looks spectacular in 2024 and the default aircraft that I have flown so far are very good.
Anyone know how to zoom in and out of the vfr moving map?
Any busy metro area or custom scenery is a guaranteed CTD on series S if you fly a larger plane. On a good small plane like the Optica or the Draco the sim does a much better job
Flying over Chicago and all I see is white/ gray buildings. LOD is terrible. textures take ages to load
How long is your actual loading time after selecting a mission? For me it’s usually long at the moment ( at least 15 min ).
Xbox Series X - UK 70mb connection
Last night I set a 50Gb rolling cache and turned off background updating of Xbox and games
Today I hopped into the A321LR and had a very enjoyable day of flying. Stutters here and there, especially in bad weather at Kastrup but otherwise it’s performing better than 2020 ever did
This evening it appears as though our 2020 addons that weren’t compatible have been set to “not installed” and I’m down to 1000 objects being loaded so may improve performance further
Pro tip - don’t press the end flight button. Always use exit to menu. Otherwise the sim will freeze and not log your flight
Sync your windows clock. Solved the loading times completely for me. 40 minutes+ to less than two…
Thanks, but that’s an heavy task for the Xbox
Ah, yes, but maybe not? Surely there’s a system clock that can be synced?
MSFS Minecraft Edition?
I have see the same tip (idea?) posted at the HeliSimmer site … and to some degree it does make (some) technical sense.
A common technique to judge remote requests it based on timestamps. One can (try to) detect if a message is too old and"outdated" … basically a form of timeout detection. Sometimes timestamps from “the future” are causing problems as well.
As a goose I personally consider “out of band” time-sync as a design flaw of protocols in distributed systems, because clock drift does happen … and there are obvious in-band timestamp techniques to mitigate (detect) such drift.
But well … the FS2024 API and servera are what they are today and nothing will change that quickly. So if there really are PCs out there which do not use NTP for automated timesync … give it a try. I actually would love to hear if that does make any difference (I somehow have my doubts).
This did the trick! To my surprise, my system clock was 4 minutes fast, even though it is set to sync automatically. I changed the time manually and the sim loaded in less than 2 minutes, for the first time ever. Nice!
Interesting!
So what was your launch experience before adjusting the clock?
I do find this a really interesting “scientific” experiment, and it is pretty easy to make. I will try to intentionally misalign my clock to see what the result will be. We might be able to “guess” what is going on inside that blackbox called FS2024 backend.
Works fine for alot of Xbox users. It’s a tiny download. Try the help desk you must have a separate issue there sir.
Allow me to ramble a little about the … time sync … topic which did come up recently.
I have not tried it myself yet (but I will … as it seems interesting) but here is an attempt (a hypothesis) to explain what might be happening.
If I assume a SIM to SIM backend setup like this:
- SIM opens keep-alive web-socket connections to the servers
- Looking at the TCP trace and the tech stack which the sim is using that seems like a plausible hypothesis.
- The web-socket is then used by some custom async JSON message protocol
- … where each message has a header with a timestamp based on the local PC clock
- The server then tries to prioritize the “important” messages
- … basically … sort the message queue not by “order of arrival” … but rather … “order to creation … based on the timestamp”.
- To judge how “old” a message is the server basically compares its clock to the message header timestamps based on a multitude (millions) of PC clocks.
- In some cases very old messages might get dropped
- … to prevent sending data which is no longer needed
- e.g. because one can assume that the aircraft has moved on to a new location.
So … if that is the logic … then in theory:
- clocks which are “in the future” should produce very long launch times
- clocks which are somewhat in the past should produce very fast launch times
- clocks which are too far in the past might also produce very long launch times.
Hmm … looks like an easy experiment.
PS: In a robust protocol the PC would not use “its clock” … but there would be a constant tracking of the servers timestamps and the PC would compute its delta to the server … and basically compute a “fake server clock” on the client side. That would be a in-band time sync … to avoid such problems.
UPDATE: The correct time zone would in this case matter a lot, because if the timestamps are based on UTC … and the PC is in the wrong TZ … then the timestamps will be many hours off the actual local time.
So I just did a quick first test:
- First run
- ensured proper time sync (which is automatic on my system … but it seems like Windows is still a little “lazy” in when it performs the automatic time sync)
- launched FS2024
- finished launch in around 4 minutes
- Second run
- intentionally moved my clock 2 hours into the future
- launched FS2024
- got stuck at “10% Activating packages” … for over 10 minutes
- killed FS2024
- Third run
- manual sync of the clock to proper time again
- launched FS2024
- finished launch in around 4 minutes … again
OK … I think the “evidence” is clear. If your clock is out of sync … you will have (lots?) of problems.
Now I do not want to sound disrespectful, FS2024 is such an amazing piece of software that I joyfully spend lots of my precious short goose life time with it, but if some of the server API actually really was designed with the assumption that every client will have a perfect local clock … then I would count that as a classical beginners mistake. I have see this so often “in the wild” that it is not even funny, and I would not be surprised.
But perhaps Asobo is even the victim in this case, because maybe that is a “feature” of some essential access control API which is provided by the Xbox ecosystem. Time will tell.
I am looking forward to the next dev stream.
UPDATE: Just to give proper credit … it looks like the first to recognize this issue was @BernardBx
MSFS2020 was sensitive to incorrect time sync too, its one of the things that can sometimes generate stuttering in flight.
How do you find the help desk? I’m new here and I don’t know my way around