SlaveTatsNG

[segaegae]

3 hours ago, nopse0 said:

Uploaded another VR test with more log output to see how far Skyrim gets before it hangs. Also doing the JContainers initialization now in the "kPostPostLoad" phase, because I suppose that's some sort of deadlock (both the JContainers reflection_interface and domain_interface use a singleton, whose creation is protected by a non-recursive mutex).

Try this out on VR and post the SlaveTatsNG.log (skse64.log could also be interesting).

So I change the name of the dll to kSlaveTatsNG.dll, and now here we are:

...

[09:12:20:358] [vm_hook] object: NiOverride, name: AddOverrideFloat, callback: 140718186921376

...

[09:12:22:507] GetModuleHandleA('skeevr.dll') = 140718186168320

 

It appears that the _ at the start does not work for the load order. So I add a k such that it loads between JContainer and sleevr

SlaveTatsNG.log

[nopse0]

4 hours ago, segaegae said:

So I change the name of the dll to kSlaveTatsNG.dll, and now here we are:

...

[09:12:20:358] [vm_hook] object: NiOverride, name: AddOverrideFloat, callback: 140718186921376

...

[09:12:22:507] GetModuleHandleA('skeevr.dll') = 140718186168320

 

It appears that the _ at the start does not work for the load order. So I add a k such that it loads between JContainer and sleevr

SlaveTatsNG.log 23.6 kB · 0 downloads

Wow, great, at least the NiOverride addresses should be no problem now. But JContainers really seems to be a problem. I registered the listener for the JContainers interface now in the 'kPostPostLoad' initialization phase of SKSE, but this seems to be to late, the listener isn't called at all, seems, it can only be installed in the 'kPostLoad' phase to have an effect. But if I install it in 'kPostLoad', I get a deadlock or whatever this problem is.

Edited September 21, 2024 by nopse0

[nopse0]

Uploaded another VR test version. I am deferring the JContainer initialization now, hopefully Skyrim doesn't hang then anymore, and added the NiOverride function addresses for VR.

 

If Skyrim still hangs, then probably the JContainers class registry is broken, and JContainers hangs forever in this function:

 const function_info* find_function_of_class(const char * functionName, const char *className) {

     const function_info * fInfo = nullptr;

     auto& db = class_registry();
     auto itr = db.find(className);
     if (itr != db.end()) {
         auto& cls = itr->second;
         fInfo = cls.find_function(functionName);
     }

     return fInfo;
 }

 

Oh, wait, I think the NiOverride config file name I am using is wrong on VR, its not "Data/SKSE/Plugins/skee64.ini" but, err, something else => skeevr.ini

 

Edit: Done.

Edited September 21, 2024 by nopse0

[segaegae]

2 hours ago, nopse0 said:

Uploaded another VR test version. I am deferring the JContainer initialization now, hopefully Skyrim doesn't hang then anymore, and added the NiOverride function addresses for VR.

 

If Skyrim still hangs, then probably the JContainers class registry is broken, and JContainers hangs forever in this function:

 const function_info* find_function_of_class(const char * functionName, const char *className) {

     const function_info * fInfo = nullptr;

     auto& db = class_registry();
     auto itr = db.find(className);
     if (itr != db.end()) {
         auto& cls = itr->second;
         fInfo = cls.find_function(functionName);
     }

     return fInfo;
 }

 

Oh, wait, I think the NiOverride config file name I am using is wrong on VR, its not "Data/SKSE/Plugins/skee64.ini" but, err, something else => skeevr.ini

 

Edit: Done.

Quick test report:

launch the game: works

start a new game: works

Open game mcm menu: works

Add/remove tatoos: works, and they can be found in the menu

Select some tatoo to add: works?

quit the mcm menu: CTD, log:

 

crash-2024-09-21-10-51-58.log

[segaegae]

2 hours ago, nopse0 said:

Uploaded another VR test version. I am deferring the JContainer initialization now, hopefully Skyrim doesn't hang then anymore, and added the NiOverride function addresses for VR.

 

If Skyrim still hangs, then probably the JContainers class registry is broken, and JContainers hangs forever in this function:

 const function_info* find_function_of_class(const char * functionName, const char *className) {

     const function_info * fInfo = nullptr;

     auto& db = class_registry();
     auto itr = db.find(className);
     if (itr != db.end()) {
         auto& cls = itr->second;
         fInfo = cls.find_function(functionName);
     }

     return fInfo;
 }

 

