Arthmoor

The thrashing issue could only be a factor if that still exists as a bug, but nobody has been able to conclusively prove that this is the case. You'll note my reply on the Reddit thread. The relationship is only possible if the old thrashing bug got reintroduced into SSE.

No, this cannot be used as a substitute for the problem. The mods must be loaded into the SSE CK and saved there. Simply changing form numbers is not enough and will continue to produce problem files that then become impossible to diagnose properly. Exactly. Anyone porting a mod over, or a mod author doing it themselves, should be following proper procedure and resaving in the SSE CK. It is the only guaranteed way this will get solved. Even if this turns out not to be the cause of the problem this thread is about, it's going to eliminate the cause of a very similar type of corruption from the game, and given the number of people already saying this is solving the problem, it may well turn out to be the only reason this thread even exists.

There are exceptions in place in the form reader for the official files. That's why they can get away with having mixed forms and other stuff can't. When even the game's developer flat out says you have to resave the ESP in the new CK, there's no excuse for not actually doing it.

Are you absolutely certain you do not have any leftover loose files in your Data folder, specifically in these 2 places: meshes\actors\character\FaceGenData\FaceGeom textures\actors\character\FaceGenData\FaceTint Not all mods that alter facegen data are packed with a BSA, so removing them may leave old pieces behind. This facegen data in these folders must match what the ESP file has to say about the NPC. If they do not match, you get grey face bugs. So what you'd need to check on was whether or not "The Hairstyler" included matching facegen for any edited NPCs. As far as USLEEP itself, no, those tint layer edits won't be causing such problems. The CK saves those stray bits anytime an NPC is edited for any reason and they've never been shown to be a problem.

Development copies of Wrye Bash are here: https://afkmods.iguanadons.net/index.php?/topic/4966-wrye-bash-all-games/ Second post. Development copies of xEdit are here: https://afkmods.iguanadons.net/index.php?/topic/3750-wipz-tes5edit/ Link at the bottom of the OP. Pretty sure LOOT also has a dev version that supports sorting with ESL files. The SSE CK has been updated and will support creating ESL files.

For SSE the actual limit is 248 mods. 5 are occupied by official ESM files, 1 is taken by the save, and 1 slot is effectively reserved for ESL form mapping. ESL files allow you to partly get around this limitation but they have their own limits as specified in the OP's link. Though even with as few as ~300 more mod slots opening up, that ought to be more than enough to satisfy even the biggest diehards.

Seeing the same issue here as well, looks just like the image in the OP.

The unofficial patch fixes the script portion of the system that sends you on the actual trip to where you're going. It doesn't need to edit dialogue to do this, only the script. Expanded Carriage Service probably just didn't carry over the patch's fix to his modified version of the script.

Probably won't even take that long. These temporary upheavals are nothing new, they've happened 13 times before (SSE + LE) and the community always adjusts.

Then we have do agree to disagree. IMO, cutting off PCs and free modding takes away 90 % of potential mod creators and the game is dead within year or two. The game will be dead to us, but we are not the audience they are courting. PC in general is along for the ride and modding is only a tool R&D uses to farm ideas and potential talent pool for the CC.

This is stale information the clickbaiters on Youtube have not bothered to correct (gee, wonder why). CC does not download any files to SSE that are not wanted. Nor does Fallout 4 after its last patch.

Anyone following advice like this should be prepared to get left behind in a hurry though when mods begin updating to account for base record changes introduced by the patch. SKSE64 was updated within hours of the beta patch going up so that's no longer a concern for people testing it.

In answer to the question in the title: No.

I only know how it works in passing, not the finer details. The risk is definitely there though since it skips ahead through so much of it and there's no indication that any care was taken to account for any subtle details such as certain variables needing to be set. Either way, it's not wise to discount Apollo's assessment of things. He's not wrong in what he said by any means on the subject. I would argue he's probably among the most knowledgeable about what the CW does and does not require from the MQ, so if he's saying the same thing I am, it means we both arrived at the same conclusion from two different approaches. Therefore it's not a good idea to simply dismiss those conclusions lightly. All I can say with absolutely certainty is that neither the MQ nor the CW will ever be broken when running LAL, and Apollo has assured me in the past that his overhaul would not impact that at all because I didn't skip things necessary to setting things up in Whiterun.

