Rape Tattoos Continued

[memati?]

Hi very cool improvements over the original SlaveTats!

I wondered if it would be possible to add a simple "maximum tat count", limiting the amount of tattoos that can be added on any character.

I like to have some tats on my char but having 30 tats at once isnt really looking good IMO

[Seeker999]

2 hours ago, memati? said:

Hi very cool improvements over the original SlaveTats!

I wondered if it would be possible to add a simple "maximum tat count", limiting the amount of tattoos that can be added on any character.

I like to have some tats on my char but having 30 tats at once isnt really looking good IMO

You can already do that in multiple ways.

• Adjust the number of overlays in your skee64.ini file. People usually increase them, but you can have them top out at whatever number you want for body, face, hands, and feet.
• Decrease the duration. Nothing says they have to last 300-800 hours. The shorter the time they endure the less likely you are to have lots of tats at once.
• Cap the amount of tats that different mods can add. And, where possible, decrease the likelihood of a tat occurring.

[elliesec]

On 12/3/2023 at 9:41 PM, memati? said:

Hi very cool improvements over the original SlaveTats!

I wondered if it would be possible to add a simple "maximum tat count", limiting the amount of tattoos that can be added on any character.

I like to have some tats on my char but having 30 tats at once isnt really looking good IMO

 

As Seeker999 mentioned, there are a few ways you could achieve this already. The easiest would probably be by decreasing the overlay limits in your skee64.ini (there's information on the mod page explaining how to do this - see the "Configuration Tips" section).

 

It's additionally worth noting that RTC to some extent has its own limiting factor based on the groups that you assign tattoos. With the exception of the special (unassigned) and (excluded) groups, RTC will never add more than one tattoo per configured group. So if you only wanted a maximum of 10 tattoos for example, you could ensure that your tattoos are configured to be spread across exactly 10 groups (i.e. don't use all of the groups) and don't use the (unassigned) group (as that group isn't limited in the same way). Again, see the "Configuring tattoo groups" subsection under "Configuration Tips" for more details. Because the group system implicitly defines a maximum number of tattoos, having an explicit max tattoo setting isn't really something I'm planning on adding.

Edited December 5, 2023 by elliesec
Words

[GL00]

I'm having an issue where I stop getting tattoos after three. Only after those ones dissapear will I get new ones, but still only three max. I upped the overlay limits in the ini file, and upped the chances for a tattoo to 100, but its still an issue. Did I miss something?

[elliesec]

1 hour ago, GL00 said:

I'm having an issue where I stop getting tattoos after three. Only after those ones dissapear will I get new ones, but still only three max. I upped the overlay limits in the ini file, and upped the chances for a tattoo to 100, but its still an issue. Did I miss something?

 

As far as I can think of, there are only two things that should be limiting tattoos like that.

1. Overlay limits, as you're already aware - if you want to post the relevant section of your skee64.ini, I'm happy to look, but that should be pretty straightforward
2. Groups configured in Rape Tattoos. As I mentioned in my post above (and outlined on the mod page under the "Configuration Tips" section), if you've assigned multiple tattoos to a single group, only one of those tattoos will ever be added at a given time. If you've spread all of your installed tattoos across exactly three groups, then you'll only ever have 3 tattoos at a given time. This seems relatively unlikely, but is certainly possible. You can fix that by changing tattoo group configurations from the MCM.

Aside from that, I can't think of any reasons for the oddly specific limit of 3. You could try turning on debug mode from the MCM and seeing what happens when you hit the "N" key - that should produce some pretty verbose notifications on the screen which might give me a clue as to where the sticking point is - Papyrus logs would be even more useful.

Edited December 8, 2023 by elliesec
More info added

[GL00]

12 hours ago, elliesec said:

 

As far as I can think of, there are only two things that should be limiting tattoos like that.

I figured it out. I never looked into the group settings, figured default settings would work fine, but when I looked, all but a few tattoos were set to excluded. Thankfully I just found a file someone made for the pack I use, so I don't need to configure 500 tattoos myself lol.

[cathytime]

Hi,

 

I'm encountering an application of the tattoos that I believe to be a bug.  I was trying to have all the tattoos that get applied glow one color. I have the colorConfig.json set for one color (the same hex color for both 'colors' and 'glows', with colors set to a factor of 1, and glows to a factor of 100. 

 

This is what I tested:

1) When I have MCM 'Tattoo Color Mode' and 'Tattoo Glow Mode' settings set to Custom and then tattoos get applied, about 70% glow the correct color, the last 30% don't glow (but are the right color).

2) When I change the MCM to 'Tattoo Color Mode' to None and 'Tattoo Glow Mode' set to Custom, and then tattoos get applied, none of them glow, and they are all shades of black and grey.

 

