Mousetick

Sorry for being thick in the head, but this is ambiguous... Are you considering a REFR marked Deleted in an ESP as an overwrite or not in the statement above? Again, ignoring the fact that Deleted references are dangerous, a Deleted-flagged REFR can be interpreted as "not existing", rather than "existing and overwritten". Does a Deleted-flagged REFR in an ESP at the highest priority in the load order cause the Large Reference Bugs? Can you please clarify, thanks. Going on a tangent here, considering that all DLCs and Update.esm are part of the vanilla SSE game, aren't you concerned that issuing all these Deleted Reference warnings for Dawnguard.esm, HearthFires.esm and Update.esm is merely "noise" that doesn't really help and can confuse users? If these references are used by SSE mods and cause CTDs, it's a bug in the mod, not in the vanilla game. For all intents and purposes, these REFR don't exist in the vanilla SSE game - they should not be used. There is no need to "clean" them either. The WIP version of the STEP guide for SSE/SAE doesn't advise users to clean the vanilla masters. They'll be faced with a ton of Deleted Reference warnings and wondering if they've done something wrong, perhaps flooding you with stupid support questions in the process.

A similar question was asked earlier but was not answered. Asking from the point of view of a mod user, not a mod author: Am I correct in assuming that flagging an 'Initially disabled large reference' UDR in a non-ESM plugin as Deleted would turn it into a 'Overwritten large reference' 'Deleted Reference' warning? Disregarding the implications of a Deleted reference, would that actually prevent the Large Reference Bugs? Thanks.

Do you mean it's not striped, grooved and/or scaly like you'd expect pine bark to look? I agree it's a bit uncharacteristic, but my understanding is that it depends on the variant and/or the age of the tree. I don't understand why these trees are called pines in the game in the first place. They're more like firs, really, aren't they? Here is a picture of Abies procera which shows bark that's smooth like HLT - you'll need to zoom in:

Yes Nemesis is supposed to work for FNIS stuff, at least most of it, there are probably a few exceptions. Regarding FNIS Sexy Move, there is a post in the comments section on Nexus (page 2 at the time of this writing) which explains how to make it work with Nemesis. I don't know if it's correct, I'm not familiar with this mod, I don't use it. You can always try the procedure given in that post. Whenever you run into issues, always search online and look at the comments and bug reports sections of the mod on Nexus. Yes it's time-consuming to sort through all the outdated and wrong information, but you're very likely to find some answers.

I've tried HLT (the full set) and my first impressions after a quick tour: it's quite nice. Pine trees are gorgeous with the larger/higher tree option. A definite improvement over EVT for my taste. Dead pine branches on trees and almost dead pine trees are a very nice detail to me. Makes the world more "realistic" and "alive", less cardboard-like. Pine bark and logs are ok, nothing more. Snowy pine trees have a very thick coat of snow on them and lack variety in coating. Slightly too much on the "artificial" side. I got the feeling the snow was about to collapse to the ground at any moment but sadly this doesn't happen. Lovely "waving" animations of branches, separate trees waving out of sync. Aspen trees are a downgrade from AA in my view. Bark, foliage, shape don't look as good IMHO. Even though I tend to dislike it, I think the wobbling/fluttering of foliage in AA, absent from HLT, is closer to real aspens or trees with similar foliage. Performance-wise I didn't notice any difference compared to EVT + AA, but I didn't really test for it. No brightness or shininess in darkness or shade. I haven't looked at the custom marsh trees yet. I think I'm going to settle on a HLT + AA combo in the end. @DoubleYou Have you tested out this mod like you were going to, and if so, what is your appraisal?

