SlaveTatsNG

[nopse0]

1 hour ago, elliesec said:

@nopse0 - how does SlaveTats NG deal with the in_bsa flag on tattoo definitions? Reason I ask is that I've had a bit of trouble getting LewdMarks to play nicely with SlaveTats NG, and I think (but haven't exhaustively tested this to be sure) that it's because it has in_bsa: 1 set on all of its tattoos, despite them not actually being packed into a BSA:

• If I install LewdMarks out of the box with SlaveTats NG, the tattoos don't show up in the MCM
• If I install LewdMarks out of the box with original SlaveTats, the tattoos do show up in the MCM
• If I remove the in_bsa flag from the tattoo definitions and use it with SlaveTats NG, they show up in the MCM (although I found I had to wipe my SlaveTats cache and start a new game to get that to happen)

 

The only occurrence of "in_bsa" in the sources I find is in the "_add_and_get_tattoo" function:

		if (JMap::getInt(a_tattoo, "in_bsa") == 0) {
			if (!JContainers::fileExistsAtPath(string(ROOT()) + string(PREFIX()) + texture.c_str())) {
			 	return 0;
			}
		}

 

So, if in_bsa is ==0, SlaveTatsNG checks that the tattoo file exists, otherwise it doesn't.  That's the only difference. I compared this with the SlaveTatsSE-1.3.9 source scripts, but it's doing exactly the same, just an existence check, if in_bsa is ==0, no other special handling of in_bsa. So, I have no explanation, why it works with Papyrus SlaveTats, but not with NG. Papyrus SlaveTats.psc:

 

 

Maybe you just forgot to call "Add/Remove tattoos" in the SlaveTats MCM.

 

Edited May 1, 2025 by nopse0

[elliesec]

1 hour ago, nopse0 said:

Maybe you just forgot to call "Add/Remove tattoos" in the SlaveTats MCM.

 

It's not about adding/removing the tattoos - they simply don't appear in the MCM at all - I can't even pick them to try to add them. I suspect that there's something in the config files for that pack that NG doesn't like for whatever reason - there have been a few other reports of the same issue from others in the support thread for LewdMarks, but I'm having trouble identifying what exactly.

 

I guess the alternative is there's some kind of caching issue with querying tattoos somewhere. If I were to add a new tattoo pack mid-playthrough and delete my SlaveTats cache file, would you expect NG to pick up the new tattoo pack?

I'll do a bit more digging when I get the time to see if I can figure out what's causing it - I'm not entirely sure that it's exclusively an NG thing. But the one time I tried switching back to original SlaveTats, the tattoos immediately appeared in the MCM, then when I switched back to NG they disappeared again. Alternatively I guess - is there any kind of caching of tattoos at the MCM level?

[nopse0]

17 minutes ago, elliesec said:

 

It's not about adding/removing the tattoos - they simply don't appear in the MCM at all

 

Not sure, maybe we are misunderstanding each other, but "Add/Rermove Tattoos" is a clickable text entry in the "SlaveTats/Setup" menu. 

Just having the "<tatto package>.json" files in the "textures\actors\character\slavetats" folder isn't enough to register new tattoo packages, you also have to click "Add/Remove Tattoos" for SlaveTats to update it's cache of installed tattoos.

[elliesec]

32 minutes ago, nopse0 said:

 

Not sure, maybe we are misunderstanding each other, but "Add/Rermove Tattoos" is a clickable text entry in the "SlaveTats/Setup" menu. 

Just having the "<tatto package>.json" files in the "textures\actors\character\slavetats" folder isn't enough to register new tattoo packages, you also have to click "Add/Remove Tattoos" for SlaveTats to update it's cache of installed tattoos.

