SlaveTatsNG

[nopse0]

4 hours ago, sidfu1 said:

kinda. what would happen is when you load the game  first racemnu would check itself and have the default listed. but then slave tats would change that to the blank.dds this seemed to cause it to sometimes prevent other mods from applying their  overlay at start for example bisr would  sometimes miss the face or hands due to it.
but i still get this with slave tats  1.3.7 and get no crash.  i think 1.3.9 crashes due to it begins to go thru every npc  you ever applied  slave tats to(i say this as ive seen it say checking xx npc that is literally not even 3d loaded/havent been ear for litearly 20 hours or on other side of map so can only guess that) and so eventuay it hits a npc it cant change to the blank texture then crashes. this would explain why the crash is so random. you can literally  one min get the crash 5 min after start and another time play 12 hours.

This sounds very reasonable, that synchronize_tattoos is triggered for actors, whose 3D models are not loaded. I added an "actor->Is3DLoaded()" check at the begin of synchronize_tattoos (sorry, for all these small, trial and error micro updates). I kow, that when a save-game is loaded, synchronize_tattoos is triggered, I have no idea, though, how. Is this coming from the 

event OnPlayerLoadGame()
    int targets = JDB.solveObj(".SlaveTatsMenu.known_targets")
    int i = JArray.count(targets)
    while i > 0
        i -= 1
        Actor who = JArray.getForm(targets, i) as Actor
        SlaveTats.synchronize_tattoos(who)
    endwhile

in SlaveTatsOnLoad.pex ? Or is this triggered by mods like Apropos2 ?

[Nuascura]

@nopse0 Wouldn't it make sense to revert the change in 0.6.7? I fear that papyrus mods unrelated to slavetats that are dependent on racemenu nioverride won't be able to properly identify open slots per sidfu's experience.

[nopse0]

21 minutes ago, Nuascura said:

@nopse0 Wouldn't it make sense to revert the change in 0.6.7? I fear that papyrus mods unrelated to slavetats that are dependent on racemenu nioverride won't be able to properly identify open slots per sidfu's experience.

Yes, I asked this myself, too, but then I thought, well, the IsD3Loaded() check probably fixes most of the crashes, and, if there are other, more exotic crash scenarios, the blocking of the free overlay slots like SlaveTats does with the slavetats/blank.dds, probably the rest. Maybe we should wait a day or two, check if there are still crashes, and if not, revert the "slavetats/blank.dds" change (and check if the crashes come back). 

[sidfu1]

ill try newest again on the existing game to see if crash happens again

update
so far after around 4 hours on existing game no crash. i will keep using it and if it doens crash by 10-15 hour mark its possible it might have fixed the issue.

Edited March 19, 2025 by sidfu1

[nopse0]

3 hours ago, sidfu1 said:

ill try newest again on the existing game to see if crash happens again

update
so far after around 4 hours on existing game no crash. i will keep using it and if it doens crash by 10-15 hour mark its possible it might have fixed the issue.

 

Thank you, sounds good so far, hopefully it stays so. If the Is3DLoaded check triggers, there will be a log message in the SlaveTatsNG.log:

		if (!a_target->Is3DLoaded()) {
			logger::info("a_target->Is3DLoaded == false, aborting synchronize_tattoos, a_target = {}", (void*)a_target);
			return true;
		}

 

[nopse0]

In my opinion, it seems to be quite clear now, that the game crashes, if NiOverride.ApplyNodeOverrides(aActor) is called on actors, whose 3D models aren't loaded. This fits to my own observations. I had noticed in the past, that the game randomly crashed, when I didn't do a ApplyNodeOverrides at the very end of synchronize_tattoos. The explanation simply is, I think, that if an actor has unapplied NodeOverrides, and ApplyNodeOverrides is triggered at a later time, when the 3D model of the actor is not loaded => crash.

 

What I mainly want to say with this comment is, that it doesn't matter who makes the ApplyNodeOverrides call on an actor with unapplied NodeOverrides and not loaded 3D, SlaveTats (Papyrus, or NG) or another mod which adds external overlays, doesn't matter, the result is the same, crash. So, mod authors, do a Is3DLoaded check, before calling NiOverride.ApplyNodeOverrides.

 