Oh, wait, I think the NiOverride config file name I am using is wrong on VR, its not "Data/SKSE/Plugins/skee64.ini" but, err, something else => skeevr.ini

 

Edit: Done.

Also, in MCM menu, change the target will CTD, log:

 

crash-2024-09-21-10-52-49.log

[segaegae]

2 hours ago, nopse0 said:

Uploaded another VR test version. I am deferring the JContainer initialization now, hopefully Skyrim doesn't hang then anymore, and added the NiOverride function addresses for VR.

 

If Skyrim still hangs, then probably the JContainers class registry is broken, and JContainers hangs forever in this function:

 const function_info* find_function_of_class(const char * functionName, const char *className) {

     const function_info * fInfo = nullptr;

     auto& db = class_registry();
     auto itr = db.find(className);
     if (itr != db.end()) {
         auto& cls = itr->second;
         fInfo = cls.find_function(functionName);
     }

     return fInfo;
 }

 

Oh, wait, I think the NiOverride config file name I am using is wrong on VR, its not "Data/SKSE/Plugins/skee64.ini" but, err, something else => skeevr.ini

 

Edit: Done.

When bSpeedUpNativeCalls = false, trying to open the mcm menu will ctd, log:

 

crash-2024-09-21-11-02-17.log

[nopse0]

1 hour ago, segaegae said:

When bSpeedUpNativeCalls = false, trying to open the mcm menu will ctd, log:

Miscalculated one VR function address (used the address of the AddNodeOverrideString function when calculating the offset of the GetNodeOverrideString function, the other addresses were ok).

 

