EshamTheUnholy Posted October 19, 2020 Share Posted October 19, 2020 (edited) Textures for certain room kits (so far only Utility hallway/room dungeon pieces) render in the GECK as if showing signs of improper archive invalidation. I attempted to fix the issue by editing my "GECKCustom.ini" to include "Fallout - Invalidation.bsa" or "Fallout - AI!.bsa" in the line under [Archive]. It is also important to note that the textures appear as intended in-game, only the GECK refuses to render these textures properly. I might also want to add that I am using the GECK Powerup if that has any influence on my issue. Screenshots: Edited October 19, 2020 by EshamTheUnholy Link to comment Share on other sites More sharing options...
dubiousintent Posted October 19, 2020 Share Posted October 19, 2020 (edited) Don't know if it is directly related, but the "GECK Extender" supercedes "PowerUp" and adds many additional features and GECK engine fixes. It also incorporates NVSE into the GECK for you. Might want to give that a try; but if so, disable "PowerUp" first. Don't use the two together. -Dubious- Edited October 19, 2020 by dubiousintent Link to comment Share on other sites More sharing options...
EshamTheUnholy Posted October 19, 2020 Author Share Posted October 19, 2020 Strangely enough I installed the GECK extender without even remembering a few months ago and I had no new issues. I opened the normal GECK application and the same exact problem occurs. I could try reinstalling it if that helps anything but I can't help but feel as if it is related to my data folder, but even if I load only FalloutNV.esm there is no difference. Link to comment Share on other sites More sharing options...
dubiousintent Posted October 20, 2020 Share Posted October 20, 2020 Yeah, I should have realized the GECKCustom.INI file was from the Extender. My bad not picking up on that. This (was working and now isn't) sounds reminiscent of problems people have following a "system update". Back to basics. Did you install the game (and thus GECK) to the default "C:\Program Files(x86)" folder tree? If so, please see the "Installing Games on Windows Vista+" article as to why eventually this will come back to bite you in the posterior. In particular pay attention to the bit about "resetting permissions" and "shadow files", something many game companies were not realizing the significance of back when FNV was being developed. "Developer tools" don't always function exactly the same as "end user products", especially in a "networked Version Control" environment. -Dubious- Link to comment Share on other sites More sharing options...
EshamTheUnholy Posted October 21, 2020 Author Share Posted October 21, 2020 No worries my friend, now that you mention it my system was updated recently. I own the steam version of FNV Ultimate and its worth noting my Steam Folder is not located in Program Files or any other folders alike and is found directly on my "C:\" drive since I've had issues with the former previously. Link to comment Share on other sites More sharing options...
dubiousintent Posted October 21, 2020 Share Posted October 21, 2020 Check that the "Steam" folder tree directly under "C:\" (e.g. "C:\Steam", "C:\Games", or whatever) folder is NOT set to "inherit permissions from it's parent" (C:\). Likely any access privilege problem is one of "File and Folder permissions" on the parent "root" folder under which you installed the games (the root folder might be reset by a system update). If this is not set correctly to allow at least "System", "Administrators", and "Users" to have "Full Control" then you can't overwrite other files or make changes. You then (while logged in as an "Administrator Account") need to enable the "Properties | Security | Advanced | Change Permissions" setting of the parent folder to enable the box: "Replace all child object permissions with inheritable permissions from this object", so those changes get applied to the existing files and sub-folders. The only other explanation I have seen for anything similar to the apparent "ArchiveInvalidation" issue was "hard coded texture paths". See the wiki article "How to fix hard-coded texture paths in NIF files" for the procedure to locate the texture file entry within NifSkope. (The path needs to be "relative" instead of "absolute"/"hard-coded" in order to be found on various installation locations, which is what many editors default to and that article covers.) But in short form the procedure is (using "left-click" with your mouse):* Open the NIF file in NifSkope.* Click on the part you want the texture for; it will "highlight" it in the Block list.* Expand it (click the triangle) and highlight BSShaderPPLightingProperty. Expand that.* Highlight BSShaderTextureSet.* In "Block Details" section you will see textures (DDS files). Expand it.* There you will see the paths to the textures used by that mesh. They should start "\textures" with nothing else before that.-Dubious- Link to comment Share on other sites More sharing options...
EshamTheUnholy Posted October 22, 2020 Author Share Posted October 22, 2020 I managed to fix the textures, but it may not be the most stable solution. I copied the textures from the vanilla game files and placed them in the path they belong (data/textures/dungeons/utility). Could future problems occur if I use this method or would you advise a more solid solution? Link to comment Share on other sites More sharing options...
GamerRick Posted October 23, 2020 Share Posted October 23, 2020 Is it possible the texture is in another BSA from a mod that isn't being loaded in the GECK? The game loads everything that is active, but in the GECK you usually only load one mod and its masters. Link to comment Share on other sites More sharing options...
dubiousintent Posted October 23, 2020 Share Posted October 23, 2020 Good point. The Gamebryo engine doesn't have a preference if a file exists in more than one BSA, so it can grab it from a random BSA file each time it loads. (This caused major "erratic behavior" headaches before it was discovered.) If you want a specific texture to be used in such a case, then you are better off to put those "art assets" in the proper folders as "loose files" as part of your mod to ensure they get used. Other than the disk space used/wasted, it really won't matter to the engine as "loose files" are intended to override the use of those in a BSA by design. If you place your own "assets" in a mod-named sub folder under the "proper folder location" (e.g. "textures\<YourMod>" and change the relative filespec in the NIF to match (e.g. "textures\<YourMod>\<YourFile>", you won't even have to worry about someone else "overwriting" it accidentally. -Dubious- Link to comment Share on other sites More sharing options...
GamerRick Posted October 23, 2020 Share Posted October 23, 2020 (edited) Actually, I just remembered that you cannot put changes to vanilla textures in a BSA. You can only put new textures in a BSA. But, when I tried it, I never saw my version get used by the game. It only showed the vanilla one from the game's BSA. I don't remember the GECK being different with this. Also, I don't know if this is true for FO3/FNV, but for Oblivion and/or Skyrim you must put your BSA in the list of BSAs to load for the Construction Set/Kit to load it at all. In the FNV GECK this would be in the GECKCustom.ini: For editing mods that don't need a DLC: SArchiveList=Fallout - Textures.bsa, Fallout - Textures2.bsa, Fallout - Meshes.bsa, Fallout - Misc.bsa, Fallout - Voices1.bsa, Fallout - Sound.bsa For editing mods that are dependent on one or more DLCs: SArchiveList=Fallout - Textures.bsa, Fallout - Textures2.bsa, Fallout - Meshes.bsa, Fallout - Voices1.bsa, Fallout - Sound.bsa, Fallout - Misc.bsa, CaravanPack - Main.bsa, ClassicPack - Main.bsa, DeadMoney - Main.bsa, GunRunnersArsenal - Main.bsa, HonestHearts - Main.bsa, LonesomeRoad - Main.bsa, MercenaryPack - Main.bsa, OldWorldBlues - Main.bsa, TribalPack - Main.bsa Edited October 23, 2020 by GamerRick Link to comment Share on other sites More sharing options...
Recommended Posts