Right, that would probably explain it (assuming they're also cached somewhere other than the slavetats_cache.json file - because I wiped that?). I'd previously ignored that button because I assumed it meant "add/remove tattoos to/from the target actor that you've selected on the left", rather than "rebuild the tattoo cache", and I don't tend to interact with the SlaveTats MCM in actual usage. Presumably original SlaveTats doesn't have that behaviour and rebuilds its cache on game load (or just doesn't have a cache? Can't remember - it's been a while since I looked at it), which would explain why switching back suddenly made it automatically pick up the tattoos.

Edited May 1, 2025 by elliesec

[nopse0]

45 minutes ago, elliesec said:

 Presumably original SlaveTats doesn't have that behaviour and rebuilds its cache on game load (or just doesn't have a cache? Can't remember - it's been a while since I looked at it), which would explain why switching back suddenly made it automatically pick up the tattoos.

 

Yes, the original SlaveTats had a bug, it's cache wasn't functional, it was rebuilding the cache each time  "query_available_tattoos" was called. Rebuild the cache each time the game is started would be ok ("it's not a bug, it's a feature"), but not each time  "query_available_tattoos" is called, so I fixed this bug.

[elliesec]

3 minutes ago, nopse0 said:

Yes, the original SlaveTats had a bug, it's cache wasn't functional, it was rebuilding the cache each time  "query_available_tattoos" was called. Rebuild the cache each time the game is started would be ok ("it's not a bug, it's a feature"), but not each time  "query_available_tattoos" is called, so I fixed this bug.

 

Right. I'd request for a rebuild on game start in that case. Whilst it's an improvement from an efficiency perspective, it's a big downgrade from a UX perspective, especially when, like me, you tend to just ignore the SlaveTats MCM altogether and assume that it will "just work" as an API. I have SlaveTats installed purely so that other mods can make use of its API, so going from the original SlaveTats where whatever tattoos I had installed were always available when another mod queried to a version where they're not guaranteed to be without manual intervention feels like a functionality downgrade to the end user, even if OG SlaveTats was inefficient about the way it handled it. Especially confusing if you're using multiple profiles in MO2 and realise that you may have to click that button each time you switch profiles. From the number of comments I've seen where people have had similar issues, I imagine this has caught at least a few people out.

[nopse0]

2 hours ago, elliesec said:

 

Right. I'd request for a rebuild on game start in that case. Whilst it's an improvement from an efficiency perspective, it's a big downgrade from a UX perspective, especially when, like me, you tend to just ignore the SlaveTats MCM altogether and assume that it will "just work" as an API. I have SlaveTats installed purely so that other mods can make use of its API, so going from the original SlaveTats where whatever tattoos I had installed were always available when another mod queried to a version where they're not guaranteed to be without manual intervention feels like a functionality downgrade to the end user, even if OG SlaveTats was inefficient about the way it handled it. Especially confusing if you're using multiple profiles in MO2 and realise that you may have to click that button each time you switch profiles. From the number of comments I've seen where people have had similar issues, I imagine this has caught at least a few people out.

 

Thanks for the idea, such a big QOL improvement and such a small change,  just added a "slavetats_ng::compile_cache()" line in "kDataLoaded" (after the .esm/.esp files are loaded):

		case SKSE::MessagingInterface::kDataLoaded:
			slavetats_ng::jcwrapper::JCWrapper::GetSingleton()->Init();
			slavetats_ng::skee_wrapper::NiOverride::Init();
			// Force SlaveTats to update it's cache of installed tattoos
			slavetats_ng::compile_cache();
			break;

 

[elliesec]

Awesome - thanks so much for putting that in!

[nopse0]

1 hour ago, elliesec said:

Awesome - thanks so much for putting that in!

Only, not sure if this really works, because I am doing this before the game is loaded, and JContainers stores it's data in the save game ... - Maybe, when the save game is loaded, the old cache from the save game is loaded, and what I did after Skyrim has been started, is overwritten again. Will check this, install a dummy tattoo package, and see, if it's tattoos really appear in the MCM.

 

Edit: Yes, as I feared, doesn't work. The "slavetats_cache.json" in the Data folder is updated, but, of course, all JContainer functions fail before a savegame is loaded. Hm, then it's getting difficult, because SlaveTats is just a bunch of global functions. Will try handling the

SKSE message, this should work.

Edited May 1, 2025 by nopse0

[elliesec]

45 minutes ago, nopse0 said:

Only, not sure if this really works, because I am doing this before the game is loaded, and JContainers stores it's data in the save game ... - Maybe, when the save game is loaded, the old cache from the save game is loaded, and what I did after Skyrim has been started, is overwritten again. Will check this, install a dummy tattoo package, and see, if it's tattoos really appear in the MCM.

 

Edit: Yes, as I feared, doesn't work. The "slavetats_cache.json" in the Data folder is updated, but, of course, all JContainer functions fail before a savegame is loaded. Hm, then it's getting difficult, because SlaveTats is just a bunch of global functions. Will try handling the

SKSE message, this should work.

 

Sounds like that should work, but presumably in the very worst case, you could still make the call from Papyrus - SlaveTats itself is globals, but there's already the OnPlayerLoadGame event in the SlaveTatsOnLoad script which you could presumably make a SlaveTats.compile_cache() call from?

[Obryanov]

A little update on "plugin failed to load" situation: it's definitely not a problem with the api-ms-win-eventing-provider-l1-1-0.dll because all SKSE plugins including the loader itself throw that error. They all work fine regardless.

BFCO Universal Support also seems to be having the same problem with failing to load despite working for others on latest AE version. Maybe the two mods try something that older systems can't do. 

Would be nice to know if there are any Windows 8 users who have this issue, would help narrow it down further. Very unlikely there are any around though.

Edited May 2, 2025 by Obryanov

[nopse0]

7 hours ago, Obryanov said:

A little update on "plugin failed to load" situation: it's definitely not a problem with the api-ms-win-eventing-provider-l1-1-0.dll because all SKSE plugins including the loader itself throw that error. They all work fine regardless.

BFCO Universal Support also seems to be having the same problem with failing to load despite working for others on latest AE version. Maybe the two mods try something that older systems can't do. 

Would be nice to know if there are any Windows 8 users who have this issue, would help narrow it down further. Very unlikely there are any around though.

 

Would be nice, if you can give a list of the SKSE dll projects, which work on your Windows 8 system. Maybe by comparing the CMakePresets.json files, one sees what the problem with Windows 8 is. My project setup (and, as far as I see, that of BFCO, too) is based on powerofthree projects, and uses the "Visual Studio 17 2022" generator, while other projects (DeviousDevicesNG, UnforgivingDevicesNative) are using an old CharmedByron setup with the "Ninja" build generator, maybe that's the problem (though I will never use the Ninja build system, it's totally intransparent how it is configured, I cannot change even the easiest things, like doing a Debug instead of a Release build).

