SexLab Framework Development

[Goubo]

It's hard to tell really but your proposition sound good to me yes, bandits should have a low morality already anyway so it should be automatically rarer for them.

 

But you should make the probabilities configurable by the user, easiest way.

[t3h0th3r]

What's New Since 1.60:

• Some other stuff I've forgotten
• Various bug fixes

 

I don't suppose one of those contains the handling of NiOverride high heels (skimmed over the code, but haven't seen it, it could be because I'm blind though )? Not to stress or pester you about it, just to know for what versions my patch will become obsolete, so I can pull it.

 

Also: Is there a hookable event for only the first stage that plays after LeadInEnd? As it seems there's no AnimationEnd/AnimationStart between foreplay and main act. For now it's using a hackish solution that runs on every StageStart...

 

Looking forward for some of the new features, specifically the stacking cum

[Ashal]

 

What's New Since 1.60:

• Some other stuff I've forgotten
• Various bug fixes

 

I don't suppose one of those contains the handling of NiOverride high heels (skimmed over the code, but haven't seen it, it could be because I'm blind though )? Not to stress or pester you about it, just to know for what versions my patch will become obsolete, so I can pull it.

 

Also: Is there a hookable event for only the first stage that plays after LeadInEnd? As it seems there's no AnimationEnd/AnimationStart between foreplay and main act. For now it's using a hackish solution that runs on every StageStart...

 

Looking forward for some of the new features, specifically the stacking cum

 

 

 

3... maybe 4 at least...? Times I've started working on SexLab SPECIFICALLY intending to implement the NiO heel stuff. Every time I end up starting it, copying an approach similar to your patch, I get half way done then think up some weirdly possible scenario in my head where everything broken and I need to rethink how to handle it. 1-2 weeks later, repeat this process as I've completely forgotten why.

 

With the site stability and the revert hopefully under control now though, 1.61 is my next priority and I'll for sure have NiO heel support implemented when official release comes in a week or two. This and async starting animation stages are the two things I absolutely must fix before releasing the official 1.61.

[t3h0th3r]

 

With the site stability and the revert hopefully under control now though, 1.61 is my next priority and I'll for sure have NiO heel support implemented when official release comes in a week or two. This and async starting animation stages are the two things I absolutely must fix before releasing the official 1.61.

 

 

Alright. I can only imagine how busy the new forum software kept you in the last month... Thanks for your hard work btw!

 

has been nagging me to remember you to use SexLab.esm as the modkey for the transforms so skse knows to purge associated transform in the case SexLab is uninstalled while a transform is still applied (something that really shouldn’t happen ever, because that would mean someone saved mid-scene and then uninstalled. aka asking for trouble).

I guess you already knew that about skse, but nevertheless, I have done what was asked of me.

[pipinosgr]

There's still you cant control your werewolf character while intercourse. Will be fixed?

[CliftonJD]

 

 

What's New Since 1.60:

• Some other stuff I've forgotten
• Various bug fixes

 

I don't suppose one of those contains the handling of NiOverride high heels (skimmed over the code, but haven't seen it, it could be because I'm blind though )? Not to stress or pester you about it, just to know for what versions my patch will become obsolete, so I can pull it.

 

Also: Is there a hookable event for only the first stage that plays after LeadInEnd? As it seems there's no AnimationEnd/AnimationStart between foreplay and main act. For now it's using a hackish solution that runs on every StageStart...

 

Looking forward for some of the new features, specifically the stacking cum

 

 

 

3... maybe 4 at least...? Times I've started working on SexLab SPECIFICALLY intending to implement the NiO heel stuff. Every time I end up starting it, copying an approach similar to your patch, I get half way done then think up some weirdly possible scenario in my head where everything broken and I need to rethink how to handle it. 1-2 weeks later, repeat this process as I've completely forgotten why.