I would assume that applying the tattoos with 'Tattoo Color Mode' set to None, and 'Tattoo Glow Mode' set to Custom should yield only glowing tattoos?

 

Thanks for any help.

[Aycelist]

any update on tattoos disappearing shortly after being applied? if i force them through the debug they seem to stick, but if i let them occur naturally they just disappear a second or two after.

[DonQuiWho]

8 hours ago, Aycelist said:

any update on tattoos disappearing shortly after being applied? if i force them through the debug they seem to stick, but if i let them occur naturally they just disappear a second or two after.

 

I seemed to solve that by checking the file structure in the 'User/,,,' directory, where there was somehow an extra spurious folder - see my posts a few pages up this thread, somewhere before a pic of of Shrek's Princess Fiona

[Dez65]

HI - love this mod.  Adds a whole new dimension to the game.

 

I'm wondering if someone might be able to troubleshoot an issue with me.  I use Slavetats, this mod and Fade Tattoos along with regular RaceMenu overlays.  I'm finding that occasionally the Racemenu BodyPaint overlays I select will simply disappear.  When I look in the BodyPaint tab of Racemenu, the overlays I added there have disappeared, while any Slavetats are still showing.  Not sure how this is happening but it seems associated with mods that automatically apply tats/overlays, such as this mod, FHU and Distributed Overlays.

 

Any ideas?  Is it possible to lock-in overlays applied through Racemenu menu so that they cannot be removed by other mods?

 

Thanks!

[elliesec]

16 hours ago, Dez65 said:

HI - love this mod.  Adds a whole new dimension to the game.

Glad to hear it!

 

16 hours ago, Dez65 said:

Any ideas?  Is it possible to lock-in overlays applied through Racemenu menu so that they cannot be removed by other mods?

Hard to say exactly what might be going wrong here. I'm not super familiar with the RaceMenu/NiOverride side of things right now unfortunately (as RapeTats doesn't deal directly with that - it only does things through the SlaveTats API), but here's what I do know (and my speculations as to what might be going on). From what I understand from having a dig through the SlaveTats source code a little while back, SlaveTats shouldn't be touching overlay slots that are filled via RaceMenu, in theory. But in practice, anything can overwrite overlays in any slot, unintentionally or otherwise - all it would take is a scripting mistake.

 

It's not impossible that there's a bug in SlaveTats (or some other overlay-handling mod) which causes it to disregard this under some circumstances. It's also perhaps worth mentioning that Zaz Animation Pack also tries to do some "overlay coordination" before/during/after sex scenes, which may result in multiple overlay-related mods running simultaneously and overwriting each other, or something like that - but that's largely vague speculation on my part. I do believe that SlaveTats doesn't deal well with a tattoo sync being triggered by multiple mods in a short space of time, which at the moment is my leading theory for the cause of the "disappearing tattoo" bug which some have experienced, and it's certainly not impossible that that's related to what you're seeing, as you're certainly getting similar symptoms.

 

Personally, I'd probably approach this by taking SlaveTats & SlaveTats-dependent mods out of your load order temporarily, then seeing if you're still having issues. If not, add SlaveTats back in on its own and verify that manually adding tattoos via the SlaveTats MCM seems to be playing nicely with your load order. Then add the other stuff back one at a time and see at what point things start breaking. I suspect this is the kind of issue that's hard to place on one single mod - it's entirely possible that it's just a timing thing where two mods try to deal with overlays simultaneously and end up overwriting things - but that might at least help you figure out which mods are clashing.

 

Sorry I couldn't be more specific, but hopefully it might help point you in the right direction at the very least. Looking into the disappearing tattoo issue is something that's been on my to-do list for a while now, but my suspicion is that it's an issue somewhere in SlaveTats that's going to be hard to track down once and for all unfortunately.

[Dez65]

3 hours ago, elliesec said:

Sorry I couldn't be more specific, but hopefully it might help point you in the right direction at the very least. Looking into the disappearing tattoo issue is something that's been on my to-do list for a while now, but my suspicion is that it's an issue somewhere in SlaveTats that's going to be hard to track down once and for all unfortunately.

Thanks so much for your thorough and thoughtful answer.  I think I'll just live with it for now as it's not that big of an inconvenience to reopen Racemenu and reapply.  The strange thing is that it doesn't seem to affect "ordinary" tattoos, only Skin feature overlays like freckles, tanlines, titkit and pubic hair.  

[Aycelist]

On 12/17/2023 at 6:26 AM, DonQuiWho said:

 

I seemed to solve that by checking the file structure in the 'User/,,,' directory, where there was somehow an extra spurious folder - see my posts a few pages up this thread, somewhere before a pic of of Shrek's Princess Fiona

