Jump to content

SexLab Framework Development


Recommended Posts

I'm probably just retarded and can't read, and apologies if this is not the right place to ask, but question:

 

Is there a way to disallow female characters from partaking in a MF scene? I'm trying a lebian run without futa (this time), but all to often female NPCs will start dry-humping me with invisible strap-ons. I thought that by disabling strap-ons I would be more non-dick scenes, but it didn't. SexLab Tools scene changer will only let me swap between MF tagged scenes when the invisible dildo comes out, so there isn't really a way for me to ignore it. I'm not dissing strap-on use, I just wanted to make more female on female sans penis scenes happen.

Edited by dovahnurse
accidentallly made a quote post instead of edit. Fixed that.
Link to comment
  • 3 months later...

Hey every one

I cannot get or set Stage 

The Messagebox works but content always 0

and SetAnimation same not work

Someone can help me?

Event AutoPlayQSH_Func(int tid, bool has_player)
	sslThreadController Controller = SexLab.GetPlayerController()
	Debug.Messagebox(Controller.Stage)
	Controller.SetAnimation()
	Controller.GoToStage(2)
EndEvent


event OnPageReset(string page)
	RegisterForModEvent("HookOrgasmStart", "AutoPlayQSH_Func")

 

Edited by DragonQuest
Link to comment
  • 9 months later...
  • 3 weeks later...

Nothing like the wholesome family activity of testing Random Sex for Thanksgiving... ?

 

Ran into an issue when testing Random Sex NG. Firstly, it seemed that SexLab was overriding the animations I was feeding to it from my evaluation code. That one was easily fixed by manually pulling a thread and setting the custom animation. However that revealed another issue.

 

Let's take anal animations. Sexlab usually sets these up as index 0 = female (victim) and index 1 = male/strapon. However my code is smart enough to figure out that the victim can be male or female in these cases (no strapon), so when my male player is involved, they are dutifully set up at the victim index = 0. However, when Sexlab starts the sex act, the player is now in the attacker position and my female follower, who I expected to be giving the player the mother of all strapon butt-fuckings, is now being victimized by the player.

 

Is there any way to override the default actor sorting and assign participants to the animation positions in the order they are presented, without regard for the gender settings for each animation position?

 

Edit #1: Did some digging around in the code and this line looks like the culprit (SSLThreadController.setAnimation(), around line 690) - Should be easy enough to create a bool property in SSLThreadModel and wrap an if statement around this line.

 

Positions = ThreadLib.SortActorsByAnimation(Positions, Animation)

 

Edit #2: Confirmed this is the culprit. Made changes to Sexlab above, updated Random Sex papyrus to override new SortActors property to false, female followers are butt-fucking the player now. And it is glorious!

 

Edited by Arizona_Steve
Link to comment

Also while I'm here - the sync lock problem still shows up with 3p+ animations. I know I have had discussions with others in the past about this, but changing the interval from 0.01 to 0.1 really helps with this in practice - probably has something to do with my framerate being maxed out at 60fps and 0.01s being less than one frame. Please consider making this change:

 

SSLThreadModel - around line 1850 (from my own copy of Sexlab, where I have made the change)

 

function SyncEventDone(int id)
    while SyncLock
        Log("SyncLock("+id+")")
        Utility.WaitMenuMode(0.1) ; Change 0.01 to 0.1 here
    endWhile

    ; Remainder of function

endfunction

 

Edited by Arizona_Steve
Link to comment
  • 2 weeks later...

hi im having trouble setting up sexlab, when i first load up the game and head to my mod manager menu, i click to install the mod it doesnt do anything.
https://imgur.com/a/E8L1b38
i have:
Xp32 SE
Unofficial sse patch
SkyUI
SKSE
SexLabFrameworkSE
RaceMenu SE
FNIS spells
FNIS behavior
FNIS creature pack
Alt start
Address library for skse all in one se

EDIT: i realize now that i had to downgrade my SE file, didnt know that i had the AE update

Edited by Vexply
Link to comment

Some suggestions I would like to still see in sexlab:

