SexLab Framework Development

[cxsora]

Sexlab animation‘s number limit need increase, I use Non-SexLab Animation Pack and ZAZ, then some ZAZ animations registration fail.

[RavinBeast]

Sexlab animation‘s number limit need increase, I use Non-SexLab Animation Pack and ZAZ, then some ZAZ animations registration fail.

Ashal Said That's Already In The Works. Along With Male & Female Creature Separation, Instead Of All Creatures Being Considered Male.

[cretin]

Finalizing an API is always a good thing.  If I had to ask for anything, it would be for a good long break, and if (and only if) you're then inspired to do so, see what tentpole mod you can make as an example / front-end for SL.  Matchmaker on steroids.

 

I've been hoping for a Lovers Extender-type mod to arrive, a kind of sex-power minigame tied to into the SL position experience system (by the way, the least used and most awesome aspect of SL, IMHO).  That aspect of Lovers Extender allowed emergent gameplay to come out of every situation and would go farther to make SL a blast to fuck around with.

 

[cretin]

 

[...] but I'd argue unless 5+ chair animations suddenly show it it's most likely simply not worth the time and effort for such a niche situation.

 

 

Version 2.1 is up!

• added seven animations by leito (throne blowjob, throne cowgirl, throne cunnilingus, throne doggystyle, throne doggystyle variant, throne missionary, throne reverse cowgirl)

 

You have to admit this is classic timing.

[l33tMan]

If completely without a clue about what to do, Ashal could code in support for a sex mimigame. Something like what I'm about to describe was already implemented in Oblivion, I think.

 

The whole thing would be either activated by a plugin, or it could be MCM deactivate-able

A HUD widget could be placed somewhere on the screen.

It would be an overlap of two circles, with a floating dot in there somewhere.

Without touching any controls, the dot would float in the outer ring for male PCs and the inner circle for female PCs.

For male PCs, the point would be to get the dot in the inner circle and hold it there, making the PC more focused and prolonging the time it takes the male to climax and terminate the sex session.

For female PCs, the point would be to get the dot out of the circle and keep it from sliding back, getting the female PC to climax faster and have multiple orgasms during one session (Note: different orgasm effect from the main one would be useful here).

 

