Jump to content

ATTENTION SEXLAB MOD MAKERS: Important questions


Recommended Posts

First off, this is a thread for me to ask questions directly of the modders making mods for SexLab, I won't hesitate to remove any posts by people who are not making/made a SexLab mod, or aren't a modder who is has some knowledge on the to actually add on the subject.

 

I have a couple important questions for the people making SexLab mods, questions I need answers to as it relates to potential major upcoming changes to the framework. I want to maintain mod compatibility with current working SexLab mods when the framework jumps to 1.20, however I fear many of the changes I want to make are at their core, to deep of a change and risk breaking some mods.

 
Some Needless Over Explanation You Probably Don't Care About:
 
SexLab 1.20 is at it's heart, almost a complete rewrite over sexlab 1.10. The aim is make it more upgradeable for the sake of future updates, as in it's 1.10 state it simply isn't as each update is making the framework less stable and/or messier. A large part of this is me taking a lot of bloat out of it's scripts, instead of a one size fits all SexLabFramework script that tries to do everything, I'm splitting it's parts out into separate more focused scripts, StripActor() & ApplyCum() are no longer a SexLabFramework function for example, they are now a sslActorLibrary function, along with other actor specific manipulation functions. This way instead of everything loading a bunch of useless functions from a single bloated script into a process that doesn't need it, it only draws from functions that are of use to it.
 
The end result is various parts of the framework have access to the parts of the framework they need, and no more, letting parts operate more independently, which in turn means when a part of it fucks up somehow, it doesn't mean bring the whole thing to a screeching halt and CTD or do crazy things, and is instead able to adjust.
 
Does this sort of thing even matter for performance in Papyrus? Honestly I haven't a clue and I have some doubts that it does, however it at the very least will result in easier to maintain framework code and overall improved stability as I go through the process of rewriting many poorly made functions with newer more stable versions of them; and in the end that makes the effort worth it enough to me.
 

There is more that I want to do than just moving/rewriting the functions around around however. For example, I've eliminated all animation position, voice, and thread scripts, resulting in SexLab using a gross total of 55 less scripts than is being used in previous versions of SexLab as they've shifted to all using a single script extending individual references so they can still maintain their separate values without having to instead use individual scripts extending a base script that extends a quest for each and every animation, voice, and thread.

 

This will mean breaking the SexLab Xaz and Vanilla Voices pack, but those are the only ones that will be affected that I know of, and updating them to work with 1.20 won't be hard, as it mostly just consists of copy pasting your LoadAnimation/Voice() function from individual scripts into a single script under individual events instead, not needing to change anything about them other than the function name into a unique event name.

 

That brings me to where I have questions however, there are some other changes I want to do in the name of isolating parts of the framework to their own section, but I do so hesitant, as there is a bigger risk of breaking existing SexLab mods if I do so.

 

In order to maintain compatibility with mods made under 1.10, I am leaving all old functions in the SexLabFramework script there, but their scripting is gutted and replaced with accessors to the new rewritten functions in their respective more focused scripts. This should, in theory, few things should be broken by this change, though continued use of those functions would be considered "suboptimal" compared to accessing those functions directly from their dependency. In the benchmarks I ran using a Papyrus benchmark tool, the difference between accessing them directly as property.function(args) and property.property.function(args) was minimal, if memory serves the benchmarks comparing the two came in at roughly 0.12 vs 0.15 respectively.

 

Anybody doing simple StartSex() calls and nothing more in a script fragment or quest somewhere should be entirely unaffected by these changes. 

 

As terrible as it may sound, I just don't know much about what existing/upcoming SexLab mods are doing and how they are using the framework, as I honestly don't ever play Skyrim these days, any chance I get to I end up feeling that time is better spent working on SexLab to improve Skyrim, rather than spent playing it, this is the curse of being a modder.

 

I have a general idea of what I think most SexLab mods are using and not using, but I don't know for sure, and thus these questions:

 

The Only BIt you Really Need To Read (TL;DR)

 