[Obryanov]

18 minutes ago, nopse0 said:

 

Would be nice, if you can give a list of the SKSE dll projects, which work on your Windows 8 system. Maybe by comparing the CMakePresets.json files, one sees what the problem with Windows 8 is. My project setup (and, as far as I see, that of BFCO, too) is based on powerofthree projects, and uses the "Visual Studio 17 2022" generator, while other projects (DeviousDevicesNG, UnforgivingDevicesNative) are using an old CharmedByron setup with the "Ninja" build generator, maybe that's the problem (though I will never use the Ninja build system, it's totally intransparent how it is configured, I cannot change even the easiest things, like doing a Debug instead of a Release build).

Unfortunately, I manually install most things, so, I can't immediately give a full name list, but you might be able to recognize enough of them by name in the log.

AnimationMotionFix.dll

AnimationMotionRevolution.dll
AttackAnimationFlingFixNG.dll
BehaviorDataInjector.dll
cbp.dll
CombatPathingRevolution.dll
ConsoleUtilSSE.dll
DbSkseFunctions.dll
DeviousDevices.dll
DodgeFramework.dll
DtryKeyUtil.dll
EngineFixes.dll
FaceGenFixes.dll
Fuz Ro D'oh.dll
hdtSMP64.dll
HeadSlide.dll
ImprovedCameraSE.dll
InventoryFunctions64.dll
IWantWidgetsNative.dll
JContainers64.dll
loki_DynamicAnimationCasting.dll
MaxsuIFrame.dll
MCMHelper.dll
MCO.dll
mfgfix.dll
OpenAnimationReplacer.dll
PairedAnimationImprovements.dll
PapyrusIniManipulator.dll
PapyrusUtil.dll
PartialAnimationReplacer.dll
PayloadInterpreter.dll
po3_BaseObjectSwapper.dll
po3_PapyrusExtender.dll
po3_SpellPerkItemDistributor.dll
po3_Tweaks.dll
Precision.dll
Proteus.dll
SCAR.dll
SexLabpp.dll
SexLabUtil.dll
skee64.dll
SMP-NPC crash fix.dll
SrtCrashFix64.dll
SSEDisplayTweaks.dll
SSMT_Fix.dll
TheNewGentleman.dll
TK_Dodge_RE.dll
TrueDirectionalMovement.dll
UDNative.dll

 

