SexLab Framework Development

[Ashal]

 

 

Would it be possible to be able block certain sex acts if there is something like a gag or chastity device on one of the participants? Also, how hard would it be to have these items keep the wearer from being satisfied (does performing oral sex satisfy the person giving it) or would that be handled by one of the other mods?

 

There isn't any "satisfaction" system. Something like that would be handled by a separate mod.

 

For restricting by item, you could hook into the animationstart event, check if the actor has certain items equipped, and if so pick new animations of your choice that doesn't include that them.

 

 

I am attempting something similar, and did try hooking the AnimationStart event.  But if I check the animation tags (to figure out whether to block it) at that point, and the animation started with foreplay, I generally don't see the tags I care about.  It works OK, if no foreplay is involved.

 

I don't see another AnimationStart when shifting to the main act, nor do I see an AnimationChange event.  Should I be looking for a different event?

 

I did try hooking the StageStart event, and that detected the conditions just fine - but calling controller.EndAnimation(quick=true) at that point doesn't seem to work cleanly (whereas it does work, if the original animation triggered the blocking check).

 

The Animations property on the thread returns the current animation sets being used, so if you're on a foreplay, it returns foreplay animations.

 

What you can do in that case is hook two separate events, AnimationStart like you are doing, and also LeadInEnd, which is sent after foreplay has ended, and the Animations property has swapped over to using the non foreplay animations.

 

There is also a LeadIn property on the controller you can check as well to see if it's running foreplay at that time or not.

[stobor]

Hooking LeadInEnd did the trick.  Thanks.

[Ashal]

New development version pushed

 

I've completed restructuring all the frameworks code to how I plan it to be for v1.20. This new version includes a complete removal of over 60 scripts, trimmed down to a couple couple smaller and simpler ones.

 

The main focus of these changes was just the restructuring, I did very little optimization as I went, so most of the meat of the code is identical, just massively moved around, you'd be hard pressed to find code that's in the same place it was before.

 

The configuration menu is currently fairly broken right now, but everything else works fine as far as I can tell, just don't plan to on changing most settings.

 

As the goal of this version was mostly restructuring, after I get the configuration menu working properly I'll be starting on the optimizations & stability. Hoping to be finishing that sunday so I can release a full beta patch of v1.20.

[Jay1646]

Can't wait Ashal thanks for all your hard work!!!

 

[xaz]

 

 

float display = ActorRef.GetScale()
ActorRef.SetScale(1.0)
float base = ActorRef.GetScale()

Scale = ( display / base )
ActorRef.SetScale(Scale)
ActorRef.SetScale(1.0 / base)

Is a much easier way to set them to the chosen scale, in this case 1.0, and is already implemented in the development build as a means to get all actors to the same height for animation alignment reasons. ActorRef.SetScale(Scale) resets them to their original.

 

Universal pregnancy stuff is all best left to 3rd party mods using SexLab as a base, I have no intrest in adding it directly to SexLab as it doesn't really fit as a component of a base framework. A pregnancy system other SexLab mods can use as a resource is perfectly suited as an extension of sexlab rather than at it's base. Just like redneck2x is doing with his arousal system, providing a unifying arousal framework for SexLab.

 

 

From what I've seen SetScale(1.0) on an actor who's base is 1.0 and the actor is 0.95, you'll not get 1.0, you get 0.95.  The actor has a height offset (not sure where/how), but the actor gets the scale based off it's base and then modifies it based on it's height alteration.  Was making me wonder why my transformed actors were either getting shorter or taller depending, until I looked into this farther.  Seems I have to add the difference from the base to the actor and set that instead.  So setting it to 1.05 would give the actor 1.0.  Since doing those calculations, I can put that scale back directly and the actor is 100% accurate, plus, if you don't round the number of their scale up, you'll find they'll start to shrink/grow on you.  (Float error in the 3rd digit in, usually winds up as a 7 or 8.  0.95 wound up as 0.947 a lot of the times while I was testing, hence the round up.)

 

Actually, they don't add together. They multiply together, which is why you get the "rounding errors".

 

Math: 0.95*1.05*0.95 = 0.947625

