TechAngel85

If you want to compare them go ahead, but it's unless. ELFX is just splitting up the meshes so that more lights can hit them before they "flicker". There shouldn't be any visual difference there. The only exceptions may be what the fix mods are specifically fixing, but a lot of that isn't visual either.

Don't know about the errors, but I trust the others. However, changing to ESM doesn't matter as the mod is all new records. So ESM or ESP...doesn't matter. ESL flag can be set.

Huh? Are you referring to v4? Or the update file that @alphaniner posted about?

I agree. Sometimes manual is just the way to go to prevent future maintenance issues due to dependencies becoming out of compliance. Not only this, but these steps teach/remind users how to install manually install mods and create/edit files for modding. You'd be surprised by the number of users that don't know the basics.

That's impressive!

Thanks. Corrected this again.

That's not what Unlimited Bookshelves does so still doesn't make since, but nice thought. It's likely a mistake. This patch would save me some time, I'm sure.

Oh, I actually tested this one on LE. It was great, though I still found I didn't really use it.

Updated download to ModDB

See above

For a rule, perhaps. But updating the ESM with the new references and running the script worked perfectly. It will be fixed in the next release of RWT, as such. I haven't gotten around to a rule yet. The sprays from RWT are particles. Not sure how particle effects fit into this mix. I know they don't show in vanilla for the first level of LOD, nor do they using the ESM/script. Only the static part of them show.

Yes, in the case of RWT, it's both a new base record and new NIF. I just finished testing this and it worked beautifully. The new references are added via ESM and new data generated. It replicated vanilla perfectly by showing up in the first level. They may still benefit from a DynDOLOD rule, though, by pushing them to load out to the next level. I'll have to test to see if it's worth it, since these aren't very large. Thanks for your help on understanding this better! Love this.

Okay. I will change those since they seem to not be needed and just keep the -30000. This replicates the DynDOLOD results, regardless if the final version will print the messages or not. I would rather have it done right than DynDOLOD needing to fix it. Okay, that doesn't sound like what I want. The ESM is only used to move the vanilla references out of the way and contains no new references. The ESP is what places the new references in the same locations as the old. Should the new references also be in the ESM? This option (call it option #1) would seem to be the only way to replicate vanilla without requiring DynDOLOD, correct? Call this option #2; the preferable option? I do like this better as it keeps the ESM to only vanilla records. This option would require DynDOLOD, though. The unfortunate reality is that there are still users that don't use DynDOLOD because they think it too complicated and then for those that do there are still users it would scare to add rules. I have to consider that RWT has nearly 400K downloads at its peak and adding any requirements to the mod isn't a light decision. Any requirement added as to be weighted whether it's the right things to do. In this case, I would love to bring all those users onboard with DynDOLOD, but the reality is that decision could also alienate 100s of thousands of users. It would fall somewhere in the middle of alienation and onboarding, but how far the scale would tip one way or the other is totally unknown. I think the best solution for everyone would be option #1, if it indeed replicates vanilla behavior (have to test). Else I will go with option #2 and make it "optional" for those users adventurous enough to learn new things; others will simply have to deal with the pop-in. I don't think there has been any reports, yet, because the issues are kind of hard to view from normal gameplay. I was TFCing and TCLing around to view them. Users would normally be within the loaded range of the cells before seeing most of the references so the issues are never noticed.

I'm mainly responsible for the ENB and patching. The ENB is far from complete and not available for public download so that will be one part users installing v2.0 won't have. Hopefully it won't take too long to finish up, though. I'm waiting for testing to be more complete as some of it will affect the ENB and I don't desire to keep reworking things. So when Z and DY's current testing that they're doing is more complete and on the Guide, I will replicate on my end and start working on the ENB again. The Patches are another thing not available to the public, so this will be something else users are missing. The Patches are probably 90% complete with the remaining 10% being resolutions for additional mods added later, review, and cleanup.

Keep in mind the v2.0 Guide is still in Development, but good catch. Yeah, Scrambled Bugs covers this one too. Another mod we can drop.

Upon closer testing, literally TFCing over there, I can see at least some of these splashes are, indeed, an issue. They are loaded for the first LOD level only in vanilla (and moving), but not when RWT is active. When I run DynDOLOD, the result is that the DynDOLOD plugin removes the "initially disabled" and "parent" records, but keeps the -30000 from the RWT changes. DynDOLOD does not touch RWT's custom placed references that replace these vanilla ones. In-game after DynDOLOD is ran, the result is the same for RWT assets. They do not show on LOD and pop-in when the cell is loaded. This means the RWT placed references aren't being see from afar (first LOD level). Does these mean I need to remove the "initially disabled" and "parent" records from these references? Will that prevent the reported issues? Second, question is the script for new RNAM was never ran for RWT (wasn't aware of it). I take it this needs to be done, and if so, is the script included with xEdit up to date (currently using v4.0.3)? Will this enable the RWT references to show on the first LOD level like vanilla? Being a moveable static, I'm not sure if those are handled differently.

The refs are "initially disabled", parent is set to "Player" with "enable opposite of parent" flag set, and then they are set to -30000 for Z value. They are mainly splashes (MSTT) that you're not going to see as large refs (I don't recall them having any LOD). I'm 99% positive DynDOLOD v2 doesn't call out these references but v3 is, which is why I'm confused as to what changed. I've never seen any issues with it in-game. Also with the amount of users installing RWT, I'm sure someone would have reported the issue by now too, if there was one. These edits have been with RWT since last year sometime. The only thing being reported now for some users are the messages from DynDOLOD v3.

Thanks for your report!

I'm confused. Perhaps you could shed some light on this. Realistic Water Two SE does this very thing (ESM, flagged as ESL to disable refs), yet DynDOLOD is calling out the disabled references within the ESM in the logs.

Really depends how immersive users want to get. I've always liked the idea as an alternative to quick traveling. Honestly, Skyrim isn't that big of a map that I feel the need to get anywhere quickly so I just tend to run everywhere. If I don't feel like it, I do usually use the carriages.

I'm bias being an author of RWT, but RWT has a lot of desirable features that would be lost using other water mods. RWT doesn't need a patch for Smooth Shores, anymore. The landscape edits have been removed from it. The only conflicts thing may be some cell records here and there, but that is just normal patching.

Discussion topic: Snow Elf Ruins Resource Pack by Modding Community Wiki Link This is a modders resource that contains a collection of assets in the Snow Elf Ruins (SERuins) art style; gathered for convenience for mod authors to use for their modding projects. The collect contains many resources from various mods, as well as, assets created by the Step Modifications Team.

I'm of the same opinion. New content doesn't exclude it from the Mandates. It just has to fit with the rest of the Mandate, which basically means it feels like it's original game content. For any new content it should integrate itself into the game fairly seamlessly so that it feels like it was always there. This means if it adds new harvestables, items, magic, shops, etc. they should all be integrated into the game mechanics, like factions, leveled lists, recipes, constructables, etc. For example, if a mod adds a new weapon that is "common" and that mod is an island off the coast of Skyrim, it should be expected to find that weapon in places throughout Skyrim...meaning it's been added to vanilla leveled lists. That is how all new content mods should be evaluated.

Since you're played it, how you would you rate it against the Mandates?

I've never played it either, but since it appeared back on Nexus I figured I would post it here again for comments. These mods have always been outside of Mandate due to being mostly complete fabrications without any basis, albeit, still good fabrications. It's recently gotten more voiced actors and a lot of bug fixes.