SexLab Framework Development

[orcking12]

Would it be possible to implement a check functionality in between certain sex stages. For example take a foreplay animation as the animation moves from cuddling to fondling or something the player gets a prompt on rather He/She wishes to allow the scene to advance. Then so forth as it moves to oral and/or on to vaginal. Also an implementation were the Player can make certain comments during sex scenes based on the sitation like please stop, keep going, don't cum here, cum here.

[TheDudeGuy]

Would it be possible to implement a check functionality in between certain sex stages. For example take a foreplay animation as the animation moves from cuddling to fondling or something the player gets a prompt on rather He/She wishes to allow the scene to advance. Then so forth as it moves to oral and/or on to vaginal. Also an implementation were the Player can make certain comments during sex scenes based on the sitation like please stop, keep going, don't cum here, cum here.

This can already be done by registering for StageStart / StageEnd. I stop my kissing Animation after stage 2,for instance. This is something that will have to be up to individual SL developers and not part of the core framework.

[xiba]

Hello guys! Still new to the Sexlab Framework. Just reinstalled Skyrim and gonna give this a go.
Unfortunatly i cant seem to find a Compatibility topic. So...I ask here now:
What is, and what is not compatible with Sexlab? what can i use safely with it? Needs mod, Winterfall, and Wet and cold, and the immersion mods people often use...

Cheers Xiba

[Arizona_Steve]

So I'm running into the very occasional issue that a SexLab thread is being closed before my AnimationEnd event handler can pull the actor list via HookActors(), resulting in an empty array being returned.

 

I think the best solution would be to return the actor form IDs as part of a comma delimited string in the second parameter of the event handler (this currently seems to return only the thread ID). I believe this was the mechanism used in earlier versions of SexLab/SexiS and at least ensures that the actors can still be retrieved even if the thread gets closed before the AnimationEnd event gets processed.

[Ashal]

So I'm running into the very occasional issue that a SexLab thread is being closed before my AnimationEnd event handler can pull the actor list via HookActors(), resulting in an empty array being returned.

 

I think the best solution would be to return the actor form IDs as part of a comma delimited string in the second parameter of the event handler (this currently seems to return only the thread ID). I believe this was the mechanism used in earlier versions of SexLab/SexiS and at least ensures that the actors can still be retrieved even if the thread gets closed before the AnimationEnd event gets processed.

 

Form IDs are unreliable as they are completely unusable when that form comes from a high load order mod. Very early versions of SexLab did exactly this, passing all the relevant information to the event comma separated in the string, but people ran into issues with that which is why it was changed. Not to mention having to do string parsing on every single hook event would be noticeably orders of magnitude slower for Papyrus to parse than simply returning them from the thread like it does now.

 

Breaking high load order actors and having slower hooks isn't a worthwhile tradeoff just for a more consistent AnimationEnd in my opinion.

 

Hook onto an earlier event like OrgasmEnd, or pull it with as little latency as possible early on in the event, or better yet store the actors and threads separately in your own script as their animations are started rather than relying on them still being present after AnimationEnd.

 

Honestly the only Hook command people should be using is HookController(), you can access all the information the others provide through the controller faster, without having to use the  Hook functions as a middleman. Only reason I've left them in is for legacy support.

 

And in any case; SexLab already waits 2 full seconds after sending the AnimationEnd hook, that should be plenty of time for most events to grab what they need before it's cleared, it should only be a problem in circumstances of the user experiencing significant script lag.

[Arizona_Steve]

Fair enough, I've seen issues with actors with negative IDs (0x80000000 and above), but I recall that was solved in SexiS somewhere so that the Actors could be retrieved correctly. It even worked with temporary (0xFFxxxxxx) actors. I'll dig around the code sometime and see if I can find it.

[gooser]

Hello guys! Still new to the Sexlab Framework. Just reinstalled Skyrim and gonna give this a go.

