z929669

Depending on the EVT version you are running, this (and perhaps even the waterfall thing) could be due to the fact that EVT comes packaged with pregenerated LOD, and even some of the tree LOD models are redundant or wrong (e.g., unused models with invalid CRC, large/lush LOD with small/not-lush full trees). I would disable all of the billboards and pregen LOD from EVT and make sure that you have correct 3D LOD models for the version you are running. Some of the EVT files have no incorrect LOD (main 'standard' file and maybe Lush), but some do (Alt Trees, Custom Trees), and all have the pregen LOD I think, which is always potentially problematic.

@TechAngel85 I reached out to somerandomguy, and he is happy to accommodate the idea of correcting any 3D LOD meshes that exist in some of the files AND stripping out all of the load-order specific pregenerated LOD from each file. I explained it all to him, and he gets it. We can keep the current versions available for those that want to use them regardless of the potential issues, but each file will be repackaged and get a new version increment otherwise. If you want to make any other changes, let me know, and we can team up. The file sizes should be substantially reduced when finished. Will keep you posted.

Exactly my caution: Batch optimizing always fixes a bunch of compression issues only to trade for new ones unless the author has painstakingly identified all of the 'exceptions' and processed those differently or not at all. If DDSopt was fully functional, then it would work as intended, but one of its issues is that not all INI config params are honored, or some of the features of interest are just faux.

Re-read second post? Look at NGIO settings and how they articulate with DynDOLOD config settings. Precache grass. There is also a troubleshooting section at the end of that. Some mods also do not properly set object bounds for grasses.

See my previous. There is just no reason to change templates Fc and Fs. They are used all of the time and work as intended. I am all for reducing the number of terms for each, but I think it is senseless to force use of an equals sign. URLs do not matter with these templates. They do for Alerts, so we use them there. I am a fan of leaving it alone but for reducing the terms. Please. EDIT: I also followed the linked document ... and I have read it many times. They are ALL standards. You are making assumptions that really aren't valid for these templates. We just never have cause to use URLs with query parameters in colored or resized text. Why would anyone color or resize text of a URL?? Nor have I ever had cause to use an = symbol in these situations. ANONYMOUS params are simplest to use and implement and that's always what should be used unless there is clear reason to use named params. I also don't like numbered params, because they are arbitrarily assigned (unless they are 'scaled' params). Also, I had changed some of your Bootstrap class uses, but I mixed up x/y and corrected. class="mt-5 mb-5" can be more succinctly done as class="my-5" Doing anything more than '5' has no effect, and they can't be stacked either like "my-5 mb-5" ... I believe the last one wins, so it is redundant. absolutely, positively, completely agree with this approach, but for these templates, {{{2}}} works without issue as it always has. If you guys want to change it like this, it will cause no cleanup issues and cannot break anything if done right. I just see no reason to change this stuff or debate it at length, because it's a non-issue. The responsive design stuff is more important, IMO. That's why I got on it ... so it's waiting for sign-off as I posted.

Just to address this question: The manual is actually under the location you extracted the DynDOLOD archive content. So something like C:/Modding/DynDOLOD/Docs/. Just go in there and open the manuals like any other file (some doc also exists in other areas I believe. Just search for *.htm* in your DynDOLOD dir). The links in the manuals work using rel paths where applicable, so should be fine.

Evidently, we removed the file from the server probably when moving the site. I determined this after restoring the page in question. I can look on the server backend, but I will bet that it was deleted. DDSopt has not been maintained or updated for several years, so we no longer use or recommend it for Skyrim. It still can be used to correct certain textures in batch, but several key features were never fully implemented in DDSopt. I don't know the status of the vanilla textures for Fallout games. @Majorman is our FalloutNV guide curator, and he likely has the best info for you in this regard.