1) I believe that unequip ammo mods are still required as SL is not taking off ammo for sex. Please correct if I am wrong.
2) I have highly polarized skyrim and there are many size of people. As physics and new bone slots have come into play it should be possible to do better actor alignment for the sex scenes when actors have differences.
3) Better support and alignment for sexanimobjects. Currently all objects misalign all the time.
4) Better arm handling for all animations. Arm bones are often the ones that break. There is mod called mujoint fix that helps the knees.
5) SLAL is almost essential for sexlab. It should be integrated to SL.
 

NOTE: proposing fixing these in the anim editor is not solution and all these features are part of SL. Also ticking scaling is not real option.

Link to comment
1 hour ago, poporaltemporal said:

I have highly polarized skyrim and there are many size of people. As physics and new bone slots have come into play it should be possible to do better actor alignment for the sex scenes when actors have differences.

The current version of SexLab Framework have very good alignment system that is able to align without issues Mods like "Racial Body Morphs SE - Diverse body types and height by Race and Gender" that have part of the scale defined in the skeleton instead of the actor.

You only have to disable the "Even Actors Height" option and take the effort of align each scale combination. 

 

 

Edited by OsmelMC
Link to comment
1 hour ago, poporaltemporal said:

Better support and alignment for sexanimobjects. Currently all objects misalign all the time.

The AnimObject are part of the animation and comes attached to the animation of one of the actors so the scale and alignment of that object depends of the actor using that animation. The problem is that the AnimObject not always  comes attached to the right actor and that's something you have to talk with the author of the animation.

By other side the next version should come with real furniture support that allow you get rid of many of the AnimObject of furnitures and use real furnitures compatible with the alignment system.

Edited by OsmelMC
Link to comment
1 hour ago, poporaltemporal said:

SLAL is almost essential for sexlab. It should be integrated to SL.

SexLab have it's own animation loader since I have memory but none animation author's use it. Even allow you do more elaborate animations.

 

Also SLAL and SexLab Framework have different author's so matter of Rights.

 

 

2 hours ago, poporaltemporal said:

Better arm handling for all animations. Arm bones are often the ones that break. There is mod called mujoint fix that helps the knees.

Arm's and Legs! The Legs are more or less supported by Skyrim and usually is enough with enable it on the animation or using another Mod. Sadly the arm's are very different from the legs for many tech reasons. The only possible and practical solutions for that is a filter to exclude any animation not suitable for the scale difference between the actors.

Link to comment
  • 3 weeks later...

One of the things that take the most time in waiting for a sex act to start is that Sexlab is expecting a "Bound" (tied up or in bondage furniture) NPC to move to an unbound NPC.  When Sexlab is picking which actor is the "center" of the sex act and who has to move the "bound" actor should be both the center and the one that does not have to move.  If there is more than one bound actor in the sex act just forget walking entirely and jump to the "teleport" system because that was never going to be realistic anyway.

 

And yes, I've seen this many, many times and am wondering why I never reported it in the past and of course why no one else reported it either.  Or am I just not seeing something else that makes it have to be this way?

Edited by WaxenFigure
Link to comment
4 hours ago, WaxenFigure said:

One of the things that take the most time in waiting for a sex act to start is that Sexlab is expecting a "Bound" (tied up or in bondage furniture) NPC to move to an unbound NPC.  When Sexlab is picking which actor is the "center" of the sex act and who has to move the "bound" actor should be both the center and the one that does not have to move.  If there is more than one bound actor in the sex act just forget walking entirely and jump to the "teleport" system because that was never going to be realistic anyway.

 

And yes, I've seen this many, many times and am wondering why I never reported it in the past and of course why no one else reported it either.  Or am I just not seeing something else that makes it have to be this way?

I added a warning indicator in Aroused Creatures' MCM Help page advising users to turn off SL's Disable Starting Teleport option to avoid such delays. This is a particular problem with large creatures such as horses, who don't appear to be able to get within the required distance from the target, probably due to the size of their collision box.

 

I think it's possible to skip the travel behaviour by not providing a CenterOnObject reference to the thread, but more often than not we still want to control where the animation takes place.

 

Maybe travelling to the animation site is something that should be left to the implementing mods rather than SL? Or perhaps an option on the thread controller to let developers skip it when it's redundant or problematic?

