z929669

I guess it's subjective then. Another problem is that we don't own or ultimately control Discord info. I like the idea of STEP Discord channels for general discussion and hangouts, but for solutions and informative posts, it's not as reliable IMO. Googling is one issue, but so is linking to a specific post from anywhere else. Anyone can see such a post if it's on the forums. With Discord, I think you would need to join the channel and all that. Then there is the problem of longevity and reliability of the info ... call me skeptical, I guess. It seems redundant to use both Discord and the forums. Just that much more work to support yet another venue.

It looks correct ... but there are also three files that should be in the actual Skyrim Special Edition game folder adjacent to the REAL /Data dir. Also, to partially rule out SKSE, try launching the game via MO using the Skyrim launcher. If it loads, you should see an SKSE not running message, but it *should* still load even if there is an issue is with SKSE config. BUT, before you do that: did you configure LOOT in MO2 per the STEP guide instructions? Did you run LOOT? Apply load order changes? Read LOOT warnings/errors and correct them? Do these things first. Then ... ... since you are running a custom mod list, next step would be to disable all mods but for the cleaned SSE masters and SKSE64. Then try launching with the SKSE launcher in MO2. If it works, you likely have a mod compatibility issue. In that case, enable mods in small batches down the list, run LOOT, sort/apply, launch game until it crashes to find the culprit(s).

Waiting on Mediawiki 1.35 ... sometime in August. Then it will be a lot of work on the backend getting that working. Probably September-ish for forum update IF they actually release MW 1.35 in August. Even then, Discord is largely redundant with forums, and the info on past resolutions is harder to find than on the forums, IMO.

ditto, that would be the simplest explanation. There are a hundred other explanations if not that. I added this explicitly to this part of the guide.

You need to run the SKSE loader to launch Skyrim or at least check that. See the instructions at the bottom of the page (also, review the whole page just to be sure). It could also be that you have not followed/read the System Setup Guide completely/correctly. I personally install Steam in its default location and MO2 according to the STEP Guide; however, I have taken ownership of all files on all drives and given myself "full control", which would be frowned upon by the more paranoid security gurus. Installing Steam and all mod-related tools/mods to a custom path and taking ownership + revising security to those paths is the more secure way of doing things ... all addressed in the guide linked. Also, follow STEP 1 of the STEP Guide and probably also STEP 2 & STEP 5.

I clarified the instruction

@sheson I made some cohesion edits to the STEP Guide that may alleviate some LOD-related setup posting on these forums. Also, I ran into this issue just recently. Specifically, "ran out of memory" error code: FAILED [decompress] (8007000e). Windows clean boot fixed, but it was specifically 'system' RAM limit and not GPU RAM ... I was watching both at the time. "C:\Modding\Tools\DynDOLOD\Edit Scripts\Texconvx64.exe" -nologo -y -f BC7_UNORM -bc q -o "C:\Modding\Tools\DynDOLOD\DynDOLOD_Output\Textures\DynDOLOD\LOD" "C:\Modding\Tools\DynDOLOD\DynDOLOD_Output\Textures\DynDOLOD\LOD\DynDOLOD_DLC2SolstheimWorld.dds"I have 32 GB RAM, and the program seems to accumulate used RAM from start all the way through addressing the Solthseim stuff before reallocating (on my successful run, I went from 2.4 GB system RAM utilization to a peak of 30.8 GB, followed by 4.4 GB once SolstheimWorld textures completed). If you know of a way to get the program to swap RAM just prior to generating the SolthseimWord textures, maybe it would alleviate. It seems like the RAM accumulation is prior to worldspace file work, and that SolthseimWorld gets and unfair shake, because it is first up. It never went over about 10 GB after SolthseimWorld. Anyway, just for benefit of anyone else out there with this issue: [spoiler=Env]date/time : 2020-07-29, 23:27:28, 19ms computer name : DHVP user name : David registered owner : David operating system : Windows 10 x64 build 19041 system language : English system up time : 28 minutes 55 seconds program up time : 7 minutes 53 seconds processors : 16x AMD Ryzen 9 3950X 16-Core Processor physical memory : 1969/32687 MB (free/total) free disk space : (C:) 1618.86 GB display mode : 2560x1440, 32 bit process id : $42ac allocated memory : 1.66 GB largest free block : 131024.78 GB command line : "C:\Modding\Tools\DynDOLOD\DynDOLODx64.exe" -SSE executable : DynDOLODx64.exe exec. date/time : 2020-07-13 20:00 version : 2.84.0.0 compiled with : Delphi 10.2 Tokyo madExcept version : 5.0.0 callstack crc : $7bedbd4b, $812c8f33, $ddb3e6df exception number : 1 exception class : Exception exception message : Executing TexConv returned error 00000001: "C:\Modding\Tools\DynDOLOD\Edit Scripts\Texconvx64.exe" -nologo -y -f BC7_UNORM -bc q -o "C:\Modding\Tools\DynDOLOD\DynDOLOD_Output\Textures\DynDOLOD\LOD" "C:\Modding\Tools\DynDOLOD\DynDOLOD_Output\Textures\DynDOLOD\LOD\DynDOLOD_DLC2SolstheimWorld.dds".