i checked, and the file/folder structure seemed fine. I had no extra folders or anything. sometimes if i start by manually adding a tattoo with the debug, future tattoos will get added just fine, but other than that the initial tattoo always disappears. any ideas?

[elliesec]

1 hour ago, Aycelist said:

i checked, and the file/folder structure seemed fine. I had no extra folders or anything. sometimes if i start by manually adding a tattoo with the debug, future tattoos will get added just fine, but other than that the initial tattoo always disappears. any ideas?

 

That sounds a lot like the disappearing tattoo bug I mentioned back on page 4 of this thread. A few people had raised it in the original Rape Tattoos mod thread too, and I experienced it at one point when on the old Rape Tattoos (but haven't seen it personally in a while now). Using the debug option works, but after a rape which adds your first tattoo, the tattoo disappears after a second or two:

 

 

 

As I've said a few times, my best guess right now is that it's a conflict with the way SlaveTats handles multiple tattoo synchronize calls from different mods (in my case, I believe it was because both Rape Tattoos & Zaz Animation Pack were triggering a sync after a rape event - ZAP always syncs tattoos after a sex scene ends if you have SlaveTats installed). My (moderately educated) guess is it's a race condition which can occur when two syncs are called on a character from different mods in quick succession and the character doesn't initially have any tattoos. But (big but)... I don't know enough about asynchronicity in Papyrus to say that's the case definitively, and I've not done enough testing to be able to say that's what's happening.

 

In short, I don't think there's really a definitive fix for the problem right now - it might go away on its own, but it also might not. The best workaround I have for it right now (as you mentioned) is to manually add a tattoo using either the Rape Tattoos debug option, or directly via SlaveTats, then subsequent tattoos should "stick". It's something that I do want to investigate at some point - I suspect the fix would need to be in SlaveTats itself though, and I need to find the time to really dig into it, as I don't think it's going to be a simple issue to fix unfortunately.

[Aycelist]

On 12/25/2023 at 7:59 PM, elliesec said:

 

That sounds a lot like the disappearing tattoo bug I mentioned back on page 4 of this thread. A few people had raised it in the original Rape Tattoos mod thread too, and I experienced it at one point when on the old Rape Tattoos (but haven't seen it personally in a while now). Using the debug option works, but after a rape which adds your first tattoo, the tattoo disappears after a second or two:

 

 

 

As I've said a few times, my best guess right now is that it's a conflict with the way SlaveTats handles multiple tattoo synchronize calls from different mods (in my case, I believe it was because both Rape Tattoos & Zaz Animation Pack were triggering a sync after a rape event - ZAP always syncs tattoos after a sex scene ends if you have SlaveTats installed). My (moderately educated) guess is it's a race condition which can occur when two syncs are called on a character from different mods in quick succession and the character doesn't initially have any tattoos. But (big but)... I don't know enough about asynchronicity in Papyrus to say that's the case definitively, and I've not done enough testing to be able to say that's what's happening.

 

In short, I don't think there's really a definitive fix for the problem right now - it might go away on its own, but it also might not. The best workaround I have for it right now (as you mentioned) is to manually add a tattoo using either the Rape Tattoos debug option, or directly via SlaveTats, then subsequent tattoos should "stick". It's something that I do want to investigate at some point - I suspect the fix would need to be in SlaveTats itself though, and I need to find the time to really dig into it, as I don't think it's going to be a simple issue to fix unfortunately.

not sure if this is a temporary fix or it just works miraculously, but i downgraded to the previous patch and it seems to work okay now!

[Guest]

@elliesec thank you for this! This is fantastic, especially the improved MCM load time.

 

Would it be possible to add functions/mod events to add/query tats on specific body parts i.e. face, body, legs, arms? I'm working on a couple events where I'd like dialogue to be more responsive to added tats. For example, a bandit threatening to tattoo something on your face and actually following thru.

 

If that is possible it'd also be nice if the automatic application pays attention to SL anim tags to decide location priority i.e. oral -> face, chest, anal -> posterior, back, legs, vaginal -> stomach, legs.

 

Also, a pie in the sky idea along the same lines as above is some kind of tagging system wherein each tat can be assigned an array of strings that indicates themes. This could allow for even more specificity in post-sex tattoos i.e. right after a multi-actor scene, a gangbang-themed tat is selected. Similarly, mods that use the API directly can query specific pools of tattoos e.g. player slavery mod might want to use slavery-themed tats and a prison mod might use crime-themed tats.

 

If you're open to contribution, I can try putting together a prototype when I get the chance. Performance is definitely a concern with both of these suggestions. I've put together a couple general native functions in a PO3 Papyrus Extender-like utility that myself and @Gyra are using, I could look into making some for RT as well if you're interested. Although, LE users would unfortunately miss out on the performance gains.

Edited January 8, 2024 by ponzipyramid

[elliesec]

5 hours ago, ponzipyramid said:

@elliesec thank you for this! This is fantastic, especially the improved MCM load time.

 

Would it be possible to add functions/mod events to add/query tats on specific body parts i.e. face, body, legs, arms? I'm working on a couple events where I'd like dialogue to be more responsive to added tats. For example, a bandit threatening to tattoo something on your face and actually following thru.

 

If that is possible it'd also be nice if the automatic application pays attention to SL anim tags to decide location priority i.e. oral -> face, chest, anal -> posterior, back, legs, vaginal -> stomach, legs.

 

Also, a pie in the sky idea along the same lines as above is some kind of tagging system wherein each tat can be assigned an array of strings that indicates themes. This could allow for even more specificity in post-sex tattoos i.e. right after a multi-actor scene, a gangbang-themed tat is selected. Similarly, mods that use the API directly can query specific pools of tattoos e.g. player slavery mod might want to use slavery-themed tats and a prison mod might use crime-themed tats.

 

If you're open to contribution, I can try putting together a prototype when I get the chance. Performance is definitely a concern with both of these suggestions. I've put together a couple general native functions in a PO3 Papyrus Extender-like utility that myself and @Gyra are using, I could look into making some for RT as well if you're interested. Although, LE users would unfortunately miss out on the performance gains.

 

Hey, thanks for the feedback, that's great to hear!

As far as adding functionality for targeting specific body parts goes, that's something I've had on my radar for a while now, and should be relatively striaghtforward to support. I've been on a bit of a modding hiatus for the last couple of months for various reasons, but my time should be freeing up to get back into this fairly soon. I have a version 3 in the works which aims to make tattoo configuration through the MCM a fair bit less tedious, and doing things like assigning tags/themes to tattoos should fit into those changes pretty nicely too (I've just been holding off on big feature changes until after I've sorted out all the groundwork for V3).

You're welcome to prototype something based on version 2, but I've since reorganised a lot of the code, so it'd probably not be straightforward merge (shouldn't be too difficult to port to the new version though). If it's easier (slash less work), you could always outline the kind of interface you'd want to RT to expose, and I'd be happy to look at putting that in just as soon as I've sorted out my modding setup again (and seen what havoc the recent SE update might have caused to it).

As far as adding some native functionsality goes, I'd definitely be interested if you get the chance. It's honestly something I've been thinking would greatly benefit RT (and probably SlaveTats too to be honest). It's also something I've been meaning to look into, but I don't really a C-family development background, and haven't gotten around to doing the learning to be able to do that myself just yet.

In any case, feel free to drop me a DM if you wanted to discuss anything.

[SexyCentimane]

9 hours ago, elliesec said:

 

Hey, thanks for the feedback, that's great to hear!

As far as adding functionality for targeting specific body parts goes, that's something I've had on my radar for a while now, and should be relatively striaghtforward to support. I've been on a bit of a modding hiatus for the last couple of months for various reasons, but my time should be freeing up to get back into this fairly soon. I have a version 3 in the works which aims to make tattoo configuration through the MCM a fair bit less tedious, and doing things like assigning tags/themes to tattoos should fit into those changes pretty nicely too (I've just been holding off on big feature changes until after I've sorted out all the groundwork for V3).

You're welcome to prototype something based on version 2, but I've since reorganised a lot of the code, so it'd probably not be straightforward merge (shouldn't be too difficult to port to the new version though). If it's easier (slash less work), you could always outline the kind of interface you'd want to RT to expose, and I'd be happy to look at putting that in just as soon as I've sorted out my modding setup again (and seen what havoc the recent SE update might have caused to it).

