z929669

The "SKSE/ path" is the full contents under and including the SKSE folder. A path is a directory structure. Since you are creating a mod, why would you alter the original mod? I will reword the instructions a bit to address what's confusing you. Have another look at the wiki instructions for this mod

Yes, this is good advice for most, I'm guessing. I misinterpreted the OP. If the defaults were used and the C drive has been reformatted, then all instances containing mods/downloads/profiles would be gone gone. I happen to have a very large C drive and keep regular backups of important file locations on a portable drive. I have configured my modding and 'working' paths as Windows Libraries with File History backups. Using Windows Libraries, you can also link to paths on other drives and use File History.

From your screenshot, it looks like you installed MO in instanced mode. Read https://stepmodifications.org/wiki/Guide:System_Setup_Guide#MO_First-Launch_Setup Once you have your instance configured for whatever game you are running (assuming SSE), go to %LOCALAPPDATA%\ModOrganizer Copy and paste that^ into the 'Run' dialog by right-clicking the Windows Start menu and choosing 'Run' You should be able to start MO and select the instance you created. You may need to copy the files manually into your new instance at %LOCALAPPDATA%\ModOrganizer\<instanceName>\profiles\<profileName>

Moved to the appropriate forum for sheson to sort.

An experienced MA creating branch textures without mipmaps? Highly doubtful, so I checked this mod myself and find that those two branch textures indeed do have mipmaps. The file sizes aren't 'strange' either, so this is not the issue. These textures are in a BSA BTW and must be extracted to have a proper look at them. Besides, I don't think TexGen or DynDOLOD actually need the mips provided by the MA. The request was to check which mods provide these textures. Are you using some kind of NotWL texture replacer? Use MO Data tab in the right pane to filter those two textures and reveal what mod is providing them.

Mod instructions updated where necessary. See the changelog "Post-Release Changes"

Read this topic and the topics linked from my and TechAngel's posts.

Please create mod topics for each mod of interest using the Editor tool:

Thanks for the info. For security reasons, we have some posting restrictions for accounts with few posts. Try to repeat the action.

Copy an image and paste it into the post using CTRL+v or whatever method you like. Or drag an image file into a post. It's that simple. The image file type matters most, so you want a file type that is small, like JPG or JPEG. If what you use to copy exists as PNG (like Windows snipping tool), you may need to save it first as JPG and drag it into the post.