Bump DW's question ^ Could also be a LOD issue if this is only apparent from distance (?). In that case, revisit LOD config, as it has been rewritten for clarity.

This may be relevant to some but not all. Will add a note to the Guide.

@DualityShift Thanks, that fixed the issue, as it looks like it is available via the guide link now

Tech fixed this Intentional, disregard Textures aren't overwritten unless by those in a BSA riding a plugin that is higher priority than HD Road Signs. Please specify the mod/BSA if that's the case. Guessing that you extracted BSAs?

We will do so if it gets hidden again, but looks fine for the time being.

I provided some context for the ENB piece of the guide. Have a look for hopefully informative answers to your last two questions.

I did update the instructions a bit to clarify some things, but these things were and are part of the guide instructions. See the Tool Setup and table following.

Updated the system specs wiki Form to allow more modern PC hardware values. See OP for link to add/update your system specs.

You cannot delete posts, but you can edit your own post for up to 15 minutes after posting. This is noted in our Citizenship Guide that includes a link to a detailed rationale for this.

We made a couple of edits to the info in the OP

Please report errors for a particular guide by navigating to the relevant forum using the link in the guide ... all guides should have a corresponding forum link:

I recently added this restriction to standard Members after we had a SPAM event ... to thwart any new registrants that could be spammers. We have an elevated Members group that I will switch Members to once they have been around for a while (like you). Still need to figure out the criteria and determine how this is handled once we move to the new software, so I have removed the restriction for now.

Fixed that mess ;) (use the special BB code > spoiler in the editor)

Your current contributions as a site member and content contributor and poster on forums, etc. is all that we can hope for; although, we do appreciate any monetary support you are willing/able to provide ... it's not expected though ;)

If your guide was built using our Pack system on the wiki, then the 'heaviest' portion will be the mod tables ... same goes for any guide really. You might consider subbing out each different mod table in that case. Text takes no time at all to serve up. Also, using links that open in other tabs could help, particularly when you are editing the guide. Imagine: user is looking at your guide (while you are in the midst of editing), user clicks a link on your guide, link replaces current browser content, you save your edit, user clicks 'back', user must reload entire page, since it has changed (or their local cache misses your changes, potentially ... can't get around that I suppose) Thanks for breaking it up though. There are some slick ways to sub out your guide(s), so I encourage you to investigate some of the methods used elsewhere. I will try to find some examples ... EDIT: See the {{ArchiveBox}} template on the wiki to see about ideas of how to enhance your breadcrumb and TOC on large guides broken up into smaller pages ... following is an example of what it looks like: https://wiki.step-project.com/Project_talk:Data_Dictionary

NOTE: the above are NOT SMW calls. They are standard Mediawiki templates. These are NOT an issue, so please keep using them. AVOID use of inline HTML/CSS If anyone is reaching the template threshold for a single page, then it is best to break it up and span 2 or more separate pages by using either internal links or (maybe even better when talking a single 'article') ... subpages Huge guide pages could be the real issue, especially if they are popular. To mitigate these issues, I think it would be best if personal guide authors (or the current guide stewards) went into their guide articles and parsed them across 2 or more pages (beginning of article on current page, and maybe create one or more subpages where you can break up the rest and link them all together) ... they should all be using the same Categories this way if I remember correctly. You may need to get creative with the TOC, but I can't say offhand how TOC might be affected without actually tinkering around. Until this is done, it may be difficult to work with our wiki outside of low-traffic hours (e.g., 12am-6am Central US time) My judgement yesterday that the wiki seemed OK and that Diana's edit may have fixed was likely WRONG ... more likely, it was just a time of day when we had relatively low traffic to the site and those huge guide pages in particular. EDIT: I finally found where s4n buried the server config files I needed to tweak. I made some changes that should reduce the 504 errors ... until we get some of the larger guides broken into subpages, the changes will only reduce the errors, and page load times should now take up to a minute before presenting 504, so just be patient. EDIT2: I also modified some of the fpm pool variables, so we should not see nearly as much bottlenecking now (I hope)

I just checked the wiki, and it seems to be behaving normally now (crossing fingers). It looks like the recent change Diana made might have done the trick ... I don't have time to look carefully at the wiki markup in that last diff, but I suspect there was some kind of recursive or circular Semantic call in there somewhere. If anyone cares to look closely at that diff, maybe that person can identify a possible culprit. HTML styling and class 'wikitable' shouldn't be a problem ... look for Semantic calls and curly braces. This corroborates my suspicion that there was a problematic edit to one of the recent guide pages beginning on the 16th. Anyone care to confirm that the wiki is behaving now and/or the latest removed content in the diff above?

I found one nginx configuration issue that I resolved, but I am not sure if that had any impact. The wiki seems to be working, but it is the timeouts and worker processes that I need to figure out. php, fpm, fast cgi appear to be the complainers. It all has to do with the size of certain requests, I think. Semantic is the likely root cause, and many requests (just serving up any guide or page with many nesting/recursive Semantic dependencies is the main issue I think. When we are seeing 504, I think it is mostly related to timeout, and not a 'broken' wiki. I can share logs at some point, but they may not make much sense, given the level of obfuscation that s4n has placed on the entire server config ... while this undoubtedly thwarts unwanted hackers, it also thwarts legit admin.