z929669

Yes. Always use the 64-bit version on 64-bit architecture. Do the same for DynDOLODx64.exe

Make sure TexGen Output is going to a location outside of the MO virtual file system (your logs indicate that this may not be the case). I send it to my DynDOLOD directory: See that you are running TexGen via MO according to standards (there are other ways to do this, but this is what we recommend) See our System Setup Guide top check that you have your environment set up according to best practice (check MO install method, DynDOLOD install, etc.)

Sounds like havok issues. Are you running with an altered timescale? Ar you not capping FPS via Skyrim.ini or other utility? Using a mod like SSE Display Tweaks also resolves some havok issues by providing an FPS limiter and other GFX fixes. Vortex isn't overly complicated, IMO. It does what it's supposed to do (and prevents issues that basic mod managers like NMM do not and can even cause in some cases). Vortex and MO are definitely your best bet for mod managers. Wrye Bash would also do better, but that is even more technical than the others. Lastly, sort your plugins with LOOT. Check yout your config by comparing to our advice in the System Setup Guide. Also configure SKSE64 properly: https://stepmodifications.org/wiki/SkyrimSE:SKSE64

Your log is showing "access violation". Given that you have DynDOLOD installed in a path outside of UAT control, you may want to be sure that TexGen, DynDOLOD, and LODGen executables have permissions to write to your DynDOLOD install path. Also check antivirus whitelist paths if applicable. From the log: [00:00] Found Bashed Patch, 0.esp. In case there are errors, test if removing the Bashed Patch allows generation without problems. If it does, it means the Bashed Patch is broken. Use a newer version of Wrye Bash to create a new patch You should post those logs on the DynDOLOD thread if removing the bashed patch and verifying permissions on that path do not resolve. @sheson will have better direction for you.

We don't have a FO4 guide curator at this time, but @Majorman and team are working on the FNV guide now.

When you do, please post back your assessment

It pays to read instructions carefully before assuming issues with the instructions themselves Untagged 'bug' from this topic.

... in which case, you should revisit the ENBoost instructions and ensure that it is configured correctly, as I mentioned previously.

Save game all "relevant to current load order"? = is save game compatible with the load order against which you are running? ... since you CTD on a new game, this says that save-game/load-order incompatibility is not the issue. ENBoost is the memory manager tweaks for ENB that are pretty much required for Skyrim LE. It allows you to exceed the 3.2-ish GB limit for 32-bit apps (Skyrim LE in this case). If you are not running this as instructed by the SkyrimLE 3.0.0 guide, then this could be the issue. The best way to resolve your issue is to verify that you have followed the guide completely and correctly. There are many places where you could make a mistake. I would start with ensuring you have ENBoost configured correctly. Then you should check that you have all of the mods required by the Step Patches installed correctly. THEN, you should check that you have followed the System Setup Guide correctly. Once verified, you should try to run a new game to see if you get a CTD again. The persons I mention will get notifications that they should check that post. This is what @MemberName does.

Bashed patch would be for leveled lists according to bash tags. You don't need a bashed patch, but you may need to do your own custom patching with xEdit if you are adding/removing mods from the guide mod list. Some of the mods in the guide are required by the Step Patches as indicated. I wouldn't bother setting up WB and bashed patch unless you are trying to resolve a specific issue. Then you can also just use xEdit.

CTD outdoors, indoors, both? Save games all relevant to current load order? Ar you running ENBoost and custom uGrids > 5? I would consult @TechAngel85 and @Darklocq, since they are the most recent SLE guide curators and may have some ideas. I haven't run LE for years now, so conveniently forget a lot of the gotchas and workarounds.

That's because you are using 'numbered' params, which is the same principle as 'named' params. Both use a "this=that". It just doesn't work with anonymous params or ordered params.

You may want to look at some of the changes I made to the Project:SiteColorPallet No changes to theme colors, just the doc. This will need to be updated in accordance with the template table (or we can simply refer to the template table and omit the keywords from the SiteColorPallet table). I'm setting this page up to articulate with the wiki guidelines so that it can be used as a quick reference for editors.