Admittedly this is a corner case and there should be no issue with ESL-flagging such plugins in most situations. One should just be careful not to ESLify them blindly. There is little information available and what is available is often incomplete or contradictory. Since there is no official documentation from Bethesda, all we have to rely on are anecdotal evidence, hearsay, folklore and urban legends... The xEdit documentation says: This seems to indicate that if the plugin that contains new CELL or WRLD records is not .esm, nor .esl, nor ESM-flagged, then ESL-flagging it should be safe. In which case the warning given by the xEdit script to find candidates is erroneous, and -PseudoESL may be correct and safe in any case. You'd have to experiment with that in practice to confirm. Also, if there's nothing else in your load order that modifies the added CELL or WRLD, it should be safe to ESLify as well. Yeah it's perfectly fine to flag SkyUI and Racemenu, the advice given is incorrect. I think the MA (mod author) was overly cautious because these mods are widely used and may have been confused because they use scripts (which can break when compacting plugins). Regarding FNIS, I don't know for sure as I don't use it. I'm using Nemesis which is a replacement for FNIS. If you want to use it, there are helpful STEP instructions. You must definitely do it before starting your full playthrough but you can wait until it's absolutely necessary while you're still building up your mod collection for that playthrough. Some pointers from the xEdit documentation: Important dangers when compacting FormIDs Compacting plugins And some advice: Thoroughly read the documentation linked above, especially the dangers. Don't bother trying to figure out if a plugin that uses its own scripts will break or not because it's using a very specific API. It's way too complicated. Just discriminate based on whether a plugin comes with its own scripts or not. If it does come with its own scripts, don't take any risk and don't compact it, period. To find out if a plugin uses its own scripts, examine the mod contents in MO and check if it has a scripts folder: If a mod contains .bsa (BSA archive) files, you need to look inside the archive to find out if it contains a scripts folder. This is easy to do in MO using the Preview feature: Once you're read the xEdit documentation linked above, you'll know that compacting a plugin that is used as master for other plugins breaks those dependent plugins. However there is an extremely useful feature of xEdit, which automatically updates all dependent plugins if they are loaded at the same time that the master is compacted. For example: Therefore it's better to compact plugins as late as possible when the mod list is nearly finalized or once a mod and all its dependent plugins (add-ons, patches, ...) are added as a complete set, so that compacting the master plugin will update the dependent plugins without breaking them. You can start by compacting compatibility patch plugins, assuming all other conditions are satisfied, as they typically are at the end of the dependency chain and nothing else uses them as master. It may go without saying, but always start a new game after compacting plugins, even while testing. Existing saves will be broken. Maybe obvious too, if you later add a plugin that depends on another plugin that you already compacted, you'll need to revert the compacted plugin to its original form and redo the whole compacting process from scratch. Beware the mods and plugins shown in the pictures above are used only for illustration purpose, this is not an indication that they're actually safe or unsafe to compact.

It kind of does in a way if you combine it with -autoload and enable the 'Show file header flags' in the general options, as explained here. But it can be dangerous because it shows plugins that contain new CELL records as safe candidates for flagging. I prefer using the 'Find ESP plugins which could be turned into ESL' script, it's a little more cumbersome and takes a little more time, but it's the safest method in my view. There is this tool which you may want to try if you find the method I suggested too complicated: Ruddy88 ESLify. It looks like it might be a little more automated and easier to use. But, I don't have any experience with it, haven't even tried it, so I don't know if it's really good - don't blame me if your game is broken because of it Yes it's good. I read it too when I was learning about ESLifying. Yes and yes.

Note: I edited the instructions above to remove some details about scripts because they're irrelevant. I was trying to be extra-extra-cautious and got mixed up with the scenario where compacting is involved, which is not the case here.

You can start with the easiest and safest ones to ESLify. Part 1 Load everything into xEdit. Right-click anywhere on the left list and select 'Apply Script'. Type "find esp" in the text field, and select 'Find ESP plugins which could be turned into ESL' in the menu below. Click OK. Copy and paste the output into a text editor so you can reference it later. Part 2 In the script results you copied to the text editor, look for plugins which "Can be turned into ESL by adding ESL flag in TES4 header" and only exactly these. Ignore those that need to be compacted, or those that have a CELL warning. Make a separate list of the good candidates. Part 3 In xEdit, select a good candidate plugin in the list on the left, right-click on 'Record Flags' line on the right panel and select 'Edit'. Check the ESL box and click OK. Repeat 1 & 2 for each good candidate. Exit xEdit and save the plugins, make backups if desired. Part 4 Run LOOT. ??? Profit. Note that if you're testing some plugins that you've ESLified and aren't sure if you're going to keep them, rather than removing them from your mod list in MO, disable their corresponding mod. Otherwise if you decide later to re-install them, you'll need to re-ESLify them again.