Or in english: If you have an actor of size 0.95, and you attempt to grow to 1.0 by scaling 1.05 times that size, then reverting back to 0.95 (attempting to shrink back to original), you'll be slightly smaller than when you started.

 

The equations that Ashal posted are correct. You can test this yourself by setting more extreme sizes where the difference between multiplying and adding becomes more significant.

[Ashal]

 

 

float display = ActorRef.GetScale()
ActorRef.SetScale(1.0)
float base = ActorRef.GetScale()

Scale = ( display / base )
ActorRef.SetScale(Scale)
ActorRef.SetScale(1.0 / base)

Is a much easier way to set them to the chosen scale, in this case 1.0, and is already implemented in the development build as a means to get all actors to the same height for animation alignment reasons. ActorRef.SetScale(Scale) resets them to their original.

 

Universal pregnancy stuff is all best left to 3rd party mods using SexLab as a base, I have no intrest in adding it directly to SexLab as it doesn't really fit as a component of a base framework. A pregnancy system other SexLab mods can use as a resource is perfectly suited as an extension of sexlab rather than at it's base. Just like redneck2x is doing with his arousal system, providing a unifying arousal framework for SexLab.

 

 

From what I've seen SetScale(1.0) on an actor who's base is 1.0 and the actor is 0.95, you'll not get 1.0, you get 0.95.  The actor has a height offset (not sure where/how), but the actor gets the scale based off it's base and then modifies it based on it's height alteration.  Was making me wonder why my transformed actors were either getting shorter or taller depending, until I looked into this farther.  Seems I have to add the difference from the base to the actor and set that instead.  So setting it to 1.05 would give the actor 1.0.  Since doing those calculations, I can put that scale back directly and the actor is 100% accurate, plus, if you don't round the number of their scale up, you'll find they'll start to shrink/grow on you.  (Float error in the 3rd digit in, usually winds up as a 7 or 8.  0.95 wound up as 0.947 a lot of the times while I was testing, hence the round up.)

 

Actually, they don't add together. They multiply together, which is why you get the "rounding errors".

 

Math: 0.95*1.05*0.95 = 0.947625

Or in english: If you have an actor of size 0.95, and you attempt to grow to 1.0 by scaling 1.05 times that size, then reverting back to 0.95 (attempting to shrink back to original), you'll be slightly smaller than when you started.

 

The equations that Ashal posted are correct. You can test this yourself by setting more extreme sizes where the difference between multiplying and adding becomes more significant.

 

 

For the record, it was Xaz here who came up with the equation being used there, not myself, I just cleaned up his proposed implementation.

 

It's worked great in all my testing, though the concern Guru brings up about actors who are 1.0 to start with I have not tested, but going by the math I can't imagine it being a problem, I would thinking plugging a scale of 1.0 into it would result in well, 1.0, seeing as 1 / 1 = 1

 

I do have some minor concern about the implementation however, according to the creationkit calling SetScale() on the same actor in rapid succession can cause CTD, I don't think calling it 3 times is enough to cause to replicate that, it hasn't caused problems for me, but story may be different for other people.

 

Using SKSE's ActorBase.Get/SetHeight() might provide a solution to cutting some of that out, but I haven't done any experimenting with it to see what sort of value that returns when compared to Get/SetScale()

[Ashal]

I've pushed my  latest development build to Git.

 

Quick update on developments:

• Finished most of the planned thread animation stability and optimization changes planned for 1.20
• Converted configuration menu to use MCM 2.0 state functions where possible, and moved all its config properties out into their applicable libraries
• Since the new version of Schlongs of Skyrim has that I developed the bend integration to work with has been taking awhile to come out, I've gone ahead and converted it to work with existing versions of SOS. Also fixed SOS light compatibility.
• TFC related issues are absolutely a thing of the past now

To do before Beta release:

• Rewrite some of the functions from the thread making system, and add new customization functions to it as well
• Rewrite most of the stat tracking system, and add new functions to it to allow modders to register their own stats for tracking
• Convert cum effects to use spells instead and stack on top of eachother, may also look into adding an option to make them "permanent" on the player requiring them to go into some water in order to "wash" it off

 