Go ahead and do your worst to Fc/Fs in DEV then to see if there are any gotchas. If you are OK with it, please add 'heading' or 'ilheading' keyword for salmon. If it all works like we want, I will port this update to live along with all of the other page/template updates I have going in DEV once we have the RD stuff finalized.

don't really 'need' u mean? (Also see my previous response to your previous)

Works for me as long as no existing template calls break. That satisfies all criteria then and everyone is happy. If we do this, all I ask is that 'text=' NOT be used unless required for compat purposes. So always default to anonymous names, else we will have an inconsistency with that template (all future Replace Text changes having 'gotchas').

It's not broken. It's also much simpler to use anonymous parameters, which is why it 's the most common implementation in most wikis and examples. There is very, very rarely justification to use '=' in font resize or color template. In the rare case that it is justifiable, it is easily circumvented. For Alerts, that's not the case, so we use named params. And @DoubleYou's example will work fine I think. The param is anonymous and being set to the equivalent of 'text'. On another note, I am poised to make the keyword changes to Template:Fc, because I want to bring up another likely point of contention. I think the use of our highlight text color for use with inline headings is yuck ... especially when many are used together. It's too bright for one (brighter than our actual headings) and was meant for use with things like Template:Ui and emphasis text, where we really do want to make the text very obvious without using a specific color. This is why I have always used salmon for inline headings. It is close to neutral and has a color temp very close to our standard text, so it's easy to identify without too much bling. See the Wiki Maintenance guide as an example. This looked terrible (killed my eyes) with Template:Ui and Template:Fc using ilheading. It functions exactly as intended now though. So ... I want to repurpose the ilheading keyword to salmon and collapse the others to 2 at most for any one color. Let the debate begin.

I experimented with both months ago, and Highlightjs "just works" the other did not work OOtB and has issues that you will find on the Extension talk or help page. What we have works well enough for our needs and is much simpler to implement. Also, this has the same issue as <pre>. The class works for guide detailed instructions and is better than multiline code tags with bullets, since it is less to code and looks better.

We do have SyntaxHighlight installed. I am updating the Wiki Guidelines page now with all relevant info and use it there for the Mod Pages tab. I am in the process of stripping out all of the general Mediawiki and SMW stuff in favor of providing contextual links to that info and fleshing out an External References tab. Our wiki guide can then focus exclusively on info pertaining to our wiki. This way that guide can remain completely relevant but much shorter and to the point. less to maintain.

In creating the mod page classes, I stumbled upon a fix for <pre> transclusion in guide Recommendations. Have a look at the SKSE64 page and look at the expanded entry in the current SSE guide.

Yes, I plan on doing that, but am waiting to implement changes made to DEV first. Once I do that, I will update the live wiki. EDIT: I just created the class using common.css for now

@TechAngel85 @DoubleYou @Greg @Majorman @Darklocq Forgot to call you guys out for the notifications. See OP

I will retain the same FOMOD structure and method. There will be one fewer levels I think, so no 400. Same number of files and same base assets. Just new LOD models in some cases but not all. The EVT billboards are completely unnecessary. TexGen will create standard and HD billboards that perfectly match each tree every time. HD billboards will have normals, so 4x textures per tree. standard will just be one billboard per tree. Handmade billboards cannot beat the TexGen versions but rather only can be approaching their equivalent.

Install EVT with billboards (which unintuitively installs the 3D LOD meshes) and hide/remove all under: textures/terrain/ meshes/terrain/ Then regen with TexGen 3 using billboards 'tree' & 'HD tree' & 'Render' options and DynDOLOD 3 using whatever options. This should more correctly generate all needed billboards (if you use those in mesh rules) and 3D tree objects on the atlas (sheson will correct my language if needed). Maybe will resolve some issues.

After doing some testing, I'm proposing some standards for wiki markup on mod pages, some of which are known, but I am documenting here for reference by others. The relevant info has been added to a section of our Wiki User Guide. Please add/revise/relocate this reference as best applies (just update this link).