Edited May 2, 2025 by Obryanov

[nopse0]

59 minutes ago, Obryanov said:

Unfortunately, I manually install most things, so, I can't immediately give a full name list, but you might be able to recognize enough of them by name in the log.

 

Could be "directxtk", SlaveTatsNG uses this.

 

https://github.com/microsoft/DirectXTK

 

 

Edit: And the DirectXTK dependency is a transitive dependency of CommonLibVR (ng branch). Guess, if I use an older version (baseline) of CommonLibVR, I could get rid of this dependency.

 

 

 

Edited May 2, 2025 by nopse0

[nopse0]

Uploaded a test version, built with an older CommonLibVR version, which doesn't have a DirectXTK dependency, to see if this works on Windows 7 & Windows 8.0

Edited May 2, 2025 by nopse0

[Obryanov]

11 hours ago, nopse0 said:

Uploaded a test version, built with an older CommonLibVR version, which doesn't have a DirectXTK dependency, to see if this works on Windows 7 & Windows 8.0

This did not work, unfortunately. Same issue.

[nopse0]

11 hours ago, Obryanov said:

This did not work, unfortunately. Same issue.

 

Can you try out, if this SlaveTatsNG-Windows8-Test-1.7zloads on Windows 8 ? It's a minimal SKSE plugin, with just a main.cpp, which just contains a "SKSEPluginLoad" function, nothing else. If even this fails to load on Windows 8, then something is wrong with commonlibsse-ng. 

 

[Siymizzie]

add back 0.6.11.7 please

[greebo1]

Seconded, 0.6.11 is required by Nefaram. A reupload would be much appreciated.

[ebbluminous]

Get whoever created the Neferam modlist to update it...

[greebo1]

I tried that too. I didn't think it would be too much trouble for someone with that version to put it back up here in the meantime.

[nilead]

 A simple test is very impressive. Compared to old ST its stupid fast. For the less magically capable among us, could you clarify what was sacrificed?

Should it be backwards compatible with everything relying on old ST? Some stuff is easy to test, but something like Deiously Acessible would take quite a bit of time to see if it correctly applies its tats.

[nopse0]

7 minutes ago, greebo1 said:

I tried that too. I didn't think it would be too much trouble for someone with that version to put it back up here in the meantime.

Didn't think on that, I don't have it anymore. Even if I would build one from same sources, binaries would be different (checksum). But  would be better if Nefarem updates modlist anyway, because 0.7+ doesn't CTD anymore.

Edited May 3, 2025 by nopse0

[greebo1]

2 minutes ago, nopse0 said:

Didn't think on that, I don't have it anymore. Even if I would build one from same sources, binaries would be different (checksum). But  would be better if Nefarem updates modlist anyway, because 0.7+ doesn't CTD anymore.

Understandable, thanks anyway.

[Siymizzie]

11 minutes ago, nopse0 said:

Didn't think on that, I don't have it anymore. Even if I would build one from same sources, binaries would be different (checksum). But  would be better if Nefarem updates modlist anyway, because 0.7+ doesn't CTD anymore.

thanks for the quick response, ill wait