This explains why it randomly crashed in line 44 in tattoo.cpp (because it's totally random what "GetNodeOverrideString" "returns" then):

 

Think the addresses are ok now, double checked this:

				static inline std::array<int, 12> _offsets4_15{
					0xBA0B0,  // GetNodeOverrideInt  140718186930352 - 140718186168320 = 762.032 = B A0B0
					0xB9FD0,  // GetNodeOverrideFloat 140718186930128 - 140718186168320 = 761.808 = B 9FD0
					0xBA260,  // GetNodeOverrideString  140718186930784 - 140718186168320 = 762.464 = B A260
					0xB9910,  // AddNodeOverrideInt 140718186928400 - 140718186168320 = 760.080 = B 9910
					0xB96B0,  // AddNodeOverrideFloat 140718186927792 - 140718186168320 = 759.472 = B 96B0
					0xB9B60,  // AddNodeOverrideString 140718186928992 - 140718186168320 = 760.672 = B 9B60
					0x96970,  // HasNodeOverride 140718186785136 - 140718186168320 = 616.816 = 9 6970
					0x96DE0,  // RemoveNodeOverride 140718186786272 - 140718186168320 = 617.952 = 9 6DE0
					0x96920,  // ApplyNodeOverrides 140718186785056 - 140718186168320 = 616.736 = 9 6920
					0x96350,  // AddOverlays 140718186783568 - 140718186168320 = 615.248 = 9 6350
					0x96370,  // HasOverlays 140718186783600 - 140718186168320 = 615.280 = 9 6370
					0x96390   // RemoveOverlays 140718186783632 - 140718186168320 = 615.312 = 9 6390
				};

 

Edited September 21, 2024 by nopse0

[segaegae]

9 minutes ago, nopse0 said:

Miscalculated one VR function address (used the address of the AddNodeOverrideString function when calculating the offset of the GetNodeOverrideString function, the other addresses were ok).

 

This explains why it randomly crashed in line 44 in tattoo.cpp (because it's totally what "GetNodeOverrideString" "returns" then):

 

Think the addresses are ok now, double checked this:

				static inline std::array<int, 12> _offsets4_15{
					0xBA0B0,  // GetNodeOverrideInt  140718186930352 - 140718186168320 = 762.032 = B A0B0
					0xB9FD0,  // GetNodeOverrideFloat 140718186930128 - 140718186168320 = 761.808 = B 9FD0
					0xBA260,  // GetNodeOverrideString  140718186930784 - 140718186168320 = 762.464 = B A260
					0xB9910,  // AddNodeOverrideInt 140718186928400 - 140718186168320 = 760.080 = B 9910
					0xB96B0,  // AddNodeOverrideFloat 140718186927792 - 140718186168320 = 759.472 = B 96B0
					0xB9B60,  // AddNodeOverrideString 140718186928992 - 140718186168320 = 760.672 = B 9B60
					0x96970,  // HasNodeOverride 140718186785136 - 140718186168320 = 616.816 = 9 6970
					0x96DE0,  // RemoveNodeOverride 140718186786272 - 140718186168320 = 617.952 = 9 6DE0
					0x96920,  // ApplyNodeOverrides 140718186785056 - 140718186168320 = 616.736 = 9 6920
					0x96350,  // AddOverlays 140718186783568 - 140718186168320 = 615.248 = 9 6350
					0x96370,  // HasOverlays 140718186783600 - 140718186168320 = 615.280 = 9 6370
					0x96390   // RemoveOverlays 140718186783632 - 140718186168320 = 615.312 = 9 6390
				};

 

I think it is working now, on my minimal test modding list at least.

 

[Polonium]

For users, do you install this mod over regular SlaveTats, or do you install it separately?

[nopse0]

58 minutes ago, Polonium said:

For users, do you install this mod over regular SlaveTats, or do you install it separately?

Over. Needs regular for MCM

[Arcane Wanderer]

I've been keeping an eye on this - Wanting to switch but unsure about compatibility.

 

I checked my installed mods.  None of them listen for the SlaveTats-added or SlaveTats-removed removed mod events.   I do see that a couple of mods I have on-disk but not active use the events: Deviously Enslaved Continued, and State of Dress.   I don't have any idea if any of the mods I use need the feature where some slave tats can have events specified in the tattoo definition...

 

What are your future plans for this?   Do mod authors need to change their mods to use some other mechanism to be compatible with SlaveTatsNG?  Or, are you planning to add modevent support in the future?

 

Do spell effects specified in a tattoo JMAP work?  I *think* Licenses uses that feature (depending on MCM settings), but I'm not sure.

[nopse0]

47 minutes ago, Arcane Wanderer said:

I've been keeping an eye on this - Wanting to switch but unsure about compatibility.

 

I checked my installed mods.  None of them listen for the SlaveTats-added or SlaveTats-removed removed mod events.   I do see that a couple of mods I have on-disk but not active use the events: Deviously Enslaved Continued, and State of Dress.   I don't have any idea if any of the mods I use need the feature where some slave tats can have events specified in the tattoo definition...

 

What are your future plans for this?   Do mod authors need to change their mods to use some other mechanism to be compatible with SlaveTatsNG?  Or, are you planning to add modevent support in the future?

 

Do spell effects specified in a tattoo JMAP work?  I *think* Licenses uses that feature (depending on MCM settings), but I'm not sure.

Oh, good to know, because I am installing Deviously Enslaved Continued just at the moment (I want to try out corsecs-lewd-patches-clusterfuck-madness with all patches, Immersive Wenches, Buxom Wench Yuriana, etc., and I know from the past that the Luxury Collection stuff looks very nice ). So, perhaps, I have to invent something. Sending complex mod events from C++ is impossible, you would have to directly use the SKSE sources for that, and then you would have an absolute version hell again with all the different SKSE and Skyrim versions. But perhaps some sort of Papyrus sattelite mod, which polls in regular intervals from SlaveTatsNG what tattoos have been removed or added (or gets notified by a simple mod event (sending these is possible from C++) from SlaveTatsNG that something has changed), and then sends the complex mod events, the other mods are listening for, would be possible.

[Polonium]

1 hour ago, nopse0 said:

Over. Needs regular for MCM

Thank you.

[Arcane Wanderer]

43 minutes ago, nopse0 said:

Oh, good to know, because I am installing Deviously Enslaved Continued just at the moment (I want to try out corsecs-lewd-patches-clusterfuck-madness with all patches, Immersive Wenches, Buxom Wench Yuriana, etc., and I know from the past that the Luxury Collection stuff looks very nice ). So, perhaps, I have to invent something. Sending complex mod events from C++ is impossible, you would have to directly use the SKSE sources for that, and then you would have an absolute version hell again with all the different SKSE and Skyrim versions. But perhaps some sort of Papyrus sattelite mod, which polls in regular intervals from SlaveTatsNG what tattoos have been removed or added (or gets notified by a simple mod event (sending these is possible from C++) from SlaveTatsNG that something has changed), and then sends the complex mod events, the other mods are listening for, would be possible.

 

Maybe it would be easier to combine some of the prior papyrus and your C++ code together?  Could your C++ code be re-factored in such a way that you could have something vaguely similar to a bare skeleton of the original papyrus, leaving the mod event stuff in place but replacing selected portions of the old papyrus with calls to your C++ code?

[nopse0]

46 minutes ago, Arcane Wanderer said:

 

Maybe it would be easier to combine some of the prior papyrus and your C++ code together?  Could your C++ code be re-factored in such a way that you could have something vaguely similar to a bare skeleton of the original papyrus, leaving the mod event stuff in place but replacing selected portions of the old papyrus with calls to your C++ code?

This all happens in the synchronize_tattoos function, it compares what you have on your body with what's in the MCM (JContainers), and then synchronizes these two states (and in the regular SlaveTats sends mod events). If you would split that up into two functions, e.g. a native_synchronize_tattoos and a Papyrus part, the synchronize_tattoos function wouldn't be atomic anymore, i.e. multiple synchronize_tattoos operations can be executed simultaneously. Well, perhaps that's not such a big thing, because the real critical part (manipulating JContainers and adding and removing overlays) is done in the native_synchronize_tattoos function, which is executed single-threaded by the Skyrim main thread, but the synchronize_tattoos is also called internally by other SlaveTats functions, e.g by simple_add_tattoo and simple_remove_tattoo, and I have no means to call the Papyrus part from C++ (same problem as sending complex mod events). In general I am quite happy with the robustness of the current solution. If it would be possible (it isn't because of compatibilty reasons), I would even remove the low level api of SlaveTats, and replace it with higher level combined atomic check and set functions like for atomic variables in programming languages. E.g. you can do a "_available_slot" in SlaveTats first, but when you then afterwards try to add a tattoo to that slot with add_tattoo, this slot may not be available anymore (concurrency). Such low level functions are useless.   

Edited September 21, 2024 by nopse0

[Arcane Wanderer]

10 minutes ago, nopse0 said:

This all happens in the synchronize_tattoos function, it compares what you have on your body with what's in the MCM (JContainers), and then synchronizes these two states (and in the regular SlaveTats sends mod events). If you would split that up into two functions, e.g. a native_synchronize_tattoos and a Papyrus part, the synchronize_tattoos function wouldn't be atomic anymore, i.e. multiple synchronize_tattoos operations can be executed simultaneously. Well, perhaps that's not such a big thing, because the real critical part (manipulating JContainers and adding and removing overlays) is done in the native_synchronize_tattoos function, which is executed single-threaded by the Skyrim main thread, but the synchronize_tattoos is also called internally by other SlaveTats functions, e.g by simple_add_tattoo and simple_remove_tattoo, and I have no means to call the Papyrus part from C++ (same problem as sending complex mod events). In general I am quite happy with the robustness of the current solution. If it would be possible (it isn't because of compatibilty reasons), I would even remove the low level api of SlaveTats, and replace it with higher level combined atomic check and set functions like for atomic variables in programming languages. E.g. you can do a "_available_slot" in SlaveTats first, but when you then afterwards try to add a tattoo to that slot with add_tattoo, this slot may not be available anymore (concurrency). Such low level functions are useless.   

 

