SexLab Framework Development

[canthics]

I was messing with the code and implemented a way of selecting scene locations with minimal collisions. it involves spawning a bear.

 

when placeatme is used to spawn an actor as opposed to something like a static, it actually spawns it at a location deemed on the ground and free of collisions. that's why when you use placeatme to spawn a bunch of NPCs at once they'll be crowded around you instead of all clipping through you or one another, but you do the same with a chair and it'll just pop wherever you are.

 

so when sslThreadModel determines centering, I spawn a large dummy actor near one of the scene participants and center on its coordinates, then immediately delete the dummy. the dummy will have spawned at a safe location and its coordinates will be used for the scene.

		; Fallback to first position actor
		else
			;CenterOnObject(Positions[0])
			CenterAid = Positions[0].PlaceActorAtMe(SexLab.Data.aaasexbear)
			CenterOnObject(CenterAid)
			CenterAid.Disable()
			CenterAid.Delete()
		endIf

using a brain-dead bear as the dummy spawn because it's a largish mesh and funny, scenes started like this are almost always happening in the safest available spots. it still has trouble if there's a LOT of clutter, particularly near walls and corners, but no more than vanilla. The dummy actor is spawned and deleted so fast that I've yet to even see it yet ingame.*

 

the big drawback I've noticed is the collision checking can be overzealous and pick spots that are fairly far away from either of the actors, probably since it counts the scene participants themselves as potential obstacles. this could be dealt with if actors were to walk to within a distance of the center coordinates before outright moving them.

 

*edit: using placeatme instead of placeactoractme is slower to where you can actually see the bear for a split second before it disappears. in retrospect, a bear isn't the best dummy mesh since its zero pose has it on its hind legs so it isn't as large as I thought for collision purposes. I'll try using a horker or troll instead, but the ideal would just be a primitive anyway. doesn't matter so long as it's an actor.

 

seems promising, just wanted to share.

 

 

[Ashal]

Creating forms using placeatme/placeactoratme and then deleting them will result in save bloat.

 

Creating an actor form results in your save needing to record that new actor existing and then your save also has to record that the actor was deleted. This would be repeated in your save file every time sex started.

 

I could be mistaken, but I'm fairly certain I remember reading this somewhere before while researching similar solutions.

 

Also I don't really see how centering on the bear is any different than centering on one of the actors. The actor is presumably standing on the navmesh, same as the bear would be once spawned.

[Ashal]

Maybe if instead of placeatme, could use moveto instead. Have the bear or whatever off in a closed off empty cell, move that specific bear to the location, run centeronobject, then move them back to the empty cell. That way your using the same form everytime sex starts, rather than making and deleting a form everytime with placeatme; resulting in save bloat.

 

Moveto may have it's own problems though, not sure if moving the bear from a far off cell is possible, or even if it'd be fast enough to not be noticeable when moving the bear from the far off cell. 

[canthics]

Creating forms using placeatme/placeactoratme and then deleting them will result in save bloat.

 

Creating an actor form results in your save needing to record that new actor existing and then your save also has to record that the actor was deleted. This would be repeated in your save file every time sex started.

 

I could be mistaken, but I'm fairly certain I remember reading this somewhere before while researching similar solutions.

 

Also I don't really see how centering on the bear is any different than centering on one of the actors. The actor is presumably standing on the navmesh, same as the bear would be once spawned.

 

The problem I observed with centering on actors is that in too many situations, the actor's collision box is not large enough to ensure that there won't be collisions once the scene is triggered.

situations where there is stuff right next to the actor, or they just stood up from leaning/sitting. spawning a new, big dummy actor basically ensures that there is enough space for the animations themselves because the spawning function picks a larger swath of flat floorspace than either actor is currently standing in. 

 

in practice, it reduces clipping through chairs and rocks and whatnot significantly, and the positioning problems that those types of issues cause. I noticed a huge difference when I tested, but again it is picking an entirely different location from both actors so there is quite a bit of teleporting.

 

As far as bloating is concerned, everything I've read indicates that non-persistent objects that are disabled and marked for deletion avoid bloating. I haven't found anything regarding whether the deletion itself is recorded, though it would seem to defeat the point of the function. Guess only way to find out is to bloat the hell out of a save or at least try to.

[Ashal]

 

Creating forms using placeatme/placeactoratme and then deleting them will result in save bloat.

 

Creating an actor form results in your save needing to record that new actor existing and then your save also has to record that the actor was deleted. This would be repeated in your save file every time sex started.

 