Unfortunatly i cant seem to find a Compatibility topic. So...I ask here now:

What is, and what is not compatible with Sexlab? what can i use safely with it? Needs mod, Winterfall, and Wet and cold, and the immersion mods people often use...

 

Cheers Xiba

 

Xiba,

 

I don't think there is any formal compatibility matrix for SexLab. I think others have answered your question in this forum.

[Ashal]

Fair enough, I've seen issues with actors with negative IDs (0x80000000 and above), but I recall that was solved in SexiS somewhere so that the Actors could be retrieved correctly. It even worked with temporary (0xFFxxxxxx) actors. I'll dig around the code sometime and see if I can find it.

 

SexiS doesn't do anything about it.

 

SexiSSystemScr, line 1078:

String args = offActors[id].GetFormID() + "," + defActors[id].GetFormID() + "," + rapi + "," + pairAnims[id] + "," + stage + "," + sexType[id]
Debug.Trace( "SexiS: Pair " + id + " [" + offActors[id].GetFormID() + "," + defActors[id].GetFormID() + "] - SendModEvent( " + eventName + " ) = " + args )
SendModEvent( eventName, args, 6 )

Short of an SKSE plugin to handle the functionality GetFormID() and GetForm() differently, I very much doubt there is anything can be done about it simply due to the nature of Papyrus. And regardless, even if there were a solution I'd see little use in switching to it, as it'd still be a slower solution than simply returning them from the thread due to string parsing.

 

 

 

Eat My Hat Edit:

Actually looks like SexiS does handle it in a way, though I can't vouch for it's efficacy, the problem of slowness and poor trade off remains.

 

SexiSUtilScr, line 109

int Function ParseInt( String str )
	int sum = 0
	int len = StringUtil.GetLength( str )
	bool negative = len > 0 && StringUtil.GetNthChar( str, 0 ) == "-"
	int loop = 0
	if negative
		loop = 1
	EndIf
	String chr
	while loop < len
		chr = StringUtil.GetNthChar( str, loop )
		sum = sum * 10 + ( StringUtil.AsOrd( chr ) - 48 )
		loop += 1
	EndWhile
	if negative
		sum = -sum
	EndIf
	return sum
EndFunction

[selinoria]

Request a groping animation using HTD physics extensions,

 

also more rape-y animations like one of the current ones, cant recall its name but involves attacker dragging victim on their back and pulling them towards them.. more stuff like that.. since it was awesome.. 

[Arizona_Steve]

 

 

 

Fair enough, I've seen issues with actors with negative IDs (0x80000000 and above), but I recall that was solved in SexiS somewhere so that the Actors could be retrieved correctly. It even worked with temporary (0xFFxxxxxx) actors. I'll dig around the code sometime and see if I can find it.

 
SexiS doesn't do anything about it.

SexiSSystemScr, line 1078:

String args = offActors[id].GetFormID() + "," + defActors[id].GetFormID() + "," + rapi + "," + pairAnims[id] + "," + stage + "," + sexType[id]
Debug.Trace( "SexiS: Pair " + id + " [" + offActors[id].GetFormID() + "," + defActors[id].GetFormID() + "] - SendModEvent( " + eventName + " ) = " + args )
SendModEvent( eventName, args, 6 )

Short of an SKSE plugin to handle the functionality GetFormID() and GetForm() differently, I very much doubt there is anything can be done about it simply due to the nature of Papyrus. And regardless, even if there were a solution I'd see little use in switching to it, as it'd still be a slower solution than simply returning them from the thread due to string parsing.

 

 

 

Eat My Hat Edit:
Actually looks like SexiS does handle it in a way, though I can't vouch for it's efficacy, the problem of slowness and poor trade off remains.

 

SexiSUtilScr, line 109

