Mousetick

Hi DY, in case you're not aware, there's a small typo in the help text for the 'Remove Clouds' FOMOD option (as of v1.7):

I'd been wondering if this was what you were referring to, but wasn't sure. Thanks for clarifying. You should never use this option when using an external mod manager like MO2. If you use MO2 to manage mods, use it exclusively and forget about the in-game option, ignore it completely. They are not compatible and are fighting each other. No wonder the game crashes as a result. Moreover, the in-game Mods option only supports standard *.esp plugins. It doesn't know anything about SKSE plugins and other types of mods.

It's quite difficult to provide you with relevant guidance and suggestions because your descriptions are too vague and confusing. Which "mods tab" are you referring to? Where is it? Where exactly are you seeing that your mods are disabled? How can you disable and re-enable mods "in game"? When exactly does the game crash? No offense but these descriptions make no sense in the context of using MO2 and Skyrim and SKSE. You may have a simple problem that's easy to solve, if only we could understand how your game is set up, what you're doing and seeing where, and precisely what's happening as a result of your actions, so we could identify the issue. Lacking any specific actionable information, the best advice we can offer is to reinstall everything from scratch and hope for the best.

A few observations after much horsing around with both SHaOM and TTaH. If you don't particularly care about horses, you may want to skip. There are some quirks to be aware of, that I don't think are caused by the mods. They are in the vanilla game, but are made more apparent by the abilities that the mods provide. No matter if told to wait or follow, any owned horse will walk back to its "home" as soon as the player mounts another owned horse. If the owned horse was "acquired" by taming it with TTaH while wandering in the middle of nowhere in the wilderness, good luck trying to find it again after it went back home. A horse found from a random world encounter and "acquired" by taming it will despawn and disappear from the world as soon as the player fast-travels, is teleported or switches between exterior/interior cells, even if told to wait. It will fast-travel with the player to an exterior destination if told to follow however. The player should therefore be mindful of what they store in the horse's saddlebag, of where and how they acquire horses, or risk losing the horse's inventory or the horse itself. The "home" of a horse acquired from a random world encounter appears to be the first location where it's told to wait, rather than its spawn point. The ability to recall the "current" owned horse (provided by SHaOM by holding down the H key) teleports it nearby. Nearby is not really close depending on surroundings, and sometimes it can be hard to find the horse waiting somewhere nearby, deep in the river, hidden behind buildings or landscape, especially in the dark. It's advised to then tell it to follow so it walks and comes to the player. In order for a horse to be "registered" with SHaOM as the current horse and issued commands, it needs to be mounted first in the owned state. For a horse acquired by taming with TTaH, that means unmounting it and re-mounting it once tamed. Stealing a horse and being seen still incurs a bounty, even if taming with TTaH is successful and it becomes owned. The stolen horse bounty in vanilla is 50 gold, which is ridiculously low compared to the value of the owned horse (1000 gold for sale at a stable), and could be considered an exploit. The TTaH MA suggests increasing the bounty to 500 gold, which I think is fair. This can be done in a custom plugin overriding Skyrim.esm, or by issuing this console command (can be executed automatically with Autorun or SSE FPS Stabilizer): setgs iCrimeGoldStealHorse 1000 (The value must be the double of the desired bounty amount) I don't know how all the above compares with Convenient Horses or the other horse mod(s) under consideration, and I have no plans to find out. I have no interest in trying them out. Meet my new friends, from left to right (the names are assigned by SHaOM): Queen Alfsigr. Bought from the Whiterun stables. Exmoor Pony. Stolen from the 'Nobles [sic] Traveling with Bodyguard' random encounter near Fort Greymoor in Whiterun, and hardly tamed with 0 carrots. Notice the 'Unknown' references in the console, indicating that this horse was spawn out of thin air and will despawn as noted above. Fjord Horse. Stolen from a hunter near Lake Ilinalta in Falkreath, and easily tamed with 100 carrots in my pocket.

From the MO2 launcher drop-down menu, select 'Explore Virtual Folder' and click the Run button. A window will pop up and display the contents of the Skyrim virtual Data folder. You should see all your mods' plugins (*.esp) and folders such as meshes and textures. Close the window afterwards. If that's not the case, troubleshoot the issue until they are present. There's no need to launch Skyrim until the issue is resolved.

