Re: [suggestion] Faster Quit
Posted: 31 Aug 2013, 20:56
I examined this issue a little closer. It’s related with a file cache located in the files Game.FidCache.Gbx and User.FidCache.Gbx.
Game.FidCache.Gbx contains (among other things) information about some system libraries and a header chunk of all campaign maps.
User.FidCache.Gbx contains some header information of all user maps and replays (including the Autosave ones) and infos about other user content (skins, stickers, ...).
Instead of extracting the needed information from all these files, the game loads them from the two cache files. This speeds up the initialisation of the game a lot.
While quitting the game, it refreshes the cache files if necessary.
For this, the game scans all folders and looks for new/deleted files or files with a different write time. If it finds such a change, it marks this folder as dirty.
After this, the cache file is created anew from all dirty marked folders by loading the header user data of all files located in this folder.
Even if only one replay file in the Autosave folder was changed or newly created, the entire Autosave folder will be processed.
The game already compares the write file times (I couldn’t found the filetime data in the *.FidCache.Gbx, but tests shows that they must be there). So it is not understandable why also files that are not changed read in again.
The index loop may bail out if the first difference was detected. This is good practice. But for a folder with potential plenty of files like the Autosave folder it may be much faster to determine the file times of all files from the file system than reading in the first 4K of all files in that folder. Nadeo should add a special handling of the Autosave folder in the code.
BTW Using the command line parameter “/noscancache†with the game exe or the launcher will instruct the game not to use both Fid cache files. But it doesn’t help. The game now quits immediately, but needs a long time to start; because now the required information must be read in from the complete set of files...
Game.FidCache.Gbx contains (among other things) information about some system libraries and a header chunk of all campaign maps.
User.FidCache.Gbx contains some header information of all user maps and replays (including the Autosave ones) and infos about other user content (skins, stickers, ...).
Instead of extracting the needed information from all these files, the game loads them from the two cache files. This speeds up the initialisation of the game a lot.
While quitting the game, it refreshes the cache files if necessary.
For this, the game scans all folders and looks for new/deleted files or files with a different write time. If it finds such a change, it marks this folder as dirty.
After this, the cache file is created anew from all dirty marked folders by loading the header user data of all files located in this folder.
Even if only one replay file in the Autosave folder was changed or newly created, the entire Autosave folder will be processed.
The game already compares the write file times (I couldn’t found the filetime data in the *.FidCache.Gbx, but tests shows that they must be there). So it is not understandable why also files that are not changed read in again.
The index loop may bail out if the first difference was detected. This is good practice. But for a folder with potential plenty of files like the Autosave folder it may be much faster to determine the file times of all files from the file system than reading in the first 4K of all files in that folder. Nadeo should add a special handling of the Autosave folder in the code.
BTW Using the command line parameter “/noscancache†with the game exe or the launcher will instruct the game not to use both Fid cache files. But it doesn’t help. The game now quits immediately, but needs a long time to start; because now the required information must be read in from the complete set of files...