Considering how closely I've worked with it I'd say I'm in a pretty good position to determine that the integration is not that vastly overstated and that brute force bypasses are not a recommended way to do things. Apollo may have overstated his initial response, but he's not wrong in his followup. So you've got two people who have closely examined stuff relating to the early MQ and CW both telling you the same thing, and we're both highly regarded for our general knowledge of the game itself. Take that for what it's worth. People are free to use what they like in their games, but IMO they should go into it as informed users.

This actually isn't true though. The way in which SU goes about doing it runs a pretty big risk of bypassing important details because it just blindly completes early quests that the game references many times later on. These are not things that can be so casually set aside because of how tightly integrated the CW is with the MQ.

Don't forget to port the ESP too because the ESP has quests in form 43 that need to be updated.

It was a bug in Open Cities that's since been fixed. You need to update :P

You can't. Steam doesn't do patch rollbacks like GoG Galaxy does.

The guy doing the Fallout 4 releases explained this once already, but I guess nobody wants to acknowledge that. He doesn't own SSE and doesn't plan to own SSE. He's also the only team member who isn't currently bogged down with other stuff that's actually important right now. So he's been working on getting F4SE some love it needed too. I don't think it's a case of the others just wanting to be left alone at this point. Although I wouldn't blame them with the level of entitlement people seem to have concerning the project.

It's neither holding things up nor is the SSE modding community dying out. That's hyperbole that has no place. SSE's modding community is very much alive and well and churning out quality stuff. All without the supposed absolute necessity of SKSE. Not entirely true. It only becomes problematic in LE if you have a massive load order, and even then it's entirely solved by the SKSE memory patch. The reason it's no longer an issue in SSE is because SSE has no need for that memory patch. Honestly, SKSE has become a crutch. One people seem unwilling to consider as such. Just look around at the various mods that claimed to once need it that ported to SSE just fine without it. Mod authors just need to be willing to be more inventive in their solutions. Obviously DLL hacks are a different story, but then SSE doesn't require them so it's kind of a moot point.

The problem is is that most of the people who are offering to help think this is as simple as knowing C++ and how to compile code. That's barely even going to scratch the surface of the work that actually needs doing and for some reason people just aren't getting that. Again, this needs a skill set only a handful of people in this community have, and as said before, those people are already on the team.

There's a huge difference between casually porting a random mod and rebuilding SKSE from scratch in 64 bit code. Porting mods is bordering on ludicrously simple, while SKSE would be at the opposite end of that scale requiring skills that maybe 5 people in this community actually have. Those 5 people happen to already be on the team though, so.....

C/C++, some windows system-level programming and obviously knowledge about Skyrim SE scripting and modding. If you know some programming you can just look at the source code for SKSE (provided by SKSE in 7z archive download) and see what is your skill gap to it. I think that recreation is doable, but will take long time and it should be api-compatibile with SKSE (otherwise mods will need to re-write the support). Maybe even better way would be to contact SKSE and join their team to help with porting (I'm not aware of their stance on this though)? If this was as simple as you're making it out to be, someone would have already stepped up and done it. There's considerably more that goes into this stuff than just some basic level Windows programming and a bit of Papyrus experience.

So far as I am aware, No Snow Under The Roof has no deleted references. Obviously neither does USSEP. This issue with floating objects above Bleakwind Basin is due to mods that have deleted references. These are the lucky ones that don't immediately cause a CTD from it. It's very much an issue with mods that needs to be taken up with the authors of those mods, once the unclean mods are identified. I realize this is an old post, but it was just erroneously reported on the USSEP tracker as a vanilla bug.