SexLab Framework Development

[mainfct]

A quick question and possible suggestion. I was trying to figure a way to detect which cum shader is currently applied on an Actor. After browser the Framework's code, I realized that it was applied directly by playing the shader, instead of casting a spell effect that apply the shader. There is a condition function (Actor.HasMagicEffect(theMagicEffect) or HasMagicEffectKeyword) to detect if a magic effect is currently on an actor, but I don't see any way to detect the presence of a shader. Also, that might explain why it sometimes disappear early when another shader overwrites it.

So the question is: Is there a way to detect the current shader and if not, perhaps if would be good to wrap the shader in a spell effect and cast the spell instead. Was it done with direct shader for performance issue or is there something else I don't see?

 

Thanks

[Someone92]

When I tested my SexLabZzz mod out and randomly shot "Masturbation" on random NPCs. One NPC was killed during their SexLab animation. Then multiple times a message box with "SexLabAnimEnd found" and "Ok" popped up.

[Ashal]

When I tested my SexLabZzz mod out and randomly shot "Masturbation" on random NPCs. One NPC was killed during their SexLab animation. Then multiple times a message box with "SexLabAnimEnd found" and "Ok" popped up.

 

Nothing in SexLab itself displays any such message. Or even uses Debug.MessageBox() for that matter.

 

Most likely another mod you have installed that's doing it.

[Aramiteus]

Hi Ashal,

 

I've made a small "Join in" mod but unfortunatelly had to make a small change to your code to get it work and therefore do not want  to publish it.

Basic concept: PC Walking up one or two persons doing it (started for example via random attack) and ask to join in. (till now will receive an "Of course"-answer :-) )

My request:

I Need a "stay naked" flag (not only for the aggressive anims).

My changes were minor but nevertheless I post them to avoid work to be done twice:

scriptname SexLabFramework extends Quest
...
bool property stayNaked = False auto
...
function UnstripActor(actor a, form[] stripped, actor victim = none)
	int i = stripped.Length
	if i < 1
		_DebugTrace("EquipStrapon","actor="+a+", stripped="+stripped+", victim="+victim,"No items passed to stripped argument for actor to equip")
	endIf
	if stayNaked == True
		return
	endif
...

My usage then:

; only posting the essential lines to clarify the intention
...
SexLab.stayNaked = True
...
	equipment0 = sexThread.GetEquipment(oldSexActors[0])
...
	sexThread.EndAnimation(quick = true) 
...
        sexlabReturn = SexLab.StartSex(sexActors,anims)
...
        sexThread.StoreEquipment(newSexActors[index], equipment0)

Sorry for using all that unofficial non interface functions. (Another reason for not publishing it, because of eventual future changes to them, but for me this is also a feasability study)

First I've tried "function ChangeActors(actor[] changeTo)" but got weired results: (PC stuck without controlls etc)

 

Besides great Framework. It is very easy to use and to understand (good code). It took me only one evening to implement it.

 

 

 

[Menesh]

A small issue: SexLab animations are sometimes overwritten by a clapping/ cheering animation if there's a bard playing music around.

 

Also, after upgrading to the latest version my character started suddenly taking off her body armor some time after having sex and traveling the wilderness. I'm still trying to confirm if that's related to SexLab or result of some weird conflict, though.

