why doesn't civ fanatics allowAnd art updates you'll soon get, mwahaha! I'm finally done with 3.7x update cycle, and now I'm back to my favourite pastime, which is painting my tin soldiers!![]()


why doesn't civ fanatics allowAnd art updates you'll soon get, mwahaha! I'm finally done with 3.7x update cycle, and now I'm back to my favourite pastime, which is painting my tin soldiers!![]()
Oh, I seeNo, as the mod names are different (deliberately from my side, for me to be able to have both side by side). You'll need a save started on the SVN version for that.
You can unpack the fpk files on your release version if you're attached to the particular save. Instead of deleting them, you can even put them somewhere else temporarily.No way around that?
I don't think it ever worked in RI - it was ported a long long time ago, way before I started meddling with code stuff, and I have absolutely no idea what's wrong with it or even how it's supposed to work in the first place.Also I was wondering how a mod like Caveman2Cosmos handles this kind of problem, since that seems to be a mod of even greater scope/scale. On their mod page it highlights the option "Graphical Paging", which should virtually erase MAF problems (or so it says there). I know RI has that option too, but whenever I tried using it before it seemed to cause even more frequent crashes. Is that a common experience? Any tips on how to better utilise this option?
... I've just downloaded the latest snapshot from SourceForge and ran an AI-generated script to find out how many files are smaller than a given number of kilobytes. For reference, the total number of art files was close to 32,600 and the total file size 1.62 GB. Here's what I got from the script:Also, in some other FPK, some huge files seem useless. For example, in assest.fpk we find some "motionflow_aircraft.tga" 8MB.
I see, thank you for the suggestion. I think I will just continue playing on medium or low graphic settings in that case, as that seems to be a bit too much effort for what I'm getting out of it.You can unpack the fpk files on your release version if you're attached to the particular save.
But you are Walter, the immortal creator, wandering the forum since time immemorable! How can that be?!I don't think it ever worked in RI - it was ported a long long time ago, way before I started meddling with code stuff, and I have absolutely no idea what's wrong with it or even how it's supposed to work in the first place.
Sorry, I’ve been very busy lately—freelancing, though unfortunately (or fortunately?) not with a lance, but with software.I see, thank you for the suggestion. I think I will just continue playing on medium or low graphic settings in that case, as that seems to be a bit too much effort for what I'm getting out of it.
But you are Walter, the immortal creator, wandering the forum since time immemorable! How can that be?!
I think I will continue my huge save game for a bit longer, the save file I already posted here, and if I can be of use as a guinea pig for further experimentation I'd be happy to help.
Download VMMap from Sysinternals, launch the first executable (not the 64-bit version) with administrator rights. Select the Civ4 process and check the Free section—the more, the better. With the right tool, it’s easy.I wouldn't really know how to test the memory use of this scheme.
There are CIV4...Infos.dat files; that's the XML cache, which seems to get created and read only when launching without a mod. And there are catalog...dat files, which are probably the ones you mean. Opening them with a hex editor (or even a text editor) shows mostly file paths in ASCII. Likely being mapped to some other type of data. DisableFileCaching in CivilizationIV.ini sounds like it should suppress those files, but it has no apparent effect. This thread is probably the most productive investigation of this subject so far. It suggests that there is a scan of files with .dds and .nif ending, but it doesn't connect that scan to the catalog files. But your post sounds like you've been able to ascertain that by observing file access patterns? I guess this might be relevant when trying to find the binary code in the EXE that performs the scan. However:At launch, the game scans every single file and creates an output in: AppData\Local\My Games\Beyond the Sword\cache
It opens, reads, and closes each file individually and sequentially, which takes an unnecessarily long time since there are tens of thousands of files. The output is below 3MB and consists of several .dat files. What could be in this files ?
The DLL being loaded only once the scan is done will make even a runtime hack of the EXE through the DLL impossible. One could at best alter the EXE on disk.At some point it suddenly starts to rapidly allocate memory and it reaches the main menu in something like 3-5 seconds. It doesn't actually connect to the DLL file before the memory allocation.
For the time being, one could also browse to the proper revision on the SourceForge page and to the Art folder and use the website's "Download Snapshot" function. One may have to resume the download manually a couple of times if it times out.Unpacking FPK and copying the output to the right place isn’t that complicated. I’ll try to create a script to automate the process. I think it’s worth it because it would allow to play the endgame with full graphics. And my friends and I could enjoy it too.
Thanks, but I feel that I should ultimately also test some large savegame with MAF errors to weigh in on which way of packing works best. That gets too laborious for me, at least for now.Download VMMap from Sysinternals, launch the first executable (not the 64-bit version) with administrator rights. Select the Civ4 process and check the Free section—the more, the better. With the right tool, it’s easy.
The issue lies in Mapped Files—this is where you’ll see which files are mapped into memory and their sizes.
What's discouraging about packing only small files is that the relationship between the number of unpacked files and the scan time is apparently linear. So packing just, say, 80% of the files will only reduce the start-up delay to one fifth. Given how long it takes (when launching the mod for the first time) to scan all files, the duration with partial packing will never be negligible. And the game showing no splash screen or other sign of life for nearly a minute is indeed a pretty bad way to greet new players.I still believe that providing an unpacked, separated version as an optional endgame solution, with all the necessary warnings, would be nice.
Actually it seems to not be linear based on my observations. The reason is likely explained here: https://forums.civfanatics.com/thre...mecoredll-to-run-faster.686918/#post-16537892What's discouraging about packing only small files is that the relationship between the number of unpacked files and the scan time is apparently linear. So packing just, say, 80% of the files will only reduce the start-up delay to one fifth.
Although it might scale differently on the first launch. That, in my test, took nearly a minute with 3733 files, 11.5% of the total number. How long would it have taken with everything unpacked? Difficult to test now; 10 minutes seemed plausible to me based on past experiences with RI. But 15 minutes I could also imagine. For reference:I made a copy of Art and placed it inside Art. This doubled the number of files there. It took 9 seconds before when starting multiple times. Now it takes 28 seconds.
Well, if inefficient look-up is what makes it superlinear, then I'd expect that to make less of a difference on the first launch.Even 10 years ago when booting up an unpacked RI, I would go off and do something else for 15-20 minute. These days, on my M2 macbook, it's only 3-5 minutes to boot unpacked, which is much more tolerable.
Looking through the thread, a lot of memory numbers have been posted, so just to be clear: what is memory usage as a mod vs copying everything into the game itself?The game launches immediately, with all available free memory ! It lauches instantly, much faster than the regular RI.
What's saves memory is the unpacking of FPK files into the Assets folder. If you do both BTS FPK + RI FPK, the saving is aroung 1.2GB (on 4GB available). 850MB for RI alone. Each new version of RI being naturaly heavier.Looking through the thread, a lot of memory numbers have been posted, so just to be clear: what is memory usage as a mod vs copying everything into the game itself?
; Custom Art from user folder is not loaded
NoCustomArt = 0
; Custom XML and Python from user folder are not loaded
NoCustomAssets = 0
@echo off
setlocal enabledelayedexpansion
:: Set paths and original file name
set "originalFilePath=C:\Users\Administrator\Documents\My Games\Beyond the Sword\CustomAssets\RIart"
set "newFileName=art"
set "executablePath=C:\Program Files (x86)\Sid Meier's Civilization 4\Beyond the Sword\Civ4BeyondSword.exe"
:: Get the directory path of the original file
for %%f in ("%originalFilePath%") do set "originalDirPath=%%~dpf"
:: Get the original file name
for %%f in ("%originalFilePath%") do set "originalFileName=%%~nxf"
:: Rename the file
ren "%originalFilePath%" "%newFileName%"
:: Start the executable and wait for it to finish
start /wait "" "%executablePath%" mod=\Realism
:: Restore the original file name
ren "%originalDirPath%%newFileName%" "%originalFileName%"
:: Exit the script
exit
Whats CustomAssets and how does it work ?However, loading the Art via CustomAssets also does the trick.
when you delete some of the FPK files, the game still runs fine, and the affected units simply become invisible, without any apparent bugs (I tested this for only two turns). I assume it's just textures, so if they’re missing, they’re simply not displayed.
I store the git revision as a string in an autogenerated header file. That string is only used as the very first variable in a savegame. That way when I open a savegame file in notepad++, the revision used when saving will be on the first line in plain text. This really helps when getting savegames from bug reports as it is clear which version should be able to load it. I imagine it can be done with svn too. In fact it should be even easier as svn has a simple revision numbering system rather than the git hash key.I can't easily check because the random SVN version I have now won't be save-compatible with anyone.