Admittedly, not looking at the details of your implementation, but what if your code pushed modevent string names (hmmm and parameters) into a formlist?   Seems like a papyrus synchronize wrapper could call your dll-based synchronize and afterwards the papyrus function could pop off the names and send the events?

[nopse0]

8 minutes ago, Arcane Wanderer said:

 

Admittedly, not looking at the details of your implementation, but what if your code pushed modevent string names (hmmm and parameters) into a formlist?   Seems like a papyrus synchronize wrapper could call your dll-based synchronize and afterwards the papyrus function could pop off the names and send the events?

I cannot call this Papyrus synchronize wrapper from c++, when synchronize_tattoos is called internally. I think the cleanest solution is a Papyrus observer, which watches some sort of queue (I would simply use a JArray with JMaps in it for this, you can put Forms into JMaps). But this queue should be bounded, in case the observer crashes or is too slow, maybe dropping the oldest entries in the queue if the observer cannot keep up, or using multiple observers (doesn't matter which script sends the mod events).

[Arcane Wanderer]

2 hours ago, nopse0 said:

I cannot call this Papyrus synchronize wrapper from c++, when synchronize_tattoos is called internally. I think the cleanest solution is a Papyrus observer, which watches some sort of queue (I would simply use a JArray with JMaps in it for this, you can put Forms into JMaps). But this queue should be bounded, in case the observer crashes or is too slow, maybe dropping the oldest entries in the queue if the observer cannot keep up, or using multiple observers (doesn't matter which script sends the mod events).

 

I can't know what's best, but I think you misunderstand what I'm trying to say.  I'm asking if you could keep the synchronize_tattoos function in papyrus but just be a "wrapper" that does as little as possible other calling your C++ code.   After the C++ code returns, the papyrus function could check the queue.  That way, you don't have to do anything complex to get the papyrus portion to run.  I'm thinking that would give you simple communication between C++ and papyrus, not require scheduling, and papyrus access to the queue would be thread safe.

 

EDIT:  You seem to be saying that synchronize_tattoos needs to be called both by mods and by your C++ internals?   I thought that all synchronization needs could be driven by the mods because I didn't think the SlaveTats system would add or remove tats by itself.    If your internal code needs to invoke synchronization, perhaps your internal code could call the same c++ code that the papyrus wrapper function would call?  But, as you say, you'd still need a listener to fire the mod events if SlaveTats does applications or removals by itself.

 

If you need a listener to fire events, I'd think one listener would be enough.   Maybe driven by a modevent or .PO3's RegisterForMagicEffectApplyEx() which seems very efficient...

Edited September 21, 2024 by Arcane Wanderer

[nopse0]

5 hours ago, Arcane Wanderer said:

 

1) EDIT:  You seem to be saying that synchronize_tattoos needs to be called both by mods and by your C++ internals? 

 

2) If you need a listener to fire events, I'd think one listener would be enough.   Maybe driven by a modevent or .PO3's RegisterForMagicEffectApplyEx() which seems very efficient...

