v286 has made a number of mods mergeable. However, imported into the Bashed Patch they clearly no longer work.
That's a hold over from CBash. In CBash they're mergeable, but they're not in regular Bash. You'll need to use "Mark Mergeable..." on your mods to make them lose their mergeable status.
Just a minor issue, with 286 release version you renamed “Rename-CBash.dll” to “Rename_CBash.dll” subsequently the old one will not be overwritten.
v286 doesn't contain CBash.dll :blink:
It was removed, and CBash disabled until a later release. There are some minor (but potentially game-breaking) issues that need to be fixed.
My question is, could I use Replace Form IDs to replace all mentions of the vanilla stones with the lit versions, forgoing the need for the scripting in the first place, and ensuring that when the mod is deactivated, no stones are lost, but they just go back to being vanilla stones? Or did I get the wrong end of the stick?
With Replace FormIDs, you could indeed swap out all uses of vanilla stones for your custom stones. It is very thorough; scripts that reference the vanilla stones will now reference your custom stones, leveled lists will drop your custom stones instead of the vanilla, etc. However, it doesn't touch the savegame. So if a player disables the plugin, the player would still lose the custom stones if they're in the inventory, or any they dropped, sold to a merchant, etc.
Basically, it would be a potential replacement for your script that initially replaces vanilla stones with your custom version. Once the player has interacted with the stones though, you'll still have problems with players deactivating the plugin. If the player hasn't interacted with a stone (went into the cell but didn't touch it), it will revert back to the vanilla stone when the patch is rebuilt with the plugin deactivated.
If we do not have that checked, and use TES4LodGen (having previously done a refresh installers to update crc's), then we go back to installers and Anneal all... Will Wrye bash re-overwrite distant lods from installers that have just had those files replaced by TES4LodGen?
In some cases at the moment I am unsure which I would prefer, the original distant lod by the mod creator, or using the TES4LodGen generated files completely.
User does not have skip distantlod selected and wants Anneal all to re-install original mod distant lods. TES4LodGen creates new distant lod with new crc and timestamp
Will Wrye bash no longer overwrite the newer distantlods with an anneal all?. Or will it do as expected.
In general, you want to use TES4LodGen so that you get the distantLOD from all your mods. I can't think of any situation where a mod's distantLOD would be preferable.
I would think that annealing when Skip distantLOD is disabled would overwrite the newer distantLODs. If it isn't, I'll take a look. It may be a deliberate inconsistency though since the generated distantLOD is nearly always preferable to distantLOD provided by a mod.
I have encountered the following issues with Wrye Bash v286 (Final).
1. DistantLOD files are installed when "Skip DistantLOD" is enabled.
DistantLOD files are installed regardless of the "Skip DistantLOD" setting.
(This does not seem to be related to the recent update-UI-after-Skip_DistantLOD-option-toggle fix, as I was able to apply it to v286 SVN 2010-06-15 without this issue.)
2. Complex Packages with files prefixed with "--" in the top-level of sub-packages are not silently skipped.
These files were skipped in v285 and v286 SVN 2010-06-15.
If "--" prefixed files are manually deleted (and Wrye Bash is restarted), executing the "Anneal" function on the owning package installs "--" prefixed ESP files. The rest of the "--" prefixed files remain listed in the "Missing" tab.
Confirmed. It was a copy/paste error I made when trying to speed up the installer refreshing. Which was the last thing I worked on before the release, so I didn't test it properly. Fixed, will have 287 out in a bit.
Request - Would it be feasible for Wrye bash to clean out the distantlod folder when a user hits the Wrye bash icon for TES4LodGen, before TES4LodGen is launched and automatically does its work?. Or would this generate different situation problems for some?.
v2.2.1 of Tes4LodGen should already be deleting all the LOD files before regenerating them.
Yes, your method should work.
However, as package content size increases, there can be potentially large amounts of redundant data being written when using the "Install" function, as the entirety of selected parts of the package seems to be re-installed.
In such instances, a more data-movement efficient method might be:
...snip...
This would probably work, but I fail to see the point. In what situation would a mod's distantLOD be preferable to what TES4LodGen creates? They would clobber any distantLOD from other mods.
» Tue Feb 01, 2011 11:57 am 
Still, it could prove quite useful nonetheless. I'll just have to think up something clever... 