As far as adding some native functionsality goes, I'd definitely be interested if you get the chance. It's honestly something I've been thinking would greatly benefit RT (and probably SlaveTats too to be honest). It's also something I've been meaning to look into, but I don't really a C-family development background, and haven't gotten around to doing the learning to be able to do that myself just yet.

In any case, feel free to drop me a DM if you wanted to discuss anything.

 

15 hours ago, ponzipyramid said:

@elliesec thank you for this! This is fantastic, especially the improved MCM load time.

 

Would it be possible to add functions/mod events to add/query tats on specific body parts i.e. face, body, legs, arms? I'm working on a couple events where I'd like dialogue to be more responsive to added tats. For example, a bandit threatening to tattoo something on your face and actually following thru.

 

If that is possible it'd also be nice if the automatic application pays attention to SL anim tags to decide location priority i.e. oral -> face, chest, anal -> posterior, back, legs, vaginal -> stomach, legs.

 

Also, a pie in the sky idea along the same lines as above is some kind of tagging system wherein each tat can be assigned an array of strings that indicates themes. This could allow for even more specificity in post-sex tattoos i.e. right after a multi-actor scene, a gangbang-themed tat is selected. Similarly, mods that use the API directly can query specific pools of tattoos e.g. player slavery mod might want to use slavery-themed tats and a prison mod might use crime-themed tats.

 

