This guide does look long, boring, intimidating and tedious. But it is only long. It is very easy and straightforward.
This guide will give your installment of Fallout 4 significant FPS boost. But in the end of day, it is really not meant to be only that.
This guide is my “love letter“ to Fallout 4 modding community. Only thing my skills could be able to produce, so I could give something back. It has it faults, wrongs and gimmicks, but it is (to date) only fully documented process how to create PreVisibines to all masters, any mod or set of mods.
It is also a manual to create better, fully automated version of it. But that is up to you, Fallout 4 modding community. Take the challenge or not.
Q: I read somewhere that Creation Kit has a size limit on how large archives it can open. Is this true? A: Do not think this is true. I have seen Creation Kit use 25GB non-compressed archive during creation of PreVisibines. All it says:
There is a limit to a ba2 archive size for the CK. As BenRierimanu mentioned in the F4 Creation Kit Fixes Posts section, if you load anything over 4gb (using luxor's texture ba2 replacers as an example) you will not see the textures in the creation kit, it will not load. You not seeing any difference in the CK is because the previsibines should be vanilla or, and if someone can correct me if I'm wrong, you wouldn't be able to tell the difference anyways.
Regarding Version Control, BenRierimanu has a git where an xedit script can be used to edit the VC Dates rather than saving the plugin through the CK. Regarding some mods that are not Previsibineable, I have created some Text files which lists mods that have troubling CELLs for the precombine and visibility steps in BenRierimanu git again.
Please test my "CK loader". It can be found from files section, inside DIY Previsibines Repair Tool archive (1_run_CK.cmd). Also use Searge’s script pack to "crack" Creationkit.exe.
I have baked a ton of high-rez textures in to official archives with BiRaitBec Workspace. Also loaded a my own PreVisibines patch (25GB) in to Creation Kit preview window. Absolutely no problem.
I have also seen how CK uses these custom, extra large, archives during genereation of PreVisibines without any problems.
Maybe this limitiation comes with f4ck_loader and unpatched Creationkit.exe?
Regarding Version Control, BenRierimanu has a git where an xedit script can be used to edit the VC Dates rather than saving the plugin through the CK.
There is no such part in this guide. You do not need to load/save plugin in CK during the process.
I speak in the simplest language, the original CK calls Assert. This should trigger CTD. Now for the technical language. The data structure contains 32-bit values of the file position and size. WinAPI is also used to work with 4 GB files. Fixes do not load such archives, they are skipped, you saw this message earlier, in 1.7 you will see another one. Unfortunately, I can't change the structure, if I was lucky and the numbers were aligned to a paragraph, I would be able to support 64-bit numbers and, as a result, load and process larger files. So what you've seen is nothing more than skipping these files. Otherwise, the theme is good, Endorsed
UPD: ; Automatic loading of archives with textures, meshes, scripts, etc. ; IMPORTANT: The value must be added together. ; MAIN 1 ; TEXTURES(X) 2 ; MESHES 4 ; MESHES_EXTRA 8 ; MATERIALS 16 ; VOICES 32 ; VOICES_EN 64 ; MISC 128 AutoloadBA2Files=3 I don't remember when, but this option is already numeric. It needs to be added. 3 set by default. (MAIN + TEXTURES) = 3.
And
; The original archive loader, the AutoloadBA2Files option will not work. OriginalLoadBA2=false
I added an option that leaves the native bootloader. Initially, it was included, because few understood the principle of operation and it was difficult for beginners.
Important edit that everyone should see. If you generate precombines, have a lot of RAM.
I can already see a few problems with this toolkit, and I don't recommend it in it's current state.
x64 builds of FO4Edit have a subtle floating point issue that occasionally nudges positions slightly on copying, this will break previs in certain situations. As Umbra (which btw, clean mode works perfectly fine in my build here and I'm on Win10 with CKF 1.6.3), there's some teething issues that need to be figured out.
Also, an anecdote for those that want to generate on their own, consider the following. A full PRP game build shoots my RAM usage all the way up to about 129GB. I have 64GB physical ram on my system.
Edit: This does not appear to account for precombine texture swap bugs and a few other things at first glance.
Edit 2: Briefly looked over the script included. The command line file might be useful here, but that's about it. Also, CDX step is not required when using filtered mode.
If you have discord, please pop into either the xedit discord (preferably) or Collective Modding, there's a lot wrong with this toolkit that can be discussed for improvement and it's getting way too big to fit into a single nexus comment.
For anyone else reading this, I have no idea why the Win8 SDK requirement is a thing when DirectX 9's redist should already supply that very dll file for you in the appropriate places.
It seems to me that you are getting off with a wrong foot here. Take a deep breath, sip some coffee, smoke a cigar or do what ever is needed to move your perspective slightly more far away.
What I mean here is that this thing, this mod, does not take anything away from you. It does not overshadow, overthrow or even replace your project, your mod. And even if it shows that there is more in this process that you already know, it is not meant as an insult. So please, stop nitpicking. It just does not get us anywhere. Take what you have learned here and use it as you wish. Or do not use it. Not my problem, do not care.
I humbly thank you for invitation. I will consider that.
Last time I looked DirectX 9 redist (Jun2010) it did not include d3dcompiler_46.dll. It had 33 to 43, but not 46. And to my knowledge, you can only get 46 from Windows 8 Kit. Requirement comes from Creation Kit. It calls it.
Apologies, 21 years in retail is catching up to me again.
Re: d3dcompiler_46.dll, I appear to have a _47 on my system, possibly from a newer directx component in the Win10 SDK, unsure on the source. (Versioned 10.0.19041) Edit: In Windows/System32
As for the nitpicking, just the xedit floating point issue (x64 only) and texture swap bug were the issues I felt that were missing from the documentation and should at least be noted or pointed out, else the userbase can and will ask about it if they are actively looking for them.
"As for the nitpicking, just the xedit floating point issue (x64 only) and texture swap bug..."Do not know anything about floating point issue, or how it can interfere this process. Could you please tell me more?
Texture swap bug is also very interesting topic. Could you point out to me a really good example of this bug? I have tested Pra's "Apply Material Swap.pas" script, but it does edits that do not even exist in original mod. Also, the way meshes work in Fallout 4, I am pretty sure that material swaps are not important part of creating PreVisibinies. I could be wrong, so please enlighten me!
Precombines ignore texture swaps assigned in game unless explicitly assigned at the reference level. That's what the script does, and that's what I used to leave in PRP before the split in 0.57 to clean them out, as they are only needed on generation.
The floating point bug is something unique to the 64-bit build of xedit due to the way the internal code processes it all. Load up a generated plugin in 32-bit xedit and you'll notice very small conflicts that weren't there in 64-bit. I don't have a very good workaround for this one aside from being stubborn with plugin prep for large sizes of records.
13 comments
This guide will give your installment of Fallout 4 significant FPS boost. But in the end of day, it is really not meant to be only that.
This guide is my “love letter“ to Fallout 4 modding community. Only thing my skills could be able to produce, so I could give something back. It has it faults, wrongs and gimmicks, but it is (to date) only fully documented process how to create PreVisibines to all masters, any mod or set of mods.
It is also a manual to create better, fully automated version of it. But that is up to you, Fallout 4 modding community. Take the challenge or not.
Thank you!
Regarding some mods that are not Previsibineable, I have created some Text files which lists mods that have troubling CELLs for the precombine and visibility steps in BenRierimanu git again.
I have baked a ton of high-rez textures in to official archives with BiRaitBec Workspace. Also loaded a my own PreVisibines patch (25GB) in to Creation Kit preview window. Absolutely no problem.
I have also seen how CK uses these custom, extra large, archives during genereation of PreVisibines without any problems.
Maybe this limitiation comes with f4ck_loader and unpatched Creationkit.exe?
Now for the technical language. The data structure contains 32-bit values of the file position and size. WinAPI is also used to work with 4 GB files.
Fixes do not load such archives, they are skipped, you saw this message earlier, in 1.7 you will see another one.
Unfortunately, I can't change the structure, if I was lucky and the numbers were aligned to a paragraph, I would be able to support 64-bit numbers and, as a result, load and process larger files. So what you've seen is nothing more than skipping these files.
Otherwise, the theme is good, Endorsed
UPD:
; Automatic loading of archives with textures, meshes, scripts, etc.
I don't remember when, but this option is already numeric. It needs to be added.; IMPORTANT: The value must be added together.
; MAIN 1
; TEXTURES(X) 2
; MESHES 4
; MESHES_EXTRA 8
; MATERIALS 16
; VOICES 32
; VOICES_EN 64
; MISC 128
AutoloadBA2Files=3
3 set by default. (MAIN + TEXTURES) = 3.
And
; The original archive loader, the AutoloadBA2Files option will not work.
OriginalLoadBA2=false
I added an option that leaves the native bootloader. Initially, it was included, because few understood the principle of operation and it was difficult for beginners.
Important edit that everyone should see. If you generate precombines, have a lot of RAM.
I can already see a few problems with this toolkit, and I don't recommend it in it's current state.
x64 builds of FO4Edit have a subtle floating point issue that occasionally nudges positions slightly on copying, this will break previs in certain situations. As Umbra (which btw, clean mode works perfectly fine in my build here and I'm on Win10 with CKF 1.6.3), there's some teething issues that need to be figured out.
Also, an anecdote for those that want to generate on their own, consider the following. A full PRP game build shoots my RAM usage all the way up to about 129GB. I have 64GB physical ram on my system.
Edit: This does not appear to account for precombine texture swap bugs and a few other things at first glance.
Edit 2: Briefly looked over the script included. The command line file might be useful here, but that's about it. Also, CDX step is not required when using filtered mode.
If you have discord, please pop into either the xedit discord (preferably) or Collective Modding, there's a lot wrong with this toolkit that can be discussed for improvement and it's getting way too big to fit into a single nexus comment.
For anyone else reading this, I have no idea why the Win8 SDK requirement is a thing when DirectX 9's redist should already supply that very dll file for you in the appropriate places.
What I mean here is that this thing, this mod, does not take anything away from you. It does not overshadow, overthrow or even replace your project, your mod. And even if it shows that there is more in this process that you already know, it is not meant as an insult. So please, stop nitpicking. It just does not get us anywhere. Take what you have learned here and use it as you wish. Or do not use it. Not my problem, do not care.
I humbly thank you for invitation. I will consider that.
Last time I looked DirectX 9 redist (Jun2010) it did not include d3dcompiler_46.dll. It had 33 to 43, but not 46. And to my knowledge, you can only get 46 from Windows 8 Kit. Requirement comes from Creation Kit. It calls it.
Re: d3dcompiler_46.dll, I appear to have a _47 on my system, possibly from a newer directx component in the Win10 SDK, unsure on the source. (Versioned 10.0.19041)
Edit: In Windows/System32
As for the nitpicking, just the xedit floating point issue (x64 only) and texture swap bug were the issues I felt that were missing from the documentation and should at least be noted or pointed out, else the userbase can and will ask about it if they are actively looking for them.
... I've really got to find a different job.
"As for the nitpicking, just the xedit floating point issue (x64 only) and texture swap bug..."Do not know anything about floating point issue, or how it can interfere this process. Could you please tell me more?Texture swap bug is also very interesting topic. Could you point out to me a really good example of this bug? I have tested Pra's "Apply Material Swap.pas" script, but it does edits that do not even exist in original mod. Also, the way meshes work in Fallout 4, I am pretty sure that material swaps are not important part of creating PreVisibinies. I could be wrong, so please enlighten me!
The floating point bug is something unique to the 64-bit build of xedit due to the way the internal code processes it all. Load up a generated plugin in 32-bit xedit and you'll notice very small conflicts that weren't there in 64-bit. I don't have a very good workaround for this one aside from being stubborn with plugin prep for large sizes of records.