I had a chance to try 'To Tame a Horse' while testing something else. I stole a horse which owner was MIA, and after many taming attempts (I had no carrots) I succeeded. The horse then became mine (activate prompt became 'Ride' instead of 'Steal') and I could give it commands (wait/follow/saddlebag) with 'Simplest Horses'. I'd recommend it if you like [stealing] horses. I think it goes well with 'Simplest Horses' for a simple, no-fluff immersive experience.

It looks like it does: ... Horse.SetFactionOwner(PlayerFaction) Horse.SetFactionRank(PlayerHorseFaction, 1) debug.Notification("You tamed the horse!") ... If the player becomes the owner, then I guess it means it's no longer stolen.

Right. I looked at the 'To Tame a Horse' mod plugin and scripts: if you're successful, the tamed horse is added to the Player Horse faction, so you effectively own it, as if you bought it.

Neither of these 2 recommended mods would probably fit the STEP mandate, but I'm going with one of them: To tame a horse. Another silly semi-realistic immersive mod for my collection. You need to have a bunch of carrots in your inventory to increase your chances of successfully taming the horse. I like this. Thanks

Discussion topic: Landscape Seam Fixes by RealPharaoh Wiki Link Comprehensive fixing of the landscape seams that result in ugly visuals. ESP Plugin. Requires Landscape Fixes For Grass Mods. Let LOOT sort it. Comments from the peanut gallery: "Comprehensive" is the MA's vision. For the time being, this is just WIP, as of this writing covering the roads Helgen-Falkreath, Falkreath-Riverwood, Riverwood-Whiterun, Whiterun-Rorikstead and Whiterun-Markath. It'll likely never be finished but what's there so far is good, and hopefully there'll be a little more to come in the future. Unlike 'Smooth Shores', which too remains unfinished and is incompatible with LFfGM in areas where they overlap, this mod's MA had the bright idea to use LFfGM as a basis. Improvements are lost in areas where other mods are modifying the same landscape records (e.g. parts of Whiterun exterior with CRF).

I use it. It works. Not much else to say about it.

Is there a way to make DynDOLOD (and related tools) use a custom INI configuration that overrides ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini? With the rapid pace of alpha updates, each installation overwrites the INI file with the factory default. It's easy to forget to edit it to re-apply one's custom settings. And even if one remembers to do so, it's a bit of hassle to be honest. For example, there could be a ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE]_Custom.ini created by end-users and not shipped as part of the .7z package. ; This is the user-specific DynDOLOD.INI for [GAME MODE] game mode [DynDOLOD] ; set to 1 for expert LODGen options in advanced mode, disables wizard automatically Expert=1 ; set to 1 to generate LOD Level 32 *.bto files (indentical to LOD Level 16 but without billboard trees when generating with TreeLOD=0) ; set [MapMenu] uLockedObjectMapLOD=32 in Skyrim.ini Level32=1 ; order to scan for *_lod*.nif files. Indentical filenames (sans path!) found *last* will overwrite win Folder1=meshes Folder2=meshes\dlc01\lod Folder3=meshes\dlc02\lod Folder4=meshes\lod Folder5=meshes\dyndolod Folder6=mymeshes\lod ; set the double_sided shader flag in object LOD *.bto meshes on these lists of meshes / textures masks (partial filename) for mods like Dynamic Volumetric Lighting and Sun Shadows DoubleSidedMeshMask=mountain,mtn Thank you.

Yep, I played it a few years ago, it's quite good. It's so good in fact that it's become a standalone game, using Unreal Engine, with enhanced visuals, gameplay and expanded story: The Forgotten City (Steam) - Overwhelmingly Positive rating.

This fixes the brightness of the aspen leaves in shadow. See my screenshot earlier in this topic. It doesn't modify the shape or texture of the models. Edit: ninja'd by Tech.

Do you have a space between -D: and "C:\Program Files ...". It looks like you may have a space character. There should be no space.

Same as above but path must end with a backslash: -D:"C:\Path\To\Data\" This works with any xEdit-based tool (xEdit, xLODGen, TexGen, DynDOLOD).

I don't think that would be desirable. LFfGM fixes would be lost in the process, and they're deemed more important than the cosmetic touches SS provides. The alpha changes are different from master (Skyrim.esm) but they're identical to Update.esm. That's my point: there's no change from vanilla. These 'edits' by LFfGM are useless.