With growing sexual proficiency (tracked by SexLab's stat tracker), the respective sex's undesirable area's (circle or outer ring) influence on the dot would diminish (less 'gravity').

Oral work would not trigger this system - any animations tagged with "oral" would use an alternate system where the point is to bring the receiving one faster to climax (same HUD widget, different rules). The "anal"-tagged animations would add a modifier making males climax slightly faster and females sligthly slower.

 

Peace!

[parzysty]

Fix for facial expressions would be nice. And no, expression's strength based on sex profficiency is not a good idea.

[Antono]

Ashal, I'm having a problem using the temporary-ephemeral animations functionality.

 

As you advised (a few months ago ), I am using my standard method for defining my animation, only in this case beginning with NewAnimationObject().

 

At some point I have to do a sslBaseAnimation.Save(), definitely before setting the timers for the stages. But as far as I can tell, I can't call this function on ephemeral animations. So, it seems I cannot finalize my animation setup. Also, I couldn't find any other mod (among those that I play with) using ephemeral animations to use as reference. Can you help?

 

It could also be that I'm completely confused and got it all backwards!

 

(There seems to be a Finalize() function in the works, could this be coming in 1.60?)

[holtof55]

Some experts gathered here, tell me the working code magical effect, which removes a Draugr, Falmer, Dremora their equipment, and after effect - Dresses all back
i need it

 

sorry for my english

[WaxenFigure]

Some experts gathered here, tell me the working code magical effect, which removes a Draugr, Falmer, Dremora their equipment, and after effect - Dresses all back

i need it

 

sorry for my english

 

You want to look at the code in this mod:

 

http://www.loverslab.com/topic/41270-creature-framework-rc5-updated-2015-1-29/

[Ashal]

SexLab 1.60 Alpha 3 - February 27th, 2015

 

----

 

Main additions of currently available development build:

• Requires SKSE 1.7.2 Beta
• Increased animation/voice/expression/creature registration limit from 125 to 350
• New API for easier adding, modifying, and checking valid creature races
• Animation offsets and actor stats saving have moved to a new API using SexLabUtil.dll instead of StorageUtil.dll
  • More hyperfocused on their one task and thus much faster at loading and recording the offsets/stats during animation where timing is important.
  • Your existing saved offsets won't carry over. Final release will properly convert your existing animation profile into the new one.
• New "Limited Strip" functionality, if the only animations present in a scene have the tags Oral, Foreplay, or LimitedStrip and there is no custom strip overide - than actors will default to using the the more minimalist foreplay strip options instead.
  • Will likely make it an optional toggle in the MCM at some point, and "foreplay" strip be renamed to "minimal"
  • The current foreplay strip options it uses are more minimalist than previous default sexlab options, TOO minimalist in some cases, need to work out the defaults for it still.
• Added stage specific cum settings for animations, so orgasms triggered at different stages can apply differing cum effects.
• Many performance optimizations
• Some important bugfixes
   
• Alpha 2: Added category specific animation/creature registration modevents so mods adding new animations can keep their animations grouped together in the in the MCM with the default sexlab animations/creatures. 
• Alpha 2: Creature animation registration will be skipped if creatures not enabled or installed. This is preparation for plans to make creature animations a secondary optional download in final 1.60 rather than included by default. AP animations likely to follow a similar route.
• Alpha 2: Some minor/major-ish performance tweaks to thread handling between between animations and actors. Greatly improves animation sync and some transitions.
   
• Alpha 3: Yet even more performance improvements, ranging from major to incredibly minor. 
• Alpha 3: Added a compatibility check for HDT High Heels
  • If the heel effect is detected on an actor during animation startup, the effect will be removed and reapplied after animation.
  • Should work with both regular HDT-HH supported armors, as well as Device Devices Expansion's "faux-soft-compatibility-support" boots. 
  • Currently this is force enabled on/off if you have the HDT-HH mod enabled - I am considering changing it to a toggle instead since some people may have built up their animation adjustment profiles specifically compensating for the height difference.
  • I haven't tested this extensively as I don't have a lot of HDT enabled mods to test it with, so feedback here is welcome. 
• Alpha 3: Added new "Strip Item Editor" menu.
  • Lets you flag specific items the player and/or targeted actor have equipped or in inventory as being "Always Strip" or "Never Strip"
  • If items flagged in this way are found during SexLab stripping, they will react accordingly, regardless of any normal/foreplay/aggressive strip settings or custom strip settings by other mods using SexLab's functions. 
  • Items that have a CreationKit keyword attached that contains the substring "NoStrip" or "AlwaysStrip", such as restrictive gear added by Devious Devices are excluded from this new editor in order to prevent breaking them, keywords supercede these overrides. 
• Alpha 3: Added preliminary support for Male/Female creature gender separation.
  • Can be enabled/disabled from the SexLab MCM (defaults to disabled).
  • If enabled, when sexlab is selecting creature animations to use, it will restrict the search to the creature genders present.
  • If disabled (default), all creatures are treated as the same gender, exactly the same as SexLab 1.59c and older.
  • Added new check for "NoGenders" tag on creature animations, this disables the gender check on a per animation basis, regardless of user setting. This has been placed on all the default SexLab creature animations that don't involve "humanoid" type creatures.
  • Support must be implemented in any mods adding new Creature animations, otherwise the animations will only be useable with the gender option disabled, or with all male creatures. Just do "AddPosition(CreatureFemale)" during animation registration to mark a position as female, and do NOT include the NoGenders tag.
  • Will only affect animations selected by SexLab by default or by a modder specifically using the new creature gender search functions. 
  • SexLab.GetGender() will now return a "3" for female creatures when the option is enabled, instead of the usual "2" for all creatures which now specifically indicates male creatures. I'm somewhat concerned this change will break any existing creature mods that identify creatures by using GetGender() == 2, as they will now become incompatible with any female creatures unless they change it to GetGender() >= 2.
  • Hasn't been to extensively tested, I've only implemented it everywhere I thought relevant and tested it using a fake test animation flagged for female werewolves.

Still to do before final release:

• Rework the actor sex skill progression and starting seed amounts
• Basic actor arousal level tracking and modification
• Documentation blocks for all API supported functions
• Give the MCM menu an overhaul
• Add new missing animations

 

SexLab 1.59c to Alpha 3 Download:
 
SexLab_159c_to_160_ALPHA_3.zip 

Requires a current install of 1.59c or previous alpha builds to use. Just apply it over an existing install and run the reinstall option from the MCM.
 
I  haven't tested the upgrade process from 1.59c to the current build much, so it may crash and burn on an existing 1.59c save or it may not, I don't know, let me know your results.
 
Previous Alpha Builds:

Alpha 1: SexLab_159c_to_160ALPHA.zip

Alpha 2: SexLab_159c_to_160_ALPHA_2.zip

 

[Ashal]

Ashal, I'm having a problem using the temporary-ephemeral animations functionality.

 

As you advised (a few months ago ), I am using my standard method for defining my animation, only in this case beginning with NewAnimationObject().

 

At some point I have to do a sslBaseAnimation.Save(), definitely before setting the timers for the stages. But as far as I can tell, I can't call this function on ephemeral animations. So, it seems I cannot finalize my animation setup. Also, I couldn't find any other mod (among those that I play with) using ephemeral animations to use as reference. Can you help?

 

It could also be that I'm completely confused and got it all backwards!

 

(There seems to be a Finalize() function in the works, could this be coming in 1.60?)

 

Save() should be the very last thing called on when setting up your animation, regardless if it's ephemeral or not. When setting up an animation the order of "doing stuff" should pretty much be something like this:

; // For cleaner access to the SFX, CumID, and Gender flag globals
import sslObjectFactory

sslBaseAnimation Base = SexLab.NewAnimationObject("MyUniqueToken", MyQuest)
if Base != none
	; // Basic animation info such as name, default SFX, and valid creatures
	Base.Name    = "My Animation"
	Base.SoundFX = Sucking()

	; // Animation positions / stages
	int a1 = Base.AddPosition(Female(), Oral())
	Base.AddPositionStage(a1, "MyAnimation_A1_S1", 0)
	Base.AddPositionStage(a1, "MyAnimation_A1_S2", 0, openMouth = true)
	Base.AddPositionStage(a1, "MyAnimation_A1_S3", 0, openMouth = true)

	int a2 = Base.AddPosition(Male())
	Base.AddPositionStage(a2, "MyAnimation_A2_S1", -120, side = -3.5, sos = -4)
	Base.AddPositionStage(a2, "MyAnimation_A2_S2", -120, side = -3.5, sos = 5)
	Base.AddPositionStage(a2, "MyAnimation_A2_S3", -120, side = -3.5, sos = 5)

	; // Stage 2/3 will be forced to 30 seconds
	Base.SetStageTimer(2, 30.0)
	; // Stage 3/3 will play a custom SFX instead of sucking
	Base.SetStageSoundFX(3, MyCustomSound)
	; // (Added in SexLab 1.60+) If the orgasm effect is played during stage 1, a1 will get vaginalanal cum instead of oral
	Base.SetStageCumID(a1, 1, VaginalAnal()) 
	
	; // Tags
	Base.AddTag("Sex")

	; // Finalize the animation with Save()
	Base.Save()
endIf

This is obviously specifically an ephemeral example using NewAnimationObject(), the regular sexlab registration for non-ephemeral objects would look a little bit different only in that you'd have access to the property versions of the different flags instead of using sslObjectFactories globals, include the id in the Save() and add a Base = Create(id)  inside your callback to get the object you're setting up.

 

The main important thing is that anything stage specific in your setup has to be done AFTER the positions setup, since setting up the animation events for them also sets up the number of positions and stages in the animation, and it won't let you set timers, cum id's, or sfx for stages or positions that don't exist.

 

As far as mods with examples, Devious Devices Integration uses them, and ZaZ I think does as well.

[Antono]

Thanks Ashal!

 

I thought I had to do a Base.Save(id) and pass the animation's id like with "normal" animations, retrieving it via sslAnimSlots.FindByName().

base.Save(sslAnimSlots.FindByName("MyAnimation"))

It wasn't working with ephemerals as they don't have a registry id. But just doing Base.Save() finalized my ephemeral!

 

Yup, you are right, DD - Integration and ZAP do use ephemerals. They just call the lower-level NewAnimation() instead of NewAnimationObject(), so a script-wide search didn't find any hits. I'll have to look closer next time.

[Min]

Thanks Ashal!

 

I thought I had to do a Base.Save(id) and pass the animation's id like with "normal" animations, retrieving it via sslAnimSlots.FindByName().

base.Save(sslAnimSlots.FindByName("MyAnimation"))

It wasn't working with ephemerals as they don't have a registry id. But just doing Base.Save() finalized my ephemeral!

 

Yup, you are right, DD - Integration and ZAP do use ephemerals. They just call the lower-level NewAnimation() instead of NewAnimationObject(), so a script-wide search didn't find any hits. I'll have to look closer next time.

 

https://github.com/DeviousDevices/DDi/blob/Development/scripts/Source/zadBeltedAnims.psc

[Ashal]

 

Thanks Ashal!

 

I thought I had to do a Base.Save(id) and pass the animation's id like with "normal" animations, retrieving it via sslAnimSlots.FindByName().

base.Save(sslAnimSlots.FindByName("MyAnimation"))

It wasn't working with ephemerals as they don't have a registry id. But just doing Base.Save() finalized my ephemeral!

 

Yup, you are right, DD - Integration and ZAP do use ephemerals. They just call the lower-level NewAnimation() instead of NewAnimationObject(), so a script-wide search didn't find any hits. I'll have to look closer next time.

 

https://github.com/DeviousDevices/DDi/blob/Development/scripts/Source/zadBeltedAnims.psc

 

 

FYI the "Anim.SetContent(Sexual)" is entirely unnecessary. I can't remember for sure if it's unnecessary in 1.59c, I wanna say it is, as it's honestly been awhile since I've used/looked at any of 1.59c's codebase, but in 1.60 it for sure literally does nothing and is an empty function. The entire SetContent() functionality is removed due to being, essentially, useless.

 

Existing animation search functions will ignore it in future updates, and any checks towards Animation.IsSexual(), which no default sexlab function has ever bothered with, will instead simply check for 'HasTag("Sex") || HasTag("Foreplay")'

 

The usage of SexLab for non sexual animations is pretty much non-existent as far as I know, so I see no more use in continuing direct support for it when there is optimization benefits to be had by discarding it.

[Antono]

 

https://github.com/DeviousDevices/DDi/blob/Development/scripts/Source/zadBeltedAnims.psc

 

 

Thank you, this is very useful as reference

[Min]

 

 

Thanks Ashal!

 

I thought I had to do a Base.Save(id) and pass the animation's id like with "normal" animations, retrieving it via sslAnimSlots.FindByName().

base.Save(sslAnimSlots.FindByName("MyAnimation"))

It wasn't working with ephemerals as they don't have a registry id. But just doing Base.Save() finalized my ephemeral!

 

Yup, you are right, DD - Integration and ZAP do use ephemerals. They just call the lower-level NewAnimation() instead of NewAnimationObject(), so a script-wide search didn't find any hits. I'll have to look closer next time.

 

https://github.com/DeviousDevices/DDi/blob/Development/scripts/Source/zadBeltedAnims.psc

 

 

FYI the "Anim.SetContent(Sexual)" is entirely unnecessary. I can't remember for sure if it's unnecessary in 1.59c, I wanna say it is, as it's honestly been awhile since I've used/looked at any of 1.59c's codebase, but in 1.60 it for sure literally does nothing and is an empty function. The entire SetContent() functionality is removed due to being, essentially, useless.

 

Existing animation search functions will ignore it in future updates, and any checks towards Animation.IsSexual(), which no default sexlab function has ever bothered with, will instead simply check for 'HasTag("Sex") || HasTag("Foreplay")'

 

The usage of SexLab for non sexual animations is pretty much non-existent as far as I know, so I see no more use in continuing direct support for it when there is optimization benefits to be had by discarding it.

 

Makes sense. I'll remove that. 

[Ashal]

 

 

 

Thanks Ashal!

 

I thought I had to do a Base.Save(id) and pass the animation's id like with "normal" animations, retrieving it via sslAnimSlots.FindByName().

base.Save(sslAnimSlots.FindByName("MyAnimation"))

It wasn't working with ephemerals as they don't have a registry id. But just doing Base.Save() finalized my ephemeral!

 

Yup, you are right, DD - Integration and ZAP do use ephemerals. They just call the lower-level NewAnimation() instead of NewAnimationObject(), so a script-wide search didn't find any hits. I'll have to look closer next time.

 

https://github.com/DeviousDevices/DDi/blob/Development/scripts/Source/zadBeltedAnims.psc

 

 

FYI the "Anim.SetContent(Sexual)" is entirely unnecessary. I can't remember for sure if it's unnecessary in 1.59c, I wanna say it is, as it's honestly been awhile since I've used/looked at any of 1.59c's codebase, but in 1.60 it for sure literally does nothing and is an empty function. The entire SetContent() functionality is removed due to being, essentially, useless.

 

Existing animation search functions will ignore it in future updates, and any checks towards Animation.IsSexual(), which no default sexlab function has ever bothered with, will instead simply check for 'HasTag("Sex") || HasTag("Foreplay")'

 

The usage of SexLab for non sexual animations is pretty much non-existent as far as I know, so I see no more use in continuing direct support for it when there is optimization benefits to be had by discarding it.

 

Makes sense. I'll remove that. 

 

 

It's completely harmless to leave in if you want to maintain backwards compatibility. Just a heads up on future changes.

[cxsora]

• Add a system to restrict + randomize the animation searching functions in the event that the animation search would return more than 128 animations. 350 animations can be installed now, but active scenes started by SexLab must still be limited to a list of 128, or possibly fewer to avoid painfully long situations of cycling through 128 animations trying to find a specific one.

Is this system will cause no significance to regist more than 128 animations?

 

[Ashal]

 

• Add a system to restrict + randomize the animation searching functions in the event that the animation search would return more than 128 animations. 350 animations can be installed now, but active scenes started by SexLab must still be limited to a list of 128, or possibly fewer to avoid painfully long situations of cycling through 128 animations trying to find a specific one.

Is this system will cause no significance to regist more than 128 animations?

 

 

It only searches through as many animations are installed. If you only have 67 animations installed, it's only going to search the first 67 out of 350 animation slots. If you have all 350 animation slots installed and it's having to search the entire list, is it going to be slower? Yes, obviously, but not by any really noticeable amount.

 

That is independent of the bullet point your quoting there though. SexLab 1.60 can handle more than 128 animations being registered, but there is still no way in Papyrus for me to return a sslBaseAnimation[] array bigger than 128, so if your animation search is going to return more than 128, it will randomly remove enough from the results to get under the limit, otherwise the animations beyonds 128 would never be returned by the search. This is likely to rarely, if ever, happen and really only exists as a precaution on the off chance there does end up being enough new animations in SexLab to make it a possibility.

[rydin]

Pushed first development build update for sexlab in a while for those using or are interested in trying the development build. Been giving it a run through for last couple days trying to iron out any obvious kinks and finally looks to be a fully working build again.

 

Main additions of currently available development build:

• Requires SKSE 1.7.2 Beta
• Increased animation/voice/expression/creature registration limit from 125 to 350
• New API for easier adding, modifying, and checking valid creature races
• Animation offsets and actor stats saving have moved to a new API using SexLabUtil.dll instead of StorageUtil.dll
  • More hyperfocused on their one task and thus much faster at loading and recording the offsets/stats during animation where timing is important.
  • Your existing saved offsets won't carry over. Final release will properly convert your existing animation profile into the new one.
• New "Limited Strip" functionality, if the only animations present in a scene have the tags Oral, Foreplay, or LimitedStrip and there is no custom strip overide - than actors will default to using the the more minimalist foreplay strip options instead.
  • Will likely make it an optional toggle in the MCM at some point, and "foreplay" strip be renamed to "minimal"
  • The current foreplay strip options it uses are more minimalist than previous default sexlab options, TOO minimalist in some cases, need to work out the defaults for it still.
• Added stage specific cum settings for animations, so orgasms triggered at different stages can apply differing cum effects.
• Many performance optimizations
• Some important bugfixes

 

Still to do before final release:

• Finish creature male/female separation option. It's partially implemented in sections right now, but not in any important ways.
• Rework the actor sex skill progression and starting seed amounts
• Basic actor arousal level tracking and modification
• Give the MCM menu an overhaul
• Add new missing animations

 

 

Here is a 1.59c to 1.60 alpha patch for those willing to help test:

SexLab_159c_to_160ALPHA.zip

 

I  haven't tested the upgrade process from 1.59c to the current build much, so it may crash and burn on an existing 1.59c save or it may not, I don't know. Just be sure to run the Rebuild/Reinstall option from the MCM menu either way. 

 

EDIT: Reuploaded alpha patch with minor upgrade to improve animation syncing. 

 

I'll take a look at this later tonight and see how to works with NSAP.

[Ashal]

 

 

Here is a 1.59c to 1.60 alpha patch for those willing to help test:

SexLab_159c_to_160ALPHA.zip

 

I  haven't tested the upgrade process from 1.59c to the current build much, so it may crash and burn on an existing 1.59c save or it may not, I don't know. Just be sure to run the Rebuild/Reinstall option from the MCM menu either way. 

 

EDIT: Reuploaded alpha patch with minor upgrade to improve animation syncing. 

 

I'll take a look at this later tonight and see how to works with NSAP.

 

 

 

I've been using NSAP while developing, it works without any issues.

 

Though the ones I have enabled weren't enough to push it over the previous limit of 125 for me. I used a bunch of copy-pasted temporary animations to push it over the limit during development. Which people can uncomment from sslAnimationDefaults.psc lines 83-173 and recompile if they really want to try quickly pushing the new registration limit.

[Earen]

Hi, Ahsal.

A suggestion about utiliing Jaxonz Positioner to adjust actor's positions. SL  computes (current-actor-position - original-position), no additional dependency.

The reason I'm suggesting this is that JaxonzPositioner seems more responsive and easy to use. I'm not aware of the way the positioning works/changed in 1.6

 

[edit]

But the main reason of suggestion is Shift button which sometimes does not inverses the action.. Or it would be simpler to copy JP functionality?

[Ashal]

Hi, Ahsal.

A suggestion about utiliing Jaxonz Positioner to adjust actor's positions. SL  computes (current-actor-position - original-position), no additional dependency.

The reason I'm suggesting this is that JaxonzPositioner seems more responsive and easy to use. I'm not aware of the way the positioning works/changed in 1.6

 

I don't see anything super different about Jaxonz positioning, other than the fact that it sets the objects motion type to keyframed. Which in my original experimentation a long time ago seemed to have no effect on actors at all.

 

Never used it before and am just looking at it's scripts now, but going by the scripts and mod description, I assume it doesn't work with actors, which is an entirely different scenario than positioning objects.

 

Actors have other things that throw a wrinkle into things, like foot IK and the fact that actors will repel other actors away from them if to close so they can't clip through each other, things SexLab has to accommodate for and account for some of the inconsistencies.

 

Jaxonz also looks to be positioning solo objects in the global space, only ever concerned with their own position. SexLab has to position multiple actors relative to a single local center point so that the multiple actors are aligned for the 2+ entirely separate animation events look like a single animation event put together.

 

 

[edit]

But the main reason of suggestion is Shift button which sometimes does not inverses the action.. Or it would be simpler to copy JP functionality?

When adjusting positions with shift make sure it's pressed down before you press the adjustment hotkey, the adjustment hotkey triggers the function which then just checks if shift is held or not so it may get passed the check for shift in the split second it takes to also press down your shift key. This is an ease of use problem I should probably fix, though I'd consider it relatively minor.

 

There's also a bit of tolerance built into the positioning adjustments, since an actor almost never has exactly a 0.0 difference between their current and expected coordinates. Sometimes the heading of the actors can throw this off and I just really need to lower the minimum distance it checks for when positioning.

 

 

 

EDIT: Looking at the scripts did finally tell what I've always been doing wrong with right/left positioning though, they've always been inconsistent in SexLab depending on the angle - it never occurred to me to simply "look" 90 degrees to either side before doing the exact same formula as forward/backward. It's fixed and working perfectly now in development build, so thanks!

[Ep1cL3w7z]

When you add the arousal rating system, I'd suggest also adding a way to register for an event when an actor's arousal goes above a defined threshold. It could be actor-specific, or a generic "ActorAroused" event that provides the actor as an event parameter.

Perhaps SexLab could have its own central default "Arousal threshold" setting as well, but it should definitely be overridable by a parameter in the registration method.

[boo]

Any way to make the spunk effects not glow?