z929669

You can choose to either adhere to the Step mandate to create an official guide, or deviate from vanilla FNV to create an unofficial guide. Both use the guide framework and allow other guides in the framework to reuse mods. This benefits all of our wiki editors. As an example, I just looked at SRB's guide and found 'NVSE', which had a bad link in his guide. I determined where it is being maintained by a quick Google search, and was able to add the mod page. Now this mod can be linked from any wiki page by simply using the following wiki markup and can also be listed in any FNV guide via the framework. [[FalloutNV:NVSE|NVSE]]

If you want to work on updating a Fallout guide, it would definitely be best to work on an official or unofficial guide using our guide framwork. EssArrBee's guide is pretty outdated and does not use the new framework. We could help you get the structure set up and the mod list based on his most recent one. What would need to happen is that guide's mods would need to be added to the wiki. @EssArrBee's guide belongs to the site and the community, so you can legally edit it; although, it should probably be left alone to preserve it's original intent. We version guides for that reason. You could alternatively reproduce it into a new version of that same guide and update it, as you indicate by 'fork'. This is just as much work as using our framework though, and does not benefit the site or other guide creators like you, because data pertaining to mods hard-coded into user pages cannot be 'reused' in other guides without directly hard coding them into another page. This is both redundant and unhelpful to all. Either way, it will be a lot of work, so it is for this reason why I advocate creating your own guide under the new framework using his guide as a reference. If you are willing, we can assist where needed (like the 'technical' instructions for modding tools, etc ... we have a reusable System Setup Guide that applies to all Bethesda RPGs for that purpose. We need guide curators for Fallout games anyway. First step is to identify all of the mods you want to use and what mod groups they belong to so that they can be added to the wiki. Just copy the info from mods in SRB's current guide into new mod pages for FalloutNV namespace. See instructions for doing this work on the Step Portal. It helps to use two browser tabs: one for the reference guide, and the other to work on the mod pages for the new guide (in fact, I often have multiple tabs open for this work). What is your timeline?

Just finished the 3D trees for Aspens Ablaze. Shared with mindflux, so hopefully available soon. I am amazed that this mod only uses one trunk texture and one branch texture having only a couple of branches (both with with normals). All that detail from so little. Meshes handle the color variation.

The NIFs say differently: Anyway, added the ",True" to end of line, and still no dice: TexGen_SSE_Debug_log.txtDynDOLOD_SSE_TexGen_Billboards_aspensablazeesp.txt Do I have the file name, location, and string content correct? I found an example in Configs folder, so changed from: AspensAblaze.esp;03000D61;TreeAspen07,True to Aspens Ablaze.esp;03000D61;TreeAspen07,True EDIT: Adding that space did the trick!

I will try adding ,"True" to the end of the text definition. If this does change things, I think you will either want to revise the documentation or let "True" be default as the doc impies without explicitly adding ,"False". Regarding your tree volume: Did you download the Aspens Ablaze main file, and are you referring to the volume of TreeAspen07 as define in that? I downloaded this file as of May 24, and this tree along with 08/09 have '0' object bounds in Aspens Ablaze.esp as shown in my post-2 When I loaded This plugin into the CK, these three trees had 'blank' Size in the Object Window for Tamriel > Trees. I then right clicked the records of all TreeAspen01-09 to "Recalc Bounds" and saved. I have also looked at TreeAspen07 in Nifskope, and it is indeed small compared to the others (going from memory, as I am not at my home PC right now). ... perhaps I must also load the DLC objects to check those as well in the CK?

So adding the bounds actually did allow the billboards to be created for two of the three new trees. The log:TexGen_SSE_Debug_log.txt ... has lines: [01:37] <Debug: Processing Aspens Ablaze.esp TreeAspen07 [TREE:29000D61]> [01:37] <Debug: Ignoring Meshes\landscape\trees\treeaspen07.nif bounds volume 237.533157348633 Aspens Ablaze.esp TreeAspen07 [TREE:29000D61]> Since the volume is < 512 (default) in TexGen_SSE.ini, I created a reference to test if I could force billboard creation for this tree, but no dice. Plugin name is "Aspens Ablaze.esp", and I placed the following file in: {modRoot}\DynDOLOD\DynDOLOD_SSE_TexGen_Billboards_aspensablazeesp.txt DynDOLOD_SSE_TexGen_Billboards_aspensablazeesp.txt My guess is that I have the file/path nomenclature wrong.

Doh! I neglected to look at the references tab ... duh. I was opening up all the subblocks and not finding them. Thanks!

I'm going to expose my lack of xEdit and plugin-management prowess here, but I need someone else to confirm: Examining in xEdit, it appears to me that the Aspens Ablaze plugin is defining but not placing any TreeAspen07, TreeAspen08, or TreeAspen09. TexGen is not creating billboards for these, and I determined it's because they don't have defined Object Bounds, so I used "Recalc Bounds" in CK for these and TreeAspen01-06 (because I assume the MA did not set these for the replaced vnilla aspens either). Can anyone confirm placement and status of object bounds? I assume that Aspens Ablaze is replacing the vanilla trees, but I don't see the records for these in the plugin, so does this mean that it's only replacing textures and meshes for the vanilla aspens? The mesh bounds are surely different, no? When I recalc bounds in the CK, these 'size' values indeed change, but I am not certain if this is appropriate:

@sheson I created 3D Hybrids for Aspens Ablaze. I haven't generated object LOD yet, but the LOD meshes and trunk billboards were created as expected for all trees in that mod, so I expect no issues. I need a quick reminder about TexGen tree-billboard creation. Aspens Ablaze mod adds three new aspens via ESP, and all seems kosher with the plugin (but for '0' value for all object bounds). However, TexGen only created billboards for treeaspen01-treeaspen06 (i.e., the vanilla replacements). TexGen did not create tree billboards for the new ones (treeaspen07-treeaspen09). Is this an issue with the new tree records in Aspens Aplaze.esp? I'm guessing that I need to set something there. EDIT: I think I have found my answer in ../DynDOLOD-3.00/docs/help/TexGenConfiguration.html .... I believe that I need to set the object bounds to trigger TexGen tree billboard creation. So If I load the plugin into the CK, I can use this method to write the prober object bounds(?): ... and then save the plugin and re-run TexGen? EDIT2: Well I did that to no avail. Even with defined object bounds, I get no billboards. Please see this post and provide me some direction if so inclined. Thanks in advance.

We support Mod Organizer here rather than Vortex. You should probably post about how to set this up on Nexus Vortex support.

You can either promote those mods to ESM via CK, not use the mods, or just ignore the warnings. Most of the large ref issues I have tracked down were for objects that I would not notice anyway. That said, mod authors should be made aware how/how not to carry forward their changes with respect to LOD.

OK, I will work on Aspens Ablaze LOD if we agree to accept this one conditional to that. Agree that it would be the best option for the next Step iteration.

I like grVulture's aspens and Aspens Ablaze as a vanilla replacer. Of course, I prefer the look of Aspen Realism, but agree that I need to soften the brightness a bit. I will fix that soon. I can create 3D hybrids for Aspens Ablaze and share them with the author to take care of that ... or upload as a separate mod if the author isn't interested. DynDOLOD 3 will handle the billboard1 and 2 nicely.

Thanks for creating this!

This means that the test output has no conflicts in the MO load order. Otherwise you would see conflicts in that middle pane under "Losing file conflicts" As sheson mentioned, you can check the game directory as well, but that is a manual process. MO works in the virtual game directory, but it can do nothing about those files in the 'real' game directory. See sheson's previous post.

You need to tell NGIO via the INI, but that mod highly advises to use precached grass to avoid stuttering and other issues. I would precache grass always with that mod, regardless of whether or not you are using it for DynDOLOD grass LODGen. This is our WIP instructions for running without grass LOD: Precaching grass will still benefit performance. To increase performance further, disable grass LOD generation completely by making the following configuration changes prior to generating (or regenerating) object LOD: In MO, make the following changes to No Grass In Objects GrassControl.config.txt: DynDOLODGrassMode = 0 OverwriteGrassDistance - Set to something between 4000 and 24000. Higher values decrease performance while increasing quality. Grass will be full-rendered to this value as per default behavior of fGrassStartFadeDistance in Skyrim.ini OverwriteGrassFadeRange - Set to something between 1000 and 18000 (depending on OverwriteGrassDistance) to transition linearly from full grass to no grass. Higher values increase performance while decreasing quality. Grass will begin fading from this value as per default behavior of fGrassFadeRange in Skyrim.ini ExtendGrassCount - Set to 'False' only if OverwriteGrassDistance ≤ 7000 Set Grass=0 in ../DynDOLOD/Edit Scripts/DynDOLOD/DynDOLOD_SSE.ini

The general consensus is to use xLODGen for Occlusion. From our guides: Run xLODGen from the MO2 executable drop-down list. Select only the Tamriel and DLC2SolstheimWorld worldspaces. Ensure only the Occlusion box is ticked. Use the following settings: Quality: 3 Height: 0 Radius: 100 Mode: -Flat +Borders Click [Generate] to run the process. Once the completed message has appeared, click the red X to close xLODGen. Occlusion.esp is saved automatically and will be placed in the Overwrite folder in MO. Right-click on the Overwrite mod listing and select, [Create new mod]. Name it Step SkyrimSE - Occlusion or anything unique. Ensure the new mod is active (ticked). Ensure the Occlusion.esp is the last plugin in the load order just after DyDOLOD.esp and that it is enabled, else run LOOT and sort plugins.

Again, I would drag the contents of TexGen_Output into a new mod and not bother with packing it into an archive. Click on the tool icon: Right click on the new empty mod: Drag contents into that and hit F5 to refresh MO. Then double click that mod > Conflicts tab, find conflicting mod

Me too, but I forgot to mention it. I discovered the issue when all of my embers were orange and waxy

... and I'm suggesting that you may have left a relic somewhere from an earlier run/move, especially if it was a single zip file that you dragged and accidentally placed into an adjacent mod. What I posted will tell you where MO is finding the output. It must be somewhere in the load order.

Important to note this post when using ENB LIght with Embers XD. We will likely need to hide some meshes from ENB Light for this and potentially some other mods.

OK, then you still have TexGen output somewhere in the MO mod list or MO overwrite. Also, you don't need to archive the output unless disk space is a concern. This may add a layer of complexity to your process. I always just move the output itself via Wind Explorer. I suggest that you click 'ignore' on the TexGen message and generate the textures folder again into TexGen_Output. Then move into a differently-named "test TexGen Output" new empty mod in MO (no need to archive this). Enable this mod. Then refresh MO mod list by hitting F5 or whatever method you prefer to refresh. Then double click the new 'test' mod to find the 'Conflicts' tab. You should see a number of conflicts here telling you the source mod(s) in conflict. Then you can find the location that MO is finding the old output.

Apparently, this only impacts female elves. I can't really tell from the Nexus page, but I think it basically clips the side of the forehead?

The Special K mod doesn't have anything to do with TexGen_Output. You ran TexGen in the past, which produced that output, so you get the message that it was found in your load order as mentioned. Also, as I mentioned, it seems like you have not set up or run DynDOLOD as per standards, else you would know that DynDOLOD_Output and TexGen_Output are folders that should exist outside of MO. By default, the output path of these programs point to ../DynDOLOD/DynDOLOD_Output and ../DynDOLOD/TexGen_Output. The user then moves that output into a mod in MO near end of load order (we suggest naming them "DynDOLOD Output" and "TexGen Output" in MO). You obviously either did that yourself, or set the output destination to be a mod in your MO EXE setup for TexGen (not sure how that would work though, since the path is defined in the TexGen program) ... or you set the output to your MO mods path. When this output exists in MO load order (as it should), then any attempt to run either program will give you the warning you noticed in the OP. You need to watch the video again or pay attention to the TexGen output destination path before you run it.

Marked for testing ... looks good with Step IMO. Need to check some of the DynDOLOD Large Reference issues though.