Yes, the textures provided by this mod are low-res and pretty poor quality. At least one texture would be necessary to keep because it's a custom texture specific to this mod: /textures/architecture/whiterun/forgeheat.dds. It's used by this mod's version of /meshes/furniture/blacksmithingskyforgemarker.nif. It doesn't exist in vanilla.

I only mentioned them because they are straightforward. The patching consists of 'Copy [SS LAND record] as override into... [patch.esp]', as if LFfGM were not there after SS. It might as well not be there, and should not be there for these particular records IMHO, since it doesn't make any difference compared to vanilla. I trust that SS edits are correct and worth restoring. I could be wrong on that point.

Does the 'Smooth Shores-Landscape Fixes for Grass Mods Patch' assume a specific order between Smooth Shores and LFfGM? For me, LOOT puts SS before LFfGM. Going through the conflicts in xEdit, I found a bunch of landscape edits made by Smooth Shores that are stupidly lost because LFfGM overrides them with 'dirty edits' (typically "ITU" - identical to Update.esm), without making any changes of its own. These are straightfoward to resolve in xEdit by simply forwarding the SS LAND edits wholesale into the patch, as if SS were loaded after LFfGM - nothing from LFfGM will be lost. They are not included in your patch as far as I can tell. Here is a list of affected LAND records that I've found so far: Worldspace \ 0000003C <Tamriel> \ 00006FA3 \ 00007FB7 Worldspace \ 0000003C <Tamriel> \ 00006FC2 \ 00007FD6 Worldspace \ 0000003C <Tamriel> \ 00006FC4 <DruadachRedoubtExterior01> \ 00007FD8 Worldspace \ 0000003C <Tamriel> \ 00006FC5 \ 00007FD9 Worldspace \ 0000003C <Tamriel> \ 00006FE4 \ 00007FF8 Worldspace \ 0000003C <Tamriel> \ 00007138 \ 0000814C Worldspace \ 0000003C <Tamriel> \ 00007157 \ 0000816B Worldspace \ 0000003C <Tamriel> \ 000075A9 <MarkarthAttackStart02> \ 000085A9 Worldspace \ 0000003C <Tamriel> \ 000075AD <MarkarthMainGate> \ 000085AD Worldspace \ 0000003C <Tamriel> \ 000075C2 \ 000085C2 Worldspace \ 0000003C <Tamriel> \ 000075C4 <ReachwaterRockExterior01> \ 000085C4 Worldspace \ 0000003C <Tamriel> \ 000075C9 <SalviusFarmExterior> \ 000085C9 Worldspace \ 0000003C <Tamriel> \ 000075E1 \ 000085E1 Worldspace \ 0000003C <Tamriel> \ 00007605 \ 00008605 It's such a pain to resolve landscape conflicts, but when landscape mods uselessly forward vanilla records without making any changes, it's even more annoying. I hate it. LFfGM is not the only mod guilty of this. If you agree with my assessment and think it would be useful to include them in your patch, I'll update the list above as I find more of these, otherwise I won't bother

In a nutshell... This is primarily middleware for mod authors. It's intended to greatly reduce or eliminate the need for traditional patches or scripts, and to improve performance in the process. I'm using the term 'patch' in its most general sense - in its simplest form, a mod plugin that overrides a few records in Skyrim.esm can be considered a patch for Skyrim. A mod plugin that voluntarily overrides a few records in another mod is a compatibility patch. The "old-school" way of replacing objects can be seen in kryptopyr's overhaul mods for example, which have big plugins that override hundreds of vanilla records, and include dozens of scripts. These overhaul mods are a pain to use with other mods because they require compatibility patches to be integrated with those other mods, and are a drain on the engine because of all the script and plugin processing. The "modern" way of dealing with this problem as implemented by SWAP is to define the new objects in the mod plugin, and let the framework (more or less an engine extension) do the replacement on-the-fly at runtime, based on substitution rules defined in the mod's SWAP configuration file. Patches or scripts are no longer needed to override the vanilla records and references. Compatibility patches are no longer needed to override another mod's record. Let's say you're a mod author and your mod replaces the vanilla salmon by a rabbit (stupid example to illustrate), and another mod replaces the vanilla salmon by an enhanced salmon. With the "old-school" way, if you wanted to replace the other mod's salmon by your rabbit, you'd have to create a compatibility patch plugin, or in the best case scenario, simply change the load order of both mods. With the "modern" way, you'd simply add a substitution rule to your SWAP configuration file. SPID has a different function, but has the same design goals as and works similarly to SWAP. This is very smart, neat and efficient. Right now SWAP is still experimental. There are a few mods that have been converted to SWAP as proof of concept: https://www.nexusmods.com/skyrimspecialedition/mods/60741 https://www.nexusmods.com/skyrimspecialedition/mods/60756 (without SWAP: patching ~1200 worldspace records / with SWAP: 0 worldspace record overrides but ~1200 substitution rules) https://www.nexusmods.com/skyrimspecialedition/mods/60762 The problem is that the long-term implications have seemingly not been thought through. This framework could be adopted too fast by too many MAs in too raw a state. Issues identified so far: Doesn't work with large references Unintuitive precedence rule, opposite of long-established rule Conflict identification and resolution process is significantly worse than plugins in xEdit This was supposed to be brief so I'll stop here