Actually, I think the 'lesson' is to modify LLs in the CK (as Mouse's screenshot above demonstrates). It's much simpler to create (and check them) in the more intuitive LL editor in the CK. I'm sure that's how the experienced MAs do it initially for their mods. Once you've done many of them, it becomes simpler to modify them using xEdit, but the data org in the more code-like UI of xEdit just isn't as clear, and it's easier to muck it up.

Use the MO data tab in the right pane to see what's providing the file: Contents of DynDOLOD_Output must be placed into a MO mod folder. in the left pane:

If you look at the current guide, this is all explained in the notice right up top. We are currently into week 8 now, and it will be several more weeks at least. Too many things have changed, and we're potentially revising a lot of the pre-update development. Too early to tell.

See sheson's previous post about providing screenshots and logs. That's necessary to diagnose and resolve the problem.

Close to giving up on this miscommunication, but I'll give it one last try with some new wording as I think I understand things: If this is correct, then I simply miscommunicated that DynDOLOD cares about Object Bounds, since it's actually TexGen that cares (and DynDOLOD only cares about what TexGen is providing in terms of a tree/grass billboard). I should be more careful then (especially when I can be this pedantic). If you disagree with this wording, then I totally give up on this one and yield all quarters Sorry I hijacked this OP

I quite literally do not understand those first two statements. Could you rephrase? The third statement is clear. ... I think EDIT (trying to understand what you typed in the doc): So for EVT TreepineForest01, which gets Ultra trees when running DynDOLOD 'Ultra' and also gets billboards from TexGen: The base record (not a reference): But "Has TreeDistant LOD" is not ticked. It has object bounds matching vanilla. You write "A tree" (one tree) "is every base record" (all base records? There's one.). Here's a STAT base record from EVT. It doesn't (and probably shouldn't) get LOD but has the "Has Tree LOD" flag mentioned unticked. Also has object bounds matching vanilla.: I might be hung up on semantics here, but I truly don't comprehend those two sentences as mentioned above^ I understand the math for calculating volume of a 3D object. Logically, the object bounds for vanilla TreeAspen04 would be ignored by TexGen when it creates billboards, because the volume is too small (height is OK though): Creating a patch plugin for this record with updated object bounds > the volume and height thresholds would cause TexGen to create the billboard, correct? ; automatic tree/grass discovery - base record object bounds Sqrt((X2-X1)^2 + (Y2-Y1)^2 + (Z2-Z1)^2) >= Min[Tree|Grass]ModelVolume MinTreeModelVolume=512 MinGrassModelVolume=64 ; automatic tree/grass discovery - base record object bounds Z2 >= Min[Tree|Grass]ModelHeight MinTreeModelHeight=256 MinGrassModelHeight=32

So to be clear after reading through that, the base record object bounds for TREE is what's used in the volume calculation to determine if TexGen will ignore the record or create the billboard and billboard data for it(?). In my previous post, I said DynDOLOD, but it sounds like I should have said TexGen.

Thanks for setting me straight. What is the context for this post then? Are you referring to threshold for TexGen billboard creation or a game INI dependency on tree object bounds (not grass)?

OK, so we can move around mod plugins by dragging or using "Send to">Group, but this cannot be done with official plugins. This is making more sense to me now. I swear I couldn't drag anything in my previous version ... 1.1 or 1.2 I think. Perhaps I failed to test it though.

Have a look at posts relating to this conversation on the DynDOLOD topic: Also, disable sky reflections in the game INI if it's not. See our BethINI instructions for some useful tips, or just use BethINI to ensure you are only using valid INI settings. Your ENB could cause this to some degree, but to be certain, toggle ENB off/on using Shift+F12

As you mentioned previously though, I think the object bounds need to be updated in a plugin patch if they are replacing small vanilla trees like TreeAspen04. Some people may confuse this with 'scale' even though they are completely different. That's not mentioned in your FAQ, AFAIK. Maybe too rare to be worth it, IDK.

HLT does not come with its own 3D LODs. To get them, you must install the accompanying add-on you linked. The main mod only has some billboards for an older version, which should not be used with DynDOLOD. I haven't used the other mods you mention, but they all should install accompanying LOD models with the selections you choose upon installation, because the LOD files are just meshes and very small ones. EVT does this. Most package them in separate files though. Look for 'DynDOLOD' files available on those tree mods. Some people refer to them incorrectly as 'billboards'. If they are meshes, then they are LODs. Billboards are textures. Tree mods typically use up hundreds of megabytes or even > a gigabyte of drive space due mostly to textures, but the LODs are relatively tiny (typically < a few megabytes collectively). ... so, install HLT again and merge the mod you linked. Then run TexGen/DynDOLOD again with settings as recommended in the sticky on Nexus. They may be under Optional Files or Misc Files. If not, then they don't have LOD models, and you will get no tree LOD with DynDOLOD > 'Ultra' setting (unless sheson has made them and packaged them with the application).

Hmmm, I don't see that, and I have the latest version: the only 'group' function I see is "Create group", no matter what plugin I choose. I do have "Remove group" if I right click on a group name though: Well, now I do see a "Send to" > Group function, which wasn't there previously, but I still see no way to modify an existing group outside of remove/recreate. It only works on a non-group-affiliated plugin though. Maybe Parapets added some functions based upon my or others' feedback.

I started a forum discussion last week under the mod's Forum tab on Nexus, and the MA responded with some useful info that's not in the Description. Evidently, Parapets made this mod primarily as an alternative to LOOT even though there is some LOOT integration. Group creation via this extension seems nonsensical to me, given that one can create a group but cannot drag or otherwise move plugins among existing groups. One must right click a plugin and "Create group" with the same name as an existing group to effectively add that plugin. This seems unintuitive and unnecessarily limited. There's also no way I have found to add/remove plugins from a group aside from using CTRL to select plugins, right click, and "Create group". One must right click the group, select "Remove group", and start over. Additionally, LOOT (integrated or standalone) will destroy any groups you create on first sort or on sort when the LO changes. I think group maintenance features of this extension need a rework. Otherwise, the LOOT integration seems rather iffy to me, and I don't really see any use for it. So ignoring groups, I like this extension for the fast insights it provides without having to run xEdit, but I've yet to use it fully until I get back into guide development (once the 1170 mod support is more established).