1): Yes, that's what I wanted to say.

2): Sounds interesting, will have a look at RegisterForMagicEffectApplyEx(). But if its just about notifying the observer that there is a new event, this can be done with _simple_ mod events (without Form fields etc.) 

[Gudulba]

I seem to have some issues with SlaveTatsSE and SlaveTatsNG:

 

- SlaveTatsSE 1.3.6 without SlaveTatsNG: seemed to be working fine (I am using SpankThatAss)

- SlaveTatsSE 1.3.9 without SlaveTatsNG: on loading a save game, it now shows "Please wait while SlaveTats works on...", which blocks access to the inventory menu for about 20 seconds -> a bit annoying...

- SlaveTatsSE 1.3.9 with the latest SlaveTatsNG and SpankThatAss patch: there is no loading message as in 1.3.9 (same behaviour as in 1.3.6), which is good, but now my PC's tits are constantly red (the ass is normal as it should be). I can revert it in SpankThatAss, but the red keeps returning. When checking in RaceMenu, I have BodyPaint entries for SpankThatAss and something like ST_SpankThatAss.

 

Is this a known issue?

 

[nopse0]

10 hours ago, Gudulba said:

- SlaveTatsSE 1.3.6 without SlaveTatsNG: seemed to be working fine (I am using SpankThatAss)

- SlaveTatsSE 1.3.9 without SlaveTatsNG: on loading a save game, it now shows "Please wait while SlaveTats works on...", which blocks access to the inventory menu for