With the site stability and the revert hopefully under control now though, 1.61 is my next priority and I'll for sure have NiO heel support implemented when official release comes in a week or two.

This and async starting animation stages are the two things I absolutely must fix before releasing the official 1.61.

 

 

 

is asynch what's causing the animations to stop playing for the new beta version - i was going to log them for you, but apparently there's quite a few of them it would make sense if there's something involved with it more than just certain animations

[Earen]

Hi, Ashal
 

got following crashes two times in hour, which made me think about stability..

>	SexLabUtil.dll!6b2c235c()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for SexLabUtil.dll]	
 	SexLabUtil.dll!6b2c2d7f()	Unknown
 	TESV.exe!00c46e61()	Unknown
 	TESV.exe!00f88004()	Unknown
 	TESV.exe!00a08a5f()	Unknown
 	TESV.exe!00a08d56()	Unknown

Unhandled exception at 0x6B2C235C (SexLabUtil.dll) in 2015-12-11_00.00.00.dmp: 0xC0000005: Access violation reading location 0x00000014.

Plus this one

 	[External Code]	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
>	SexLabUtil.dll!6abb80ce()	Unknown
 	SexLabUtil.dll!6abb6249()	Unknown
 	SexLabUtil.dll!6abc18f9()	Unknown
 	SexLabUtil.dll!6abc194e()	Unknown
 	SexLabUtil.dll!6abc194e()	Unknown

6ABB80B8  ret  
6ABB80B9  push        ebp  
6ABB80BA  mov         ebp,esp  
6ABB80BC  mov         eax,dword ptr ds:[6ABF7A88h]  
6ABB80C1  xor         eax,dword ptr ds:[6ABF04D0h]  
6ABB80C7  push        dword ptr [ebp+8]  
6ABB80CA  je          6ABB80D0  
6ABB80CC  call        eax  
6ABB80CE  pop         ebp  <-- freeze
6ABB80CF  ret  
6ABB80D0  call        dword ptr ds:[6ABD90A0h]  
6ABB80D6  pop         ebp  
6ABB80D7  ret  

I'd looked at it further, but I don't have source code

[Ashal]

Hi, Ashal

 

got following crashes two times in hour, which made me think about stability..

Plus this one

I'd looked at it further, but I don't have source code

 

 

I don't know how to interpt that stuff myself. If you wanna take a look though here's the source + current compiled version with its pdb and such

 

source: plugin_example.zip

dll + pdb: plugins.zip

[Earen]

 

Hi, Ashal

 

got following crashes two times in hour, which made me think about stability..

Plus this one

I'd looked at it further, but I don't have source code

 

 

I don't know how to interpt that stuff myself. If you wanna take a look though here's the source + current compiled version with its pdb and such

 

source: plugin_example.zip

dll + pdb: plugins.zip

 

 

Thanks, I'll look then

 

[Ashal]

Hi Ashal.

Any way you can add the per-animation logic for scaling actors?

Creature animations will really benefit from it.

 

This was I did for 1.60 HF2: Patch to have control on scaling.7z

 

The problem there is it's only checking the scaling flag for the first played animation, so if you start an animation that doesn't have scaling disabled, the flag is meaningless once you switch to an animation mid-scene that does have it enabled. 

 

I'm not really sold on disabling scaling being the solution to the scaling issues with some creatures. Skyrim's engine will forcefully scale an actor when they are attached to a marker, which is why SexLab always "scales" regardless if the even actors height option is checked or not, what that option is really doing is telling sexlab whether or not the actors should have their scale reset to their "normal" scale (disabled) or their "evened" scale (enabled) during a scene every time their marker get's reattached, which is semi-frequent during animation. 

 

I'm sure this is an actual issue, I myself however haven't yet had a good chance to look deeper into the issue myself, as I've never been able to get into a good testing scenario where this would be relevant. Regardless though, I think a more appropriate solution would be creature specific rather than animation specific. 

[Blade_Runner]