If you're open to contribution, I can try putting together a prototype when I get the chance. Performance is definitely a concern with both of these suggestions. I've put together a couple general native functions in a PO3 Papyrus Extender-like utility that myself and @Gyra are using, I could look into making some for RT as well if you're interested. Although, LE users would unfortunately miss out on the performance gains.

 

@elliesec @ponzipyramid this idea--tattoo tagging based on things like scene type, player and aggressor faction, completed quests (e.g. I can think of a few tattoos that reference Dragonborn or Archmage) was something that I was thinking about when I was last using RapeTats. I dug into the code a little bit to see about viability but then ended up having to uninstall for a while. I'm back now, though, so if you think this is a good direction for the mod, I could potentially also take a crack at it.

 

I will say, though, while I have some programming experience, I'm very new to papyrus, so I expect some deficiencies with regard to performance especially. If you'd rather not deal with potential contributions like that (or you'd rather not have me work on it for any other reason), fair enough and I hope this comes through--I love both of your work!

[Guest]

11 hours ago, elliesec said:

 

Hey, thanks for the feedback, that's great to hear!

As far as adding functionality for targeting specific body parts goes, that's something I've had on my radar for a while now, and should be relatively striaghtforward to support. I've been on a bit of a modding hiatus for the last couple of months for various reasons, but my time should be freeing up to get back into this fairly soon. I have a version 3 in the works which aims to make tattoo configuration through the MCM a fair bit less tedious, and doing things like assigning tags/themes to tattoos should fit into those changes pretty nicely too (I've just been holding off on big feature changes until after I've sorted out all the groundwork for V3).

You're welcome to prototype something based on version 2, but I've since reorganised a lot of the code, so it'd probably not be straightforward merge (shouldn't be too difficult to port to the new version though). If it's easier (slash less work), you could always outline the kind of interface you'd want to RT to expose, and I'd be happy to look at putting that in just as soon as I've sorted out my modding setup again (and seen what havoc the recent SE update might have caused to it).

As far as adding some native functionsality goes, I'd definitely be interested if you get the chance. It's honestly something I've been thinking would greatly benefit RT (and probably SlaveTats too to be honest). It's also something I've been meaning to look into, but I don't really a C-family development background, and haven't gotten around to doing the learning to be able to do that myself just yet.

In any case, feel free to drop me a DM if you wanted to discuss anything.

 

1 hour ago, SexyCentimane said:

 

 

@elliesec @ponzipyramid this idea--tattoo tagging based on things like scene type, player and aggressor faction, completed quests (e.g. I can think of a few tattoos that reference Dragonborn or Archmage) was something that I was thinking about when I was last using RapeTats. I dug into the code a little bit to see about viability but then ended up having to uninstall for a while. I'm back now, though, so if you think this is a good direction for the mod, I could potentially also take a crack at it.

 