Is this with my SpankThatAss patch ? (because otherwise STA doesn't use SlaveTats at all, but directly calls NiOverride functions).

 

The regular SlaveTats is very slow, because it makes thousands of JContainer calls (which, per se, are very fast, but the context switches between the Papyrus VM and the Skyrim main thread, which executes the native JContainer functions, take long)(also depends on the number of overlay slots you have). And the SlaveTats functions have a "silent" parameter, if this is false you get the message "Please wait while SlaveTats works on...", and the player controls are disabled, while SlaveTats is working (I ignore the silent flag in my implementation, because applying tattoos only takes a fraction of a second with NG, so a message or disabling player controls makes no sense).

 

10 hours ago, Gudulba said:

 but now my PC's tits are constantly red (the ass is normal as it should be). I can revert it in SpankThatAss, but the red keeps returning. When checking in RaceMenu, I have BodyPaint entries for SpankThatAss and something like ST_SpankThatAss.

 

Hmm, not sure. Basically I replaced in my STA patch in the UpdateAlpha() function:

NiOverride.AddNodeOverrideFloat(akTarget, Gender, Node, 8, -1, Alpha, TRUE)

 

with:

SlaveTats.simple_remove_tattoo(akTarget, "Spank That Ass", "sta_" + name, silent = true, last = False)
SlaveTats.simple_add_tattoo(akTarget, "Spank That Ass", "sta_" + name, alpha = Alpha, silent = true)

 

I first remove the tattoo with last = false (=> without synchronize_tattoos), and then reapply the tattoo with a different alpha (inverse transparency) value (last = true is the default), because you cannot change the alpha value of applied tattoos. Edit: This is ok, checked it, SlaveTats only lets external tattoos untouched in synchronize_tattoos, all other slots are either cleared or set anew.

 

10 hours ago, Gudulba said:

 When checking in RaceMenu, I have BodyPaint entries for SpankThatAss and something like ST_SpankThatAss.

 

 

If you see both SpankThatAss and ST_SpankThatAss in RaceMenu, I guess that you have both applied, the external STA overlay from before my STA patch, and SlaveTats tattoo from after my STA patch. 

 

 

Edit:

 

Something is wrong. I did a "skee dump overrides", and I see this in the skee64.log:

 

Something ois screwed up. The spank breasts & ass tattoos are applied twice in different overlay slots with different alpha values (Key (8)). If you reset the redness level (alpha = 0) only one of the two entries is changed (the one with Value 0.283536), the other one with value 1.0 keeps applied forever. Don't know where the second entry comes from, perhaps I made a mistake in my STA patch? Both entries have the same texture path, as one can see in the skee overlay dump, but they have different pattern names in the MCM:

 

 

Edit: Remove the double entries in the MCM (which don't start with "STA_"), then it works Ok.

 

I think the reason for the problem is, that I renamed the pattern names, so that they are the same as the texture names (I thought this is less confusing, because SlaveTats identifies what tattoos you have on your body by the texture names, not the pattern names). Didn't think on, that the entries with the old names still stay in the JContainer database.

 

 

 

 

 

Edited September 23, 2024 by nopse0

[superbongo330]

Sorry for asking a dumb question, but what exactly are the install requirements for this and what are the optimal load orders? My load order works perfectly as is; fully functioning sexlab and cum overlays extended, etc, pretty extensive but all working together and stable. I decided to try implementing this, fade tattoos, rape tattoos and a dozen or so texture mods for them to draw from and my game has started freezing frequently after load screens, or trying to adjust MCM settings causes it to outright crash as soon as I close the MCM submenu I was fiddling with.

 

Does SlaveTats (the original) need to be installed and then this? Is it just this without the original SlaveTats and everything like fadetats/rapetats works with it? Does manually going through the MCM menu and setting every tattoo placement to unassigned break your game? Is it designed to only have a handful of texture mods and too many cause a huge problem like loading screen freezes and MCM crashes?

Edited September 24, 2024 by superbongo330

[lovalter]

On 9/9/2024 at 2:19 AM, lovalter said:

Would it be possible to add more color options? Maybe an rgb picker?

Bump

[nopse0]

9 hours ago, superbongo330 said:

Sorry for asking a dumb question, but what exactly are the install requirements for this and what are the optimal load orders? My load order works perfectly as is; fully functioning sexlab and cum overlays extended, etc, pretty extensive but all working together and stable. I decided to try implementing this, fade tattoos, rape tattoos and a dozen or so texture mods for them to draw from and my game has started freezing frequently after load screens, or trying to adjust MCM settings causes it to outright crash as soon as I close the MCM submenu I was fiddling with.

 

Does SlaveTats (the original) need to be installed and then this? Is it just this without the original SlaveTats and everything like fadetats/rapetats works with it? Does manually going through the MCM menu and setting every tattoo placement to unassigned break your game? Is it designed to only have a handful of texture mods and too many cause a huge problem like loading screen freezes and MCM crashes?

No, normally it shouldn't cause any freezes, I have fade tattoos and rape tattoos installed, too, and have no problems. Also the number of tattoos doesn't matter with SlaveTats-NG, I have 120 overlay slots, and no problems, I think, the number of tattoos is only limited by how many textures your graphics card can render. I think your problem is cum overlays, I had the same problems, if you enter a new cell, and it tries to apply persistent cum overlays to npc's which aren't completely loaded yet, it crashes or freezes. It also crashes, if it applies cum overlays in sex scenes initiated by RandomSex-NG, and it often makes actors invisible after sex scenes, it must have a timing/concurrency problem, and now with the increased speed of SlaveTats, it also has a problem with SlaveTats. I would deinstall it (the SexLab cum textures doesn't look that bad, I find). But I fear you have to start a new game after deinstalling cum overlays, at least I didn't manage to continue my savegame after that. But at least for me this solved all stability problems, and with the increased speed of SlaveTats-NG, my Skyrim is as solid as a rock, didn't have a ctd/freeze for a month, or so

[nopse0]

5 hours ago, lovalter said:

Bump

Not me, SlaveTatsMCMMenu.psc is 31 kb (!), and, err, not easy to understand, this would be an enormous amount of work.