May get the beta out as soon as thursday or friday, as the majority of the hard and time consuming stuff of 1.20 is behind me.

[GuruSR]

Actually, they don't add together. They multiply together, which is why you get the "rounding errors".

 

Math: 0.95*1.05*0.95 = 0.947625

Or in english: If you have an actor of size 0.95, and you attempt to grow to 1.0 by scaling 1.05 times that size, then reverting back to 0.95 (attempting to shrink back to original), you'll be slightly smaller than when you started.

 

The equations that Ashal posted are correct. You can test this yourself by setting more extreme sizes where the difference between multiplying and adding becomes more significant.

 

Actually, the rounding error was with SexLab's equations.  I noted the error mid-sex scene.  Why I posted that.  The value during sex wasn't where it was supposed to be (1.0), it did return to normal afterwards.

 

Sadly, fan death (and eventually, the card's voltage regulation for the fan burnt to a crisp) on my video card has made me put everything on hold for my modding (I can mod, but I can't test, the onboard just won't do more than 10fps).  But the test I did, showed the rounding error during the sex scene (SexLab one).  It's supposed to bring the actor to 1.0, but it didn't, was just under it, which threw the visual off a bit (but also caused the actor to sink farther into the ground, doing more offset).  Now, I haven't looked, but is the scaling allowing Havoc to settle the actor, or is the offset difference in the height being calculated and the Z axes set to avoid that?  I know in Oblivion, scaling with allowing the Havoc to settle caused all sorts of bizarre movements (including the actor falling through the ground, which I've seen at the end of a sex scene in more than one place).

 

GuruSR.

[GuruSR]

On SetScale(), with Oblivion (and Skyrim), the Havoc can't adjust the location of the actor (or it'll toss it whereever).  I had one sex scene toss the actor up on a bed (upstairs), the two went at it, then they both fell through the bed and floor to the original floor they were on (it was a fall [fall anim played], not a *pop* back).

 

When setscale/height/weight is done, the Havoc engine first deletes the collision object for the object, changes the desired dimension and recreates the collision object for the object, the problem with that is, this is a threaded game, meaning, mid-deletion of the collision object, the engine could be doing a collision test for another object that comes in contact with that object, this produces a CTD (referencing a now deleted collision object, the game thinks all hell broke loose, and it's right).  The way we were supposed to do it was:  disable collsion, move/size/move/etc object, enable collision.  When changing the scale, it was best to alter the location (Z axes) of the object being scaled so that the object would go up prior to scaling up or go down after scaling down.  This would prevent the havoc engine from settling the actor (and possibly dropping it onto lower orbit).  This all happened a good deal of the time in caves during enslavement sex scenes and some rape scenes outdoors (and indoors), and always happens at the end of the sex scene (when the scaling returns to normal, in the case of my one actor, it gets larger, hence feet fall through the surface they're on).

 

Another note about the scaling, the rounding error, this is also can be caused by a combo of C++ library version and CPU.  The calculations may or may not work on the variety of processors out in the world.  I do know that the C++ library used on the 360 doesn't have this issue (since the rounding error was fixed in it).  Take someone like myself, who has the programming C++ library (SDK, etc), my libraries may not be the same as yours, thus the version I have may not have the rounding fix, or my processor may be causing it due to an error elsewhere in the coding for it.  I know that if *I* manually round the numbers, I will get accurate results regardless of these variants.

 

At the start of a Sexlab sex scene, my one character's base was 1.0 with it being 0.97, thus the value being added should have been 1.03 (to raise my character to 1.0), during the sex scene, I hit tilde and up arrowed for GetScale and pressed enter, the values were 1.02 and 0.99, should have been 1.03 and 1.0, so a rounding error happened.

 

Not blaming anyone who's code did what, so please, don't take this the wrong way!  I'm just stating that errors can and will happen since there are a variety of CPUs and C++ library flavors out there on all machines, not every one will be returning the same result.  During my transformation mod, I was seeing that character slowly shrink, hence my Rounding code being added, after that, the actor never shrank again, and others didn't slowly grow either and I know that this issue won't cause others to on other machines where they don't have the rounding error happening.

 

GuruSR.

[nknight2084]

Is it possible for you to add new category for bed animations like you have for foreplay and aggressive animations?

I've pushed my  latest development build to Git.

 

Quick update on developments:

• Finished most of the planned thread animation stability and optimization changes planned for 1.20
• Converted configuration menu to use MCM 2.0 state functions where possible, and moved all its config properties out into their applicable libraries
• Since the new version of Schlongs of Skyrim has that I developed the bend integration to work with has been taking awhile to come out, I've gone ahead and converted it to work with existing versions of SOS. Also fixed SOS light compatibility.
• TFC related issues are absolutely a thing of the past now

To do before Beta release:

• Rewrite some of the functions from the thread making system, and add new customization functions to it as well
• Rewrite most of the stat tracking system, and add new functions to it to allow modders to register their own stats for tracking
• Convert cum effects to use spells instead and stack on top of eachother, may also look into adding an option to make them "permanent" on the player requiring them to go into some water in order to "wash" it off

 

May get the beta out as soon as thursday or friday, as the majority of the hard and time consuming stuff of 1.20 is behind me.

 

[Demona]

A quick question: if I'm trying the development version, what plugin should I use to start animations? The basic plugins like matchmaker, romance, etc are not really coping with the development build and refuse to start any animations. I'm just curious about trying the development build if it helps me with the constant freezing problems.

[Ashal]

Matchmaker works fine on most recent development build, it's what I use for all my testing while developing, and I wouldn't push a development build public if it wasn't working with it.

[GodSmack]

I'm also having a problem with match maker, it doesn't let me do 3-some and normal sex.

[Ashal]

SexLab v1.20 beta 3

 

Important Note: This is a beta build of SexLab, it contains major changes to the scripting and structure of the mod that have not been extensively tested outside of basic usage. I would in no way recommend saving over your primary character save with this beta installed, as it may cause currently unforeseen issues.

 

If all you want to do is have "the latest and greatest version" and are not willing to post your results of using this beta, than don't use it, what I am interested in here is people's detailed results, downloading it and saying nothing is not helping in anyway and you are better off waiting for the full version.

 

Also note that this is NOT a general tech support thread, I am intrested in hearing 1.20 related problems, and 1.20 related problems only, if a problem appears to be the result of your own botched Skyrim/SexLab install or update, it will go ignored.

 

Must Read/Follow Upgrade Instructions

 

If plan on using a new game for this update, skip steps 2 through 4.

1. IMPORTANT: Delete all previous SexLab Framework script files from your Skyrim's data/scripts folder.
   • Delete any .pex file in the data/scripts folder starting with "ssl" EXCEPT sslMatchMaker.pex and sslMatchMakerMagicEffect.pex
   • Delete data/scripts/SexLabFramework.pex
   • (optional, but recommended) Delete the same files above, only this with .psc extensions and in /data/scripts/source 
2. Disable any SexLab mods you have installed, along with SexLab.esm
3. Load the save game you wish to use the beta on, with all SexLab mods still disabled
4. Wait a couple seconds after loading your game, then save into a new slot
5. Download SexLabFramework.v120.BETA3.7z
6. Extract the downloaded files content into your data folder, overwriting any existing files.
7. Run GenerateFNISforUsers.exe and update the character behaviors, do Creatures behaviors as well if you have FNIS 4.0 and wish to test creature animations.
8. Enabled SexLab.esm and any applicable SexLab mods you wish to use for testing it.
9. Load your save made in step 4, or just start a new game
10. WAIT, you will get a popup soon after loading into the game that says SexLab is installing
11. Do nothing until you get another popup saying SexLab has finished installing
12. Wait a couple more seconds just for good measure.
13. Do whatever it is you people do with SexLab.

 

Upgrading from a previous beta install

 

Just overwrite the existing files, load the game, and do a click Clean System from the Rebuild SexLab MCM page.

 

Testing The SexLab Beta

 

I am expecting the final release of 1.20 to break some sexlab mods, this is unavoidable, I'd suggest doing most of your testing using the plugin SexLab MatchMaker, as I know it works without any problems that are the direct result of the beta itself. While I am interested in knowing what mods get broken by 1.20, realize there is little I can do about it short of throwing out many of the important scripting changes made in 1.20. I have made every reasonable effort I can to make sure 1.20 stays as backwards compatible as possible, but ultimately there will be a few unavoidable casualties, and it's up to the mod makers to update their mods for 1.20 if need be.

 

If you come across an issue related to the beta, POST YOUR DEBUG LOG. Unless you have a fucked up load order, which would likely mean fixing your problem by using BOSS, posting them are 90% of the time completely useless, load order matters little to SexLab. On the other hand, SexLab tends to be good about reporting errors it comes across to the debug log, there are few things more telling about a problem in Skyrim then checking your damned debug log. If you don't know how to check it, read here: http://forums.steampowered.com/forums/showpost.php?p=31562721&postcount=2

 

In addition to posting your debug log after having an issue with the beta version, repeat the problem atleast once, explain how you were able to repeat it, and if it was on a new or existing save.

 

If you had stability issues with a previous version of SexLab, I would also like to know if this version fixed it for you or not.

 

What This Beta Is Not

• It does NOT contain many of the planned API additions I want  to make available to modders with the final 1.20, though it does contain a few.
• It does NOT contain creature animation support, it is still up in the air whether or not I will include this with the final 1.20 release
• It does NOT contain any "perceptible" additions to 1.15b that the average user would notice, it is mostly a scripting overhaul, bug fix, and stability release
• It does NOT contain all the final animations, I will be adding some new animations made by LoversLab members, and catching up on the missing AP animations.
• It is NOT Completely bug free yet, I still have some stuff to fix before final 1.20 release

 

What v1.20 Beta 3 Has

• Several new API features for modders that will be documented post final release.
• Creature animation support. Once properly upgraded, creature animations will be disabled by default.
  • Requires FNIS 4.0
  • Requires FNIS Creature Pack
  • Run GenerateFNISforUsers.exe with the 'FNIS Behavior "Creatures"' in addition to the 'FNIS Behavior "Characters"' button
  • Enable Creature Animations in the Animation Settings page of the SexLab MCM
  • Should work out of the box with any SexLab mod that doesn't require you talking to them to initiate an animation. Though I have only tested them with MatchMaker.
• Heavily reworked actor positioning system, actors will stay in place better and align better as a result.
  • You may notice the Player TCL option is gone, it is 100% unneeded as the result of these changes, all actors have their collisions turned off on an individual basis, rather than just when the player is involved.
  • The Rough Behind animation is turned back on by default as it now lines up properly as a result (SOS users beware though, you'll see why...)
  • There is currently a bug from this new system that will cause you to run in place when using the Move Scene hotkey, rendering it useless, will be fixed before release.

 

Download

For the love of Talos and my few remaining glimmers of hope for humanity; do not click the link below unless you read and understand all the above text in this post.

 

SexLabFramework.v120.BETA3.7z

 

 

[Guest plobis]

/e Nevermind seems to be solved, I hope.

[Liuli]

Testing 1.20 beta 1.

 

Tried out a few sex scenes in succession as well as a threesome. Everything works great. No undress lag, no missing strapons, quicksaving afterwords doesn't cause a crash.

 

Triggered the scenes with SexLab Submit's dialogue component and SexLab Romance, neither had problems, which is actually good to see that SexLab Romance still functions properly and can even trigger the threesomes after the changes (as it wasn't updated since may).

 

On install I'm getting a message that the game is installing version 1.19 of SexLab. As that's the only "problem" I've noticed at all, version 1.20 looks very solid.

[shinji72]

I had much more problems.... 

First to be said... I use Mod Manager. So, on a "old" game, I just untick LL framework 1.15 and then (after the "clean" install) make it load the 1.20. And I run also Fnis 4.0.
 

Sometimes the SOS stayed flaccid. Sometimes the animation didn't start (with Defeat). 

But above all I've notice an issue with Radian prostitution...

When the sex finish... I can talk to the client and ask for the payment... and he answer affirmatively...  but then there is no money exchange and the client keeps following me...

 

This was an issue that came up every single time I tried...

I 

[Jakebiobommer]

Updated from 1.14 -> 1.20 and here is what I've found!

 

Positives:

- Animations in this version are a lot more quicker and snappy when toggling through scenes. Very Nice.

- Default Player and NPC alignment have been greatly improved.

- Fewer crashes when multiple groups are utilizing Sexlab. *Tested with about 20 NPC's simultaneously * (Random Sex)

- Cum textures do not disappear anymore.

- Overall. A more solid script. A great improvement.

 

Negatives:

- If any NPC is utilizing Sexlab and player starts an animation (Ex: Masturbation) while NPCs are still engaged, breaks there animation and NPC's all stand for a while. 

- Sudden alignment bug is still present at the beginning of the first animation. NPC suddenly jumps in first few seconds of animation. *Fixed when you change animation or move positions*

 

SoS related:

- In some animations schlongs are fully upwards. So far that they touch the stomach. 

- Other times schlongs are flaccid throughout animation. 

- Ability to adjust players schlong broken.

 

 

That's all I've noticed so far, if I find anything else (Positive or Negative) I'll edit my post.

This update seems very well built. Very stable, fantastic work as usual Ashal! 

[WizzyD]

don't feel like looking for this option but.

 

is there a way to turn off smart ai npc's... like serana?

[m593691259]

I had much more problems.... 

First to be said... I use Mod Manager. So, on a "old" game, I just untick LL framework 1.15 and then (after the "clean" install) make it load the 1.20. And I run also Fnis 4.0.

 

Sometimes the SOS stayed flaccid. Sometimes the animation didn't start (with Defeat). 

But above all I've notice an issue with Radian prostitution...

When the sex finish... I can talk to the client and ask for the payment... and he answer affirmatively...  but then there is no money exchange and the client keeps following me...

 

This was an issue that came up every single time I tried...

I 

Same problem...

[Ashal]

Number of people who have followed instructions on reporting issues with the beta: 0

[cretin]

Well that was very interesting...

 

I followed instructions to the letter (I fully understand clean saves).  Purged all SexLab bits including xaz and Zaz stuff.  But MCM was being very weird-- it wouldn't release the old SexLab menus.

 

I purged everything, performed a clean save, confirmed that the MCM was empty of any SexLab menus.  Upon reloading with the new 1.20 Beta active, however, I think the old SexLab MCM menu stub was still there, conflicting with the new "SexLab Framework" menu upgrade/installation; the result was the old "SexLab" MCM menu, completely empty.

 

I had to load the clean save without SexLab active again (and hell, there are those old SexLab menus this time.  In a clean save, with no SL mods active.  All empty, but the stubs were there.  Weird...), then do a:

 

setStage SKI_ConfigManagerInstance 1

 

At that point MCM purged the old SexLab menus, then I could reload with the 1.20 beta framework active, and the new menu installed correctly.  I should note that I tested two savegames, one 500+ hour and the other had the old SL but had never left the post-character-creation AlternateStart prison.  Maybe fifteen minutes on that one.  The above command had to be performed for each one, separately.  However, a completely *new* game (as opposed to a clean save) had none of these shenanigans.

 

So, not SexLab related per se, just MCM / SkyUI being weird.  But if it happens that you see an empty SexLab menu...  well, there you go.

PapyrusLogs.7z

[WaxenFigure]

Number of people who have followed instructions on reporting issues with the beta: 0

From the post where you were told what to do when reporting a problem (emphasis added):

 

If you come across an issue related to the beta, POST YOUR DEBUG LOG.

 

That's not all, please go back and read the rest of the paragraph that came from.

[Aleanne]

I wanted to try this new version, to see if I would get rid of the "R6025 pure virtual function call" (C++ runtime error) crashes I'm getting with 1.19b. No dice, I'm still getting those.

I'm also getting "Null start: [Actor < (00000014)>]", on current and new games. PC is floating in the middle of nowhere for some seconds, then get teleported back into action but does not participate. Controls are disabled.

 

The test was made with all SexLab mods deactivated except Matchmaker.

 

Here is a debug log.  It ended with a "R6025 pure virtual function call" crash.

Papyrus.0.log.7z

[Jay1646]

Did a completely clean game 

 

testing it out so far

 

works flawlessly, having no freezing issues what so ever