I could be mistaken, but I'm fairly certain I remember reading this somewhere before while researching similar solutions.

 

Also I don't really see how centering on the bear is any different than centering on one of the actors. The actor is presumably standing on the navmesh, same as the bear would be once spawned.

 

The problem I observed with centering on actors is that in too many situations, the actor's collision box is not large enough to ensure that there won't be collisions once the scene is triggered.

situations where there is stuff right next to the actor, or they just stood up from leaning/sitting. spawning a new, big dummy actor basically ensures that there is enough space for the animations themselves because the spawning function picks a larger swath of flat floorspace than either actor is currently standing in. 

 

in practice, it reduces clipping through chairs and rocks and whatnot significantly, and the positioning problems that those types of issues cause. I noticed a huge difference when I tested, but again it is picking an entirely different location from both actors so there is quite a bit of teleporting.

 

As far as bloating is concerned, everything I've read indicates that non-persistent objects that are disabled and marked for deletion avoid bloating. I haven't found anything regarding whether the deletion itself is recorded, though it would seem to defeat the point of the function. Guess only way to find out is to bloat the hell out of a save or at least try to.

 

 

 

I was researching a similar solution to you when I read about the bloating, only instead of spawning a creature I was looking to place a largeish moveable static item with no mesh but flagged as an obstacle, seemed promising, but after reading about potential bloating issues I moved on.

 

Still, may be workable, I can't verify the accuracy of the bloat claims, it was sometime ago and I haven't done any testing myself. And if it does may be that SKSE's function Form.TempClone() may provide some semblance of a solution. 

[canthics]

Maybe if instead of placeatme, could use moveto instead. Have the bear or whatever off in a closed off empty cell, move that specific bear to the location, run centeronobject, then move them back to the empty cell. That way your using the same form everytime sex starts, rather than making and deleting a form everytime with placeatme; resulting in save bloat.

 

Moveto may have it's own problems though, not sure if moving the bear from a far off cell is possible, or even if it'd be fast enough to not be noticeable when moving the bear from the far off cell. 

 

Moveto would have been the ideal solution, but it appears that the collision detection functionality I'm exploiting appears to be exclusive to placeatme on actors.

 