Normal plugins are indexed in the load order using a base 16 numbering scheme rather than base 10, starting at 00. Number 10 in base 10 is represented as 0A in base 16, 11 as 0B, ...15 as 0F, 16 is 10, 17 is 11, and so on. FE is the highest index, (15 x 16) + 14 = 254, for a maximum total of 254 + 1 = 255 normal plugins, since 00 is the first plugin and counts as one. The FF index is reserved by the engine. Light plugins are indexed in the same way, but they are prefixed by FE. The first light plugin is indexed FE:000, the second FE:001, the tenth FE:00A, and so on. Theoretical maximum number of light plugins: 4096. They're called 'light' I guess because they can only contain a maximum of 4096 records. You can see the plugin indexes on the right side of MO in the Mod Index column. MO is telling you that you have a normal plugin indexed at FE, and you also have light plugins, the first of which is indexed at FE:000. And apparently that's a problem. I can't confirm nor deny, as I have never reached that point and I don't care to investigate. I haven't merged any plugins as I haven't had the need to do so, and I'd rather avoid it if I can. So I can't offer any advice. Instead I've been ESLifying normal plugins so they become light plugins (aka ESPFE), by compacting them first if necessary, then flagging them as light. This can all be done in xEdit. There are some gotchas to this process and it must be done carefully only on plugins that are safe to ESLify. You should not merge UHDAP plugins for 2 reasons. First, they need to remain separate as they are used to load their corresponding .bsa (BSA archive) file. If you merge them you'll break their association. In theory you could merge them if you also merged their BSA archives. Second, they're already ESPFE (light) plugins so they don't count towards the normal plugin limit, merging them would be useless.

The plugins I converted, only a couple if I remember correctly, were quite simple. Converting them in CK was just a matter of opening the plugin and saving it. If CK warns about stuff, it may be an indication that the plugin may not work at all in SSE, whether it's form 43 or form 44, or that the plugin depends on another plugin that's not an ESM. In any case, you should examine the plugin in xEdit beforehand, check for errors, etc. But why go through all this trouble for a piece of armor? There are ~3000 armor mods available on Nexus for SSE. You should be able to find something that you like. You can use the console to add items to your inventory so you can verify them. Please search online to find out how.

I don't really know. It's supposed to be bad when used with SSE...? I've installed a few mods with Form 43 but I always converted them to 44 so I wouldn't have to worry about potential issues caused by them, real or not.

First crash occurred while loading SexLabTools.bsa. Second crash occurred while saving the game to Save2_328F920D_0_507269736F6E6572_WhiterunBanneredMare_000009_20220130144214_1_1. The log shows: Possible relevant objects (2) { [ 144] TESNPC(Name: `Miraak`, FormId: 040200D9, File: `Dragonborn.esm`) [ 144] Character(FormId: FF00124F, BaseForm: TESNPC(Name: `Miraak`, FormId: 040200D9, File: `Dragonborn.esm`)) } This is just a hint. It doesn't necessarily mean this particular object is faulty. But if you have a mod that modifies this NPC you can start looking there. Don't assume people know intrinsically what you're talking about. Please make an effort to provide some context. You're using ASLAL, and you started a new game, yes? In any case, this has nothing to do with Actor Limit Fix or Bug Fixes SSE.