Been testing the new beta, very slick! Loved the walk-instead-of-teleport feature, and the new added MCM options. But i'd like to request please, PLEASE, please, for hotkeys to go back animations stages and rotate counter-clockwise, since using the modifier key almost never works (script heavy game? dunno, but surely i'm not the only user with this issue).

[Ashal]

Been testing the new beta, very slick! Loved the walk-instead-of-teleport feature, and the new added MCM options. But i'd like to request please, PLEASE, please, for hotkeys to go back animations stages and rotate counter-clockwise, since using the modifier key almost never works (script heavy game? dunno, but surely i'm not the only user with this issue).

 

The reverse key works fine on both of those. Just make sure you're holding it FIRST before you press the other key, as it checks if that key's pressed after you press the other one in combo with it.

[Blade_Runner]

 

Been testing the new beta, very slick! Loved the walk-instead-of-teleport feature, and the new added MCM options. But i'd like to request please, PLEASE, please, for hotkeys to go back animations stages and rotate counter-clockwise, since using the modifier key almost never works (script heavy game? dunno, but surely i'm not the only user with this issue).

 

The reverse key works fine on both of those. Just make sure you're holding it FIRST before you press the other key, as it checks if that key's pressed after you press the other one in combo with it.

 

Thanks Ashal. Yes, i'm pressing the modifier before the other hotkey, and yes, it works, but not always. When i want to reverse several animation stages, for example, it always end up advancing them - unless i release shift, wait a good while, press shit and the shortcut again, and even then it may not recognize the modifier key sometimes. Again, i believe it's due to a script-heavy modded game, but i think it's a far simpler solution to just have a reverse hotkey for both those functions - it prevents those issues in any scenario. 

 