I will say, though, while I have some programming experience, I'm very new to papyrus, so I expect some deficiencies with regard to performance especially. If you'd rather not deal with potential contributions like that (or you'd rather not have me work on it for any other reason), fair enough and I hope this comes through--I love both of your work!

 

Excited for the new update!

 

IMO, there's two approaches we could take to address the performance problem. The first, if we just want to offload the longer linear operations to native is to make some generic array processing functions. The other is to create a DLL for the tattoo family of mods: SlaveTats, RapeTats, and FadeTats with specialized functions for this use case, assuming @murfk is okay with a patch.

 

The latter approach is basically necessary for a user-defined rules-based application system. Here's a quick example I slapped together inspired by @Alpia's pack.

 

[
    {
        "type": "IsAggressorInFaction",
        "value": "GuardFactionWhiterun",
        "tags": ["whiterun", "guard"]
    },
    {
        "type": "IsAggressorInFaction",
        "value": "BanditFaction",
        "tags": ["bandit"]
    },
    {
        "type": "GetAggressorRace",
        "value": "Nord",
        "tags": ["nord-dominant"]
    },
    {
        "type": "AnimationHasTag",
        "value": "oral",
        "tags": ["blowjob", "oral"],
        "groups": ["face", "chest"] 
    },
    {
        "type": "AnimationHasTag",
        "value": "spanking",
        "tags": ["spank"],
        "groups": ["posterior", "lower back"] 
    },
    {
        "type": "AnimationNumParticpants>=",
        "value": "2",
        "tags": ["gangbang"]
    },
    {
        "type": "VictimWornHasKeywrd", // devious devices integration
        "value": "zad_InventoryDevice", 
        "tags": ["bondage"]
    },
    {
        "type": "VictimWornHasKeywrd", // devious devices integration
        "value": "zad_DeviousBelt",
        "tags": ["edging", "denial"]
    },
    {
        "type": "QuestIsRunning", // prison alternative integration
        "value": "PamaPA_Imprisoned",
        "tags": ["prison", "crime"]
    },
    {
        "type": "QuestIsRunning", // public whore integration
        "value": "PW__DawnstarQuest",
        "tags": ["whore", "freeuse", "dawnstar"]
    },
    {
        "type": "QuestIsRunning", // public whore integration
        "value": "PW__FalkreathQuest",
        "tags": ["whore", "freeuse", "falkreath"]
    },
    {
        "type": "IsVictimInFaction", // soul gem oven integration
        "value": "dse_sgo_FactionProduceGems", 
        "tags": ["pregnant", "soulgem", "breeding"]
    }
]

 

My primary concern is fuzzy filtering. If the system uses strict filters for tattoo selection, it will likely fail to find any tattoos or arguably worse, it will keep selecting the same tattoos over and over again. It might be better to rely on a nonuniform distribution instead of going all or nothing.

Edited January 8, 2024 by ponzipyramid

[Alpia]

Quote

The latter approach is basically necessary for a user-defined rules-based application system. Here's a quick example I slapped together inspired by @Alpia's pack.

My pack is gonna have to grow pretty big to satisfy these kinda filters ?

 "type": "IsVictimInFaction", // soul gem oven integration
        "value": "dse_sgo_FactionProduceGems", 
        "tags": ["pregnant", "soulgem", "breeding"]

soulgem oven... and another bunch of tattoos on my ever growing todo list

 

[SexyCentimane]

52 minutes ago, ponzipyramid said:

 

 

Excited for the new update!

 

IMO, there's two approaches we could take to address the performance problem. The first, if we just want to offload the longer linear operations to native is to make some generic array processing functions. The other is to create a DLL for the tattoo family of mods: SlaveTats, RapeTats, and FadeTats with specialized functions for this use case, assuming @murfk is okay with a patch.

 

The latter approach is basically necessary for a user-defined rules-based application system. Here's a quick example I slapped together inspired by @Alpia's pack.

 

[
    {
        "type": "IsAggressorInFaction",
        "value": "GuardFactionWhiterun",
        "tags": ["whiterun", "guard"]
    },
    {
        "type": "IsAggressorInFaction",
        "value": "BanditFaction",
        "tags": ["bandit"]
    },
    {
        "type": "GetAggressorRace",
        "value": "Nord",
        "tags": ["nord-dominant"]
    },
    {
        "type": "AnimationHasTag",
        "value": "oral",
        "tags": ["blowjob", "oral"],
        "groups": ["face", "chest"] 
    },
    {
        "type": "AnimationHasTag",
        "value": "spanking",
        "tags": ["spank"],
        "groups": ["posterior", "lower back"] 
    },
    {
        "type": "AnimationNumParticpants>=",
        "value": "2",
        "tags": ["gangbang"]
    },
    {
        "type": "VictimWornHasKeywrd", // devious devices integration
        "value": "zad_InventoryDevice", 
        "tags": ["bondage"]
    },
    {
        "type": "VictimWornHasKeywrd", // devious devices integration
        "value": "zad_DeviousBelt",
        "tags": ["edging", "denial"]
    },
    {
        "type": "QuestIsRunning", // prison alternative integration
        "value": "PamaPA_Imprisoned",
        "tags": ["prison", "crime"]
    },
    {
        "type": "QuestIsRunning", // public whore integration
        "value": "PW__DawnstarQuest",
        "tags": ["whore", "freeuse", "dawnstar"]
    },
    {
        "type": "QuestIsRunning", // public whore integration
        "value": "PW__FalkreathQuest",
        "tags": ["whore", "freeuse", "falkreath"]
    },
    {
        "type": "IsVictimInFaction", // soul gem oven integration
        "value": "dse_sgo_FactionProduceGems", 
        "tags": ["pregnant", "soulgem", "breeding"]
    }
]

 

My primary concern is fuzzy filtering. If the system uses strict filters for tattoo selection, it will likely fail to find any tattoos or arguably worse, it will keep selecting the same tattoos over and over again. It might be better to rely on a nonuniform distribution instead of going all or nothing.

 

The point about over-filtering brings up a key point about the tagging logic, since there are a large number of fairly generic tattoos out there that make sense for most scenarios. In the full DLL/API scenario, I could maybe see this addressed by a bidirectional system--a calling mod can request a tattoo matching a certain tag set, but a tag can also have a rule attached to it allowing tattoos of that tag to be applied only when a given condition is met.

 

This, I think, would mostly address failure-to-find, since a "generic" request would likely still have a fairly large pool to choose from--the fairly generic "fuck her" type tattoos could maybe be even completely untagged. This also could address another concern I was thinking about: we can't necessarily expect every existing pack to update to a new tagging system, and in an ideal world a user who doesn't really care about that tagging could just not worry about it (for the bidirectional setup, simply by not setting requirements for any tag).

 

Then, the user's main install would carry a config associating tags with rules, while each tattoo pack would associate its tattoos to tags, and mod authors could fairly easily query for specific tattoos.

 

On the downside, of course, this all requires a fair bit more overhead, both in terms of programming effort and in-game performance. C++ to match a tattoo's tags to the current scene's parameters based on a set of rules doesn't strike me as too difficult, but implementing a system to actually define and expose those rules to the user, as well as making it performant on a potentially quite large tattoo list and tag list, would be substantially more effort.

 

I'm curious for your thoughts on the viability of this--I have some C-family experience, but I'm not familiar with Skyrim modding, so I don't have a good sense of how feasible it is in context.

Edited January 8, 2024 by SexyCentimane

[elliesec]

Oh wow, some nice discussion.

 

@ponzipyramid - as far as performance goes right now, I believe the filtering/querying is actually relatively fast (based on the last time I checked). Probably about 95% (I made that number up, but it was substantial) of the time between a sex scene ending and the "Your last partner left you a memento" message is taken up doing the SlaveTats sync (i.e. reconciling/removing/adding overlays via NiO). So I've been wanting to look into making that faster (I think it should be possible to implement some kind of "double-buffering" style system for SlaveTats, which may speed things up, and possibly get rid of the disappearing tattoo bug, but I'd need to look into that).

 