I'm nearing completion of wrapping up 1.20, I just need some questions answered to know which direction I go in terms of finishing it.

  • What parts/functions of the framework are you making use of?
     
  • Do you ever check and/or manipulate the system settings, either via the SexLabFramework.Config property or  directly from the sslSystemConfig script?
     
  • Do you ever make use of the many properties stuffed into sslSystemResources script? Be it through the SexLabFramework.Data property or directly from the sslSystemResources.
     
  • Do you ever use any of the stat functions or make use of the stats in your own mod in any way?
     
  • What's a functionality you wish existed in the framework itself and why?
     
  • What do you find hard to use about SexLab?
     
  • If you read the above wall of text, does any of it concern you? How and why?
Link to comment

Not sure how much use my answers are going to be given my limited experience of SexLab. But for what it's worth:

 

What parts/functions of the framework are you making use of?

Currently, nothing that isn't in the "Ulfric Is Mean" example. I have a few place where I select by more than one tag, and one where I exclude a tag. Otherwise, I'm keeping it simple for now.

 

Do you ever check and/or manipulate the system settings, either via the SexLabFramework.Config property or  directly from the sslSystemConfig script?

Nope.

 

Do you ever make use of the many properties stuffed into sslSystemResources script? Be it through the SexLabFramework.Data property or directly from the sslSystemResources.

Nope.

 

Do you ever use any of the stat functions or make use of the stats in your own mod in any way?

Planning on it, but not yet. So there's no impact for me if you change them. It'd be a shame to see them vanish though.

 

What's a functionality you wish existed in the framework itself and why?

It'd be nice to be able to do dialogue driven sex scenes as in Sexrim.

 

What do you find hard to use about SexLab?

Nothing so far.

 

If you read the above wall of text, does any of it concern you? How and why?

Only thing I'd say is that I find the current interface very easy to use, and I'd hate to see that ease of use sacrificed for better separation of concerns. Having said that you seem to have that covered by reimplementing the current interface in terms of the new one, and from what you say of the performance hit, I doubt there's going to be a problem.

Link to comment

Hi Ashal, in Radiant Prostitution I use the NewThread() and most of the associated function to specify the thread. I also use generic hooks and custom hooks to get some feedback on what happens/happened. I also use the stats functions since they provide an overall feedback of the player's experience across all mod using SL. The more detailed they are the better IMO but I understand many possible stats fall beyond the scope of the framework itself.

 