Forgive me for being nosy, but I can't help wondering. The first thing I asked you to try for troubleshooting, was to turn off whatever security software you were using. This wasn't meant lightly or to put you at risk. This was intended to get this potential culprit out of the way first, because it's the most likely culprit in scenarios like this. So what exactly happened there? Was there something that wasn't clear about the need to. turn. the. damn. thing. OFF? Furthermore, doesn't your security tool keep you informed about the blocking actions it takes? Isn't there a log or dashboard somewhere? Some notification perhaps? Or does it mess with your system silently and leave you constantly in the dark as to what might have gone wrong? The amount of time and productivity wasted by these 3rd-party security tools is quite amazing.

This is the end of crash the log file. It tells us you are using 2 Net Script Framework plugins: Actor Limit Fix, and Bug Fixes SSE. Nothing more. The whole log file contains a lot more, potentially helpful, information about the crash.

I'll read your latest report later if needed, but in the meantime: are you using BitDefender by any chance? Have you tried googling 'skse windows 11'? First search result, at redddit: Yeah...I gambled and lost (Windows 11 and MO2 and SKSE) Related: https://github.com/ModOrganizer2/modorganizer/issues/1596 https://github.com/ModOrganizer2/modorganizer/issues/1561 You may want to read all that. Please report back thereafter.

It seems my last instructions were wrong sorry for the mix-up. Let's do this again: Please revert your testing profile to only SKSE + USSEP + ASLAL. Install 'SSE Engine Fixes (Part 2) - skse64 Preloader and TBB Lib' and only Part 2. That is, manually copy d3dx9_42.dll, tbb.dll and tbbmalloc.dll from the .7z archive to the game folder (i.e. folder containing SkyrimSE.exe). Don't install Part 1. Install/enable '.NET Script Framework'. Test again. Post the following logs: From 'C:\Steam\Steam\steamapps\common\Skyrim Special Edition': d3dx9_42.log. From '\Documents\My Games\Skyrim Special Edition\SKSE': skse64.log, skse64_loader.log, skse64_steam_loader.log. From MO, select the '.NET Script Framework' mod, right-click and select 'Open in Explorer', then in Windows Explorer, open the NetScriptFramework folder within: NetScriptFramework.log.txt. From MO's overwrite folder, inside NetScriptFramework/Crash folder if present: any file found within. The SKSE log you posted above shows that the game is saving, SKSE is starting to create a co-save, and that process is interrupted because the log abruptly stops there. So nothing new here. I doubt the test above will bring much useful information but it's worth a shot. Seriously running out of ideas now... Do you have an SKSE.ini? Try storing game saves inside MO's profile instead of the 'Documents\My Games\Skyrim Special Edition' by checking the relevant option in MO profile (see screenshot below). Test again. In Windows Explorer, navigate to 'C:\Steam\Steam\steamapps\common\Skyrim Special Edition', right-click skse64_loader.exe and select Properties. In the Properties window, select the Compatibility tab, check the 'Run this program as administrator' option, click OK. Then test again, you should get a UAC prompt, accept or enter admin password if needed. Reinstall Windows 10. Just kidding

