z929669

@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.

At this point, I don't think we need to delete anything. The ultimate issue is the Semantic Mediawiki software and config ... it may be that we have reached the cap of what Semantic will support as we have it configured. I suspect that our requests timeout is too restrictive and that the wiki is just taking a while to serve up pages that are not cached ... among other things relating to memory, process workers, and PHP as it relates to the wiki. Forums run fine, as always. I will keep looking into it, but s4n had implemented many security barriers that make access to some config settings very difficult for me to troubleshoot/edit ... and he is MIA, so it could be a while before I can resolve. Bouncing PHP fixes but only for minutes now when it used to be months.

I have been messing with things on and off most of the day. Recent additions to the wiki have overloaded associated processes, I suspect. THis would have started on the 17th, so whomever has created anything really big (Pack guide maybe?) has likely put us over the top. We may need to disable the offending pages to resolve until I can figure out another way.

I have restarted PHP again, and things work fine, but soon after bouncing, the problem seems to return. I suspect it has something to do with recently created pages that are heavily reliant on Semantic Mediawiki and possibly customization of certain Semantic dependencies. I don't have time to hunt the issue down right now, but this problem may come back if/when the problematic content is loaded/edited/saved, etc. ( https://wiki.step-project.com/Special:RecentChanges

I just rebooted PHP service, so all is working again

No problem ;) We'll be better situated in the coming months once we get the new site up and running.

I fixed the issue, and we should be back up now. Sorry for the delay, but I was not aware until about 15 minutes ago. My bad though!