As for the feature I which were there: 1) something which may already be possible but I don't know how to do it. A way to know if a cum shader is currently displayed, and which. If the shader were wrapped in a magic effect one could use the "HasMagicEffect" condition function. 2) More animations/ non-sexual animations, dancing, etc. I find SL so convenient and easy to use I wish it'd be the first and last animation solution (at least as far as I'm concerned).

 

Speaking only for myself, I don't really mind heavy changes in the framework (even without backward compatibility) as long as most of the features find their way in the new version. The only concern is with mods that are not currently being updated.

 

Cheers

Link to comment

First off, this is a thread for me to ask questions directly of the modders making mods for SexLab,

 

Woohoo! I qualify!

 

Does this sort of thing even matter for performance in Papyrus?

 

This is a question I've asked for a while. The Papyrus compiler is, at best, suboptimal and was designed for correctness over the efficiency of the generated code (this from smkViper on the Bethesda forums, and he should know, he created Papyrus). My long term back-burner project is actually a rewrite of the compiler to (at the very least) optimize out all of the unnecessary assignments and temporary variables. Don't expect anything before the end of the year though.

 

I have a project thread here

 

What parts/functions of the framework are you making use of?

 

As of now, nothing more than the startSex() call, along with some clean-up code that operates off the completed callback.

 

Do you ever check and/or manipulate the system settings, either via the SexLabFramework.Config property or  directly from the sslSystemConfig script?

Do you ever make use of the many properties stuffed into sslSystemResources script? Be it through the SexLabFramework.Data property or directly from the sslSystemResources.

Do you ever use any of the stat functions or make use of the stats in your own mod in any way?

 

Answer to all of these is no.

 

What's a functionality you wish existed in the framework itself and why?

 

For me, more animations. Especially masturbation. I intend to add a bestiality option to random sex once that's a possibility.

 

What do you find hard to use about SexLab?

 

As I only use StartSex(), nothing so far.

 

If you read the above wall of text, does any of it concern you? How and why?

 

Nothing so far, looking forward to the new version.

Link to comment

 

I have a general idea of what I think most SexLab mods are using and not using, but I don't know for sure, and thus these questions:

 

The Only BIt you Really Need To Read (TL;DR)

 

I'm nearing completion of wrapping up 1.20, I just need some questions answered to know which direction I go in terms of finishing it.

  • What parts/functions of the framework are you making use of?

     

  • Do you ever check and/or manipulate the system settings, either via the SexLabFramework.Config property or  directly from the sslSystemConfig script?

     

  • Do you ever make use of the many properties stuffed into sslSystemResources script? Be it through the SexLabFramework.Data property or directly from the sslSystemResources.

     

  • Do you ever use any of the stat functions or make use of the stats in your own mod in any way?

     

  • What's a functionality you wish existed in the framework itself and why?

     

  • What do you find hard to use about SexLab?

     

  • If you read the above wall of text, does any of it concern you? How and why?

 

 

"What parts/functions of the framework are you making use of?"

StartSex, events.

 

"Do you ever check and/or manipulate the system settings, either via the SexLabFramework.Config property or  directly from the sslSystemConfig script?"

"Do you ever make use of the many properties stuffed into sslSystemResources script? Be it through the SexLabFramework.Data property or directly from the sslSystemResources."

No. Thats *your* job :P  I like white box/open source frameworks/libraries. But the reason are bugs and documentation only.

 

"Do you ever use any of the stat functions or make use of the stats in your own mod in any way?"

Don't realy know what you mean. I use faction to check if actors are still busy.

 

"What's a functionality you wish existed in the framework itself and why?"

Thou shalt not move ... gimme hot animations, but not in another time zone :P

Animation and sound engine.

 

 

"What do you find hard to use about SexLab?"

Events are not, <can't find english word> ... for every "Start" there must be equivalent "End". If there is "new", there is matching "delete", if there is "open"  there is "close". And it must be, how to say, paired. Not that sometimes there is Start, but End is ... or there is Abort, or ...

 

Also strict specification when *you* handle actors and when you stoped.

 

 

"If you read the above wall of text, does any of it concern you? How and why?"

Made mods, one even released. Plan for more. But I'd like that SL is stable and rock solid.

Link to comment

I'm nearing completion of wrapping up 1.20, I just need some questions answered to know which direction I go in terms of finishing it.

  • What parts/functions of the framework are you making use of?

startsex(), getanimationsbytag()(A lot, great function), GetPlayerStatLevel()

  • Do you ever check and/or manipulate the system settings, either via the SexLabFramework.Config property or  directly from the sslSystemConfig script?

Nope

  • Do you ever make use of the many properties stuffed into sslSystemResources script? Be it through the SexLabFramework.Data property or directly from the sslSystemResources.
     

Nope

  • Do you ever use any of the stat functions or make use of the stats in your own mod in any way?
     

Yes, I sometimes check in order to make NPC give comments on your handywork

  • What's a functionality you wish existed in the framework itself and why?

I'm not sure if it's already possible but sex in an AIpackage is something I would really like to see.

  • What do you find hard to use about SexLab?

The rest of the creation kit. :P No really, in comparison to the troubles I have to go through to get everything else to work, SexLab itself (the parts that i have used so far) is a breeze.

Link to comment

This is a question I've asked for a while. The Papyrus compiler is, at best, suboptimal and was designed for correctness over the efficiency of the generated code (this from smkViper on the Bethesda forums, and he should know, he created Papyrus). My long term back-burner project is actually a rewrite of the compiler to (at the very least) optimize out all of the unnecessary assignments and temporary variables. Don't expect anything before the end of the year though.

 

I have a project thread here

 

Seems like an interesting project that could have a pretty profound effect. Compiler stuff is largely over my head however, as I've typically steered clear of compiled languages and stuck with interpreted, namely Python and PHP, so excuse my potential ignorance on the matter.

 

If I might make a suggested addition though, since you're looking to add a for loop, I'd love a foreach loop myself. I imagine it would look something like this in papyrus, going off your proposed for syntax 

; // Object array to be looped
ObjectReference[] array = new ObjectReference[10]

; // foreach syntax version
foreach (array as index : object)
	object.DoStuff()
endforeach

; // Assembled version
int index
while(index < array.Length)
	ObjectReference object = array[index]

	object.DoStuff()

	index += 1
endWhile
Default empty array args would be nice to, stupidly it lets you compile with them, but not use them.

; // Compiles
function DoStuff(int[] array = none)
endFunction
; // Does not compile
DoStuff()
; // Compiles
int[] array
DoStuff(array)

I assume it has something to do with the fact that it doesn't technically consider none a valid array, despite it being able to used most places such as returns and returning 0 from array.Length

 

No idea the feasibility of any of that, just my two cents of what would be nice to see in a new compiler. Good luck in any case.

Link to comment
If I might make a suggested addition though, since you're looking to add a for loop, I'd love a foreach loop myself. I imagine it would look something like this in papyrus, going off your proposed for syntax 

; // Object array to be looped
ObjectReference[] array = new ObjectReference[10]

; // foreach syntax version
foreach (array as index : object)
	object.DoStuff()
endforeach

 

I'm basing a lot of the constructs off Java which (as of version 5) has an "enhanced for loop" construct that exactly matches what you are requesting above. If I add it to Papyrus, it would probably look like:

int[] array = new int[10]

foreach (int arrayElement : array)
    DoStuff(arrayElement)
endforeach

I also hate the compile errors that arise from array = none. I'm planning on fixing that as part of my initial release.

 

Link to comment

"What parts/functions of the framework are you making use of?"

StartSex, events.

What events specifically, and are you using the hook function, or are you just grabbing the sslThreadController and pulling stuff from it directly when using events?

 

"What's a functionality you wish existed in the framework itself and why?"

Thou shalt not move ... gimme hot animations, but not in another time zone :P

Animation and sound engine

Not sure what exactly you mean by this, can you explain further?

Link to comment

I also use the stats functions since they provide an overall feedback of the player's experience across all mod using SL. The more detailed they are the better IMO but I understand many possible stats fall beyond the scope of the framework itself.

Which ones exactly? Are you using the functions or are you you accessing properties themselves to check straight numbers? And what sort of additional detail is it you'd like?

 

One of the features I plan on adding soonish is giving mods the ability to register custom stats that can be managed by individual mods that display on the MCM menu, would this be of interest?

 

 something which may already be possible but I don't know how to do it. A way to know if a cum shader is currently displayed, and which. If the shader were wrapped in a magic effect one could use the "HasMagicEffect" condition function

 

With the final release of 1.20 I plan on moving the cum effect to spells as you say, and making them add up instead of replace, for example if the actor already has Oral cum spell applied, and its trying to add Vaginal cum, it will instead remove the Oral only cum and apply a Vaginal + Oral cum spell in it's place.

 

I've messed around a little bit with it, I haven't yet been able to figure out how to get the shader effects to show with the spell buff, I tried setting the shader effect as enchant shader and some other shader setting I can't remember, seemed to apply the shader effect when the spell was cast. Creation Kit stuff isn't my strong point, but I'll dig around more though to hopefully include it with 1.20 as planned. 

 

If somebody could shed some light on how to do spells to show the cum shader for me I'd appreciate.

Link to comment

I'm using the GetPlayerStatLevel(), no direct access. I was vague on the possible additional details because I don't know exactly the boundary of the framework. Looks like you next comment covers any possibility

 

One of the features I plan on adding soonish is giving mods the ability to register custom stats that can be managed by individual mods that display on the MCM menu, would this be of interest?

That sounds pretty neat. This would make mod interoperable without any other dependencies than sexlab. I think it would be a great tool.

 

For the cum effects into spells, I think what you want to look at is how the armor/flesh spell effect work. The shader to draw is specified in the magic effect, and the spell uses the magic effect and specify a duration and magnitude. The spell is cast with Cast() and applies the list of magic effects.

 

Another thing that could be added to the framework is a minimal stripping option. It was easy enough to implement in my mod but it could be integrated further in the framework. For instance, one could gradually remove pieces of clothing as the animation sequence is played, only removing a piece when it is necessary.

Link to comment

Submit actually uses very little of the Sexlab Framework's functions beyond the StartSex() function.  There's some basic stuff to set up which animations are valid for the various options (Aggressive, Oral, Anal, Etc), plus a couple of hooks to handle post sex, but it primarily just makes use of the StartSex().

 

So, my own personal opinion is break whatever you need to if it will make it better long term, I am sure I can easily adapt my mod to work with it.  I've recently done similar, breaking one mega script into two smaller ones to handle the various algorithm functions vs the various 'scene' functions, and then the required reassociation of everything else to the new separate scripts, so I can appreciate your goal of more modularity.

 

The only thing I would bring up (And maybe this can already be done and I'm just slow) is separating the "Strip" function from the StartSex().  Or at least being able to declare which actor needs to use the Strip function.  I bring this up because I have my own stripping mechanism I use on victims so that they have their worn items in their inventory so they show up in the Gift() function so that you can effectively rob them, which means it's kind of silly when they redo the Sexlab "Strip" animation when they are already naked.

 

So I guess that's my input.

Link to comment

What parts/functions of the framework are you making use of?

Zap: Registering new animations.

PO: Playing animations using custom threads. Needs some more tweaking (of SL) before I can fully use it everywhere.

 

Do you ever check and/or manipulate the system settings, either via the SexLabFramework.Config property or  directly from the sslSystemConfig script?

Zap and Po: No. I consider the config to be off limits (maybe incorrectly).

 

Do you ever make use of the many properties stuffed into sslSystemResources script? Be it through the SexLabFramework.Data property or directly from the sslSystemResources.

Zap: No, there was no need.

PO: Didn't know about it until now, but it wouldn't work with the current setup.

 

Do you ever use any of the stat functions or make use of the stats in your own mod in any way?

Zap and PO: No.

 

What's a functionality you wish existed in the framework itself and why?

Better setup of custom threads, ie. not through MCM exclusively. As an example, ragdolling is a huge immersion breaker if one actor is locked in a pillory.
  • Disable strip animation on actors.
  • Control of changes through the Game variable (eg. Player ai control).
  • Disable/enable ragdolling.

What do you find hard to use about SexLab?

It's easy enough to use. Most difficult things are finding out order of fired events (internally and externally) to debug how SL works when looking for workarounds on the above items.

 

If you read the above wall of text, does any of it concern you? How and why?

Not really. There may be concurrency issues when you split up implementation between different instances, but from looking at the current implementation, I guess you know how to handle those.
Link to comment

The only thing I would bring up (And maybe this can already be done and I'm just slow) is separating the "Strip" function from the StartSex().  Or at least being able to declare which actor needs to use the Strip function.  I bring this up because I have my own stripping mechanism I use on victims so that they have their worn items in their inventory so they show up in the Gift() function so that you can effectively rob them, which means it's kind of silly when they redo the Sexlab "Strip" animation when they are already naked.

 

 

If you use the thread making system instead of StartSex(), you can essentially disable SexLab's stripping as is right now.

 

In place of StartSex(): 

; // Open a new thread for setup
sslThreadModel Model = SexLab.NewThread()

; // Add your actors to scene
Model.AddActor(VictimRef, isVictim = true)
Model.AddACtor(AggressorRef)

; // Create an empty strip bool
; // must be 33 as that's the number of biped slots
; // with all left at false like this, nothing will be stripped
bool[] emptyStrip = new bool[33]

; // Set VictimRef's strip options
Model.SetStrip(VictimRef, emptyStrip)

; // Start the sex
Model.StartThread()

If you wanted to customize the stripping instead of disabling it, then you could do so by setting the bools in that array to true, where index + 30 = biped slot, so "emptyStrip[3] = true" would strip the actor of biped slot 33, which is hands. http://www.creationkit.com/Biped_Object for reference.

Link to comment

 

What's a functionality you wish existed in the framework itself and why?

Better setup of custom threads, ie. not through MCM exclusively. As an example, ragdolling is a huge immersion breaker if one actor is locked in a pillory.
  • Disable strip animation on actors.
  • Control of changes through the Game variable (eg. Player ai control).
  • Disable/enable ragdolling.

One idea I'm messing with as a potential addition to the custom threads, is being able to register custom end callbacks that would be used in place of ragdolling and forcing default idle.

 

after SexLab releases the actor and about to do the final act of resetting their idle with ragdoll/forcedefaultstate, this could be overriden with a custom callback, then the actor will instead be sent a mod event via ActorRef.SendModEvent("YourCallback") 

 

This way you could register those actors for the event, and do whatever you want with them after a scene, including toggling their AI or sending them the idle of your choosing.

 

Or maybe I'll just start sending actors some hook events of their own in general, like "SexLabStart" for when they are starting a SexLab animation, and "SexLabEnd" for when the actor is finished within SexLab. This way people could start hooking into specific actor events, rather than just going ons in the thread.

Link to comment

 

 

What's a functionality you wish existed in the framework itself and why?

Better setup of custom threads, ie. not through MCM exclusively. As an example, ragdolling is a huge immersion breaker if one actor is locked in a pillory.
  • Disable strip animation on actors.
  • Control of changes through the Game variable (eg. Player ai control).
  • Disable/enable ragdolling.

One idea I'm messing with as a potential addition to the custom threads, is being able to register custom end callbacks that would be used in place of ragdolling and forcing default idle.

 

after SexLab releases the actor and about to do the final act of resetting their idle with ragdoll/forcedefaultstate, this could be overriden with a custom callback, then the actor will instead be sent a mod event via ActorRef.SendModEvent("YourCallback") 

 

This way you could register those actors for the event, and do whatever you want with them after a scene, including toggling their AI or sending them the idle of your choosing.

 

Or maybe I'll just start sending actors some hook events of their own in general, like "SexLabStart" for when they are starting a SexLab animation, and "SexLabEnd" for when the actor is finished within SexLab. This way people could start hooking into specific actor events, rather than just going ons in the thread.

 

The problem with sending events or callbacks is that you don't know if they were handled, and so you won't know if you should run the default behavior or not. Of course, you could require the modder to tell the thread if he wants to take control, or assume that all custom threads always wanted to control these things.

 

From my pov, I'd prefer a third option, a setting: -1 = always off, 0 = use default, 1 = always on, or something similar. Easy to use and removes all doubt about where and if something happens.

 

Regarding actor events, I think I saw something about that in 1.15b at least. Iirc, events are sent and consumed internally for cleaning up actors after sex. It would be possible to hook into those events and do processing. ...

Link to comment

I plan to use SexLab to support my mods. What I would like to see:

 

Pseudocode

bool isCumCovered
int enumCumCoveredBodyParts
 
function setCumCovered( bool isActorCumCovered )
  isCumCovered = isActorCumCovered
endfunction
 
function addBodyPartCoveredWithCum (int bodyPart)
  if( isCumCovered == true)
    enumCumCoveredBodyParts += bodyPart
 
    return enumCumCoveredBodyParts
  endif
endfunction

Now you could have some bukkake like effects. The function setCumCovered determines if the actors body is clean or not (For example if he washes after sex you could call the function and when you have sex again it would not cover that specific body part, except it would be the same as last time). Now the mod author just has to call addBodyPartCoveredWithCum and use the returned integer to call ApplyCum(akActor, SprayTheBodyParts) for example.

That of course would need to change how the bodyparts are arranged in the ApplyCum function. Maybe write a new function like ApplyCumEffects() to support a flag-like system ?

Link to comment

 

The only thing I would bring up (And maybe this can already be done and I'm just slow) is separating the "Strip" function from the StartSex().  Or at least being able to declare which actor needs to use the Strip function.  I bring this up because I have my own stripping mechanism I use on victims so that they have their worn items in their inventory so they show up in the Gift() function so that you can effectively rob them, which means it's kind of silly when they redo the Sexlab "Strip" animation when they are already naked.

 

 

If you use the thread making system instead of StartSex(), you can essentially disable SexLab's stripping as is right now.

 

In place of StartSex(): 

; // Open a new thread for setup
sslThreadModel Model = SexLab.NewThread()

; // Add your actors to scene
Model.AddActor(VictimRef, isVictim = true)
Model.AddACtor(AggressorRef)

; // Create an empty strip bool
; // must be 33 as that's the number of biped slots
; // with all left at false like this, nothing will be stripped
bool[] emptyStrip = new bool[33]

; // Set VictimRef's strip options
Model.SetStrip(VictimRef, emptyStrip)

; // Start the sex
Model.StartThread()

If you wanted to customize the stripping instead of disabling it, then you could do so by setting the bools in that array to true, where index + 30 = biped slot, so "emptyStrip[3] = true" would strip the actor of biped slot 33, which is hands. http://www.creationkit.com/Biped_Object for reference.

 

Ah, good to know.  I figured it was there!  For my purpose, I just want to disable on the victim on nonconsensual, as they have already been stripped at that point.

Link to comment

There's a function I've added to the thread making system in 1.20 that lets you disable it, Model.DisableUndressAnimation(true) will cause it to forcibly skip it regardless of user settings.

Yes, that's all I want!

 

Only question is will that be for all actors involved, or can you specify per actor, so I could have it be "skip victim's, play animation for aggressors"?

Link to comment

 

There's a function I've added to the thread making system in 1.20 that lets you disable it, Model.DisableUndressAnimation(true) will cause it to forcibly skip it regardless of user settings.

Yes, that's all I want!

 

Only question is will that be for all actors involved, or can you specify per actor, so I could have it be "skip victim's, play animation for aggressors"?

 

It's not super important, but I'd also prefer to have that setting on a per-actor basis. This would also mesh better with the rest of the function on the model which all take an actor argument as input (where it's relevant).

Link to comment

I'm nearing completion of wrapping up 1.20, I just need some questions answered to know which direction I go in terms of finishing it.

  • 1. What parts/functions of the framework are you making use of?

     

  • 2. Do you ever check and/or manipulate the system settings, either via the SexLabFramework.Config property or  directly from the sslSystemConfig script?

     

  • 3. Do you ever make use of the many properties stuffed into sslSystemResources script? Be it through the SexLabFramework.Data property or directly from the sslSystemResources.

     

  • 4. Do you ever use any of the stat functions or make use of the stats in your own mod in any way?

     

  • 5. What's a functionality you wish existed in the framework itself and why?

     

  • 6. What do you find hard to use about SexLab?

     

  • 7. If you read the above wall of text, does any of it concern you? How and why?
1. If I take the wiki as a basis it's SexLabFramework and sslThreadModel, I may use Sslthreadcontroller in the future.

 

2. 3.

Read Timers, current stage, I plan to manipulate Timers in the future.

 

4.

No.

 

5.

Blur effects during orgasm; liked that feature in Lovers very much.

GetThreadNumber; to be able to constantly monitor all animations.

Disable undress animation for specific actor(s); e.g. useful in Defeat where the rapist first strips the victim, so prior to the animation only the rapist should strip.

MCM setting "Display name of animation"; right now I'm just reading "Rape added".

Being able to set the sexual orientation of the PC instead of letting it determine by their actions; possibly locking the PC out of animations that contradict to their orientation.

 

6.

Wiki not up-to-date/complete; when using "advanced" features it can get confusing/frustrating.

 

7.

No, more stable sounds good.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use