Are you unzipping the same file - that is same download or did you download again?
I downloaded the file again from flightsim.to
So Iāve used the same file for both extractions (it was the file i downloaded from flightsim.to last week)
Iāve run a Powershell compare and a Beyond Compare Binary file check and there are no differences between the 7zip and Windows extracted files on my system.
Iām running the default Microsoft Defender in Win 11 pro.
Getting a bit confusing the threadā¦ But as I see you post above you did not have any issues either with neither of the filesā¦ If the two files are identical it would be logical that you have a correctly unzipped file.
Now, again we might have different issues for different users.
We know for sure that two users unzipped files and the whole effects library was missing; that happend for Knud and one more user. So the zip can be seriously damaged either in download or during unpacking. It is 10 Gb of contents.
Splitting up the file yesterday but also making a new download and unzip resolved most of the problem from Nbrich though one out of 16 test flights failed; but that was coming from a situation were nothing worked.
1 Like
Generally speaking a Zip file creation generates a CRC to compare against in unpack. In other words, if the file was damaged at rest (while on the download site) or in transit (during download), the Zip operation throws an error to that effect when unpacking/unzipping. So if you suspect a damaged file, it should be very obvious when unpacking it.
3 Likes
I posted this a while ago, but could it be an issue with ālong file namesā on some windows installations? I have ālong file namesā enabled on my system, but itās not enabled by default and most people donāt ever enable it. I wonder if the decompression utility skips files that have names/paths that are too long.
I know that with AIG, my installation directory is āC:\aig-aitraffic-oci-betaā. When it was in the community folder, I kept getting warnings about long file names.
Windows default, you canāt exceed MAX_PATH value (259 characters for files, 248 for folders). With long file names enabled, the limit is raised to 32,767 characters.
1 Like
I donāt think it is only GAIST that is being affected by changes that Asobo made to the sim startup procedures when they decided to incorporate marketing into the World map in SU8. Although GAIST seems the worst affected, possibly due to its size, I am also seeing problems with other apps and even core sim elements randomly failing to load fully or at all. There seems to be a timing problem or some kind of resource management issue during the startup phases of MSFS.
1 Like
I do not know if they got and eventually overlooked an error report.
Looking around there are many other reporting issues with or without addonsā¦ And while we definitely have some issues for some users with GAIST the number of error reports compared to the number of positive feedbacks and the number of downloads is very limited. And some of the error reports have been resolved, but still there is mystery issues out there and I would like to get them resolved.
1 Like
CasualClickForum Moderator Team
Generally speaking a Zip file creation generates a CRC to compare against in unpack. In other words, if the file was damaged at rest (while on the download site) or in transit (during download), the Zip operation throws an error to that effect when unpacking/unzipping. So if you suspect a damaged file, it should be very obvious when unpacking it.
I agree that a Cyclic Redundancy Check should and would throw out an error in any good unzip process. Which would include long file names.
1 Like
And now itās working for me. I didnāt do anything really except using Addon Linker, de-select the GAIST older version 2. Then selected GAIST Beta. Everything is working now. No CTD after several flights.
So thatās strange. But Iām happy for now.
Of course I type this now and the next time I start up the sim, itāll CTD. Right?
Brad
EDIT: After being able to complete one flight, I tried to exit the flight by returning to the main menu, and CTD. I re-booted the PC, started up the simulator again. Trying a new flight, select āFlyā, CTD. Back to square one again.
I would suggest removing the effects files maybe, then see if the new ships show up and operate like before. Maybe itās the effects? Just a suggestion. Is there even a way for users to do that?
I also use Winrar to extract the archives. Iām using PC, Windows 10, nVidia RTX2080, MSFS Store version. Addon Linker for MSFS community folder links.
1 Like
Is there any way to get Gaist V1? Iām also having random freezes on startup with V2 and would like to go back to V1 for the time being.
1 Like
When we should expect a new beta with some of the fixes addressed ?
1 Like
Iām pretty sure it wonāt change anything, SU8 broke something, not GAIST. Worth giving it a try though!
1 Like
Yep I suspect the same Flpbud. Definitely have a suspicion that it was SU8, or subsequent update, that altered some core files that are the source of these hangs and odd CTD, for some users, but being intermittent and/or random it is difficult to pinpoint or establish the cause. Will keep working on it.
1 Like
I agree with Flobud and nbrich1, the SU8 update started the problem on the very same gaist-msfs-V2 that was working fine before. It wasnāt instantaneous, it seemed to slowly build up after running many flights (like a buffer loading up until it is full).
Here are some of my experiences:
When loading after āFlyā selection, my sim seems to be choking on the number of track bgls being loaded. I say that after testing GAIST-ultra-Beta over the last 13 or 14 days. I can clearly demonstrate that by breaking the GAIST-ultra-Beta into 3 GAIST test packages of 720, 720 & 718 tracks respectively using MSFSLayoutGenerator, I can successfully run each of the 3 GAIST test packages (one at a time) while doing 15 different flight departures from the Welcome screen (for each test package) to points all over the world without a single hang. Most of the time there was nothing more than a quick hesitation at the āhangā point. In fact, the loads were so smooth, I checked numerous times at the target locations to make sure I could see Henrikās boats running, most with smoke and wakes. The boats were always there (of course only if the particular GAIST test package had tracks that covered the location I had loaded)!
I then tried one of the GASIT test packages along with Janās Boats also enabled (which runs fine by itself and was not enabled during the test package loading tests). The hang happened on the first flight departure. The GAIST test package was 720 track bgls and Janās boats package was 497 track bgls for a total of 1217 tracks. It seemed that was too many for the sim to load and it hung while loading them. This is a perfect example where each of the two packages ran fine by themselves but a hang took place when both were enabled at the same time most likely due to the aggregate number of tracks. As soon as I disabled one the test packs, Janās boast ran fine again.
My guess: Asobo must have changed a method for loading .bgls or, specifically, track bgls that wonāt allow a large number files to exist at the same time.
These are just my documented experiences. Others may have different results.
2 Likes
From memory (and my memory is rubbish) in FSX and P3D, did it not load the BGL files as they were needed? I know it built the index of the files, but i didnāt think it loaded the traffic until you were within a certain radius. 
1 Like
That is pretty much in line with my thinking.
1 Like
Well said Stilletto202 and AviatorDown8227. And many of us are thinking/suspecting a similar thing.
IE: After SU8 (or some subsequent update @3 or so weeks ago,) things in the sim changed. Intermittent hangs started when loading flights and the odd CTD in-flight for unknown reasons. Perhaps Asobo has limited file/type āloadingā resources etc or invoked a restriction- perhaps in an effort to quicken or smooth loading for either PC and/or the XBox consol: but who really knows for sure as all of this is guess work right now- but it sure makes some sense why the sim is responding the way it is.
(I documented and sent my āhangā issue to zendesk however they will only deal with their own content as far as trouble shooting and will not investigate outside their environment. They simply advised to return the SIM and content to the default and will not address any further).
Again, many still suspect that the issue may have nothing to do with add-ons at all but the limit or file cap or a more restrictive condition or limit placed in the core sim, which also is undocumented. Again, until a few weeks ago we didnāt have these issues with GAIST or with any of the vessel type add-ons.
So. I guess the question becomes, how can we establish for sure if core sim changes were made? and if so ascertain the new changed limits or restrictions were invoked. Only then will we be able to have a clearer picture how to solve this problem: that being either to recommend a reasonable fix for the sim restriction or modify the add-ons to fall into the parameters of the new sim restrictions and limitations. It sure would be nice to know what is really going on here. (Anyways enough said so will shut up now ā¦ that is (lol) unless something comes out of the woodwork to help fix this problem).
2 Likes
Unlikely as I would be instantly suffering from this by loading over 160000 files alone from my community folder 
(Full AIG install as being an alpha tester, large scale scenery files and GAIST). Still me and others using similar setups habe got 0 issues but random CTDs everyone has from time to time.
One thing that could make a difference is the package installation path as Windows struggles with really long paths (especially on MSFS store edition). That caused issues before which were hard to notice (e.g. texture errors on objects from misaligned textures) but could cause more intense issues by now. A solution would be to move the package folder to a new place.
Anyway I think that also users with custom package paths have these issues if I followed the thread correctly.
Still if someone with the default windows store installation path suffers from these issues it would anyway be good to move the packages to a more short path (like C:\MSFS) - a description on how to do that easily is found here:
1 Like