I will make the blocking of free overlay slots by using the slavetats/blank.dds texture the default, as a safety measure. But I will make it configurable, i.e. if "slavetats/blank.dds" or "default.dds" is used for clearing free overlay slots, and if you are sure that all your mods are well behaved, and are checking Is3DLoaded before calling ApplyNodeOverrides, you can switch on, that "default.dds" is used.

 

Where do this ApplyNodeOverrides calls for actors without 3D coming from ? Some guesses: Maybe dangling ReferenceAliases to actors, which are deleted or far away ? And also, Papyrus is slow (stack dumps, etc.), it may be when the line with the ApplyNodeOverrides call in your script is executed, the 3D of the actor is already unloaded again.

 

 

[sidfu1]

i did have 1 crash in around 10 hours  but dont think this crash was due to a none 3d loaded actor as it was in the instance  i went ot bath with followers. i had forgot about the ng log so ill keep playing and if i get another crash ill check it. so think you may have fixed the issue with none 3d loaded people but not the issue is  of why racemnu keeps messing up overlays causing the access error.

im thinking at this point the issue is nore more on racmenu side than slave tats or other mods

 

[Nuascura]

21 hours ago, nopse0 said:

I will make the blocking of free overlay slots by using the slavetats/blank.dds texture the default, as a safety measure. But I will make it configurable, i.e. if "slavetats/blank.dds" or "default.dds" is used for clearing free overlay slots, and if you are sure that all your mods are well behaved, and are checking Is3DLoaded before calling ApplyNodeOverrides, you can switch on, that "default.dds" is used.

I think it may be wiser to revert the change first and see what the actual effect of blank.dds is. I am still confused what's the purpose of this blocker within slavetats unless you wanted to lock and reserve empty slots for later slavetats use. If papyrus mods must change overlays on the fly, the current idea and setup is unintuitive. Unless we actually understand how this part of slavetats (and nioverride) functions, it would at least be more reasonable to leave the use of blank.dds as an optional toggle on.

[nopse0]

 

2 hours ago, Nuascura said:

I think it may be wiser to revert the change first and see what the actual effect of blank.dds is. I am still confused what's the purpose of this blocker within slavetats unless you wanted to lock and reserve empty slots for later slavetats use. If papyrus mods must change overlays on the fly, the current idea and setup is unintuitive. Unless we actually understand how this part of slavetats (and nioverride) functions, it would at least be more reasonable to leave the use of blank.dds as an optional toggle on.

 

It's very unclear to me, too, what effect using slavetats/blank.dds instead of default.dds has. In any case, It doesn't seem to permanently block free overlay slots. It seems, that after the node overrides have been applied (= converted to shader properties), the shaders detect that blank.dds is an empty texture and that there is nothing is to be done, and  this feedback gets back to Racemenu. Because initially, when you do a 'showracemenu' in the console, RaceMenu is showing this:

Spoiler

 

After having applied a slavetats tattoo, racemenu is showing this:

Spoiler

 

But if you do a "skee dump overrides" in the console, you get this, the character has no overrides, the character has no "blank" overlays:

Spoiler

 

And after saving and restarting the game, racemenu shows this:

Spoiler

 

 

So I think, practically it makes no difference, if using slavetats/blank.dds or default.dds. On the other hand, that's the only difference I see between Papyrus SlaveTats and SlaveTatsNG, and maybe this helps in the critical phase when SlaveTats and other mods simultaneously try to add overlays.

 

Btw., Face overlays seem to be treated differently, racemenu always shows "default.dds" for them and never "blank.dds". Maybe this has to do with all this headparts/facegen stuff.

Spoiler

 

Edited March 21, 2025 by nopse0

[Nuascura]

2 hours ago, nopse0 said:

So I think, practically it makes no difference, if using slavetats/blank.dds or default.dds. On the other hand, that's the only difference I see between Papyrus SlaveTats and SlaveTatsNG, and maybe this helps in the critical phase when SlaveTats and other mods simultaneously try to add overlays.

This I will have to defer to @sidfu1 again. To be clear, I'm still using your 0.6.6 version without any visible issues. My Bathing in Skyrim Renewed operates just like Monoman's BiS Tweaked when applying dirt, which is through RM overlays. Apparently, in base SlaveTats (without your NG), the blank.dds reserves the slot and prevents BISR from applying dirt on game load IF the MCM has been opened once, which triggers some sort of flag to always refresh and re-check all slots on each game load thereafter.

 