Weird. It sounds like your installation is ok, so there must be something in your Windows environment that's causing trouble. Try turning off any software that's running in the background and is not part of Windows, particularly cloud storage apps (OneDrive, Google Drive, DropBox and the like...). Some stuff may still live in the background even when switched off via their UI, so an uninstall might be necessary. By the way, which Windows version are you using? Post the SKSE logs as attachments. skse64.log, skse64_loader.log, skse64_steam_loader.log are found in My Documents/My Games/Skyrim Special Edition/SKSE/. Install 'SSE Engine Fixes (Part 1)' and '.NET Script Framework'. Test again and see if a crash log is generated (normally found in NetScriptFramework/Crash/ within MO's overwrite folder when MO regains control after the crash).

I missed the fact in your first post that you had already fully installed the guide, sorry. Are you using a dedicated MO profile for testing? If not, please create a new empty profile, and enable only SKSE, USSEP and ASLAL. To make sure there isn't anything else. Temporarily move away the file from 'SSE Engine Fixes (Part 1)' which is still in the Skyrim SE game folder: d3dx9_42.dll. It's still active because it's not managed by MO. Test again. Temporarily move away the Skyrim configuration files (Skyrim.ini, SkyrimPrefs.ini, SkyrimCustom.ini). They are in MO's profile folder if you configured the test profile with 'Use Profile-specific Game INI Files', or in 'Documents/My Games/Skyrim Special Edition' otherwise. Run 'Skyrim Special Edition Launcher' from MO, adjust display resolution if needed and leave everything else as is. Quit the launcher without starting the game. Test again.

So this is a completely fresh installation from scratch, without any leftovers from a previous installation? Please confirm. First off, to save yourself a lot of troubleshooting aggravation, install the USSEP (Unofficial Skyrim Special Edition Patch) and ASLAL (Alternate Start - Live Another Life) mods, add them to your MO test profile in that order, and enable them. Please refer to the STEP guide for download links and installation instructions, or ask if you need further help with that. With ASLAL active, you'll be presented with the character creation screen right after selecting 'New' from the game main menu. Immediately after accepting the character and naming it, you'll be teleported to a cell and the game will autosave. Result: No more waiting for the whole cart ride intro sequence to finish, dozens and dozens of minutes saved in the process. Second, are you using any kind of antivirus or security software? Turn it/them off completely for testing purposes. Even if you can only turn off temporarily, do it so you can test while it's turned off. Reboot the computer if necessary, but turn it OFF. Don't use exclusions or anything like that - turn it OFF If you're not sure whether you are using such piece of software, you're probably using the one built into Windows without knowing. Doesn't matter which it is - turn it OFF Then try a new game save. The save in TMP format is just a consequence of the game crashing while saving. It's a symptom, not a cause.

Your Skyrim.ini does contain the [General] section, it's just further down in the file, past [Actor], [Archive], [Audio], etc. BethINI sorts sections and settings within each section alphabetically. Everything looks all right. I guess it could be a bug in xEdit when it converts the language setting to lowercase, with your OS language, ENGLISH becomes 'englısh'. I'm surprised this is not a more widespread problem.

FYI there is a patch for Hearthfire Extended and Fishing CC: Hearthfires Extended and Creation Club Fishing Patch (Nexus). Apparently there is an issue when building both Fishing CC aquariums and HE extended cellars... I have no idea what the actual issue is, or whether this patch works, or if it's good. I don't use SAE nor the Fishing CC content. But it may be relevant to the STEP 2.0 guide.

Thanks. The Skyrim.ini you attached is valid, it contains sLanguage=english with a standard lowercase "i". I tried running xEdit with it and there is no issue, as expected. Where exactly are you seeing your language's letter "ı"? Are you using profile-specific INI files in MO? As shown here: If you are using profile-specific INI files, you need to look for Skyrim.ini, SkyrimCustom.ini and SkyrimPrefs.ini in your MO profile folder. Click on the Folders menu in MO and select 'Open INIs Folder' to open a Windows Explorer window for that folder: Then please post the Skyrim.ini and SkyrimCustom.ini files as attachments.

Ok, thanks. I'm still not convinced your OS language is the direct cause, as xEdit doesn't use it for setting the language. xEdit only uses the language setting from Skyrim configuration files or from the command line if specified. Could you please post your Skyrim.ini and SkyrimCustom.ini (if it exists) from your 'Documents\My Games\Skyrim Special Edition', folder as attachments. Using the command line option is fine as a workaround, but you may still have something wrong with your Skyrim configuration files, which could cause other issues elsewhere. The same command line option applies to the TexGen, xLODGen and DynDOLOD tools. They're all built "on top of" xEdit.

So, were you able to resolve the xEdit strings error issue in the end? If so please describe what you think caused it to the best of your knowledge, and describe the solution you used for the benefit of others who may encounter the same issue and bump into this topic. This particular one is completely normal and harmless. As Z mentioned above, please start a new topic about any new issue or question rather than continuing an existing one that's unrelated. And please provide some context. Like, what are you trying to accomplish by checking for errors in the vanilla plugins? I'd suggest not to waste your time and to leave them alone.