int Function ParseInt( String str )
	int sum = 0
	int len = StringUtil.GetLength( str )
	bool negative = len > 0 && StringUtil.GetNthChar( str, 0 ) == "-"
	int loop = 0
	if negative
		loop = 1
	EndIf
	String chr
	while loop < len
		chr = StringUtil.GetNthChar( str, loop )
		sum = sum * 10 + ( StringUtil.AsOrd( chr ) - 48 )
		loop += 1
	EndWhile
	if negative
		sum = -sum
	EndIf
	return sum
EndFunction

 

 

 

No worries Ashal, I'll handle it on my side.

 

[tase]

Has anything been found out about the bug that makes the game crash when you try to save after a SexLab animation with Auto TFC turned on ?

[Ashal]

only that people are completely incapable of reading the hundreds of posts/threads saying to make sure they disable tfc before the end of an animation.

[AwfulArchdemon]

There is a support topic thread for problem solving if you have issues in general involving SexLab's framework.

 

 

 

It is here

( http://www.loverslab.com/topic/22241-sexlab-support-troubleshooting-guide-read-me-first/ )

 

FAQ's

[Ashal]

So I decided to set aside a block of time tonight to do a deeper investigation of all the TFC related crashes that happen when saving or using a door after sex.

 

Here's my findings:

 

I removed every "non-essential" system SexLab has during animation except for actor animation playing and positioning, then added them back one by one, in between each doing a quick solo animation with auto-TFC on and then quicksaving as soon as the animation ends to see if it crashes. I was 100% crash free up until I added back moaning. To confirm I fully added back everything except moaning, and it went back to not crashing, added it back; crash. So I repeated the process again, only this time adding back in pieces of the moaning system one by one until I got crashes again.

 

I am now reasonably certain that the TFC crashes are directly related to the lip syncing of the moans.

• Playing the moan audio and the lip sync - Crash.
• Playing just the moan audio - No crash.
• Playing just the lip sync with no audio - Crash.

 

TL;DR:  Fairly likely that the crash on save and entering doors bug will be fixed in the next version of SexLab, at the expense of lip sync moans being skipped while in free camera.

 

I will also likely release a new version in a day or two ahead of the planned 1.40 update, that contains this fix and a handful of others, mainly just to shut up the endlessly annoying bitching from people who keep reporting it.

[shinji72]

Hi ashal. Two question.
1) When in tfc, now and after this coming update, you don't see any lip synch and expressions, right?

2) There is any difference (in stability) by using the framework proprietary TFC or another mod TFC?

 

Well, I regret the constant bitching... but I'm happy about the upcoming update!

 

[AwfulArchdemon]

Hi ashal. Two question.

1) When in tfc, now and after this coming update, you don't see any lip synch and expressions, right?

2) There is any difference (in stability) by using the framework proprietary TFC or another mod TFC?

 

Well, I regret the constant bitching... but I'm happy about the upcoming update!

 

 

There is a support topic thread for problem solving if you have issues in general involving SexLab's framework.

 

 

 

It is here