So that's the root of my worry. Since Sidfu was the original reporter: if they can confirm this issue doesn't exist with your latest STNG version, then we're gucci. Otherwise, I worry blank.dds, when applied in any condition non-NG or NG, really does take the slot away from mods like mine which need to apply and remove overlays throughout gameplay and within a single game session.

 

Alternatively, since you observed that blank.dds behavior on your end after applying a tat, maybe you can test it out with your NG: After applying a tattoo, wait until BISR applies dirt. See if there are any issues with BISR applying its racemenu overlays.

Edited March 21, 2025 by Nuascura

[nopse0]

4 hours ago, Nuascura said:

This I will have to defer to @sidfu1 again. To be clear, I'm still using your 0.6.6 version without any visible issues. My Bathing in Skyrim Renewed operates just like Monoman's BiS Tweaked when applying dirt, which is through RM overlays. Apparently, in base SlaveTats (without your NG), the blank.dds reserves the slot and prevents BISR from applying dirt on game load IF the MCM has been opened once, which triggers some sort of flag to always refresh and re-check all slots on each game load thereafter.

 

So that's the root of my worry. Since Sidfu was the original reporter: if they can confirm this issue doesn't exist with your latest STNG version, then we're gucci. Otherwise, I worry blank.dds, when applied in any condition non-NG or NG, really does take the slot away from mods like mine which need to apply and remove overlays throughout gameplay and within a single game session.

 

Alternatively, since you observed that blank.dds behavior on your end after applying a tat, maybe you can test it out with your NG: After applying a tattoo, wait until BISR applies dirt. See if there are any issues with BISR applying its racemenu overlays.

 

My main concern are the crashes. Starting from a clean base situation without crashes, would make it easier to find out, what's causing problems.

[Nuascura]

25 minutes ago, nopse0 said:

My main concern are the crashes. Starting from a clean base situation without crashes, would make it easier to find out, what's causing problems.

 

I understand. But as a data point, I never had crashes with default.dds. And with is3DLoaded being confirmed to mitigate or resolve the issue, the crashes ostensibly seem less and less to do with default.dds, so ostensibly it feels like we could've been regressing unnecessarily even for testing.

 

But that's all irrelevant anyway. At least I think it is. I had some time so I tested 0.6.9 for us all. This is my process:

1. Create a new character
2. Add SlaveTats Tattoo via Licenses' event
3. Run showracemenu
4. Observe that the "Default" labeled slots are now filled by "blank.dds", per your observation
5. Enable BISR
6. Wait until BISR applies dirt
7. Observe that dirt is applied successfully
8. Restart game session (reload from desktop)
9. Observe that the dirt stays applied (BISR runs a complete overlay reapplication on game load to workaround Racemenu issues)

So at least on my end, it seems like there is no difference between blank.dds and default.dds, correctly per your own observation.

[sidfu1]

so far with  slave tats ng 6.8 and slave tats 1.3.7 ive only had that 1 crash  since the is3d loaded was added. this is with around 20 hours playing. so there is some situations it may still crash but its probaly far more rare now.
for bisr so far it seems to be doing fine  with  overlays getting applied fine. ive not noticed any missing body parts on anyone.

ima install the newest  NG and set it to use the racemenu default at first to see if any issues happen.

i think the bisr issue before was not that it was teh  blank.dds but more of slave tats when it did that debug funtion at game load would reserve the racmeny slots causing bisr to faill to apply the texture. this woudl explain why it would be fine on  new game till slave tats mcm was opened triggering that  checking of overlays.

update.
newest version has bug that if you open the  mcm for slave tats everyone goes blue skined even after a save reload.
also had another crash. and the thing both crashes ive had with the newest versions since the 3dloaded was added is both crashes was when the equipment state of said npc was changing. 1st was when went naked to bath. this one was went naked to sleep.

 

Edited March 22, 2025 by sidfu1

[nopse0]

8 hours ago, sidfu1 said:

newest version has bug that if you open the  mcm for slave tats everyone goes blue skined even after a save reload.
also had another crash. and the thing both crashes ive had with the newest versions since the 3dloaded was added is both crashes was when the equipment state of said npc was changing. 1st was when went naked to bath. this one was went naked to sleep.