Edited by Sailing Rebel
Link to comment
4 hours ago, WaxenFigure said:

One of the things that take the most time in waiting for a sex act to start is that Sexlab is expecting a "Bound" (tied up or in bondage furniture) NPC to move to an unbound NPC.  When Sexlab is picking which actor is the "center" of the sex act and who has to move the "bound" actor should be both the center and the one that does not have to move.  If there is more than one bound actor in the sex act just forget walking entirely and jump to the "teleport" system because that was never going to be realistic anyway.

 

And yes, I've seen this many, many times and am wondering why I never reported it in the past and of course why no one else reported it either.  Or am I just not seeing something else that makes it have to be this way?

SexLab don't even detect the bondage on the actors and of course don't have furniture support so unless the future be a Bed, SexLab will try to start the animation far away as possible from the furniture. Thing's like that should be treated by Mods like DDi or ZAP.

 

My SLU+ support Furnitures, DDi and ZAP.

Link to comment
4 minutes ago, Sailing Rebel said:

This is a particular problem with large creatures such as horses, who don't appear to be able to get within the required distance from the target, probably due to the size of their collision box.

 

On the SLU+ and future versions of SexLab Framework the walk to the center is done already as parallel function together with the strip while the rest of the process are being executed so don't take extra time. Also the real size of the creatures and furnitures are take in consideration for the min distance. 

Still need a bit more of work to be perfect but is way better than the original method.

 

 

Link to comment
  • 1 month later...
On 5/31/2017 at 7:33 PM, MadMansGun said:

the last stage in that animation was made for scale 1 for some unknown reason.

 

no, they all count as a different race but share sexlab animations between them, the scaling is just a part of the problem that is going on.

post-71862-0-36732800-1496249412_thumb.jpg

 

Chaurus and Chaurus Reaper in same animation pool
    ClearRaceKey("Chaurus")
    AddRaceID("Chaurus", "ChaurusRace")
    AddRaceID("Chaurus", "ChaurusReaperRace")
    AddRaceID("Chaurus", "DLC1_BF_ChaurusRace")

small spider on its own (like they all should be)
    ClearRaceKey("Spiders")
    AddRaceID("Spiders", "FrostbiteSpiderRace")
    AddRaceID("Spiders", "_00ChaurusCrawlerRace")
    AddRaceID("Spiders", "_00DwarvenSpiderBoltRace")
    AddRaceID("Spiders", "_00DwarvenSpiderFireRace")
    AddRaceID("Spiders", "_00SkeletonSpiderRace")

large and Giant Spiders in same animation pool
    ClearRaceKey("LargeSpiders")
    AddRaceID("LargeSpiders", "FrostbiteSpiderRaceGiant")
    AddRaceID("LargeSpiders", "FrostbiteSpiderRaceLarge")
    AddRaceID("LargeSpiders", "_00ChaurusCrawlerRaceGiant")
    AddRaceID("LargeSpiders", "_00ChaurusCrawlerRaceLarge")

truth be told i think the bug races would be better off if they were removed form SexLab and re-added to MNC & SLAL, it wont fix the re-scaling problem but it would fix the pool problem.

 

I may be necroposting about this issue, but it's something I've met repeatedly. I feel like the issue isn't one of scaling, but the animation that play are tagged either as "spider" or "giant spider" and "chaurus" or "chaurus reaper", but in effect it doesn't seem like the game tags the actual creatures as such. If there was a way to make the game tag each creature size in a way that sexlab could recognize, then it might be able to play the right animation for the right creature size. Is there any way to make that happen reliably?

Link to comment
19 minutes ago, Arkanium said:

 

I may be necroposting about this issue, but it's something I've met repeatedly. I feel like the issue isn't one of scaling, but the animation that play are tagged either as "spider" or "giant spider" and "chaurus" or "chaurus reaper", but in effect it doesn't seem like the game tags the actual creatures as such. If there was a way to make the game tag each creature size in a way that sexlab could recognize, then it might be able to play the right animation for the right creature size. Is there any way to make that happen reliably?

the race issue was fixed by MNC years ago.

Link to comment
  • 10 months later...
  • 1 month later...
  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use