As far as animation stages are concerned, i simply use the SL Tools mod to set stage, and it works wonderfully, but i felt i should point it out, since if there wasn't a need for a better way to select animation stages, that function wouldn't even exist in the mod to begin with (also, it's one mod you should consider implementing in the main SL package, along with SL Anim Speed, because they really, really improve the overall experience).

 

A couple other things that i'd like to suggest is to implement progressive undressing animations (like the strip mod, or 0sex), and more option to choose the type of animations playing in beds besides excluding standing ones. It's pretty trivial, but would be nice nonetheless. Anyway, thanks for the incredible update!

[Earen]

Regarding the first one, it seems sometimes (empty array? invalid array?) arr pointer is zero and your OffsetCoords crashes when obtaining coords.

In my case this happened due to bad OffsetBy array

template <typename T>
class VMArray
{
public:
    VMValue::ArrayData      * arr;

[Ashal]

 

Regarding the first one, it seems sometimes (empty array? invalid array?) arr is zero  and your OffsetCoords crashes when obtaining coords

template <typename T>
class VMArray
{
public:
    VMValue::ArrayData      * arr;

 

Suggesting your crash happened at/during animation, and not specifically at the end when it saves the adjustments to json?

 

That being the case, I can't think of a single scenario where OffsetCoords would be null here. But if that is indeed the case, should be simple enough to just have the relevant functions treat a null offset array as 0,0,0,0 instead, bypassing the issue in a way that may result in a poorly aligned animation, but better that than a crash.

[Earen]

 

 

Regarding the first one, it seems sometimes (empty array? invalid array?) arr is zero  and your OffsetCoords crashes when obtaining coords

template <typename T>
class VMArray
{
public:
    VMValue::ArrayData      * arr;

 

Suggesting your crash happened at/during animation, and not specifically at the end when it saves the adjustments to json?

 

That being the case, I can't think of a single scenario where OffsetCoords would be null here. But if that is indeed the case, should be simple enough to just have the relevant functions treat a null offset array as 0,0,0,0 instead, bypassing the issue in a way that may result in a poorly aligned animation, but better that than a crash.

 

 

Yea, during animation, I didn't adjusted anything, if I recall. Indeed, better protect the function, anyone can call it and cause Skyrim 'shutdown'.

And another one happens somewhere in CalcEnjoyment, don't know where exactly yet, though there isn't much variety^^

[Ashal]

 

 

 

Regarding the first one, it seems sometimes (empty array? invalid array?) arr is zero  and your OffsetCoords crashes when obtaining coords

template <typename T>
class VMArray
{
public:
    VMValue::ArrayData      * arr;

 

Suggesting your crash happened at/during animation, and not specifically at the end when it saves the adjustments to json?

 

That being the case, I can't think of a single scenario where OffsetCoords would be null here. But if that is indeed the case, should be simple enough to just have the relevant functions treat a null offset array as 0,0,0,0 instead, bypassing the issue in a way that may result in a poorly aligned animation, but better that than a crash.

 

 

Yea, during animation, I didn't adjusted anything, if I recall. Indeed, better protect the function, anyone can call it and cause Skyrim 'shutdown'.

And another one happens somewhere in CalcEnjoyment, don't know where exactly yet

 

 

 

If it happens during CalcEnjoyment in addition to offset functions, unless whatever sexlab mod you were using to trigger the scene also happens to erroneously trigger sexlab's native functions with arrays, I can't think of any scenario this should be possible under normal circumstances. And  yes, I'm aware "shouldn't be possible" is basically the programmer version of "shit weirdly fucked up in a way I don't know"

 

I know I specifically check for "if (!array.arr) return false;" type stuff before continuing with a lot of the functions, but could you tell me if that's something I'm specifically remembering to do before the functions the crash trace back to? Or is that paticular check getting by when it shouldn't, and/or "array.arr" being the cause of the problem to being with, with "array" not existing, so "if (!array || !array.arr)" being a better solution?

[Earen]

If it happens during CalcEnjoyment in addition to offset functions, unless whatever sexlab mod you were using to trigger the scene also happens to erroneously trigger sexlab's native functions with arrays, I can't think of any scenario this should be possible under normal circumstances. And  yes, I'm aware "shouldn't be possible" is basically the programmer version of "shit weirdly fucked up in a way I don't know"

 

I know I specifically check for "if (!array.arr) return false;" type stuff before continuing with a lot of the functions, but could you tell me if that's something I'm specifically remembering to do before the functions the crash trace back to? Or is that paticular check getting by when it shouldn't, and/or "array.arr" being the cause of the problem to being with, with "array" not existing, so "if (!array || !array.arr)" being a better solution?

 

 

I thought this too, either my setup is horribly weird and something screwing arrays(?), then my case is unique, but then I think I 'd had ton of problems just everywhere

 

I haven't slept enough to understand you properly, but something like "arr.Length() > N" or "arr.Length() != 0" will perform the same (it already tests for !array.arr), and "!array" just won't compile.

 

Length test would be enough to fix this, 'array' is not  a pointer, it can't be tested with "!array"

 

[Ashal]

I though this too, either my setup is horribly weird and something screwing arrays(?), then my case is unique, but then I think I 'd had ton of problems just everywhere

I haven't slept enough to understand you properly, but something like "arr.Length() > N" or "arr.Length() != 0" will perform the same (it already tests for !array.arr), and "!array" just won't compile.

 

I fail to see how that improves over !Array.arr I mean, if arr doesn't exist, than obviously Length() shouldn't either right? But adding an additional bool check before functions should be a minor thing I guess, so why not. Though this honestly sounds more like an issue with papyrus or skse's handling of arrays. Which admitably is also on me/sexulabutil/storageutil to deal with at the end of the day

 

The only situation I see this being relevant in is something like

int[] arr ; // not init to anything
SexLabUtil.Function(arr)

And even that I'm fairly certain should function fine and is the exact scenario !VMArray.arr is intended for.

[Earen]

 

I though this too, either my setup is horribly weird and something screwing arrays(?), then my case is unique, but then I think I 'd had ton of problems just everywhere

I haven't slept enough to understand you properly, but something like "arr.Length() > N" or "arr.Length() != 0" will perform the same (it already tests for !array.arr), and "!array" just won't compile.

 

I fail to see how that improves over !Array.arr I mean, if arr doesn't exist, than obviously Length() shouldn't either right? But adding an additional bool check before functions should be a minor thing I guess, so why not. Though this honestly sounds more like an issue with papyrus or skse's handling of arrays. Which admitably is also on me/sexulabutil/storageutil to deal with at the end of the day

 

The only situation I see this being relevant in is something like

int[] arr ; // not init to anything
SexLabUtil.Function(arr)

And even that I'm fairly certain should function fine, being caught by the !Array.arr check.

 

 

VMArrray's length is "Length() { return arr ? arr->GetLength() : 0; }". Using Length just makes code compact. Also, aren't you relying on some particular array lengths?

Also, what if (in theory) arr is non-zero, but array's length is still 0..

 

[Ashal]

 

 

I though this too, either my setup is horribly weird and something screwing arrays(?), then my case is unique, but then I think I 'd had ton of problems just everywhere

I haven't slept enough to understand you properly, but something like "arr.Length() > N" or "arr.Length() != 0" will perform the same (it already tests for !array.arr), and "!array" just won't compile.

 

I fail to see how that improves over !Array.arr I mean, if arr doesn't exist, than obviously Length() shouldn't either right? But adding an additional bool check before functions should be a minor thing I guess, so why not. Though this honestly sounds more like an issue with papyrus or skse's handling of arrays. Which admitably is also on me/sexulabutil/storageutil to deal with at the end of the day

 

The only situation I see this being relevant in is something like

int[] arr ; // not init to anything
SexLabUtil.Function(arr)

And even that I'm fairly certain should function fine, being caught by the !Array.arr check.

 

 

VMArrray's length is "Length() { return arr ? arr->GetLength() : 0; }". Using Length just makes code compact. Also, aren't you relying on some particular array lengths?

Also, what if (in theory) arr is non-zero, but array's length is still 0..

 

 

Using length still relies on the pointer existing, which is why I'd say !arr is preferable before arr->GetLength() > 0. If pointer arr doesn't exist, than length is obviously 0.

 

I mean even your example of arr's Length() says exactly that. "arr ? arr->GetLength() : 0" aka, if arr isn't false/null, return it's length, if it is false/null, return 0/false."

 

From another point of view though, I assume this is exactly the problem here? The pointer isn't null, but length is still 0. Making checking for both preferable.

 

For reference, I come from a PHP background, where false and null are essentially the same. Something I recognize as "wrong" here, but potentially relevant.

[Ashal]

 

VMArrray's length is "Length() { return arr ? arr->GetLength() : 0; }". Using Length just makes code compact. Also, aren't you relying on some particular array lengths?

Also, what if (in theory) arr is non-zero, but array's length is still 0..

 

 

Using length still relies on the pointer existing, which is why I'd say !arr is preferable before arr->GetLength() > 0. If pointer arr doesn't exist, than length is obviously 0.

 

I mean even your example of arr's Length() says exactly that. "arr ? arr->GetLength() : 0" aka, if arr isn't false/null, return it's length, if it is false/null, return 0/false."

 

From another point of view though, I assume this is exactly the problem here? The pointer isn't null, but length is still 0. Making checking for both preferable.

 

For reference, I come from a PHP background, where false and null are essentially the same. Something I recognize as "wrong" here, but potentially relevant.

 

 

Thinking about it some more, I guess if Length() checks for arr in a ternary operator, it makes other checks for it rather moot.  Accomplishing both of our purposes here. I guess my confusion then lies solely in whether or not the secondary/rumored part of it remains relevant or not. 

[Earen]

 

 

Using length still relies on the pointer existing, which is why I'd say !arr is preferable before arr->GetLength() > 0. If pointer arr doesn't exist, than length is obviously 0.

 

I mean even your example of arr's Length() says exactly that. "arr ? arr->GetLength() : 0" aka, if arr isn't false/null, return it's length, if it is false/null, return 0/false."

 

From another point of view though, I assume this is exactly the problem here? The pointer isn't null, but length is still 0. Making checking for both preferable.

 

For reference, I come from a PHP background, where false and null are essentially the same. Something I recognize as "wrong" here, but potentially relevant.

 

 

Thinking about it some more, I guess if Length() checks for arr in a ternary operator, it makes other checks for it rather moot.  Accomplishing both of our purposes here. I guess my confusion then lies solely in whether or not the secondary/rumored part of it remains relevant or not. 

 

 

I was just pointing more on use of length(), rather than 'arr' cause it indeed performs both checks and also because the code won't depend on implementation, that is 'arr' field

 

[Vbloodwrith]

 

 

New report - I'm not sure is it related to SL or NSAP but when using Defeat 5.1 mod, my female follower is using male (strapon) animations when raping males. Any suggestion how to fix it permanently? I'm using SL's edit key on my follower and change their positions, but the problem continues whenever she is raping males.

 

You mean the females are defaulting to the male position? This isn't something SexLab has control over, the positions actors take during animation is 100% controlled by the mod starting the scene. If your positive it's a 1.60 issue and the mod your using the start animations doesn't have or isn't using an option for what position female attackers default to (which I know several of those mods do have) than it's possibly a backwards compatibility issue and I'd have to see a debug log of it happening. But I can't think of anything that would cause it, as sexlab doesn't ever touch the actor positions, with the obvious exception of the change positions hotkey.

 

Sl does have some control of female's defaulting into male roles. You have to go to HOTKEYs in the MCM and find which key causes them to swap roles. I also use SL, but use it with Sexaddicts and have maped SL keys to the same one that Sexaddicts uses and seem to deal with that issue. It also give me more than one way for my character to have sex. I think it works much better then AP and removed it with no issues. Then again, AP might allow somethings that I never noticed. LOL.

[chajapa]

I tried using this and ended up with some anomalies.

 

XPMSE 3.63

FNIS 6.2

 

SL Framework 160 HF2 full and then applied this patch.

 

New entries in MCM had "$SSL_" and no descriptions. I chalked it up to beta and continued on since I could still see what they were for. 

 

I wrote JUGs so naturally I tested this first on a breastfeeding animation.

When the animation started, the characters did like a quick hump with what appeared to be on of the "rough behind" standing animations, then both stood there while the animation apparently was playing because Apropos continued to update the description of what was happening at each stage change even though the characters were not actually DOING the animation. Facial expression changed on the male PC as directed by the animation, but...not animation.

 

NOT the "T" pose. Just standing...female follower showing standing idle animation as though nothing was happening. Well.... ok... nothing was happening.

 

Is this odd or just part of the beta? I can run it again and get a papyrus log if necessary, but figured I'd check in and see if this was all known issue stuff or if it needed further investigation.

 

Attempts to resolve:

In trying to resolve this I first reset the animation registry.

NORMALLY, when I do this I expect to see all animations toggled ON when I go into the Toggle Animations page of MCM. Many were NOT toggled on. All of the ones from NSAP that I had toggled on were on, but many of the older, original SL animations were not toggled on.

 

When resetting the animation registry failed to fix the animations I then did the "Clean" cycle to reset SexLab.

Saved, exited game, re-ran FNIS, went back in.

"Clean" cycle also did not toggle all animations on as I had expected.

Animations still doing the same thing. Tried a doggy style vaginal animation..... standing.....they looked bored.

 

Rolled back to SL 1.60 HF2 and animations work normally again. 

 

Suggestions to resolve this?