Jump to content


  • Content Count

  • Joined

  • Last visited

About CrankyCat

  • Rank

Profile Information

  • Gender
  1. After getting my plugins just right I started up Wrye Bash 307.20180731 to create the bashed patch and Kaspersky decided it was a Trojan and deleted it. It then "restored" plugins.txt to "rollback malware changes" leaving it somehow total scrambled garbage. Boo Kaspereky! Afterwards, I just did an update to Kaspersky and restored plugins.txt from a backup to redo my changes, and was able to run normally. 03.12.2018 16.49.21;Malware deleted;PDM:Trojan.Win32.Generic;Wrye Bash;c:\games\steam\steamapps\common\fallout 4\mopy\wrye bash.exe;12/03/2018 16:49:21 So, beware! Make sure you create a copy of your plugins.txt.
  2. Thanks for the reply. I had some success with finding objects by type based on existing types and managed to shrink my save by 20MB or so using keyboard macros to perform prid and fp combos based on a generated list. Yeesh. Earlier I went all the way to Nuka-World to go into a new worldspace to see if that would clear deleted items with a save/quit/reload but it didn't. Only my nasty macro created in Notepad++ with regex search and replace cleaned up many of the deleted temp persistence (FFxxxxxx) objects. I never could find the reason for some persistence although some point after my initial cleaning the deleted objects cleaned up correctly after refreshing instead of remaining in their deleted state forever. All KingGath did was explicitly remove the linked reference to the workshop as far as I know but perhaps that change avoided the forced persistence going forward. Not sure why it wasn't everyone with the issue unless it has to do with script performance or it wasn't noticed. I didn't find most of the junk apparently since a clean install of Sim Settlements lowered the save size another 40MB down to 40MB without SS and 60 with it reinstalled. I was able to do a clean reinstall without screwing up my game by destructing all of the ASAM sensors/plots and going to the old QaSmoke location to do the uninstall ala Skyrim. My custom buildings are still there so I can add the plots back but I'm kind of tired of Fallout for now :-|
  3. I have objects persisting even though they've been deleted and the linked keywords were removed. So, they aren't going to be returned if I select a workshop and use GetLinkedRefChildren(WorkshopItemKeyword). In FallrimTools they'll show up as just changeforms while in game if I select using prid they'll show with the [T] [PP] and [D] tags; temporary persistence, papyrus placed, and deleted(?) or disabled(?). They are both deleted and disabled and dppi shows nothing. I can use 'fp' (forcepersistence) to toggle and remove persistence manually but I need a way to write a cleanup script. I only have some I know about and could remove but there are many more. There is no 'fp' command in papyrus so figuring that out is the second problem. In the console I can use 'fp' to toggle persistence and the deleted item is immediately removed from the game but I don't know how to do that in Papyrus. Thanks for any assistance.
  4. The problem plugin is Valdacils Item Sorting specifically ValdacilsItemSorting-00-ValsPicks-DLCVersion.esp. I'll exclude it when building the merge. Thanks for the explanation!
  5. I can re-run on dev version with same result and no error so maybe the error just wasn't reported originally? The logs of old and new are identical except for the timestamps and the errors at the end of the newest version. I can run the new version as you suggest to see if I can spot the culprit though.
  6. The latest 3.2.1 shows new error messages creating FO4Merged which weren't there on the DEV build I have dated 2/2/2018. Assertion failure (D:\Projects\TES5Edit\wbImplementation.pas, line 5345) I've attached the log which is identical for both versions except for the assertion failures at the end. The produced merge is binary identical for both versions. Is this anything I should be concerned about? Thanks! FO4Edit_log2.txt
  7. It's there now. Wrye Bash 307.201711250133
  8. I asked Wim95 and he was familiar with the backslash issue. Apparently if you pack files from within the fallout 4 data structure, in place, then you get backslashes. I was unpacking elsewhere and repacking them which apparently results in forward slashes. It makes sense that devs do it by packing the files they use to develop with. That doesn't explain why only Wild Plants Farming (farm - main.ba2) caused an issue while other mods didn't though. I'll repack the "right way" and see if I get the expected results. Edit: I rebuilt the right way and there was no error from missing string localizations and the bashed patch had no issues. To do this I did the following: Installed the original Wild Plants Farming mod normally. Unpacked the original mod 7z for Wild Plants Farming to a working folder. Unpacked the main ba2 (only) Created a 7z for the unpacked mod without the textures. Installed the temporary mod Generated a build_farm.txt to use as a source file (attached) from an edited list of the unpacked files and placed it in the data folder. I have full paths in it since past tests caused errors when I didn't but perhaps relative paths would work from \data\. Used archive2.exe to create a new archive from the source file. I used compression of "none" like the original mod. Replaced the "farm - main.ba2" with the new one. Uninstalled my temp mod. WB had no issues with either strings or the bashed patch. I did a binary compare on the original vs the new ba2 and they are different possibly because wim95 originally had upper case folder names for existing folders and I have lower case. The size was the same and both had backslashes in the file paths though. farm_build.txt
  9. While the rebuilt "Farm - Main.ba2" does get the missing strings error now it no longer fails when building the bashed patch. This is odd since the Ground mod by the same author (wim95) works the same way and has no issues. Edit: I tried building in archive2 with a source file but that didn't change the slash direction.
  10. Definitely. The only real difference I see in the original "Farm - Main.ba2" file vs one I repacked is that the file paths in the original have back slashes instead of forward slashes. Maybe it's a Russian Windows thing. :-) Oddly enough I get a missing strings warning with Wrye Bash on the repacked ba2 file even though they are the same size and the only difference is that the original had forward slashes. Edit: Another difference is that in the Strings folder the En versions were first in the original ba2 archive but on my system they aren't that way alphabetically in the folder. I reproduced this when recreating the archive to put the English strings files first but WB still shows the "Missing strings localization files" warning like the mod did on the 307 beta 1 release. Farms actually does have several translation files included with the mod. i.e. original has: Strings\Farm_En.DLSTRINGS repacked has: Strings/Farm_En.DLSTRINGS Edit2: If I use archive2 to repack anything I have with strings localizations then i get the "Missing strings localization files" error when loading in WB. The only binary difference is the backslashes in the original are now forward slashes. Does the string localization validation expect backslashes? This seems to be a separate issue from the bash rebuild though. I don't see anything done differently than the "Ground" mod which doesn't cause the error. I'll leave the rest to the experts and just unselect farms when rebuilding my bashed patch for now :-)
  11. And the culprit is... Wild Plants Farming. Everything else works when enabled except this. I'll manually extract and rebuild the Farm - Main.ba2 with Archive2 and see if that fixes it for me. Thanks everyone! Hopefully this is simple to reproduce and either work around, get the author to fix it, or add a warning.
  12. Using Fallout 4 1.10.26 and WB 307.201711041935 standalone. Windows 10 professional. I doubt my load order will help but I've included it. Currently I get the following whenever I try to rebuild a bashed patch: I searched and found nothing for the B2aFileRecordTexture but presumably this has to do with the "modname - textures.ba2" type of files. I enabled debug but that didn't tell me anything and changing iKeepLog in the ini did nothing for me and it is otherwise the default. The released 307 beta Wrye Bash works for creating the bashed patch but obviously has other obvious issues. It did work for the bashed patch though. How can I tell which file it was on when the error occurred? PatchConfig.txt bashtags.txt loadorder.txt

Support us on Patreon!

  • Create New...