SlaveTatsNG

[wareware]

With this mod enabled I get "[STEB] ERROR: OnAddTattoo synchronize_tattoos failed" notification when I start a new game. It probably belongs to YPS as it uses the STEBAddTattoo function to equip slavetats to its vendors on game start.

 

I am assuming its failing because of the Is3dLoaded() condition added in 0.6.8

[nopse0]

2 hours ago, wareware said:

With this mod enabled I get "[STEB] ERROR: OnAddTattoo synchronize_tattoos failed" notification when I start a new game. It probably belongs to YPS as it uses the STEBAddTattoo function to equip slavetats to its vendors on game start.

 

I am assuming its failing because of the Is3dLoaded() condition added in 0.6.8

Yes, can be. Do you get this for the player actor or another actor? In SlaveTatsNG.log there will be a ""a_target->Is3DLoaded == false, aborting synchronize_tattoos, a_target =.." message, if synchronize_tattoos is aborted because of not loaded 3D model. If it's for the player, then maybe this is happening while the player is changing cells. Maybe trying to repeat synchronize_tattoos a few times with some delay helps. On the other hand, if synchronize_tattoos fails, this isn't the end of the world, the tattoos aren't lost, they will just become visible the next time, when synchronize_tattoos is successfull

[Nuascura]

On 4/14/2025 at 3:48 PM, nopse0 said:

The functions ApplyDirt, CleanDirt and UpdateAlpha are working, the problem is, to get Nua to call them. I added log output to those functions, they simply aren't called, Last time, when I tested this, I could trigger those functions by modifying the "Begin Applying Dirt At" and "Starting Opacity" sliders in the BIS MCM, but this time, after saving and reloading, I wasn't able to do this, like you. There seem to be problems in BISR, BIS Tweaked from Monoman is much more reliable in this regard. From my side, I did everything I can do, the above mentioned functions are working, the rest is Nua's problem.

If a mod doesn't work for a user no matter what they've thought of trying, then it doesn't work. But those functions are critical for use; people would've thrown a fit much earlier if they aren't called at all. If you have enabled the papyrus log with monoman's BIS, you would have seen just how much memory pressure is applied by the sheer number of both unnecessary and duplicate calls to these functions. This was a critical issue I had to fix for BISR/

 

I would double-check your SDK before compiling and re-test your files on a new game.

[nopse0]

22 minutes ago, Nuascura said:

If a mod doesn't work for a user no matter what they've thought of trying, then it doesn't work. But those functions are critical for use; people would've thrown a fit much earlier if they aren't called at all. If you have enabled the papyrus log with monoman's BIS, you would have seen just how much memory pressure is applied by the sheer number of both unnecessary and duplicate calls to these functions. This was a critical issue I had to fix for BISR/

 

I would double-check your SDK before compiling and re-test your files on a new game.

Sorry, I sounded a bit angry, I didn't wanted to insult you, but I simply changed the AddDirt, CleanDirt and UpdateAlpha function to use SlaveTats functions (have a look at my changed overlay.psc), and noticed that this doesn't work as expected. I suspect the reason is (I may be wrong), that you call AddDirt initially twice, then CleanDirt (which in your version only removes 1 of the 2 overlays), and afterwards never call AddDirt again, is this right (from your mail, I gather yes) ? This is a total change of the logic behind these functions. The simplest way to achieve this with SlaveTats, would be to do a simple_add_tattoo in AddDirt, and do nothing in CleanDirt, but this feels a bit hacky to me. At least, I confirm to you, when using SlaveTats, you can use the three functions as intended, no noticable time penalty. 

[Nuascura]

@nopse0 The sequence is heavily derivative of monoman's seq ofc.

 

We do an "OnBiS_UpdateActorsAll" event, called from onplayerloadgame, under mzinGetDirtyOverTime. So if we trace that, it should call overlayutility's "ApplyDirt()" if applicable for an actor. That calls ClearDirt() and then BeginOverlay().

 

I assume you mean ApplyDirt rather than AddDirt: the logic for calling these functions shouldn't be too dissimilar from how monoman used them. We never call ApplyDirt twice in succession. But yeah like you said, we never call it again under an active dirt cycle in the same game session; like from our mzinDirtyOverlay MGEF script, we try only to ever call this function once and never again.

 