( http://www.loverslab...shooting-guide-read-me-first/ )

 

FAQ's

 

 

 

[Redflyingmonkey]

 

So I decided to set aside a block of time tonight to do a deeper investigation of all the TFC related crashes that happen when saving or using a door after sex.

 

Here's my findings:

 

I removed every "non-essential" system SexLab has during animation except for actor animation playing and positioning, then added them back one by one, in between each doing a quick solo animation with auto-TFC on and then quicksaving as soon as the animation ends to see if it crashes. I was 100% crash free up until I added back moaning. To confirm I fully added back everything except moaning, and it went back to not crashing, added it back; crash. So I repeated the process again, only this time adding back in pieces of the moaning system one by one until I got crashes again.

 

I am now reasonably certain that the TFC crashes are directly related to the lip syncing of the moans.

• Playing the moan audio and the lip sync - Crash.
• Playing just the moan audio - No crash.
• Playing just the lip sync with no audio - Crash.

 

TL;DR:  Fairly likely that the crash on save and entering doors bug will be fixed in the next version of SexLab, at the expense of lip sync moans being skipped while in free camera.

 

I will also likely release a new version in a day or two ahead of the planned 1.40 update, that contains this fix and a handful of others, mainly just to shut up the endlessly annoying bitching from people who keep reporting it.

 

 

So it was an issue with the mfg console right ? Is it a conflict between two console commands used at the same time ? Like, basically what lip sync does is composing a console command line with the mfg modifier stuff right ? 

Trying to understand stuff, I've been wondering about this and I noticed I didn't crash before with tfc activated after I manually put a mfg preset on my character. 

[Ashal]

No, the lip sync stuff just uses Skyrims built in system for doing lip sync on dialog.

[dje34]

No, the lip sync stuff just uses Skyrims built in system for doing lip sync on dialog.

 

How could a lip sync do have some conflict with a flying camera ?!

 

I mean, there should be something somewhere in the source code with a function for the lip sync and another one for the free camera doing something they shouldn't do, they may be coded by some rushed developer who didn't see there would be a problem somewhere! that's for sure ! Is there a way to get a trace/tracking of what is happening ? Like with papyrus ?

[WaxenFigure]

So I decided to set aside a block of time tonight to do a deeper investigation of all the TFC related crashes that happen when saving or using a door after sex.

 

Here's my findings:

 

I removed every "non-essential" system SexLab has during animation except for actor animation playing and positioning, then added them back one by one, in between each doing a quick solo animation with auto-TFC on and then quicksaving as soon as the animation ends to see if it crashes. I was 100% crash free up until I added back moaning. To confirm I fully added back everything except moaning, and it went back to not crashing, added it back; crash. So I repeated the process again, only this time adding back in pieces of the moaning system one by one until I got crashes again.

 

I am now reasonably certain that the TFC crashes are directly related to the lip syncing of the moans.

• Playing the moan audio and the lip sync - Crash.
• Playing just the moan audio - No crash.
• Playing just the lip sync with no audio - Crash.

 

TL;DR:  Fairly likely that the crash on save and entering doors bug will be fixed in the next version of SexLab, at the expense of lip sync moans being skipped while in free camera.

 

I will also likely release a new version in a day or two ahead of the planned 1.40 update, that contains this fix and a handful of others, mainly just to shut up the endlessly annoying bitching from people who keep reporting it.

 

Does it crash with the MFG Expressions module uninstalled?  In other words is this crash a conflict between lip syncing and the expressions?

 

[Ashal]

 

So I decided to set aside a block of time tonight to do a deeper investigation of all the TFC related crashes that happen when saving or using a door after sex.

 

Here's my findings:

 

I removed every "non-essential" system SexLab has during animation except for actor animation playing and positioning, then added them back one by one, in between each doing a quick solo animation with auto-TFC on and then quicksaving as soon as the animation ends to see if it crashes. I was 100% crash free up until I added back moaning. To confirm I fully added back everything except moaning, and it went back to not crashing, added it back; crash. So I repeated the process again, only this time adding back in pieces of the moaning system one by one until I got crashes again.

 

I am now reasonably certain that the TFC crashes are directly related to the lip syncing of the moans.

• Playing the moan audio and the lip sync - Crash.
• Playing just the moan audio - No crash.
• Playing just the lip sync with no audio - Crash.

 

TL;DR:  Fairly likely that the crash on save and entering doors bug will be fixed in the next version of SexLab, at the expense of lip sync moans being skipped while in free camera.

 

I will also likely release a new version in a day or two ahead of the planned 1.40 update, that contains this fix and a handful of others, mainly just to shut up the endlessly annoying bitching from people who keep reporting it.

 

Does it crash with the MFG Expressions module uninstalled?  In other words is this crash a conflict between lip syncing and the expressions?

 

 

No, the MFG stuff has no effect on it, and the bug has existed long before the MFG stuff was ever implemented. It's just highlighted now because of the TFC hotkey.

[WaxenFigure]

 

No, the lip sync stuff just uses Skyrims built in system for doing lip sync on dialog.

 

How could a lip sync do have some conflict with a flying camera ?!

 

I mean, there should be something somewhere in the source code with a function for the lip sync and another one for the free camera doing something they shouldn't do, they may be coded by some rushed developer who didn't see there would be a problem somewhere! that's for sure ! Is there a way to get a trace/tracking of what is happening ? Like with papyrus ?

 

 

One of the complaints is that lip syncing and expressions are not happening when the flying camera is on.  There is definitely some sort of conflict between the two but figuring out the how/where is the problem since there's no accessing the Bethesda code.

[WaxenFigure]

 

 

So I decided to set aside a block of time tonight to do a deeper investigation of all the TFC related crashes that happen when saving or using a door after sex.

 

Here's my findings:

 

I removed every "non-essential" system SexLab has during animation except for actor animation playing and positioning, then added them back one by one, in between each doing a quick solo animation with auto-TFC on and then quicksaving as soon as the animation ends to see if it crashes. I was 100% crash free up until I added back moaning. To confirm I fully added back everything except moaning, and it went back to not crashing, added it back; crash. So I repeated the process again, only this time adding back in pieces of the moaning system one by one until I got crashes again.

 

I am now reasonably certain that the TFC crashes are directly related to the lip syncing of the moans.

• Playing the moan audio and the lip sync - Crash.
• Playing just the moan audio - No crash.
• Playing just the lip sync with no audio - Crash.

 

TL;DR:  Fairly likely that the crash on save and entering doors bug will be fixed in the next version of SexLab, at the expense of lip sync moans being skipped while in free camera.

 

I will also likely release a new version in a day or two ahead of the planned 1.40 update, that contains this fix and a handful of others, mainly just to shut up the endlessly annoying bitching from people who keep reporting it.

 

Does it crash with the MFG Expressions module uninstalled?  In other words is this crash a conflict between lip syncing and the expressions?

 

 

No, the MFG stuff has no effect on it, and the bug has existed long before the MFG stuff was ever implemented. It's just highlighted now because of the TFC hotkey.

 

 

Good, I like the MFG mod and would hate to have to run it back.

 

 

[dje34]

 

 

No, the lip sync stuff just uses Skyrims built in system for doing lip sync on dialog.

 

How could a lip sync do have some conflict with a flying camera ?!

 

I mean, there should be something somewhere in the source code with a function for the lip sync and another one for the free camera doing something they shouldn't do, they may be coded by some rushed developer who didn't see there would be a problem somewhere! that's for sure ! Is there a way to get a trace/tracking of what is happening ? Like with papyrus ?

 

 

One of the complaints is that lip syncing and expressions are not happening when the flying camera is on.  There is definitely some sort of conflict between the two but figuring out the how/where is the problem since there's no accessing the Bethesda code.

 

 

Yup, I know that bug... weird thing is that it is happening in animcam and sometimes with the 3rd person view too... there must be something really wrong between the two as nothing seems to solve the problem even the mods customizing the cameras and improving lip sync can't do anything about it... maybe some sort of partial/complete rewrite of one of them would do the trick... or both.

[Dayelyte]

Hey Ashal,  slightly off topic question for you but one only you code guru's can answer. 

 

For animation purposes, it's possible to determine the gender of the actors when they are human.  Is this functionality available to the critter world ?  I know of no means, outside of the mesh any given critter is wearing, to determine the gender of a critter considering the skeletons of the critters ( and all meshes unless they are custom ) are pretty much gender neutral. 

 

If I can ever get the damned export to play correctly within Skyrim, I've been playing with the Werewolf models in Max, but the thought occurred to me that, from a scripting perspective, it may not be possible to differentiate between the two genders.  Which would make certain animations a bit, wierd ( for lack of a better word ) if run on a gender the animation wasn't designed for. 

 

Thoughts ?