This is my current load order. I also had "Another Sleep Mod" active when I experienced the undressing, but non of these mods mess with player equipment except SexLab and maybe SoS (my char's female, though).

 

 

 

00  Skyrim.esm
01  Update.esm
02  Dawnguard.esm
03  HearthFires.esm
04  Dragonborn.esm
05  ApachiiHair.esm
06  Schlongs of Skyrim - Core.esm
07  SexLab.esm  [Version 1.14]
08  Skyrim - Director's Cut.esp  [Version 3.0]
09  Malachit zu Vulkanglas.esp
0A  Brawl Bugs CE.esp
0B  Unofficial Skyrim Patch.esp  [Version 1.3.2c]
0C  Unofficial Dawnguard Patch.esp  [Version 1.2.2]
0D  Unofficial Hearthfire Patch.esp  [Version 1.1.1]
0E  Unofficial Dragonborn Patch.esp  [Version 1.0.4]
0F  TradeBarter.esp
10  LoversHook.esp
11  SexLab Submit.esp
12  SexLab Romance.esp
13  LoversComfort.esp
14  SexLab Theft and Seduction.esp
15  SexLab Solutions.esp
16  TouringCarriages.esp
17  SkyUI.esp
18  NobleFemaleClothes.esp
19  Raven Set v1.4.esp
1A  theRoadstrokersRogueSorceress.esp
1B  TrissArmorRetextured.esp
1C  GuardianStonesStash.esp
1D  Inconsequential NPCs.esp
1E  Northern Bathhouses.esp
1F  Headtracking.esp
++  Hoodless Archmage - OE.esp
20  Schlongs of Skyrim.esp
21  SOS - VectorPlexus Regular Addon.esp
22  SOS - Smurf Average Addon.esp
++  SOS - Dawnguard Armors.esp
++  SOS - Dragonborn Armors.esp
23  Unique Region Names - Dragonborn.esp  [Version 1.1]
24  FNISspells.esp
25  Dual Wield Parrying_SKSE.esp
26  AzarHair.esp
27  Kashim.esp
28  dD - Realistic Ragdoll Force - Realistic.esp
29  Unique Region Names.esp  [Version 5]
2A  Bashed Patch, 0.esp
2B  Bards&Merchants.esp
2C  OpulentOutfitsV2Universal.esp

 

[Someone92]

How do I get the .GetHook() function to work? If I type SexLab.GetHook(argString) the compiler says "GetHook is not a function or does not exist".

edit:
sslThreadModel property ThreadModel Auto Hidden
ThreadModel.GetHook()

 

 

 

edit2:

Suggestions for the Option Highlight Text of animations:

- Include info for how many actors, how many females and how many males the animation was intended.

- Include a short description of the animation; if you want I can do that.

I think using a similar notation as the notation as the .GetAnimationsByType function (e.g. for a vanilla sex animation it would be "actors=2, males=1, females=1", for an anal penetration animation it would be "actors=2, males=1+, females=0+" (because the receiver could be of both sexes)) would be best; that why it would be possible to use two lines to describe an animation.

[Cululu]

Request a Virgin blood effect.

It might be hard to track all the female NPCs, but for female player I think this is possible.

An alternative cum texture mix with blood for first time penetrating sex would be nice for virgins. Also, give virgins a simple buff so they are more attractive or something. 

[Someone92]

The .getHook() function doesn't require an argument; how does SexLab knows from which animation I want to get the hook when there are multiple ongoing without passing the argString?

[Ashal]

The .getHook() function doesn't require an argument; how does SexLab knows from which animation I want to get the hook when there are multiple ongoing without passing the argString?

 

Because you call it on a specific instance of sslThreadController/Model, not on the raw version of the script. There's 15 Threads, each one maintains it's own variables on a running animation.  This is what makes SexLab work with multiple scenes at once without relying on magic effects and tokens, as most similar mods do.

 

For example, in a hook event, if you called SexLabFramework.HookController(argString) you'd return the specific controller handling the animation you hooked in sslThreadController form. So calling GetHook() on that returned controller, returns the hook string used on that animation.

 

 

[Someone92]

Because you call it on a specific instance of sslThreadController/Model, not on the raw version of the script. There's 15 Threads, each one maintains it's own variables on a running animation.  This is what makes SexLab work with multiple scenes at once without relying on magic effects and tokens, as most similar mods do.

 

For example, in a hook event, if you called SexLabFramework.HookController(argString) you'd return the specific controller handling the animation you hooked in sslThreadController form. So calling GetHook() on that returned controller, returns the hook string used on that animation.

So like this:

a = SexLabFramework.HookController(argString)
hook= a.GetHook()

?

 

 

 

 

[Ashal]

more like 

function DoSex()
	RegisterForModEvent("AnimationEnd_MatchMaker", "EndMessage")
	SexLab.StartSex(sexActors, animations, hook="MatchMaker")
endFunction

event EndMessage(string eventName, string argString, float argNum, form sender)
	sslThreadController Controller = SexLab.HookController(argString)
	string hook = Controller.GetHook() ; // Returns MatchMaker
	Debug.MessageBox(hook)
endEvent

[Someone92]

Thanks for that.

 

One of my questions I wanted to ask has already been answered here: http://www.loverslab.com/topic/19778-how-to-disable-foreplay-temporarily-the-right-way/

Another similar question: Is there a way to disable the disrobe animation for a single SexLab animation, maybe just for specific actors?

[Ashal]

I've started the process of updating the wiki with the latest changes and functions. The main thing is the new thread system that replaces sslBaseThread; it's a lot of functions though to make pages for, so may take some time. Also going to write a guide on using NewThread() instead of StartSex() to accompany these functions.

 

Have finished filling out the main directories, the function explanation pages will take awhile to finish filling out, but using the listing of functions with their description, and abit of browsing the scripts themselves to see their arguments should make most things clear until then.

 

http://git.loverslab.com/sexlab/wikis/function-newthread

http://git.loverslab.com/sexlab/wikis/sslthreadmodel-script

http://git.loverslab.com/sexlab/wikis/sslthreadcontroller-script

[Someone92]

Are all the new functions hidden in the sslThreadModel script or also in other scripts?

[DovahTroll]

Hi! is there any double penetration animation in the SexLab Framework? If not, are you planning to include that in a future update?

[sammythesquirrel]

Hi! is there any double penetration animation in the SexLab Framework? If not, are you planning to include that in a future update?

best place to look for that would be here http://www.loverslab.com/topic/15293-arroks-ssl-tbbp-animations-resource-for-modders-updated-6202013/?hl=arrok%26%2339%3Bs as arrok is to my knowledge the most active animator we have for human animations most if not all of his work usually finds its way into the main sexlab files 

[canthics]

Been a while, just thought I'd upload what I've been using to test dummy actor spawning.

 

Simply a modified version of matchmaker, just use the "smart" spell.

 

does improve scene placement, but is not 100% effective. in some cases the dummy actor itself will not spawn in a good spot where there's a lot of clutter.

 

also, the scene is still liable to get havoked after it's started. stage switching is also an issue. a scene may be collision free when it starts, but the offset collision boxes are all over the place when going from stage to stage, foreplay to main event, etc. other than repositioning the scene for each animation switch (ugly) or reworking animations to standardize offsets (hard?), I don't see a way around this right now.

 

I've kept the dummy actor flickering before it deletes itself for testing purposes. I'm using the mudcrab mesh right now and it seems to give good results, but I think the idea would really be much more effective if we used an actor mesh that was tailor-made for this purpose. as far as potential bloat it concerned, I think we're in the clear, as even vanilla scripts like bookshelves make liberal use of placeat() so it shouldn't break things anymore than they are already broken in skyrim (maybe not saying much).

 

it seems that it's really not possible to make actors unpushable through things like havok motion type. I also tried the translateto() exploit to try and remove collision boxes, but it was no go as well. these things are off-topic from what the dummy actor is supposed to do, though.

 

bottom line, something like this will help, but it's not going to be an end-all for collision problems.

 

edit: integrating with marker-spawning for walk-to should be pretty simple. the actor itself is pretty much deleted immediately, leaving just the center coordinates. you can spawn offset markers based off that center without even considering the actor.

MatchmakerExperimental.7z

[WaxenFigure]

 

 

Been a while, just thought I'd upload what I've been using to test dummy actor spawning.

 

Simply a modified version of matchmaker, just use the "smart" spell.

 

does improve scene placement, but is not 100% effective. in some cases the dummy actor itself will not spawn in a good spot where there's a lot of clutter.

 

also, the scene is still liable to get havoked after it's started. stage switching is also an issue. a scene may be collision free when it starts, but the offset collision boxes are all over the place when going from stage to stage, foreplay to main event, etc. other than repositioning the scene for each animation switch (ugly) or reworking animations to standardize offsets (hard?), I don't see a way around this right now.

 

I've kept the dummy actor flickering before it deletes itself for testing purposes. I'm using the mudcrab mesh right now and it seems to give good results, but I think the idea would really be much more effective if we used an actor mesh that was tailor-made for this purpose. as far as potential bloat it concerned, I think we're in the clear, as even vanilla scripts like bookshelves make liberal use of placeat() so it shouldn't break things anymore than they are already broken in skyrim (maybe not saying much).

 

it seems that it's really not possible to make actors unpushable through things like havok motion type. I also tried the translateto() exploit to try and remove collision boxes, but it was no go as well. these things are off-topic from what the dummy actor is supposed to do, though.

 

bottom line, something like this will help, but it's not going to be an end-all for collision problems.

 

edit: integrating with marker-spawning for walk-to should be pretty simple. the actor itself is pretty much deleted immediately, leaving just the center coordinates. you can spawn offset markers based off that center without even considering the actor.

 

 

Back when I was actively working on SexAddicts I considered the possibility of creating an invisible cage (or a cage where only the flat floor is visible) and placing the actors inside the cage to keep the other NPCs from walking through or worse yet standing right on top of the sex animation.

[Ashal]

Been a while, just thought I'd upload what I've been using to test dummy actor spawning.

 

Simply a modified version of matchmaker, just use the "smart" spell.

 

does improve scene placement, but is not 100% effective. in some cases the dummy actor itself will not spawn in a good spot where there's a lot of clutter.

 

also, the scene is still liable to get havoked after it's started. stage switching is also an issue. a scene may be collision free when it starts, but the offset collision boxes are all over the place when going from stage to stage, foreplay to main event, etc. other than repositioning the scene for each animation switch (ugly) or reworking animations to standardize offsets (hard?), I don't see a way around this right now.

 

I've kept the dummy actor flickering before it deletes itself for testing purposes. I'm using the mudcrab mesh right now and it seems to give good results, but I think the idea would really be much more effective if we used an actor mesh that was tailor-made for this purpose. as far as potential bloat it concerned, I think we're in the clear, as even vanilla scripts like bookshelves make liberal use of placeat() so it shouldn't break things anymore than they are already broken in skyrim (maybe not saying much).

 

it seems that it's really not possible to make actors unpushable through things like havok motion type. I also tried the translateto() exploit to try and remove collision boxes, but it was no go as well. these things are off-topic from what the dummy actor is supposed to do, though.

 

bottom line, something like this will help, but it's not going to be an end-all for collision problems.

 

edit: integrating with marker-spawning for walk-to should be pretty simple. the actor itself is pretty much deleted immediately, leaving just the center coordinates. you can spawn offset markers based off that center without even considering the actor.

 

Do you know of any good cluttered spots to test it in?

 

I started experimenting with a more direct implementation of this. Instead of an actor I'm using a MoveableStatic in the form of an oil barrel instead of a static, as they are simpler objects than actors/creatures and are still affected by havok.

 

It spawns and places well enough, although scaling to match the actors is a bit of a problem, as you can't scale it before doing placeatme, you have to spawn it with placeatme, scale it, then use moveto. However, moveto doesn't respect the same location rules placeatme seems to, instead opting place it directly where the center object, pushing the actor out of the way as there's now a barrel in their way.

 

I'm thinking maybe one of the wooden plank meshes would work better as the placed object, as it'd be a long object and orient itself in a way that would hopefully result in a z-rotation that would better match with 2 actors laying flat on their back

 

Atleast that's how it seemed in my very light testing, I couldn't find any good testing spots in towns that gave me a good sense of it helping or not.

[Adam Jensen]

Ashal with all due respect, how stable is the latest Sexlab version? I'm about to make a new save file and I want to know if I should get the latest version of sexlab while I am at it. Thing is, I'm still running 1.1 and it works smoothly. 

[Ashal]

Ashal with all due respect, how stable is the latest Sexlab version? I'm about to make a new save file and I want to know if I should get the latest version of sexlab while I am at it. Thing is, I'm still running 1.1 and it works smoothly. 

 

And with all due respect, they've all been very stable for me and many others. If your having stability issues it's almost certainly more related to your install process or interactions with other mods. I myself haven't had a crash directly related to SexLab since Rev 2. I can't speak to your Skyrim install however, install it and find out for yourself.

[Adam Jensen]

 

Ashal with all due respect, how stable is the latest Sexlab version? I'm about to make a new save file and I want to know if I should get the latest version of sexlab while I am at it. Thing is, I'm still running 1.1 and it works smoothly. 

 

And with all due respect, they've all been very stable for me and many others. If your having stability issues it's almost certainly more related to your install process or interactions with other mods. I myself haven't had a crash directly related to SexLab since Rev 2. I can't speak to your Skyrim install however, install it and find out for yourself.

 

 

Oh it's just that I had heard that there have been some trouble with .11 was it? I was afraid that it could cause some issues, but if things are working smoothly, then I'll take the opportunity to upgrade it.

[canthics]

I test mainly in the bannered mare.  Lots of NPCs (I'm running some NPC mods that make it more crowded) and clutter, varied rooms at different levels, stairs, furniture interactions and also moveable doors to test havok interactions (trigger a scene near that back room door and you can see the NPCs get pushed around when you open or close it).

 

The problem with the method you describe is that the meat of this hack are the collision checks that only placeatme uses. Moveto defeats the point of the exercise altogether because it does not collision check automatically, it merely shoves the object into the designated coordinates and lets havok sort things out, which is actually what's causing a lot of the misalignment problems right now.

 

I have not tested use of moveable statics thoroughly, mainly just experimented with different objects through the console.  The problem I see is that placeatme does not do z-level checks the same way it does with actors, i.e. actors will always be placed on the ground or on top of a nearby surface if there is no other space, whereas statics can spawn midair and drop to the ground, or stack on top of one another. Since we're doing this to position actors which use a different set of collision mechanics and physics than even dynamic statics, using the same type of object as seen by the engine would probably be the safest bet. I've not run into performance issues with the spawning; I imagine in extreme situations where you have like a dozen scenes triggering simultaneously, there may be some lag similar to what you see in spawn increaser mods.

 

As far as scaling goes, I've only been using prescaled actors in the CK and tending toward larger meshes to check as much clear space as possible.  If moveable statics are placing correctly (I still think it's iffier than just using actors) and you can't adjust their scale in the CK, it's really just a question of cobbling together a mesh that has the right dimensions.

[canthics]

One other alignment tweak that was mentioned before was continually enforcing actor positions to keep them from getting knocked out of alignment. right now it's just a hamfisted version of waxenfigure's method (no movedistance check).

 

I've actually tested running moveactors constantly while a scene is running with mixed results.  It's effective for keeping things aligned when it's just an isolated havok hiccup that knocks the scene out of alignment, but with more persistent problems like furniture collisions, actors will bounce or vibrate as they are constantly getting pushed out and back into position (heh).

 

I mention this because I did a lot of testing with the dummy actor script using this tweak, and now that I've disabled it the incidences where the smart placement still doesn't prevent alignment problems arenmore frequent. On the other hand, this does mean that both these do work well together to reduce the wtf-so-off scenes significantly.

[mainfct]

Hi, I've been writing a new mod that take advantage of the new thread controller, specifically the endanimation() function to break an anim prematurely. However, I get an unreliable behavior: sometimes the animation ends and all actor resets but most of the time they continue animating forever, even though the animation scene has ended. I've looked the log report and I get the following

 

[08/02/2013 - 08:47:41PM] ERROR: Cannot access an element of a None array

stack:

[sexLabController (0B030196)].sslthreadview00.ResetActor() - "sslThreadController.psc" Line 604

[sexLabController (0B030196)].sslthreadview00.Reset_Actor() - "sslThreadController.psc" Line 835

[08/02/2013 - 08:47:41PM] ERROR: Cannot push back a None actor

stack:

[ (00000014)].Actor.PushActorAway() - "<native>" Line ?

[sexLabController (0B030196)].sslthreadview00.ResetActor() - "sslThreadController.psc" Line 604

[sexLabController (0B030196)].sslthreadview00.Reset_Actor() - "sslThreadController.psc" Line 835

 

 

 

Just thought I'd let you know in case it's an issue with the Thread Controller, as it appears to be.