I also had this blue skin problem when I changed the blank texture name, as I wrote, and as you saw. Save reload isn't enough to reset the shaders, you have to restart the game, can/did you try this ? I double checked with log messages that the texture name string is ok (first when the .ini is parsed, and later, when it's used  for  the AddNodeOverrideString call), and it is ok:

		RE::BSFixedString blankPrefix = slavetats_ng::config::Config::GetSingleton()->blank_texture_name;
		logger::info("blank_texture_name = {}", blankPrefix);
		// RE::BSFixedString blankPrefix = string(PREFIX()) + "blank.dds";

 

This was the only thing I changed in the new version, so I think the equipment state change crashes are unrelated to this.

 

Since sleeping and bathing changes the dirtiness of actors, the crashes are probably caused by BIS. I gathered from the mail thread here, that you are using Nuascura 's BISR. Can you ask him, to add "Is3DLoaded()" checks in mzinOverlayUtiliy.psc around the blocks with ApplyNodeOverides calls, e.g. in the ClearDirt function change:

	If akTarget != PlayerRef
		NiOverride.ApplyNodeOverrides(akTarget)
		NiOverride.RemoveOverlays(akTarget)
	EndIf

to

	If akTarget != PlayerRef && akTarget.Is3DLoaded()
		NiOverride.ApplyNodeOverrides(akTarget)
		NiOverride.RemoveOverlays(akTarget)
	EndIf

 

Edited March 22, 2025 by nopse0

[JohnConquest12]

Hello i wanted to update my Slavetats with this mod as well as fade and rape tattoos with the continued versions and now I'm facing a bug where it spams messages on my screen saying "Slavetats is working on my character" every 15 seconds. Is this concerning?

[nopse0]

1 hour ago, JohnConquest12 said:

Hello i wanted to update my Slavetats with this mod as well as fade and rape tattoos with the continued versions and now I'm facing a bug where it spams messages on my screen saying "Slavetats is working on my character" every 15 seconds. Is this concerning?

 

The "Slavetats is working on my character" notification is not from me, SlaveTatsNG is absolutely silent (makes no sense to show a notification on screen, if it only takes a fraction of a second to add a tattoo). So, if you already installed SlaveTatsNG, my SlavetTats.pex, which calls the native functions, is overwritten by another mod (LewdMarks?, check load order). Otherwise, the message is not concerning, the continued rape and fade mods are using SlaveTats (just had a look in the scripts), and the Papyrus SlaveTats shows this message, when applying tattoos.

Edited March 23, 2025 by nopse0

[JohnConquest12]

1 hour ago, nopse0 said:

 

The "Slavetats is working on my character" notification is not from me, SlaveTatsNG is absolutely silent (makes no sense to show a notification on screen, if it only takes a fraction of a second to add a tattoo). So, if you already installed SlaveTatsNG, my SlavetTats.pex, which calls the native functions, is overwritten by another mod (LewdMarks?, check load order). Otherwise, the message is not concerning, the continued rape and fade mods are using SlaveTats (just had a look in the scripts), and the Papyrus SlaveTats shows this message, when applying tattoos.

Ok. i also forgot to mention I have combat wounds too which is also another mod that adds them mostly in combat but I wasnt in combat when the messages kept getting spammed. But now I'm facing another issue. Since i updated all these mods I get a CTD when loading certain saves. Even tried it on a new game and same thing. Crash log said it's a skee64 thing which i think it's racemenu related. So I'm trying to narrow it down. It could be this mod, or combat wounds or maybe obody since they're racemenu related mods. This didn't happen until I put SlavetatsNG , rape and fade tats continued onto my load order. I just used the older versions of those mods and had no problem

Edited March 23, 2025 by JohnConquest12

[nopse0]

53 minutes ago, JohnConquest12 said:

Ok. i also forgot to mention I have combat wounds too which is also another mod that adds them mostly in combat but I wasnt in combat when the messages kept getting spammed. But now I'm facing another issue. Since i updated all these mods I get a CTD when loading certain saves. Even tried it on a new game and same thing. Crash log said it's a skee64 thing which i think it's racemenu related. So I'm trying to narrow it down. It could be this mod, or combat wounds or maybe obody since they're racemenu related mods. This didn't happen until I put SlavetatsNG , rape and fade tats continued onto my load order. I just used the older versions of those mods and had no problem

 