Yep. It's mostly great for mod authors who only need to create the record(s) for the replacer object(s) in a plugin, and everything else is defined in the _SWAP.ini. The framework takes care of patching replaced objects at runtime. In case of conflicting SWAPs, what will ultimately happen is that mod users will need to merge all _SWAP.ini files from the different mods into a single file, and then perform "conflict resolution" by hand-editing the merged file. To make matters worse, the framework author decided that the first occurrence in a conflict is the one to win, which is the opposite of regular mods.

Let's say I have autobuild turned ON and I launch app1. Later I launch app2. Later I quit app1. RB will perform a clear which may affect app2 still running. Later I enable or disable a root mod. Later I launch app3. RB will perform a build which may affect app2 still running. I'd rather keep autobuild OFF and not have to worry about what may happen. It's just my personal preference, so I'm glad the Autobuild can be switched off and thanks for making it possible.

It doesn't sound like we're talking about the same things. I'd like to clarify some points. Why not? If mod managers start supporting a root folder structure, mod users may start requesting that mod authors package their root mods as such, because it's easier to install and manage them. The mod authors may or may not listen, I don't know. Other mod managers may or may not follow suit, I don't know. But at least there is a path forward, some foundation to build upon. In the current situation, nothing will change and it remains as "difficult" to install a root mod manually without a mod manager, than with one. What about FOMODs? They're packaged specifically for use with mod managers, which is not the global 'default'. They can still be installed manually if one wants. It seems like you're shooting for the stars which is great. I'm only suggesting baby steps. All I'm suggesting is that a root mod with only a 'root' folder be considered a valid mod by MO, so that it can be installed and displayed in the mod list like any other mod without throwing warnings. That's all. Everything else remains the same for RB and MO. Any improvement such as shipping RB as part of the MO package, or tighter and cleaner integration between RB and MO via enhanced APIs would be wonderful. But that can come later. The issue is that RB requires users to repackage the root mods so that the root files are in a root folder. This is not very complicated, but it's error-prone and worrisome if you're not a power user. And then the mod manager throws warning and tells the user this mod is invalid, which must be ignored to proceed. Once the mod is installed, the mod manager keeps telling the user the mod contents are invalid. How can the user tell that this is a false positive? Perhaps they did make a mistake in re-arranging the file/folder structure, but how would they know? It's a bad user experience. Mod managers are supposed to make installing and managing easier and safer for users.

Yes it would need to be added to all BGS games, but it doesn't seem like copy-pasting the "root" string into a dozen or so .h files would be an insurmountable task for the MO2 dev team, or for yourself via a PR. Making an API with Python bindings available to plugins is another story, and I can understand that they would be more hesitant to implement such a feature, not to mention it could be quite a while before it's ready. In another topic here, you alluded to the 'root' folder being the "de-facto" standard for packaging root mods. That may be true, but the reality is that it's currently not supported by any mod manager, as far as I know - with MO, one of the most popular ones, among them. So there is no incentive for mod authors to package their root mods in a 'root' folder. If you want it to really become a de-facto standard, you need to start somewhere, and adding 'root' folder support to MO would be a good place to start a virtuous cycle. There is a difference between 'must work as expected' and 'nice to have'. I'd put the support for 'root' folder for content validation in the first category, and the content indication icon in the second. Get the essential basic support in first, then it can be improved later. Anyway, there's no hurry and I don't mean to pressure you in any way. The 'root' mods being considered invalid by MO2 is not a deal-breaker for me, and there are workarounds. But I'd be hesitant to recommend Root Builder to average users who typically have a low tolerance for unexpected behavior and/or are not willing to make any effort to deal with it.