That said, I really like the rules-based approach you've proposed there for RT (and appreciate that introducing something like that could well introduce performance concerns which would likely benefit from some native filtering functions). I do wonder whether those kinds of rules should be a native SlaveTats thing, or whether they'd actually be better off living in RT though - in my eyes, SlaveTats is more or less purely an API for applying the overlays, and perhaps metadata on how/when they should be applied is somewhat out of scope. But... I have for a long time thought that having support for generic tattoo tagging within SlaveTats itself could be incredibly useful for mods like RT (and quite possibly other SlaveTats-dependent mods that may come along).

 

As far as the concerns about over-filtering go, I do think a nonuniform distribution approach feels like the correct approach as far as the core RT functionality goes (i.e. the basic have sex -> get tattoo loop), whereby tattoos with higher specificity to a scene have a higher chance of being selected, but given the number of tattoos available in the ecosystem nowadays, I'm sure there's an abundance of generic non-specific tattoos that could be added to the pool as fallbacks.

Then there is also the external RapeTats interface to other mods to consider - i.e. what would a useful API be for mods that want to call RapeTats to add a random tattoo? These calls usually come without an attached sex scene, so the animation-based filters don't really apply, but the tags certainly do. If a mod requests tattoos to be applied with a particular tag (or tags), what's the expected behaviour if no such tattoos are available? I could see arguments going both ways there (i.e. fall back to generic tattoos vs. don't apply anything). I don't imagine it'd be too hard to support both though, and let the calling mod decide.

 

@SexyCentimane - thanks for the offer. I would certainly be open to accepting contributions to the mod at some point. That said, as I mentioned above, at the moment it's kind of in flux - with V3 I've pretty substantially reworked the structure of the mod, so I'd probably need to do some interpretation to patch in contributions based on V2.

 

All that said, I do unfortunately have relatively limited time to work on the mod at the moment, and am getting a bit of a sense that I might bite off more than I can chew by rolling too much into V3. So as things stand, I think as a top priority I want to get V3 out the door with relatively little scope change from what I currently have planned (for the most part, this is code reorganisation, and improved MCM tattoo configuration - substantially enhanced tattoo search/filter functionality, and the ability to batch-assign groups to tattoos via the MCM, as well as a few tweaks to tattoo groups as suggested by @Alpia - read "more groups"). After that's done out, I should be in a position where I can maintain that release and start thinking about these tagging/filtering features in earnest.

[Guest]

4 hours ago, elliesec said:

Oh wow, some nice discussion.

 

@ponzipyramid - as far as performance goes right now, I believe the filtering/querying is actually relatively fast (based on the last time I checked). Probably about 95% (I made that number up, but it was substantial) of the time between a sex scene ending and the "Your last partner left you a memento" message is taken up doing the SlaveTats sync (i.e. reconciling/removing/adding overlays via NiO). So I've been wanting to look into making that faster (I think it should be possible to implement some kind of "double-buffering" style system for SlaveTats, which may speed things up, and possibly get rid of the disappearing tattoo bug, but I'd need to look into that).

 