You could try to rescue the old saves by removing all NiOverride overlays and clearing the SlaveTats JContainers Data (by using the .esp from https://www.nexusmods.com/skyrimspecialedition/mods/125941 and the patched NiOverrideClean.pex from SlaveTatsNG), and perhaps by making a clean save and reinstalling rape&fade tattoos (I always make a backup of my Skyrim installation, if doing such risky stuff, load order changes, mod deinstallation, clean save, etc, so in case nothing works after this, I can rollback), in case there are script zombies of the old versions still active. But you said, you also have this on new games, this is strange. Can you upload the CrashDump (from NexusMods) log, SlaveTatsNG.log, Papyrus0.log  from a new game crash, and any other logs, which may contain useful information (obody?, combat wounds?) ?

Edited March 23, 2025 by nopse0

[JohnConquest12]

I think i solved it but i'll put the crash log anyway just to see what it was. All I did was rollback everything. Uninstalled this mod, rape and fade tats back to the old versions and coincidentally did find that mod you linked earlier and used it but not sure if it helped solved my problem since i tried it after reverting everything back. I even loaded up a save with missing plugins and scripts to test it out and surprisingly it did load without CTD. Now everything loads back up. It's a heavy load order just fyi and yes it's stable in case your wondering. Still getting the message spam from time to time which is strange since it didn't do that before so it's probably not your mod then

 

https://pastebin.com/Z4aQ0MYX

Edited March 23, 2025 by JohnConquest12

[GraysW]

Don't work with Dibellan Defender.

I was trying with 6.9 and 6.5 versions, same observation.

 

[nopse0]

16 hours ago, GraysW said:

Don't work with Dibellan Defender.

I was trying with 6.9 and 6.5 versions, same observation.

 

 

Yes, just checked it, it uses this tattoo magic stuff, this isn't implemented:

 

 

To be honest, I have no idea what this is supposed to do, and how this works, does this add a magic effect to the player, and template contains the spell and the magnitude/duration ?

 

Could be complicated, first of all I have no complex mod events (would need a workaround for this, see previous posts), and then I do not know if there is an equivalent for the used Papyrus functions in a low level C++ plugin.

Spoiler

 

bool function activate_tattoo_magic(Actor target, int tattoo, bool deactivate_first = false) global
    bool magic = false

    string tattoo_event = JMap.getStr(tattoo, "event")
    if tattoo_event != ""
        magic = true
        int evt

        if deactivate_first
            evt = ModEvent.Create(tattoo_event)
            if evt
                ModEvent.PushString(evt, "cleared")
                ModEvent.PushForm(evt, target)
                ModEvent.Send(evt)
                Debug.Trace("SlaveTats: Sent ModEvent " + tattoo_event + "(\"cleared\", " + target.GetLeveledActorBase().GetName() + ")")
            endif
        endif

        evt = ModEvent.Create(tattoo_event)
        if evt
            ModEvent.PushString(evt, "applied")
            ModEvent.PushForm(evt, target)
            ModEvent.Send(evt)
            Debug.Trace("SlaveTats: Sent ModEvent " + tattoo_event + "(\"applied\", " + target.GetLeveledActorBase().GetName() + ")")
        endif
    endif

    Spell spell_ = get_form(tattoo, "spell_plugin", "spell_formid") as Spell
    if spell_ != none
        magic = true

        Debug.Trace("SlaveTats: Tattoo spell = " + spell_.GetName())

        ObjectReference source = get_form(tattoo, "spell_source_plugin", "spell_source_formid", target) as ObjectReference

        if deactivate_first
            Debug.Trace("SlaveTats: Dispelling " + spell_.GetName())
            target.DispelSpell(spell_)
            Utility.Wait(0.25)
        endif

        Debug.Trace("SlaveTats: Casting " + spell_.GetName())
        spell_.Cast(source, target)
    endif

    if magic
        int activated = JFormDB.getObj(target, ".SlaveTats.activated")
        if activated == 0
            activated = JValue.addToPool(JArray.object(), "SlaveTats-activate_tattoo_magic") ; I would love for this to be a JSet, but no such beast exists
            JFormDB.setObj(target, ".SlaveTats.activated", activated)
        endif
        if JArray.findObj(activated, tattoo) < 0
            JArray.addObj(activated, tattoo)
        endif
    endif

    JValue.cleanPool("SlaveTats-activate_tattoo_magic")
    return false
endfunction

 

Problem is, that activate_tattoo_magic and deactivate_tattoo_magic are also called from within synchronize_tattoos (C++). I think I could send a simple mod event from C++, and then do the rest from a Papyrus script. But I would need something which listens for these events, and executes the Papyrus part => player ReferenceAlias +  .esp file, not nice.

 

Edit: I think at least the Papyrus "target.DispelSpell" i can do natively, because a "RE::Actor" is also a "Re::MagicTarget", and a magic target has a function "MagicTarget::DispelEffect(MagicItem* a_spell, ..)", and a spell ("Re::SpellItem" in C++)  is also a "RE::MagicItem". Quite sure, this would do the same as in Papyrus.

The other functions, "spell.cast" etc., can probably also be done natively in C++. Then there remains only the problem of the complex mod events. 

 

Edit:

Does this work with Papyrus SlaveTats, or has this ever worked at all ?

 

Because I see DibellanDefender is calling "SlaveTats.refresh_tattoo_magic(defender, template)", with template = (as JSON):  {  "dibellan_tattoo": 1 }

but I don't see it is adding any tattoos at all to SlaveTats (or the JContainer data SlaveTats uses). and if it would add any tattoos to SlaveTats, the tattoos would have to have the fields "spell_plugin" and "spell_formid" for refresh_tattoo_magic to do anything.

 

Edit #2: Ah, I see, this is part of the dibellandefender.json:

[
    {"name":"Dibellan Warrior's Mark",
     "section":"Dibellan Calling",
     "texture":"dibellandefender\\dibellan_warrior.dds",
     "area":"Body",
     "color":16777215,
     "glow":16777215,
     "spell_plugin":"DibellanDefender.esp",
     "spell_formid":4810,
     "dibellan_tattoo":1,
     "dibellan_calling":1,
     "excluded_by":"dibellan_calling"},

    {"name":"Dibellan Assassin's Mark",
     "section":"Dibellan Calling",
     "texture":"dibellandefender\\dibellan_assassin.dds",
     "area":"Body",
     "color":16777215,
     "glow":16777215,
     "spell_plugin":"DibellanDefender.esp",
     "spell_formid":4811,
     "dibellan_tattoo":1,
     "dibellan_calling":1,
     "excluded_by":"dibellan_calling"},

 

I will implement the missing functions (without the "event" stuff, DibellanDefender" doesn't use this). But, I may be wrong, but I still think, there is missing something like "add_tattoo" or so, to actually add those tattoos to the character:

 

In SlaveTats.psc:

bool function refresh_tattoo_magic(Actor target, int template) global
    int matches = JValue.addToPool(JArray.object(), "SlaveTats-refresh_tattoo_magic")
    if query_applied_tattoos(target, template, matches)
        JValue.cleanPool("SlaveTats-refresh_tattoo_magic")
        return true

So if the tattoo isn't applied, refresh_tattoo_magic does nothing. Maybe this has changed between SlaveTats versions, because DibellanDefender is 10 years old, and uses SlaveTats 1.0.4

 

 

Edited March 24, 2025 by nopse0

[nopse0]

Implemented the missing tattoo_magic functions ("DibellanDefender").

Untested, just checked that the program still works and doesn't crash.

[GraysW]

Thx !  It seems to work, indeed.

[w234aew]

So what mods even use the missing ModEvents features? I've been trying to figure out if I can switch over or not.

 

Main mods which use slavetats in my load order are YPS, BoS, BimboSkin (though I don't use slavetats on PC, I use skin tint), and maybe Beach Body?

 

I seem to remember older LE mods (SD+, etc.) having an independent mod/ESP set to deal with interfacing between SlaveTats API and ModEvents.

Edited March 26, 2025 by w234aew

[nopse0]

5 hours ago, w234aew said:

So what mods even use the missing ModEvents features? I've been trying to figure out if I can switch over or not.

 

Main mods which use slavetats in my load order are YPS, BoS, BimboSkin (though I don't use slavetats on PC, I use skin tint), and maybe Beach Body?

 

I seem to remember older LE mods (SD+, etc.) having an independent mod/ESP set to deal with interfacing between SlaveTats API and ModEvents.

 

In my opinion the mod event feature of SlaveTats is not good, it produces far too many events (see my mail from September 27, 2024 ). This may be ok if you only have the default number of overlay slots (6,3,3,3), but not if you have over 100 overlay slots like me. I think this would bring down the vm.