Piranhaha

Sorry, one last thing (I hate that there's a time limit to edit posts on this forum). I tried copying the records mentioned in my previous post (the MGEFs from AWE and Undeath) into a new override esp and deleted the KSIZ field in the new plugin. The idea was that I still need to tweak out some final (non-CTD-related) kinks in my smash rules and I didn't want to have to delete the KSIZs every time I rebuild the patch. However, the game still gave me a CTD even with the override patch enabled. In contrast, deleting the same KSIZs from the smashed patch itself results in a successfully loaded main menu and save file. So it seems like even if these records get overwritten by a correctly formatted record with higher priority, the game engine still reads the lower priority records as it loads and hiccups when it sees KSIZ=0. Looks like I'll have to delete the KSIZ from the smash every time. I think this concludes my debugging :p

Sorry for the quadruple post; quick followup. I investigated the other two plugins I was having problems smashing (Animated Weapon Enchants and Undeath). In both cases I tracked the CTDs to a single MGEF with KSIZ=0 after smashing: AWE: 0005B450 (https://imgur.com/QjKgmDU) Undeath: 0200C601 (https://imgur.com/kd1Cnuq) In both cases deleting the KSIZ entry entirely from the smashed patch resulted in elimination of the CTD on main menu. Figured I'd post in case someone has a similar issue and reaches this thread.

Sorry for the triple post; quick followup. I downloaded the newest version of AOS, and also copied the two AOS - Ordinator records (which are the exact two formIDs that I mentioned in my previous post) as overrides into a new AOS- Ordinator Patch Patch, in which I deleted the keywords and KSIZ entries. When I ran Merge Plugins Standalone, it gave me a merged plugin with KSIZ = 0, and this plugin crashed at main menu just like smashed patch did. Figured I'd let you know that it's an issue in Merge Plugins as well. Sorry for probing the extreme edge cases :p

Edit: I figured it out! Please see below - this may be something that should be fixed in Mator Smash when you have time. To follow up on my previous topic, I noticed that in the file header of the smashed patches, even though Number of Records is identical between my culled working patch and the nonfunctional one, the former has a Data Size of 4801 while the latter is 4842. I modified my script (code below) to report on the data size for each record within the patches. The script returns a blank for most of the values (for reasons that I don't understand) but I compared the ones that were returned as numbers and found two records that were each shifted by 10 (bytes?), accounting for 20 of the 41 (byte?) size difference. Both records were MGEF with FormIDs 000F3F10 and 000F392F. For example, the latter has a data size of 1114 in the working smashed patch, but 1124 in the crashing patch. I tracked down the size difference to the KSIZ entry. In Skyrim.esm this MGEF comes with a keyword entry which AOS preserves, but Ordinator then removes it. AOS patches then brings it back, but since Bash.Sound doesn't include keyword records, my smashed patch doesn't forward them: https://imgur.com/Nk6YF1p As you can see, what ends up happening is that the smashed patch carries through Ordinator's keyword deletion. The difference is that when I include AOS Patches using Bash.Sound, it populates the KSIZ - Keyword Count field with "0" whereas the smash without AOS Patches leaves it blank. I don't know what's going on under the hood to cause that behavior, of course. What I do know now is that "0" does not seem to be an acceptable parameter in this position. When I manually deleted this KSIZ entry for both of the above FormIDs in the crashing smashed patch, the game was able to load successfully (which I guess makes it not a crashing smashed patch anymore). So I guess perhaps there should be a validation function at the end of patch generation which looks for KSIZ values of zero and replaces them with null? Here's the script that I used to dump FormIDs and their corresponding data sizes. Sorry for the clunkiness; I'm a chemist who learned Pascal this evening explicitly for this purpose :). If anyone could let me know why most of my data sizes are being recorded as blank, I'd appreciate it (I still want to investigate why there's a remaining difference of 21 (bytes?) between my two smashed patches in case it could lead to errors down the road). The two FormIDs that I mentioned above are the only ones where Diffchecker found a difference in size, so the other difference(s) must be buried in the blanks. Thanks! { Prints the FULL name of selected records to the log. } unit MyDebugScript; // This is the unit name that will contain all the script functions uses mteFunctions; // import Mator's functions // global variables var slFormIDs: TStringList; var slDataSizes: TStringList; var f: IInterface; var g: IInterface; // // Called when the script starts function Initialize: integer; begin slFormIDs := TStringList.Create; slDataSizes := TStringList.Create; end; // Called for each selected record in the TES5Edit tree // If an entire plugin is selected then all records in the plugin will be processed function Process(e : IInterface) : integer; var test : string; var test2: string; var recordHeader: IInterface; begin test := GetLoadOrderFormID(e); //this is apparently considered better practice than just FormID(e) recordHeader := ElementByIndex(e, 0); test2 := geev(recordHeader, 'Data Size'); slFormIDs.Add(IntToHex(test,8)); // converts the formID to the value seen in SSEEdit. slDataSizes.Add(test2); end; // Called after the script has finished processing every record function Finalize : integer; var i: integer; s: string; slFormIDs_size: integer; // test to see if I can get stringlist count filename: string; begin AddMessage('element count:'); slFormIDs_size := slFormIDs.Count; AddMessage(IntToStr(slFormIDs_size) + ' records found'); AddMessage('FormIDs:'); for i := 0 to slFormIDs_size - 1 do begin s:= slFormIDs[i]; //AddMessage(s); end; filename := ProgramPath + 'Edit Scripts\FormIDs.txt'; AddMessage('Saving record list to ' + filename); slFormIDs.SaveToFile(filename); slFormIDs.Free; filename := ProgramPath + 'Edit Scripts\Data_Sizes.txt'; AddMessage('Saving record list to ' + filename); slDataSizes.SaveToFile(filename); slDataSizes.Free; AddMessage('end script'); end; end.

I used Mator Smash to make individualized profiles for about 80 different mods that showed conflicting records in SSEedit. When I tried to launch the game with the patch enabled, the main menu window comes up and starts to load (e.g. the point where, if you have a large data folder, the New, Continue, etc buttons aren't yet visible but you see the dragon logo). However, before the menu buttons become visible it CTDs with no error message. By selectively removing plugins from the smashed patch I tracked the cause down to three esps, any of which cause the issue when included in the patch (even without the other two). These ESPs are: UndeathAnimated Weapon EnchantsMy Audio Overhaul Skyrim Patches merged patchI started trying to debug using my AOS patches as the test case and encountered the following: When using a new smash setting on AOS patches in which none of the fields are toggled, the patch still causes a CTDWhen using the Bash.Audio setting that I had cloned as Smash.AOS_Patches, the smashed patch actually contains 7 fewer records than when I exclude AOS Patches from the smashed patch.I wrote a quick SSEedit script to dump all FormIDs touched by the smashed patches, and found the 7 FormIDs that are in the working smashed patch but are absent in the non-working smashed patch. They are all WEAP entries.In 4 of these 7 entries, the entire entry was identical to the previous entry in the load order (AOS_Patches merged).In the other 3, the entry had inherited and overwritten the INAM record from Skyrim.esm in preference to the value in AOS_Patches merged (this is because Bash.Audio doesn't include WEAP INAM records, but including them and rebuilding the patch doesn't resolve the crashing).When I deleted these 7 WEAP entries from the working (AOS_Patches-excluded) smashed patch, resulting in a smashed plugin that appears (in SSEedit) to be identical to the CTD-inducing version, the game is still able to launch. Despite having the same amount of records as the non-working patch and also being the same filesize, the CRC32 checksum of this edited file is different from the non-working file.I can make a second smashed patch in which AOS_Patches and the non-working smashed patch 1 are smashed together, and the game is able to launch normally with smashed patch 2 activated. However this isn't really useful because smashed patch 1 is the conflict winner in the load order and as such overwrites any desired changes from AOS_Patches. I suppose I could drag AOS_Patches below it but having to do the same with Undeath would significantly interfere with my load order. It seems like there's something aside from records that's being edited when I include AOS_Patches (and presumably Animated Weapon Enchants and Undeath). I'm kind of at the limit of my knowhow as to how to debug this though. All of my plugins are form44 in case that matters; the AOS_Patches is generated by Merge Plugins standalone. Anyone have any ideas for troubleshooting? Edit: I figured it might help if I upload the smashed patches. 1: Working version of smashed patch (AOS_Patches.esp excluded): https://mega.nz/#!IqYhxBgD!0lYmHodc3tvHZggCcc4ydh_kgL_d1o_PsXOSLECoWPk 2: Non-working version of smashed patch (AOS_Patches.esp included): https://mega.nz/#!dqgH2YzR!5q77PLyW6phtprV03qz8tkulXQrkTN98JsbozVib--A 3: Working version of smashed patch (AOS_Patches.esp excluded) where I removed the 7 extra records in SSEedit such that its record list matches that of the non-working version: https://mega.nz/#!ImwSUZLK!gyoB6ThGPEd6Id5vK8cmeXqRORdAqEXLwyUNLp6sHxQ

Hey Mator, thanks for your response. I had tried control-clicking all of the chained elements and toggling "Treat as single entity", and only records with sub-records (e.g. NAMA, NAM9, etc) end up with that flag toggled; FTST doesn't get toggled. I just tried again and got the same behavior. I then toggled "Treat as single entity" on the entire NPC_ record and was rewarded with the blue circled (1) next to it, but when I rebuild the smashed patch the FTST record still wasn't preserved. It's not a huge deal and it looks fine in-game so I'll just roll with it for now. I do have another issue which I'll post in the main Mator Smash thread (sorry, overlooked it when posting this one). Thanks again.

Hi all, I'm tinkering around with how to use Mator Smash and it's working amazingly well for the most part, but there's one particular scenario where I can't get it to behave correctly. The record in question is Ulfric's head texture. In my load order, it's handled as follows: Skyrim.esm (not smashed): default Unofficial Patch (smashed rules #1): same as master Original Opening Scene Extended (not smashed): same as master WICO (smashed rules #2): record is deleted WICO Original Opening Scene patch (not smashed): record is deleted MorrowLoot Ultimate (smashed rules #1): record is resurrected, same as Skyrim.esm MorrowLoot Patches Merged (smashed rules #1): record is deleted as in WICO Small NPC Appearance Mods Merged (smashed rules #2): record is resurrected, same as Skyrim.esm Here's a screenshot of the scenario in SSEEdit, highlighting the problem: https://imgur.com/HJDHN0h Here's a screenshot of the NPC record settings in Mator Smash which I'm using for mods that are not supposed to edit NPC appearance: https://imgur.com/RHjLuj4 (smashed rules #1) Here's a screenshot of the NPC record settings in Mator Smash which I'm using for mods that are only supposed to edit NPC appearance: https://imgur.com/zalsAgM (smashed rules #2) As you can see, the record gets passed around a lot. The conflict-winning mod (before the smashed patch) is my merged appearance mods esp, which contains Males Of Skyrim, which contains a record for Ulfric that seems to depend on having the default head texture. The problem I'm running into is that in this special case, WICO and the Appearance Merge Patch are both mods that edit NPC appearance so I want to use the same smash settings with them. The merge patch contains records for a small number of NPCs that I want to use in preference to WICO's settings. Because WICO removes the head texture (different from master) while the merge patch's record restores the same record as master, Mator Smash decides to bring that change from WICO into the smashed patch. But I need the appearance mods to completely overwrite one another; otherwise I'll get a blend of appearances. I thought I'd be able to do this by chaining all appearance attributes together (as in my screenshot for smashed rules #2) but it doesn't seem to be working as you can see in my SSEEdit results. Everything else is working great; I'm getting skills, inventory, AIdata, etc being forwarded from other mods and mixed into my NPC appearance mod. It seems to be just this one thing that's not getting handled correctly. I could easily fix it in SSEEdit but I'd rather learn how to Smash correctly so that if I see something similar pop up when I'm re-checking the records I can deal with it in an automated way. Thanks for any help!

I just tried to launch TexGen via Mod Organizer 2 using the -sse argument and got the following error: [00:00:00.000] TexGen based on xEdit x64 starting session 2018-01-04 02:42:19[00:00:00.014] Using Skyrim Special Edition Data Path: C:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\[00:00:00.025] Using ini: -sse\My Games\Skyrim Special Edition\Skyrim.ini[00:00:00.036] Fatal: Could not find ini I believe I used the exact same parameter for DynDOLOD 2.30 and it launched just fine. Did I miss something that changed between versions? Why is it appending "-sse" to the ini path?

I figure if this were possible it would already be done, but I might as well ask... In the DynDOLOD mesh list when selecting the grid, I noticed there's a "Full" option which is described as "Full model even if LOD is available". Is there a set of meshes that comprise ground/landscape that I could apply this rule to so as to push back the "landscape pop" that occurs during the LOD->Full transition without having to increase ugrids?

Thanks! I actually just came back to this thread to report I found the other thread about categories and the tip worked. I can't believe you answered so quickly :). I don't know if this behavior is intentional or not, but now that I have the dropdown menu set to "no categories", I'm no longer having the unchecking issue. Perhaps this is a bug?

I have MO 1.3.8 installed and until yesterday it was working great. All of a sudden it bugged out and now I'm wrestling with it. The main problem is that it randomly won't let me uncheck mods. If I have the list of mods in front of me, I can uncheck some of them and the checkmark goes away, but when I click on the other checkboxes absolutely nothing happens in response. The mods that behave this way are random; for instance, I performed the following: 1. clicked on Deadly Dragons checkbox - no response 2. Restarted MO 3. clicked on Deadly Dragons checkbox - no response 4. Restarted MO 5. clicked on Deadly Dragons checkbox - this time the checkmark went away. So I really have to wrestle with it to turn mods on and off. Additionally, MO now refuses to sort by priority; it's always priority within the context of categories, the order of which seems to be locked. An example is shown here: When I launch MO, the console reports the following (no idea if this is relevant): 22:15:26 [W] QSslSocket: cannot resolve TLSv1_2_client_method22:15:26 [W] QSslSocket: cannot resolve TLSv1_1_server_method22:15:26 [W] QSslSocket: cannot resolve TLSv1_2_server_method22:15:26 [W] QSslSocket: cannot resolve SSL_select_next_proto22:15:26 [W] QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb22:15:26 [W] QSslSocket: cannot resolve SSL_get0_next_proto_negotiated22:15:26 [D] ssl support: 122:15:26 [D] Working directory: Z:\Games\Skyrim\Mods\Mod Organizer22:15:26 [D] MO at: Z:\Games\Skyrim\Mods\Mod Organizer22:15:26 [D] removing obsolete files22:15:26 [D] initializing core22:15:26 [D] initialize plugins22:15:26 [D] looking for plugins in Z:\Games\Skyrim\Mods\Mod Organizer\plugins22:15:26 [D] loaded plugin "bsaExtractor.dll"22:15:26 [D] loaded plugin "checkFNIS.dll"22:15:26 [D] loaded plugin "diagnoseBasic.dll"22:15:26 [D] loaded plugin "gameFallout3.dll"22:15:26 [D] loaded plugin "gameFalloutNV.dll"22:15:26 [D] loaded plugin "gameOblivion.dll"22:15:26 [D] loaded plugin "gameSkyrim.dll"22:15:26 [D] loaded plugin "iniEditor.dll"22:15:26 [D] loaded plugin "installerBAIN.dll"22:15:26 [D] loaded plugin "installerBundle.dll"22:15:26 [D] loaded plugin "installerFomod.dll"22:15:26 [D] loaded plugin "installerManual.dll"22:15:26 [D] loaded plugin "installerNCC.dll"22:15:26 [D] loaded plugin "installerQuick.dll"22:15:26 [D] loaded plugin "NMMImport.dll"22:15:26 [D] loaded plugin "previewBase.dll"22:15:26 [D] loaded plugin "pyCfg.py"22:15:26 [D] loaded plugin "proxyPython.dll"22:15:26 [D] downloads after refresh: 33322:15:26 [D] game path: e:\entertainment\games\steam\steamapps\common\Skyrim22:15:26 [D] managing game at e:\entertainment\games\steam\steamapps\common\Skyrim22:15:26 [D] setting up configured executables22:15:27 [D] configured profile: Stable Requiem Base Troubleshooting22:15:27 [D] initializing tutorials22:15:27 [D] loaded language en-US22:15:27 [D] interface Ethernet seems to be up (address: fe80::fdb6:fe86:b9ff:4038%3)22:15:27 [D] displaying main window22:15:27 [W] QObject::connect: No such signal QtGroupingProxy::aboutToChangeData()22:15:27 [W] QObject::connect: No such signal QtGroupingProxy::postDataChanged()22:15:28 [D] Z:\Games\Skyrim\Mods\Mod Organizer\profiles\Stable Requiem Base Troubleshooting\modlist.txt saved [] I've tried downloading and reinstalling MO over top of the existing installation and it didn't help. What other troubleshooting steps should I try?