That said, I really like the rules-based approach you've proposed there for RT (and appreciate that introducing something like that could well introduce performance concerns which would likely benefit from some native filtering functions). I do wonder whether those kinds of rules should be a native SlaveTats thing, or whether they'd actually be better off living in RT though - in my eyes, SlaveTats is more or less purely an API for applying the overlays, and perhaps metadata on how/when they should be applied is somewhat out of scope. But... I have for a long time thought that having support for generic tattoo tagging within SlaveTats itself could be incredibly useful for mods like RT (and quite possibly other SlaveTats-dependent mods that may come along).

 

As far as the concerns about over-filtering go, I do think a nonuniform distribution approach feels like the correct approach as far as the core RT functionality goes (i.e. the basic have sex -> get tattoo loop), whereby tattoos with higher specificity to a scene have a higher chance of being selected, but given the number of tattoos available in the ecosystem nowadays, I'm sure there's an abundance of generic non-specific tattoos that could be added to the pool as fallbacks.

Then there is also the external RapeTats interface to other mods to consider - i.e. what would a useful API be for mods that want to call RapeTats to add a random tattoo? These calls usually come without an attached sex scene, so the animation-based filters don't really apply, but the tags certainly do. If a mod requests tattoos to be applied with a particular tag (or tags), what's the expected behaviour if no such tattoos are available? I could see arguments going both ways there (i.e. fall back to generic tattoos vs. don't apply anything). I don't imagine it'd be too hard to support both though, and let the calling mod decide.

 

@SexyCentimane - thanks for the offer. I would certainly be open to accepting contributions to the mod at some point. That said, as I mentioned above, at the moment it's kind of in flux - with V3 I've pretty substantially reworked the structure of the mod, so I'd probably need to do some interpretation to patch in contributions based on V2.

 

All that said, I do unfortunately have relatively limited time to work on the mod at the moment, and am getting a bit of a sense that I might bite off more than I can chew by rolling too much into V3. So as things stand, I think as a top priority I want to get V3 out the door with relatively little scope change from what I currently have planned (for the most part, this is code reorganisation, and improved MCM tattoo configuration - substantially enhanced tattoo search/filter functionality, and the ability to batch-assign groups to tattoos via the MCM, as well as a few tweaks to tattoo groups as suggested by @Alpia - read "more groups"). After that's done out, I should be in a position where I can maintain that release and start thinking about these tagging/filtering features in earnest.

 

I was originally intending to create a native overlay management system and then patch ST to use it. The problem it's facing rn is shared by basically any mod that works with overlays (bathing, sex effects, etc) so I believe this would be a generally useful utility. I was also planning on adding animated and fade effects directly to reduce background Papyrus load. Might be useful for FadeTats as well.

 

I can try to wrap that up while you're working on v3. And once both are complete, we can look into a bespoke DLL for RT to do things like rule based application.

 

I would def ensure everything can run with the DLL disabled. Always a chance Todd updates Skyrim without us around to recompile.

[elliesec]

1 hour ago, ponzipyramid said:

 

I was originally intending to create a native overlay management system and then patch ST to use it. The problem it's facing rn is shared by basically any mod that works with overlays (bathing, sex effects, etc) so I believe this would be a generally useful utility. I was also planning on adding animated and fade effects directly to reduce background Papyrus load. Might be useful for FadeTats as well.

 

I can try to wrap that up while you're working on v3. And once both are complete, we can look into a bespoke DLL for RT to do things like rule based application.

 

I would def ensure everything can run with the DLL disabled. Always a chance Todd updates Skyrim without us around to recompile.

 

That honestly sounds amazing - bringing down that overlay management overhead would be incredibly useful.

[Alpia]

I noticed I have a bug with rape tats I'm not sure if its always been there. The last page of the mcm shows the same entries as the second last. The last page is also what should be the first. It starts with 100-149 and on page 5 and 6 it shows 0-49 meanwhile 50-99 is missing. I supposed one of the last two pages that get loaded twice is what should be 50-99. Happens to me independend of load order and with new just like with ongoing games. (screen of issue in spoiler)
Tried the previous 2.0.1 version, same there.
Tried original rape tats, loads fine and in the right order
 

Spoiler

 

Edited January 14, 2024 by Alpia