I also agree. There are multiple standards, including named/ordered parameters. No need to do anything other than collapse redundant keywords into the few needed. EDIT: Anonymous params are always simplest to use and what we default to most of the time (like for this one). Numbered/named params are useful only when you are using certain chars in the text. It's rare. I believe it would be possible to allow use of anonymous as well as named/numbered in same template if you really want to make both work. We did this with Notice/alert templates for obvious reasons, but I have never needed to worry about an = symbol with Fc/Fs templates. I never use URLs in those, and if I do, I only style the link text. I do prefer named over numbered params, since the numbers are arbitrarily assigned and provide no indication of what they represent

@TechAngel85 Wiki updated to reflect color changes for mod flags.

As long as it's intuitive, it works for me. three max is fine, but we could simplify even further. Just need to know what is in use using what key words so that I can replace without changing anything or conflating changes so that we can't easily revert them. ilheading was for inline headings. I started that one a while back, because I thought salmon was good for that. Calls out without too much flash

Starting a topic to collaborate on updating the MO wiki guide to current MO2 relevance. The guide has been updated to address many of the most important changes from MO to MO2, but it still needs a comprehensive audit/revision as well as a title change to make it clear that it is the "Mod Organizer 2" manual/guide. I know that MO(1) is still available for whatever reason, but unless there is a really good reason to do so, I'd prefer not to maintain doc on what I believe is no longer relevant (set me straight if I am mistaken). Thus the drive to revise the current doc. Ultimately, this is a call to contributors familiar with the intended use and direction of MO2. At the very least, we will need 'expert' content reviewers. I'm hoping that the MO2 devs or maintenance staff have some interest here, as this maintenance should serve them well as a resource to which users can be directed from the app itself and from Discord/Reddit/wherever in order the RTFM. There is also this forum, where MO supporters are encouraged to post (and MO devs and enthusiasts are also encouraged to use as a resource). Anyway, we still have the primary MO-manual creator, @DoubleYou --and those of us here at Step that know MO well-- but having developer support and that of others will help us to keep it relevant and remove any persisting redundancy.

You may want to read through the MO Guide Executables chapter. There is instruction specific to Bodyslide in that. I know that it is sometimes important to set the "start in" path. I do not know it there are any 'gotchas' associated with bodyslide though. Nifskope can have issues, since you need to set the resources path in that program in addition to EXE setup in MO. Perhaps Bosyslide requires resource paths to be set as well, IDK (hence the link to MO Guide). What I'd like to know is if one can invoke a shortcut to the MO VFS to use as a resource path directly ... I always just get around the Nifskope resources issue manually, but it's a PITA.

Check your/admin permissions on that file. Can you manually delete it? Any message when you try? Then retry update.

I fixed it. Somehow the ModList was using the wrong page name. I didn't look into cause, just fixed.

@R0AST3DN3WT The LoS lighting color can be fixed in xEdit. @TechAngel85 What records control the white light aura? This is probably the flame but not the aura:

No, it's still needed but not showing on the mod list for some reason. I will invoke a refresh of the data to try to resolve. In the meantime, just follow the mod instructions: https://stepmodifications.org/wiki/SkyrimSE:Step_SkyrimSE_CR_Patch

Actually, C:\ is fine. It's certain other locations under C:\ that are under UAC control: https://stepmodifications.org/wiki/Guide:System_Setup_Guide#Modding_Folder

I see. I don't run FO games, so wasn't sure. I guess I did know about FNVLODGen vaguely though. You will need to wait for sheson or Google it. @Majorman probably knows. he is curating our FNV guide and knows this stuff well.

No problem!

You are invoking the app via MO, right? Also, when you run the app, note that path in DynDOLOD/TexGen itself to be sure it is pointing to same place.

Path = same as "binary" but without the file name at end ... I have always though that the "start in" param was stupid. The OS/app should always know it is same string without file or params ... unless it's not. Never encountered otherwise and seems to not make any sense. Must be a use case, but I can't imagine what it would be

Add path to "Start In" and be sure '-fnv' is correct ... not sure that one.

Yes, you can either rename the executable or add the command switch to shortcut or MO shortcut path in EXE setup:

I defer to @TechAngel85 on patch edits and related, but you can work on both at the same time in theory.

PM'd it 2 U