brewmasterhal

You've identified the issue, and the fix is extremely trivial. Why not just fix it for yourself? Even better, upload your fix as a patch so that everyone can use it.

The mod has not been updated for the latest version.

Have you tried washing?

I can probably figure it out.

Don't lose three times.

As of now, it is highly likely that loading some of these patches will break parts of the mod. None of this has been updated over the last 7 updates. https://www.mediafire.com/folder/zurjk1iti9sc5/Dogma_-_Thief_v1.0.0

The beta for v1.7.0.7 has been uploaded for top-tier Patrons.

This mod doesn't use Sexlab for anything. Sexlab settings won't change the mod's behavior at all. All of the unequip events are just scripted, no way around them.

Been playing through the game again and made my way through Blackreach the other day. While I was down there, I set up some SkyUI hotkey groups so that I could equip a staff in my left hand. No idea if this is relevant to the bug, but the glitch is new since I did that. With a save file that's 120 hours old at this point, the bug is either related to Blackreach or the SkyUI thing. The attached image tells pretty much the whole story. Something has taken a big shit on the alpha channel handling for the game's renderer. Starting from the left, you can see what my character is supposed to look like and what the glitch is doing. Every single one of my SlaveTats overlays is causing the portions of skin with even 1/255 alpha to be completely invisible. Furthermore, my hair textures contain alpha channels and are similarly invisible. Notably, the full-body alpha-enabled overlay added by WetFunctionRedux does not have the same issue. In the next two images, you can see that other cloth items with alpha simply have the alpha disabled. This is distinct from the observed behavior with the hair, which as far as I understand is handled in exactly the same way by the engine. This somehow means that the engine is treating alpha in three distinct ways depending on the circumstance. The bugged alpha can be reversed temporarily by casting any spell that applies a shader effect to the player. Until the next time the player's model gets updated (meaning any item equipped or unequipped), alpha is back to normal. Using a spell like ebony skin that applies a consistent shader will seems to instantly correct the issue while the buff lasts. Even stranger, while in Vampire Lord form my entire body becomes invisible. Everything that is "skin" on the model is gone, and only the cloth and metal bits are visible. What makes this so weird is that there should be no alpha applied to the skin of that mesh at all. Anybody got any ideas about this?

Tried enableplayercontrols ?

The interface file thing is definitely a beyond-ridiculous idea. I think you can also fix it by forcing a complete re-compile of scripts in the SE version of CS when you do a conversion. The string data will still be in English, but at least it won't be illegible. This is the solution I would pick in your position - just let the CS handle it for you (assuming you can get the goddamn SSE one to work). Other options that have worked before: Copy the message data out of the scripts and into actual MESG records so that when someone makes a translation of the mod that text will also get updated. Wouldn't take forever, but you'd still need to copy/paste shit into a bunch of new MESG records and update all of the Debug.Messagebox() calls to call .show() on message properties. Copy the data out of the scripts and into the quest properties as string or string[], then when you call Debug.Messagebox() you pull the relevant reference from the quest data and get the string that way. Translators can still update quest properties in TES5Edit like they can MESG records, it's just a little more annoying. Not sure if this is realistically less work than option 1...

SE is capable of encoding everything as UTF-8. I think that's one of the things that converting a mod to SE format does for languages that aren't English, French, Spanish, and a few others for which the encodings are identical. Thing is, when the string data is created in the LE CS and encoded in win-whatever, the SE engine does not implicitly convert it to UTF before display. So in order to get the stuff that's stored in the strings to show up correctly, you'd need to either re-compile from source after modifying the string to your target language, or edit the compiled script data in-place to have properly encoded strings.

Looks like an encoding problem. LE uses the Windows character sets for English, French, German, Russian, etc. This includes text that is defined within a script and displayed to the player as any kind of notification. If the user's version of Skyrim is set to display text in win-1251 and the scripts are encoded in win-1252 for instance, you'll get shit like this.

Mods can modify .ini files. You'd have to set up your mod to make the modifications under certain conditions, but in principle it should be possible. The caveat is that the changes would not be reflected within a given session. The player would have to close the game and start up again to update the SPID config.

If you're looking for more ideas for initialization settings, you could set it so that only Imperial-aligned regions start enslaved (due to Thalmor?) or only Stormcloak-aligned regions (due to misplaced traditionalism?) This would allow the player to expand/abolish slavery in a vanilla-friendly way. Not sure if SPID natively supports conditions that would allow that. Could also create interesting situations re: NPCs with different alignment reacting to a player slave (or simply a female player) in different ways.