also, if it does bloat, I'd also argue that it couldn't possibly bloat any more than what common spawn increasers such as ASIS and skyrimmorespawns do (and I've not heard about them causing bloat, only instability because people use way too many spawns), as they all use placeatme to proc the extra spawns and don't even bother to delete them. of course, they aren't actually deleting but simply allowing skyrim's native garbage cleanup to deal with non-persistent actors, which may be why they are actually quite stable for modest spawn increases.

 

Thing to keep in mind is this isn't about spawning a stage or a barrier or anything like that. The dummy actor is nothing more than a delivery mechanism for the collision detection functions that kick in when it is placed to find a nice spot to trigger the scene.

[Ashal]

Well looking at creationkit wiki page for placeatme backs you up on disable. It says

 

Objects no longer used should be disabled (through DisableNoWait or a similar function) and marked for deletion (through Delete) to prevent "savegames bloat".

 

 

Where I was reading about the bloat was likely either talking about a specific use case or didn't know better.

[Ashal]

To get around the spawning at a distance problem though, I'd suggest looking to statics rather than creatures, as it carries less overhead. And doing some simple math to scale the object to a size more suitable to the actors involved may alleviate that some.

[canthics]

Well looking at creationkit wiki page for placeatme backs you up on disable. It says

 

Objects no longer used should be disabled (through DisableNoWait or a similar function) and marked for deletion (through Delete) to prevent "savegames bloat".

 

 

Where I was reading about the bloat was likely either talking about a specific use case or didn't know better.

 

we're looking at the same pages. =P

 

apparently non-persistent actor cleanup has been kicking since fallout 3, at least whenever they didn't go ash pile.

 

I'm guessing it's one of those situations where bloat is so gradual it's only going to be confirmable with a lot of testing, which I'm personally fine with. if you want to pursue it further officially, maybe having it as an experimental option would be a way to go.

[canthics]

To get around the spawning at a distance problem though, I'd suggest looking to statics rather than creatures, as it carries less overhead. And doing some simple math to scale the object to a size more suitable to the actors involved may alleviate that some.

 

The problem with using statics is that their placeatme does not have the collision detection built in, which is the whole point of the exercise. they spawn anywhere regardless of open space. I haven't looked at using larger dynamic objects, though, but given that they can be spawn midair (something that the collision checker eliminates for actors) it's not promising.

 

one interesting thing is that I've experimented with different dummy types (just using placeatme for various creatures in the console works here), and the aggressiveness of the collision-detection doesn't always track with the size of the mesh. I've observed that dogs tend to be pickier than cows, for example.

 

but using ingame creatures is just a shortcut. I'd imagine any serious implementation would just be an actor that's just a sphere or a box.

 

also, testing...

 

 

 

[Ashal]

In other experimenting news. I was messing around with methods of making actors walk to each other before starting a scene instead of warping.

 

Or rather at least get near each other before warping instead of being 30+ feet away. The warping itself in unavoidable due to the nature of animation offsets.
 
The problem I always came across with it was figuring out how to wait for them to be in place before starting animation, or making them all do it at the same time instead of taking turns. I came close to a solution while testing, but had to call it a night as  I had just spent literally the entire day getting v1.12 ready/released and really just needed to get away from SexLab for my own sanity, haven't revisited it since.
 
Here's a basic bastardized quick version of what the solution was, as I threw out the code without committing my changes to my experimenting git branch in a moment of passion wanting to be free of SexLab for the day after 15-16 hours straight of nothing but SexLab work.
 
Normally sslThreadController starts the animation with PrimeThread(), going into the Preparing state to ready the actors, followed by the states for animation looping/timing.
 
Replacing the Preparing state with 5 separate states for each actor slot, lets them strip and move at the same time like so:
 

bool Actor0Ready = false
bool Actor1Ready = false
bool Actor2Ready = false
bool Actor3Ready = false
bool Actor4Ready = false

sslThreadController function PrimeThread()
	; // Other unimportant PrimeThread() stuff
	GotoState("PrepareActor0")
	RegisterForSingleUpdate(0.01)
	return self
endFunction

state PrepareActor0
	event OnUpdate()
		GotoState("PrepareActor1")
		RegisterForSingleUpdate(0.01)
		; // The actor being prepared
		actor position = Positions[0]
		; // Latent actor path to CenterRef
		position.PathToReference(CenterRef, 0.8)
		; // Begin slowed stripping with animation
		form[] equipment = SexLab.StripSlots(position, GetStrip(position), true)
		if equipment.Length > 0
			StoreEquipment(position, equipment)
		endIf
		; // Disables their movement and crap
		SetupActor(position)
		; // Mark as ready
		Actor0Ready = true
	endEvent
endState

state PrepareActor1
	event OnUpdate()
		GotoState("PrepareActor2")
		RegisterForSingleUpdate(0.01)
		; // The actor being prepared
		actor position = Positions[1]
		; // Latent actor path to CenterRef
		position.PathToReference(CenterRef, 0.8)
		; // Begin slowed stripping with animation
		form[] equipment = SexLab.StripSlots(position, GetStrip(position), true)
		if equipment.Length > 0
			StoreEquipment(position, equipment)
		endIf
		; // Disables their movement and crap
		SetupActor(position)
		; // Mark as ready
		Actor1Ready = true
	endEvent
endState

; // state PrepareActor2 Here

; // state PrepareActor3 Here

state PrepareActor4
	event OnUpdate()
		GotoState("EndPrepare")
		RegisterForSingleUpdate(0.01)
		; // The actor being prepared
		actor position = Positions[4]
		; // Latent actor path to CenterRef
		position.PathToReference(CenterRef, 0.8)
		; // Begin slowed stripping with animation
		form[] equipment = SexLab.StripSlots(position, GetStrip(position), true)
		if equipment.Length > 0
			StoreEquipment(position, equipment)
		endIf
		; // Disables their movement and crap
		SetupActor(position)
		; // Mark as ready
		Actor4Ready = true
	endEvent
endState

state EndPrepare
	event OnUpdate()
		while !Actor0Ready || !Actor1Ready || !Actor2Ready || !Actor3Ready || !Actor4Ready
			; // Hold here until all preparing states give the ready signal
		endWhile

		; // Other unimportant prepartion stuff here

		; // Start the actual animation loop
		RealignActors()
		GotoState("BeginLoop")
	endEvent
endState

That's not everything, and it 100% wouldn't work in that state, since I didn't save my attempts thats more or less just a quickly written example of the idea behind it.

The problem I came across however; was trying to juggle around the different actor setup stuff, since the current SetupActor() function does everything in one swoop, so some of it's actions, particularly disabling their movement had to be moved to be done after they've already pathed to CenterRef, and stuff like slotting their DoNothing alias to force their AI out of choosing to the ignore the PathToReference command to be done before it.

It had mild amounts of success, it would stick infinite looping on EndPrepare in most cases; laregely from an actor freezing in place, not able to path to the given center reference and thus standing there doing nothing as a result, stopping their ActorReady bool from flipping. Or their vanilla AI taking precedence and them just walking about their own way patrolling the streets, all the while stripping themselves naked.

Had better success with them moving to the center reference reliably using Actor.KeepOffsetFromActor(CenterRef), but that presented other hurdles as well, since it doesn't delay it's return until the the actor is within the given offset, and instead just returns right away; resulting in them taking 1 or 2 steps, stripping, then warping into place like normal.

Was close to figuring it out when I called it quits for the day, but failing being able to get them to reliably walk to each other, it proved a workable solution for making all the actors strip at the same time instead of taking turns stripping like they do now in v1.12.

[Ashal]

Or rather at least get near each other before warping instead of being 30+ feet away. The warping itself in unavoidable due to the nature of animation offsets.

 

 

Or maybe it is avoidable? Thinking maybe instead of pathing the actors to the center reference, maybe if they pathed to their first animations offset coordinates instead of us using SetPosition()/SetAngel() to warp them to those coordinates. It would make the transition into animating much more seamless if so.

 

Maybe anyway, it would have to use a method similiar to what Canthics is trying with setting the center location, since as far as I know there is no method of making an actor path to coordinates, would have to spawn a temporary marker in their offset coordinates and path the actor to that before removing the marker.

[WaxenFigure]

To get around the spawning at a distance problem though, I'd suggest looking to statics rather than creatures, as it carries less overhead. And doing some simple math to scale the object to a size more suitable to the actors involved may alleviate that some.

And make it an invisible object/actor so even it if takes a moment to place and remove it, no one is going to see it happen (might want to test with a visible object/actor though).

[Ferrox]

Ashal, I know it has to be possible to recognise the original voices for the characters, because there are other mods that make a character respond only using vanilla lines, but never in conflicting mods.

 

I use a mod called vanilla voices, and it works pretty fine (though I will sugest that for another male voice the author checks out this mod made for a younger elf voice), but both for this mod AND for your own voice set, is it at all possible to check the original vanilla voice and then select the best suited voice file?

 

Even if you don't use the vanilla voice mod, then at least you can sellect when to use huskier or higher voices...

 

Sorry to seem demanding, but it would make Sex Lab more immersive. Rather than now selecting a single voice and then innitiating sex.

[canthics]

 

To get around the spawning at a distance problem though, I'd suggest looking to statics rather than creatures, as it carries less overhead. And doing some simple math to scale the object to a size more suitable to the actors involved may alleviate that some.

And make it an invisible object/actor so even it if takes a moment to place and remove it, no one is going to see it happen (might want to test with a visible object/actor though).

 

 

I'm using modified versions of vanilla actors right now just for testing purposes, and it's already completely unnoticable 99% of the time. the other 1% occurs when there's a lot happening scriptwise (many scenes) and it's usually little more than a flicker or a shadow.

 

in practice, it would be trivial to slap a transparent texture on the dummy, but that's not needed at the moment. unfortunately I've completely forgotten how to do anything with nifs, so If anyone out there has the skill to create an actor with mesh that is a transparent but collidable primitive with sufficient dimensions to completely enclose say, a large horker, that would be the ideal dummy actor to test with.

 

with what ashal's trying to do with pathing actors to offsets, using markers would be sufficient. they're lightweight and invisible.

 

 

I use a mod called vanilla voices, and it works pretty fine (though I will sugest that for another male voice the author checks out this mod made for a younger elf voice), but both for this mod AND for your own voice set, is it at all possible to check the original vanilla voice and then select the best suited voice file?

 

Even if you don't use the vanilla voice mod, then at least you can sellect when to use huskier or higher voices...

 

LPK let you assign permanent voices to NPCs at will as well as track their sex stats. I think it did it using metadata in invisible inventory objects. Wonder if that's feasible here; it would certainly open up a lot of interesting possibilities.

 

Aside from that, I think the API should have voice selection, so it's not necessarily something the framework needs to include (though would be nice for consistency sake).

[easykill]

It would be nice to have multiple cum effects that are chosen from randomly and can stack. Go to an orgy and come out covered

 

Also if it is just a performance issue, an mcm option or something for higher res cum would be cool.

[WaxenFigure]

It would be nice to have multiple cum effects that are chosen from randomly and can stack. Go to an orgy and come out covered

 

Also if it is just a performance issue, an mcm option or something for higher res cum would be cool.

I suspect that if someone were the take the time to make several cum textures to use that Ashal would be happy to implement them. Seriously, if you have the skill and you want this, put the skill to use. Ashal is not going to be able to do it all himself and I'm thinking that textures etc like this are outside his skill set.

 

(Not really trying to demand you personally do it, just wanting to put the challenge out there. I know we have people with the skills using this mod).

[nknight2084]

I am having alignment problems with SOS and UNPB (xpms included). Is better males and UNPB (xpms included) the best set up to get alignment for most animations?

[ballsy]

 

It would be nice to have multiple cum effects that are chosen from randomly and can stack. Go to an orgy and come out covered

 

Also if it is just a performance issue, an mcm option or something for higher res cum would be cool.

I suspect that if someone were the take the time to make several cum textures to use that Ashal would be happy to implement them. Seriously, if you have the skill and you want this, put the skill to use. Ashal is not going to be able to do it all himself and I'm thinking that textures etc like this are outside his skill set.

 

(Not really trying to demand you personally do it, just wanting to put the challenge out there. I know we have people with the skills using this mod).

 

The higher res cum option sounds fairly simple at least. It would pretty much be the matter of getting the original (highest resolution) textures then running that through DDSopt into various lower resolutions. 5 minutes tops. 

[AwfulArchdemon]

Will there be an option to use alignment keys when being raped? My alignment issues come from being the victim (defeat), and the alignment controls don't appear to work then.

[WaxenFigure]

 

 

It would be nice to have multiple cum effects that are chosen from randomly and can stack. Go to an orgy and come out covered

 

Also if it is just a performance issue, an mcm option or something for higher res cum would be cool.

I suspect that if someone were the take the time to make several cum textures to use that Ashal would be happy to implement them. Seriously, if you have the skill and you want this, put the skill to use. Ashal is not going to be able to do it all himself and I'm thinking that textures etc like this are outside his skill set.

 

(Not really trying to demand you personally do it, just wanting to put the challenge out there. I know we have people with the skills using this mod).

 

The higher res cum option sounds fairly simple at least. It would pretty much be the matter of getting the original (highest resolution) textures then running that through DDSopt into various lower resolutions. 5 minutes tops.

 

I posted the original 4k textures here just this week but that's NOT what I was proposing. I'm not talking about multiple resolutions of a single texture. I want to see multiple textures that can overlap and if you get enough of them quickly your character will show a lot of cum, not just the one single cum texture that is always applied right now.

[Sensual Nautilus]

Will there be an option to use alignment keys when being raped? My alignment issues come from being the victim (defeat), and the alignment controls don't appear to work then.

 

I don't want to sound condescending, but SexLab has been packaged with the option of enabling and disabling controls during in a victim position which can be found at the animation settings for a very very long time, unless I misread your post. Only issue I have right now is the annoying jitter bounce that occurs everytime I shift forward or backwards... or atleast I used to. current versions of sexlab (dev and official versions) are extremely broken for me.

 

[AwfulArchdemon]

 

Will there be an option to use alignment keys when being raped? My alignment issues come from being the victim (defeat), and the alignment controls don't appear to work then.

 

I don't want to sound condescending, but SexLab has been packaged with the option of enabling and disabling controls during in a victim position which can be found at the animation settings for a very very long time, unless I misread your post. Only issue I have right now is the annoying jitter bounce that occurs everytime I shift forward or backwards... or atleast I used to. current versions of sexlab (dev and official versions) are extremely broken for me.

 

 

It's not letting me adjust my character (K), just his.

 

Edit: @Sensual Nautilus, fyi, I've only been using using Sexlab for less than a week, oh condescending one . Still learning it. So far, this is the only problem I've had, but when it comes to sex anims, alignment is sort of a big deal.

[Crate123]

I am having alignment problems with SOS and UNPB (xpms included). Is better males and UNPB (xpms included) the best set up to get alignment for most animations?

 

UNP Skinny and SoS are going to be the default bodies used for animations so you should get the best result using those.

Oh and use even heigh on actors, that helps too.

[Stormsone]

Is it possible to make it so audio has more folders that play during different situations? Right now there is basically one folder that plays during consensual sex only,one that plays during both rape and consensual, and one that plays during the final stage. I was hoping that you could add a folder that would only play during rape and a folder that would only play during foreplay.