Mono's BIS calls ApplyDirt at each change of dirt state which removed and re-applies dirt, and at loc change. This is problematic because

1. For some users, rapidly removing an overlay and applying it immediately afterward caused the overlay to go missing
2. It's an unnecessary step to update dirt for the player actor when, in those cases, we only need to update alpha

 

Btw, I noticed you used my utility script's collecting LogTrace() function instead of debug.log. Did you enable the "Log Traces" option under my MCM?

Edited April 16, 2025 by Nuascura

[nopse0]

4 hours ago, Nuascura said:

Did you enable the "Log Traces" option under my MCM?

Yes, I enabled it  and used your log function, because I wanted to get all log output, your's and mine, to find out what's going on.

 

Btw., I also detected a big bug in my patch, I was only applying the body area dirt tattoo, not the others (uploaded new version), but this won't fix the problem.

 

It's ok, if you don't do a:

  

  ClearDirt()

  BeginOverlay()

 

if it isn't neccessary. But then, CleanDirt must not not be called after ApplyDirt, otherwise the dirt tattoo is gone, and this seems to happen somewhere in the BISR code (far beyond my scope, to find out where this happens). 

 

 

Edited April 16, 2025 by nopse0

[Nuascura]

2 hours ago, nopse0 said:

if it isn't neccessary. But then, CleanDirt must not not be called after ApplyDirt, otherwise the dirt tattoo is gone, and this seems to happen somewhere in the BISR code (far beyond my scope, to find out where this happens). 

can you let me know in what context it happens? Or if you have a step-by-step process in-game?

 

Are you able to replicate this issue without your patch, using just BISR with no other conflicting mods?

Edited April 16, 2025 by Nuascura

[nopse0]

7 hours ago, Nuascura said:

can you let me know in what context it happens? Or if you have a step-by-step process in-game?

 

Are you able to replicate this issue without your patch, using just BISR with no other conflicting mods?

 

Ok, your mail motivated me to investigate this further instead of to give up.

 

Loaded an older game without Mono+Baka+Improved Animations or BISR, installed BISR and got this (exactly as you said):

 

Suche "#######" (24 Treffer in 1 Dateien von 1 gesucht)
  C:\Users\nirme\Documents\My Games\Skyrim Special Edition\Logs\Script\Papyrus.0.log (24 Treffer)
	Zeile 698: [04/16/2025 - 09:23:11PM] [BISR] ClearDirtGameLoad, akTarget=[Actor < (00000014)>]###############################
	Zeile 734: [04/16/2025 - 09:27:10PM] [BISR] ClearDirt, akTarget=[Actor < (00000014)>]###############################
	Zeile 735: [04/16/2025 - 09:27:10PM] [BISR] BeginOverlay, akTarget=[Actor < (00000014)>]###############################
	Zeile 739: [04/16/2025 - 09:27:10PM] [BISR] UpdateAlpha, akTarget=[Actor < (00000014)>]###############################
	Zeile 809: [04/16/2025 - 09:31:08PM] [BISR] UpdateAlpha, akTarget=[Actor < (00000014)>]###############################
	Zeile 822: [04/16/2025 - 09:31:09PM] [BISR] UpdateAlpha, akTarget=[Actor < (00000014)>]###############################

 

 

About the "ClearDirtGameLoad" line: This is because I saved the game, I see in the log each time before the VM freezes the game, ClearDirtGameLoad is called (so "GameLoad" is a bit misleading, it is also an "BeforeSave" event).

 

I guess, if I simply do nothing in the "ClearDirtGameLoad" function, it would work. Only problem I see, I don't want, that if you play for a prolonged time, that thousands of actors have dirt overlays/tattoos. Are you also clearing the dirt of actors, if the "dirty over time" spell of actors expires, or some other sort of garbage collection ?

 

Edit: Yes, works. I changed the ClearDirtGameLoadFunction to:

Function ClearDirtGameLoad(Actor akTarget)
	; Only clears npc tattoos on Save/Load game, leave player tattoos untouched
	If akTarget != PlayerRef
		Int Template = JValue.retain(JValue.objectFromPrototype("{ \"mzin\":1 }"))
		SlaveTats.remove_tattoos(akTarget, Template)
		; No synchronize_tattoos, so the dirt tattoos remain visible on npc's (until synchronize_tattoos is called the next time, or the game is reloaded) 
		; SlaveTats.synchronize_tattoos(akTarget, silent = True)
		JValue.release(Template)
	
		StorageUtil.UnSetStringValue(akTarget, "mzin_DirtTexturePrefix")
	EndIf
EndFunction

So, the dirt tattoos on npc's are still removed on Save/Load game, but remain visible  until synchronize_tattoos is called the next time, or the game is reloaded. This comes close to what BISR is doing.

 

 

Edited April 16, 2025 by nopse0

[Nuascura]

8 hours ago, nopse0 said:

About the "ClearDirtGameLoad" line: This is because I saved the game, I see in the log each time before the VM freezes the game, ClearDirtGameLoad is called (so "GameLoad" is a bit misleading, it is also an "BeforeSave" event).

 

I guess, if I simply do nothing in the "ClearDirtGameLoad" function, it would work. Only problem I see, I don't want, that if you play for a prolonged time, that thousands of actors have dirt overlays/tattoos.

ClearDirtGameLoad might be better referred to as ClearAll, where we attempt to remove every possible dirt overlay from each available set folder, whereas ClearDirt only clears based on the prefix path we cached with papyrusutil.

 

So this bumps into another problem I had to previously fix.

 

RaceMenu has an issue for some users where the overlay that was applied to a character on a previous game session disappears on the next game session. For example, you have a character with a full body dirt. You save your game and quit to desktop. You then load your game again, load into that file you had previously saved, and find your dirt overlays now gone. This is probably the reason why monoman named that function that way, and why I have to call it everytime onplayerloadgame. We safeguard this function by only passing for players and NPCs that are 3D loaded or near player.

 

However, this function is not supposed to be called whenever you save your game. I might have to investigate that behavior - I can't think of how this could happen.

 

8 hours ago, nopse0 said:

Are you also clearing the dirt of actors, if the "dirty over time" spell of actors expires, or some other sort of garbage collection ?

Not exactly. We do clear dirt when the OnDeath() event is invoked on the getdirtyovertime mgef script. We do not clear dirt on spell expiry - you can see that I've completely erased the use of OnEffectFinish() from the script.

 

mzin and mono previously used OnEffectFinish(). The problem is that not much in this space can be properly and safely executed, even if for garbage collection. Spells will always stick with NPCs, but MGEFs will expire for NPCs when they are unloaded. When said NPCs are loaded again, the MGEFs restart. Based on memory pressure and load speed, OnEffectFinish() may even run concurrently with OnEffectStart(). This issue doesn't affect player actors.

 

This is what created a lot of issues in past BiS versions, and why my only on-script garbage collection is via OnDeath().

 

--

 

Ultimately, if overlays applied via slavetats do not bump into this issue of no overlay on game load, then maybe it'd be best to do with you did.

Edited April 17, 2025 by Nuascura

[nopse0]

15 hours ago, Nuascura said:

However, this function is not supposed to be called whenever you save your game. I might have to investigate that behavior - I can't think of how this could happen.

 

Yes! Would be really great, if you can find out, what's happening there. Because the workaround for this, removing the dirt from npc's in "ClearDirtGameLoad" but not making the change visible, is not really a solution for this problem, it just delays it. If another mod calls synchronize_tattoos (or NiOverride.ApplyNodeOverrides in the BISR version), the dirt would suddenly disappear from the npc mid-session (and UpdateAlpha also doesn't work after the dirt is removed in ClearDirtGameLoad), it must only be called once at the begin of the session, after the game has been loaded.

[nopse0]

Good news!

 

I was lucky, and had a reproducable CTD. I found out, what's the mayor flaw in SlaveTatsNG, big mistake of mine. I always had assumed, that native function calls are automatically executed by the Skyrim main thread, so that no synchronization is needed. But this isn't the case, they are directly executed by the Papyrus threads (though I assume, the Skyrim main thread sleeps, while the Papyrus threads are executed (Papyrus budget, etc.). So, synchronize_tattoos was always executed concurrently, if called by multiple Papyrus threads at the same time; no wonder that this caused crashes.

 

If you want that something is executed by the Skyrim main thread, you must do a:

fail_t synchronize_tattoos(RE::Actor* a_target, bool a_silent)
{
	logger::info("synchronize_tattoos: a_target = {}", (void*)a_target);

	if (!a_target) {
		logger::info("a_target is null");
		return true;
	}

	logger::info("synchronize_tattoos: current thread id = {}", slavetats_ng::threading::thread_id_to_string(std::this_thread::get_id()));

	if (std::this_thread::get_id() != slavetats_ng::threading::System::GetSingleton()->main_thread_id()) {
		//std::promise<fail_t> result;
		//auto                 future = result.get_future();

		SKSE::GetTaskInterface()->AddTask([a_target, a_silent] {
			//result.set_value(
			synchronize_tattoos_internal(a_target, a_silent);
			//);
		});
		//future.wait();
		//return future.get();
		return false;
	} else {
		return synchronize_tattoos_internal(a_target, a_silent);
	}
}

 

I am doing this now. Only problem is, I cannot return the result from the SKSE main thread task via a future (dead-lock), so at the moment synchronize_tattoos always return "false" (= no error).

 

Probably the functions for manipulating the SlaveTats data structures (query_applied_tattoos, add_tattoo, etc.) also need some synchronization, but at least no crashes anymore (I hope).

 

Will upload an update soon.

 

[Nuascura]

@nopse0 I'm unable to replicate this issue where "ClearDirtGameLoad" is called mid-game, outside of just after game/savefile load. I'm testing on my current 2.5.0 beta with an added debug output under the GameLoad overlayutil function. If you are interested in my log, simply search with the keyword "mzin". Lines should be self-explanatory. Nothing special happens when the VM freezes i.e. pause menu, or when saving the game. It would look as if BISR is running with as little nioverride calls as necessary.

 

 

If you are able to pass me a step-by-step on a new game, please do let me know.

 

My own process is to setup BISR 2.5 on a fresh character, restart the game session, then load in again. Wait a couple in-game days for dirt to accumulate, run around some cells, and save my game a couple times all the while. It's nothing special.

Edited July 8, 2025 by Nuascura
Removed Attachment

[Obryanov]

The plugin fails to load on startup. Installing Visual Basic stuff (as suggested earlier changes nothing and there are no logs generated for this mod either. I am on the correct version and have all the mods I'm supposed to (as far as I know). This has been a problem for all 10 latest versions (didn't try earlier). No other mod (that isn't too old) throws this error.

This better not be because I'm on Windows 8.

[nopse0]

11 hours ago, Obryanov said:

The plugin fails to load on startup. Installing Visual Basic stuff (as suggested earlier changes nothing and there are no logs generated for this mod either. I am on the correct version and have all the mods I'm supposed to (as far as I know). This has been a problem for all 10 latest versions (didn't try earlier). No other mod (that isn't too old) throws this error.

This better not be because I'm on Windows 8.

 

Hmm, on the MS VC++ Redistributable site, it says:

+ Redistributable for Visual Studio 2015-2022 only support Windows 7, 8.1, 10, and 11

 

Do you have Windows 8.1 ?

 

Maybe you can install "depends.exe" on your computer. and check, what dependencies of the SlaveTatsNG.dll are missing on your computer.

 

https://www.dependencywalker.com/

https://learn.microsoft.com/en-us/cpp/windows/understanding-the-dependencies-of-a-visual-cpp-application?view=msvc-170

 

Edit: Maybe it's this "Windows 10 Universal C Runtime" (ucrt.dll), but it can be installed on older Windows versions:

 

https://www.microsoft.com/en-us/download/details.aspx?id=48234

https://learn.microsoft.com/en-us/cpp/windows/determining-which-dlls-to-redistribute?view=msvc-170

 

 

 

 

Edited April 21, 2025 by nopse0

[Obryanov]

6 hours ago, nopse0 said:

 

Hmm, on the MS VC++ Redistributable site, it says:

+ Redistributable for Visual Studio 2015-2022 only support Windows 7, 8.1, 10, and 11

 

Do you have Windows 8.1 ?

 

Maybe you can install "depends.exe" on your computer. and check, what dependencies of the SlaveTatsNG.dll are missing on your computer.

 

https://www.dependencywalker.com/

https://learn.microsoft.com/en-us/cpp/windows/understanding-the-dependencies-of-a-visual-cpp-application?view=msvc-170

 

Edit: Maybe it's this "Windows 10 Universal C Runtime" (ucrt.dll), but it can be installed on older Windows versions:

 

https://www.microsoft.com/en-us/download/details.aspx?id=48234

https://learn.microsoft.com/en-us/cpp/windows/determining-which-dlls-to-redistribute?view=msvc-170

 

 

 

 

No, I don't as I've already mentioned.

 

I have no idea what is missing when looking at depends.exe. It threw 2 errors (something about missing export functions), but doesn't elaborate. VCRun140 or whatever is there at least. Things that are highlighted in red are present as well, like SHCore.

 

Universal C Runtime is not applicable, neither 8 nor 8.1 versions.

Edited April 21, 2025 by Obryanov

[nopse0]

1 hour ago, Obryanov said:

No, I don't as I've already mentioned.

 

I have no idea what is missing when looking at depends.exe. It threw 2 errors (something about missing export functions), but doesn't elaborate. VCRun140 or whatever is there at least. Things that are highlighted in red are present as well, like SHCore.

 

Universal C Runtime is not applicable, neither 8 nor 8.1 versions.

 

I read (maybe I am wrong) "Visual Studio 2015-2022 only support Windows 7, 8.1, 10, and 11" as that the redistributable only supports Windows 8.1 but not 8. Maybe this has to do with the Smartphone like Gui, Windows 8 first had, until they reverted this. I could imagine, that Windows 8 simply doesn't have certain system libraries/ functions needed by VC++ 2015-2022. So, I fear, no chance.

 

Edit: I surfed a bit, and found this

 

https://msfn.org/board/topic/186360-visual-c-2015-20192022-redistributable-failed-to-install-on-windows-80-0x80240017/

 

Guess, you need an update:

 

 

 

 

Edited April 21, 2025 by nopse0

[Obryanov]

56 minutes ago, nopse0 said:

 

I read (maybe I am wrong) "Visual Studio 2015-2022 only support Windows 7, 8.1, 10, and 11" as that the redistributable only supports Windows 8.1 but not 8. Maybe this has to do with the Smartphone like Gui, Windows 8 first had, until they reverted this. I could imagine, that Windows 8 simply doesn't have certain system libraries/ functions needed by VC++ 2015-2022. So, I fear, no chance.

Well, it is what it is. Hopefully the original mod works well enough with all of its flaws.

Still pretty weird this is the only mod with this problem.

[nopse0]

5 hours ago, Obryanov said:

Well, it is what it is. Hopefully the original mod works well enough with all of its flaws.

Still pretty weird this is the only mod with this problem.

 

Hey, didn't you read my edit above ?

 

I think you need KB2999226 or KB3118401, that's why ucrt.dll is not "applicable" on your system.

[Obryanov]

1 hour ago, nopse0 said:

 

Hey, didn't you read my edit above ?

 

I think you need KB2999226 or KB3118401, that's why ucrt.dll is not "applicable" on your system.

Oh, it came after I began writing a response. I'll try it out.
EDIT: no changes. I never encountered that VC++ error to begin with. Anything else requiring that seems fine, I never had problems with other mods or software, it's only this one thing.

Edited April 22, 2025 by Obryanov

[nopse0]

50 minutes ago, Obryanov said:

Oh, it came after I began writing a response. I'll try it out.
Update: no changes. I never encountered that VC++ error to begin with. Anything else requiring that seems fine, I never had problems with other mods or software, it's only this one thing.

 

Maybe some compiler options, which require something which isn't present in W8 or so, difficult to say.

 

The Log View of depends.exe has an option to write the log to a file, can you do this and post the file, so that I see what exactly the error is ?

[Obryanov]

15 minutes ago, nopse0 said:

 

Maybe some compiler options, which require something which isn't present in W8 or so, difficult to say.

 

The Log View of depends.exe has an option to write the log to a file, can you do this and post the file, so that I see what exactly the error is ?

This one?
It says api-ms-win-eventing-provider-l1-1-0.dll is missing and I have no idea where that's from.

SlaveTatsNG.txt

Edited April 22, 2025 by Obryanov

[nopse0]

1 hour ago, Obryanov said:

This one?
It says api-ms-win-eventing-provider-l1-1-0.dll is missing and I have no idea where that's from.

SlaveTatsNG.txt 504.36 kB · 0 downloads

 

Ah, ok. Then it's clear, you don't have this api-ms-win-eventing-provider-l1-1-0.dll. I read this happens, if your 64 Bit Windows is screwed up, and you have the 32 bit version of this dll  in your Windows\system32 folder. You must reinstall it. I found this video: 

 But I don't know if the link from this video can be trusted (maybe the dll has a virus or trojan or so), maybe you can get something "official" from Microsoft or so.

 

Another solution would be, to simply copy this dll (the correct, 64 bit version!) into the Skyrim folder (where Skyrim.exe is).

 

Edit: Oh, wrong DLL in the video above ("win-crt-utility"), maybe there is no win-eventing-provider dll for Windows 8, then it's hopeless.

 

Found this: (I think "winblue" is for Windows 8.1, maybe you must use one of the other 64 bit 6.x.x.x versions, don't know):

 

https://www.dllme.com/dll/files/api-ms-win-eventing-provider-l1-1-0

https://www.dllme.com/dll/files/api-ms-win-eventing-provider-l1-1-0/versions

 

I would download the right dll from www.dllme.com (64 bit, Windows 8), copy it into the Skyrim folder, and check if this works.

 

 

Edited April 22, 2025 by nopse0

[Obryanov]

1 hour ago, nopse0 said:

 

Ah, ok. Then it's clear, you don't have this api-ms-win-eventing-provider-l1-1-0.dll. I read this happens, if your 64 Bit Windows is screwed up, and you have the 32 bit version of this dll  in your Windows\system32 folder. You must reinstall it. I found this video: 

 But I don't know if the link from this video can be trusted (maybe the dll has a virus or trojan or so), maybe you can get something "official" from Microsoft or so.

 

Another solution would be, to simply copy this dll (the correct, 64 bit version!) into the Skyrim folder (where Skyrim.exe is).

 

Edit: Oh, wrong DLL in the video above ("win-crt-utility"), maybe there is no win-eventing-provider dll for Windows 8, then it's hopeless.

 

Found this: (I think "winblue" is for Windows 8.1, maybe you must use one of the other 64 bit 6.x.x.x versions, don't know):

 

https://www.dllme.com/dll/files/api-ms-win-eventing-provider-l1-1-0

https://www.dllme.com/dll/files/api-ms-win-eventing-provider-l1-1-0/versions

 

I would download the right dll from www.dllme.com (64 bit, Windows 8), copy it into the Skyrim folder, and check if this works.

 

 

I'll find out which version is the correct one (though it seems they support either 10 or...6?) and report back.

EDIT: I tried shoving them into System32. This removed the depends.exe missing file error, but didn't actually fix anything. I don't think any of those are compatible with any other version. Adding it to Skyrim folder both had missing file error pop up and didn't let SlaveTats load anyway.

Edited April 22, 2025 by Obryanov

[nopse0]

58 minutes ago, Obryanov said:

I'll find out which version is the correct one (though it seems they support either 10 or...6?) and report back.

EDIT: I tried shoving them into System32. This removed the depends.exe missing file error, but didn't actually fix anything. I don't think any of those are compatible with any other version. Adding it to Skyrim folder both had missing file error pop up and didn't let SlaveTats load anyway.

 

You definitely need a dll starting with 6, the versions starting with 10 are for Windows >= Windows 10.

I think the 6'er versions are only empty stub dll's (because they are so small, only 2k), without functionality, just that the OS doesn't complain about a missing dll, so it doesn't really matter what 6'er version you are using.

[Obryanov]

14 hours ago, nopse0 said:

 

You definitely need a dll starting with 6, the versions starting with 10 are for Windows >= Windows 10.

I think the 6'er versions are only empty stub dll's (because they are so small, only 2k), without functionality, just that the OS doesn't complain about a missing dll, so it doesn't really matter what 6'er version you are using.

As mentioned earlier, simply having a file with correct name and in correct folder doesn't solve anything beyond removing that error, the plugin refuses to load all the same. Either it needs to be actually functional or that's not the main problem.
I'll try a 6 version anyway to be sure.