SexLab Framework Development

[Someone92]

If I remember correctly the 'hook' of an animation is now added to an animation as a tag, and GetHooks() returns an array with all tags as an array.

 

If possible I would like to see the following two functions:

- int function HasTagInt(string tag)

Returns -1 is the animation doesn't have said tag, returns the index in the GetHooks() array if it exists

- string function GetTagInt(int index)

Returns the tag at the specific index of the GetHooks() array

 

With those functions mods/plugins could communicate with each in a limited way directly over the framework. E.g. a mod could add a specific trigger string to an animation, and behind it another string that specifies what exactly should be done; the other mod would try to find said specific trigger string, and, if it finds it, look for the tag an index higher.

 

Properly the function something like 'AddTags(string tag0, string tag1)' would be helpful to ensure that the tags a mod adds to communicate with another mod in this way are always behind each other.

[LaEspada]

 

 

So I've kinda gone off the deep end again, and am once again majorily rewriting SexLab's code to the point I'm considering releasing the next version as SexLab 2.0

 

Before when I did this on 1.20's release, it wasn't so much a rewrite as a "restructuring," most of the code was kept and just shuffled around to new scripts, the result was less repeated coding and being able to track down specific parts of the framework to work on easier. All well in and good, but for the most part it was still using the same old code with a few performance improvements (and in some cases determinants) tacked onto the side to try and convince myself it was worth the effort.

 

Now however, I am rewriting everything literally from the start. I've erased everything and am starting fresh, tackling each part as if I was making a whole new mod, rethinking core concepts and enforcing a stricter consistency across the board, while also actually simplyfying much of SexLab's previously cumberson portions.

 

I don't really anticipate it breaking many current mods, as I am keeping all modder facing API function names and arguments the exact same so they should work out of the box, a few mods using the more hidden stuff in SexLab, stuff not contained in the SexLabFramework.psc, SexLabUtil.psc, and sslUtility.psc API scripts, may break in minor ways, but they should be easy to update.

 

Right now I have the animation sets and threads implemented, which are the 2 biggest components in SexLab by far. Leftover is a redo of the MCM, Voices, Expressions, Stats, and the modder API.

 

Ashal,

 

I read in one of your posts that you considered SL to be fairly bug free and most issues that were being reported to you actually worked back something a mod was doing incorrectly, requiring you to add more "robustness" into SL.

 

As a professional developer with over 20 years of development experience, I'm a little surprised for you to announce this. Is it to satisfy an itch? Do you feel you've accumulated some internal code design "debt"? 

 

 

SexLab is for me first and foremost, a hobby programming project.

 

Much of it's code has become sloppy over the year of updates, quick fixes, and tacked on additions. As I went about recently implementing FNIS 5.0 Paired Animation support and enter/exit transition animations, really compounded the tacked on feeling, which is what lead me to doing this. Redoing it all from scratch with the foresight of the past additions, fixes, and improved knowledge of Papyrus will hopefully inform cleaner code; which makes me happy, and better performance; which makes the people to lazy to fix their Skyrim installs happy.

 

And it being a hobby project, starting over scratches that hobby itch without having to do the more complicated task of trying to come up with a new interesting and worthwhile addition. Improving upon on what you already know is generally easier, and will provide a better base for later coming up with the new.

 

I'm following the existing structure and names of current SexLab for the sake of backwards compatibility, but I'm rewriting each script piece by piece without looking at the existing version until finished with the script to see how I did things differently, then I benchmark the current sexlab version vs my rewritten versions, find where the bottlenecks are of each and settle on which version or combination thereof to use going forward.

 

So far for example, my new version can rebuild the animation registry in ~3 seconds, current sexlab usually takes ~10 seconds for that. New version can retrieve an animations actor offsets (forward, side, up, rotation) including manual player adjustments in 0.096 seconds, current sexlab benchmarks this same task to 0.173 seconds. A seemingly small improvement, but SexLab performs that task fairly frequently during animation, so it can add up.

 

Basically it's just because I'm bored and felt like it would be interesting to see how I would go about things a second time. 

 

 

That's some really good improvement right there. Looking forward to your new update!

[Dayelyte]

Both myself and Panicforever are working on critter animations. Hopefully the new SL versions play nice with them lol He is about to release a new giant animation and I'm about to release a second werewolf animation.

 

Giant anim is Giant > player actor, while the werewolf anims are player actor > female werewolf.

 

But damn, Ashal is a coding machine. By the time I have an animation ready, we are two versions beyond in testing lol

[nutluck]

So I've kinda gone off the deep end again, and am once again majorily rewriting SexLab's code to the point I'm considering releasing the next version as SexLab 2.0

 

Before when I did this on 1.20's release, it wasn't so much a rewrite as a "restructuring," most of the code was kept and just shuffled around to new scripts, the result was less repeated coding and being able to track down specific parts of the framework to work on easier. All well in and good, but for the most part it was still using the same old code with a few performance improvements (and in some cases determinants) tacked onto the side to try and convince myself it was worth the effort.

 

Now however, I am rewriting everything literally from the start. I've erased everything and am starting fresh, tackling each part as if I was making a whole new mod, rethinking core concepts and enforcing a stricter consistency across the board, while also actually simplyfying much of SexLab's previously cumberson portions.

 

I don't really anticipate it breaking many current mods, as I am keeping all modder facing API function names and arguments the exact same so they should work out of the box, a few mods using the more hidden stuff in SexLab, stuff not contained in the SexLabFramework.psc, SexLabUtil.psc, and sslUtility.psc API scripts, may break in minor ways, but they should be easy to update.

 

Right now I have the animation sets and threads implemented, which are the 2 biggest components in SexLab by far. Leftover is a redo of the MCM, Voices, Expressions, Stats, and the modder API.

 

Just curious, I recently finished up a skyrim play and was going to start a new game soon. Are you close to finished with this? If so I will just wait until you do and any mods I use have a chance to make any changes they need to use the new version before starting my next game.

 

[fore]

 

... As I went about recently implementing FNIS 5.0 Paired Animation support and enter/exit transition animations ..............

 

Oh I like that.   I was beginning to believe that I had put 100+ hours of work into paired animations without use. Now it looks much better.

 

Thanks for the reply! It was as I guessed. It's great to have a perfectionist working on the framework!

 

So if you are bored, why not develop some mods, or are you only "the framework guy" ?

 

"Only" the framework guy? Why not develop "some" mods? Like in "another mod similar to dozens of other mods"?

 

Ashal is making something no one else is doing. And his work is a big part of the success of this site. Don't you think this alone can be thriving stimulus?

 

You should be happy he is doing SL, and not try to talk him out of that. (Just kidding. Didn't really mean that  )

[Ashal]

 

... As I went about recently implementing FNIS 5.0 Paired Animation support and enter/exit transition animations ..............

 

Oh I like that.   I was beginning to believe that I had put 100+ hours of work into paired animations without use. Now it looks much better.

 

I'm sure it'll be awhile before the actual sex animations make use of them; but my immediate goal for the next release is to have enter/exit transition animations, showing the actors getting into and out of an approximation of where the animation loops start and end.

 

Beforehand I had an animator (bleagh) working on stuff like "enter/exit kneeling position" then would apply them to actors individually. It kind of ended up being a mess though since varying animation offsets would make it look very off in certain cases without having to resort to some messy scripting to compensate.

 

Now though I've decided to just toss out that idea and have the transition animations be paired animations, it means restricting the transitions to 2 actor animations, but should result in much much easier implementation in the framework. Bleagh's working on paired animation versions now, will implement them soon as he finishes a set and let you know the results.

 

Personally I'd like to find some more use of the furniture animation stuff as well, it's hard to really go about implementing stuff like that and paired animations though, when Skyrim seems to have a real lack of animators willing to make useable animations to test with.

 

 

Thanks for the reply! It was as I guessed. It's great to have a perfectionist working on the framework!

 

So if you are bored, why not develop some mods, or are you only "the framework guy" ?

 

"Only" the framework guy? Why not develop "some" mods? Like in "another mod similar to dozens of other mods"?

 

Ashal is making something no one else is doing. And his work is a big part of the success of this site. Don't you think this alone can be thriving stimulus?

 

You should be happy he is doing SL, and not try to talk him out of that. (Just kidding. Didn't really mean that  )

 

I really want to and have tried to do other mods, unfortunately though with the success of SexLab I always feel guilty when I venture away from it, like the time spent working on something else is kinda wasted when I could be doing something to improve sexlab instead.

 

Same reason I've never actually made it past Whiterun when playing Skyrim; play time almost always inevitably ends up turning into work time.

[Ashal]

Just curious, I recently finished up a skyrim play and was going to start a new game soon. Are you close to finished with this? If so I will just wait until you do and any mods I use have a chance to make any changes they need to use the new version before starting my next game.

It'll be at least a month, possibly 2, before any sort of final release.

[Ashal]

Both myself and Panicforever are working on critter animations. Hopefully the new SL versions play nice with them lol He is about to release a new giant animation and I'm about to release a second werewolf animation.

 

Giant anim is Giant > player actor, while the werewolf anims are player actor > female werewolf.

 

But damn, Ashal is a coding machine. By the time I have an animation ready, we are two versions beyond in testing lol

On of the main goals of the rewrite is to implement creature animation support better. Right now it's kinda hacked in and fairly limited. Anything creature related that sticks out to you that could stand an update? I know a lot of people have asked for "male creature" and "female creature" support.

[Ashal]

If I remember correctly the 'hook' of an animation is now added to an animation as a tag, and GetHooks() returns an array with all tags as an array.

GetHooks() will only return the hooks, GetTags() will return the hooks + other non-hook tags. Hooks and Tags are still separate things, one just happens to inform the other.

 

If possible I would like to see the following two functions:

- int function HasTagInt(string tag)

Returns -1 is the animation doesn't have said tag, returns the index in the GetHooks() array if it exists

int index = Thread.GetHooks().Find("findHook")

- string function GetTagInt(int index)

Returns the tag at the specific index of the GetHooks() array

string hook = Thread.GetHooks()[index]

With those functions mods/plugins could communicate with each in a limited way directly over the framework. E.g. a mod could add a specific trigger string to an animation, and behind it another string that specifies what exactly should be done; the other mod would try to find said specific trigger string, and, if it finds it, look for the tag an index higher.

The order of the tags is completely irrelevant, and any scenario you can come up with where it is relevant I guarantee has a different better solution. A simple bool check on the existing HasTag("tag") serves the situation of mod communication just fine.

 

Properly the function something like 'AddTags(string tag0, string tag1)' would be helpful to ensure that the tags a mod adds to communicate with another mod in this way are always behind each other.

You can already do AddTag("tag0,tag1") and it'll add them both as separate tags, currently every location in sexlab that accepts a tag argument will accept a comma separated list and treat them as individuals.

 

Same goes for Hooks, SetHook("hook0,hook1") will add both as separate hooks. You should be careful about using multiple hooks as a primary means of inter-mod communication though, each hook on a thread adds somewhat significantly to the overhead, as each one has to generate it's own separate "StageStart_NthCustomHookHere" and such, while tags do not but can still have it's contents checked inside any relevant hooked event.

[Dayelyte]

 

Both myself and Panicforever are working on critter animations. Hopefully the new SL versions play nice with them lol He is about to release a new giant animation and I'm about to release a second werewolf animation.

 

Giant anim is Giant > player actor, while the werewolf anims are player actor > female werewolf.

 

But damn, Ashal is a coding machine. By the time I have an animation ready, we are two versions beyond in testing lol

On of the main goals of the rewrite is to implement creature animation support better. Right now it's kinda hacked in and fairly limited. Anything creature related that sticks out to you that could stand an update? I know a lot of people have asked for "male creature" and "female creature" support.

 

 

The male and female support is definitely on my list as some of the animations I'm doing will work well for the female werewolf mesh, not so much for the male variant.  ( Due to some equipment being in the way )

 

Without the ability to differentiate between the genders, it will be difficult to implement the animations I think and have them make any sense.  Example, the male werewolf mesh is larger than the female counterpart ( without some console work anyway ) and, as a result, the animations which are built and aligned around the smaller female mesh will probably not align correctly if applied to a non-modified male model. 

 

Though, I'm not entirely sure how you will go about differentiating between them as they both utilize the same skeletal structure.  It's only the mesh that really sets them apart. Is it even possible to check what mesh any given actor is wearing ?  This would likely be true for all creatures unless they have custom skeletons. 

 

 

 

[Arizona_Steve]

Would it be possible to fire off an event when the sslConfig.OnVersionUpdate() has completed following an update by the user? I have some ideas to greatly speed up the Random Sex evaluation code, but would need to know when the user updates SexLab so I can evaluate new animations etc.

[WaxenFigure]

Aight, someone stop me or feel free to correct me if I'm wrong. 

 

Some animations forthcoming as I get into the swing of things and wanted to run this past you all before I jumped in feet first and blow something up. 

 

I know Ashal is busy as hell working with the SL updates, so a thought occured to me as a means to placate those who are waiting on release X.Y to include whatever animations are pending.  Unless I'm missing something ( and it's a good possibility ) you need the following things to get the animations working in SexLab ( assuming the code hasn't changed much ) for a new werewolf animation:   ( change critters based on the animation being done of course )

 

1)  The converted and ready to go animations

2)  The updated FNIS animation file located in the same directory as the animations edited to include the new files

3)  The updated FNIS behavior files associated with the mod ( In my case would be FNIS_SexLabCreature_werewolfbeast_Behavior.hkx and its player character counterpart in the actors/characters/behaviors folder )

4)  The updated and compiled .pex script file ( sslCreatureAnimationDefaults.pex ) to register and setup the new animations

 

I basically test my own animations with the above procedure,  but I've never considered distributing it with the animation files until now. 

 

I think, if the above files are distributed out with the animations ( in a correct folder hierarchy for simple drag and drop installation ) , then ( once installed ) you should be able to just run the FNIS for Users, start the game, then reset the animation registry within SexLab to get it up and running.  The beauty of this would be any future official SexLab releases would simply overwrite all the script and behavior files, it would add it's own animation files ( since Ashals naming convention would likely be different ) leaving only the old animation files to be deleted at the users whim.  I can't think of a conflict this would cause. . . . thus this post for those whose coding skills are far in excess of mine. 

 

Thoughts ?

Didn't see a reply to this on the same page but you should NOT need to be editing the ssl* scripts to add animations, look at the code for the ZAZ Animation pack which both contains its own animation files AND registers them with the Sexlab Framework.

 

Try replicating the script that mod uses for registering animations and you can then release your own mods that contain your own animations and have them added to the animations available to the framework without Ashal having to add them to the framework himself.

 

That would also have the advantage of allowing those new animations to work with the current and older versions of the framework for those who have not upgraded the framework for various reasons.

[WaxenFigure]

 

Since you are rewriting the framework have you used the Papyrus Utility ability to assign behavior packages without using quest aliases to expand the number of simultaneous sex acts to be effectively unlimited?

[Ashal]

Since you are rewriting the framework have you used the Papyrus Utility ability to assign behavior packages without using quest aliases to expand the number of simultaneous sex acts to be effectively unlimited?

 

It's currently still using quest aliases for actors, aside from the package stuff, the aliases provide a convenient place to handle the individual actors during animation while keeping their separate information and storage apart from eachother without having to keep track of their position in the animation to know what data belonged to who. As well as to keep the actor specific handling functions separate from the animation handling of the thread, which makes it a lot easier to maintain. I do however still make use of the PapyrusUtility package overrides, it's really more of just a precaution to make sure the package takes priority than any real need, since they are still inside aliases.

 

I've dumped the massive 75 actor quest alias storage however. Threads are now individual quests instead of reference aliases themselves, and each has their own individual 5 actor aliases. Meaning the answer to the unlimited simultaneous sex acts is also still no. The main benefit of doing it this way, with the sslThreadController being a Quest script instead of a ReferenceAlias, is that now they have are effectively a form, letting them be passed as an argument in the new SKSE 1.7.0 mod events. So now hooks will look something like this:

event OnInit()
	RegisterForModEvent("StageStart", "NotifyStage")
endEvent

; // NEW SexLab event callback using SKSE 1.7.0
function NotifyStage(sslThreadController Thread, bool HasPlayer = false)

	; // Popup thread information at start of stage, if player is present
	if HasPlayer
		Debug.MessageBox("Started Animation '"+Thread.Animation.Name+"' stage "+Thread.Stage+" with the actors "+Thread.Positions)
	endIf

endFunction

; // CURRENT SexLab event callback using SKSE 1.6.16
function NotifyStage(string eventName, string argString, float argNum, form sender)

	; // Typical hook functions to grab info
	sslThreadController Thread = SexLab.HookController(argString)
	int stage = SexLab.HookStage(argString)
	actor[] positions = SexLab.HookActors(argString)
	sslBaseAnimation animation = SexLab.HookAnimation(argString)

	; // Popup thread information at start of stage, if player is present
	if Thread.HasPlayer
		Debug.MessageBox("The player has started stage " + stage + " with the actors " + positions)
	endIf	

endFunction

This is all kinda straying from your question though. So to put it simply, no there won't be unlimited threads. It'll still be limited by the number of thread quests I implement, which will probably end up being 15 or 20. Which in my opinion is more than enough. Only situation I've ever seen the current limit of 15 get used is when standing in an inn with the lively inns & taverns mods then running SexLab Random Sex on high settings, a situation I wouldn't consider typical or likely to come up in any real situation. 

[fore]

 

Beforehand I had an animator (bleagh) working on stuff like "enter/exit kneeling position" then would apply them to actors individually. It kind of ended up being a mess though since varying animation offsets would make it look very off in certain cases without having to resort to some messy scripting to compensate.

 

Now though I've decided to just toss out that idea and have the transition animations be paired animations, it means restricting the transitions to 2 actor animations, but should result in much much easier implementation in the framework. Bleagh's working on paired animation versions now, will implement them soon as he finishes a set and let you know the results.

 

I don't know if I understand you right with using paired animations for transitions, but I don't think paired animations are useful for that. 

 

First, paired animations start with teleport of the active actor to the other. And I don't think you want to start with a teleport when the goal of the pa is to avoid unnatural connection. The same thing with furniture animations. The problem is, this teleporting is controlled by the engine, and is not part of the behavior. This is one of the reasons why the engine needs these stupid .txt files in the meshes directory. There is nothing FNIS can do about. I only see 2 ways to somehow "lore friendly" connect the 2 actors

1. Use an Idlemarker or something, and an AI package to make the actor1 go to the start position, while actor2 is connected to a setvehicle(). But that probably could not avoid collision on actor1 in many cases
2. Connect actor1 with setvehicle() as well, make him play a walk or something as an idle, and gradually move him to the start position.

I know these are very unpleasant work-arounds, but I don't see anything better. Teleport, what the game does, I much worse.

 

 

Personally I'd like to find some more use of the furniture animation stuff as well, it's hard to really go about implementing stuff like that and paired animations though, when Skyrim seems to have a real lack of animators willing to make useable animations to test with.

 

That's so true. I have contacted serveral well-known animators. And they all have totally stopped, or don't seem to be interested any more, or are stuck in RL.

[Ashal]

 

 

Beforehand I had an animator (bleagh) working on stuff like "enter/exit kneeling position" then would apply them to actors individually. It kind of ended up being a mess though since varying animation offsets would make it look very off in certain cases without having to resort to some messy scripting to compensate.

 

Now though I've decided to just toss out that idea and have the transition animations be paired animations, it means restricting the transitions to 2 actor animations, but should result in much much easier implementation in the framework. Bleagh's working on paired animation versions now, will implement them soon as he finishes a set and let you know the results.

 

I don't know if I understand you right with using paired animations for transitions, but I don't think paired animations are useful for that. 

 

 

Not transition in the typical skyrim idle behavior sense, just something to stick in between the actors suddenly teleporting to each other already going at it and something at the end to replace the sudden change to standing up straight from IdleForceDeafultState or ragdolling as a means to get them out of an animation animation. Make things a little more seamless and less abrupt all around.

[Dayelyte]

 

Aight, someone stop me or feel free to correct me if I'm wrong.

 

Some animations forthcoming as I get into the swing of things and wanted to run this past you all before I jumped in feet first and blow something up.

 

I know Ashal is busy as hell working with the SL updates, so a thought occured to me as a means to placate those who are waiting on release X.Y to include whatever animations are pending. Unless I'm missing something ( and it's a good possibility ) you need the following things to get the animations working in SexLab ( assuming the code hasn't changed much ) for a new werewolf animation: ( change critters based on the animation being done of course )

 

1) The converted and ready to go animations

2) The updated FNIS animation file located in the same directory as the animations edited to include the new files

3) The updated FNIS behavior files associated with the mod ( In my case would be FNIS_SexLabCreature_werewolfbeast_Behavior.hkx and its player character counterpart in the actors/characters/behaviors folder )

4) The updated and compiled .pex script file ( sslCreatureAnimationDefaults.pex ) to register and setup the new animations

 

I basically test my own animations with the above procedure, but I've never considered distributing it with the animation files until now.

 

I think, if the above files are distributed out with the animations ( in a correct folder hierarchy for simple drag and drop installation ) , then ( once installed ) you should be able to just run the FNIS for Users, start the game, then reset the animation registry within SexLab to get it up and running. The beauty of this would be any future official SexLab releases would simply overwrite all the script and behavior files, it would add it's own animation files ( since Ashals naming convention would likely be different ) leaving only the old animation files to be deleted at the users whim. I can't think of a conflict this would cause. . . . thus this post for those whose coding skills are far in excess of mine.

 

Thoughts ?

Didn't see a reply to this on the same page but you should NOT need to be editing the ssl* scripts to add animations, look at the code for the ZAZ Animation pack which both contains its own animation files AND registers them with the Sexlab Framework.

 

Try replicating the script that mod uses for registering animations and you can then release your own mods that contain your own animations and have them added to the animations available to the framework without Ashal having to add them to the framework himself.

 

That would also have the advantage of allowing those new animations to work with the current and older versions of the framework for those who have not upgraded the framework for various reasons.

I'll look into it but while I posses some basic ability to read / write / comprehend the scripting, it is only that. Basic.  Creation of an official "mod" to run these is beyond not only my means, but time I have available.  A mod would not only require the time and skills to write and test, but would also need to be maintained during future SexLab updates to retain functionality.  Time I do not have unfortunately. 

 

I do understand, however, that Ashal also doesn't have the time to constantly update the SL engine to include new animations any time they are created.  Thus, I will put some effort into at least trying to figure out how the other mods register their animations with SL.  No promises, but I'll give it a shot.

 

Writing said mod is a rather simple endeavor for professional programmers.  Not so much for one such as I.  Would be similar to asking the professional coder to model, rig, skin and animate game assets I think While they certainly would have the ability to learn it, the time investment required to do so would make it an unattractive option. 

 

That said, the method I've mentioned does work for the moment as a means to test the animations in game. However, as Ashal is rewriting the code, it may not stay that way and, thus, my reluctance to try hacking together any sort of official  mod. Will have to keep an eye on it.

 

Currently, all I'm doing is adding the extra function to handle the new animation files. The source script, compiled version, behavior files and animation files are all there is to it. The animation files all have a "test" suffix appended to them to make them easy to spot for removal later on by the user.  They are also easily spotted in the function itself and FNIS animation file listings for the same reason.

 

Both the source script, compiled pex version and the behavior files will get overwritten with any official SL update so there exists no chance of any residual file interference. Only the test animation files will remain and can be removed by the user at their convenience. The only negative impact I can think of would be the new animations would cease to work if they were not included in the update. 

 

It isn't really designed to be a mod, rather a means for the users to test the animations ingame temporarily until the official update includes them.  Believe me, having a dozen pairs of eyes checking the animation is far better than my eyes alone.  Folks will spot anomalies and let me know rather quickly

 

The readme file strongly urges folks to wait for the official update, but for those with the urge to tinker with things, the file is available for them to use.

 

If, however, any objections to this method exist, I will certainly understand and remove the test files availability.  I will use the method to test the animations in game myself, but will refrain from releasing it publicly. 

 

If you wish to take a closer look at it, the file can be found on the download page here:

 

Fem_WW_SexLab_Testing.rar

[WaxenFigure]

Ashal,

 

Since Papryrus Utility allows you to store data in files you can use that to store custom positioning information by race. That way custom races with custom skeletons won't have to be out of alignment. I was going to suggest you store it on the form for each race but using the file method the file can be moved to a new game as long as the player's skeleton still matches the adjustments.

[Ashal]

Ashal,

 

Since Papryrus Utility allows you to store data in files you can use that to store custom positioning information by race. That way custom races with custom skeletons won't have to be out of alignment. I was going to suggest you store it on the form for each race but using the file method the file can be moved to a new game as long as the player's skeleton still matches the adjustments.

 

 

One of my goals with the rewrite is to completely overhaul how the adjustments system works. I can look into storing the adjustments on race instead of animation, but I'm not really sold on that being the best solution.

 

There's more to it than just individual race, there's also combination of races, an adjustment saved on a Nord might align well with a Breton, but using that same Nord adjustment with an Orc might not work as well, then throw in the fact that the Orc's saved adjustment might have been saved for best alignment with a Redguard, throwing it off even more.

 

There's just more to it than a simple "X race uses Y offset," it'd have to be "X race uses Y offset when partnered with Z race" in order to accomplish it's task, and that significantly complicates things a great deal.

 

Though while you have me thinking of it, here's a possible solution to that I just thought of.

 

Storing them keyed by strings of race names rather than race forms. I could get the name of each race as a string, and combine them in the order they appear in the animation. For example; a female Breton and a male Nord would store their adjustment for the Arrok Cowgirl animation in StorageUtil under "ArrokCowGirl.Adjustments.BretonNord" and if the roles were reversed, with the female being the Nord and the male the Breton, than it would be "ArrokCowGirl.Adjustments.NordBreton"

 

That solves the problem of them needing to be combination specific rather than individual specific. But my fear is that it would ultimately have very little pay off and mostly  result in annoyance, most combinations for people who don't have custom or height adjusted vanilla races, would just end up needing to use the same adjustments and they'll find themselves having to readjust in practically every scene as new combinations come up.

[Ashal]

I've got a basic version of the rewritten SexLab fully functional, the only things missing right now are actor stats, creature animations, expressions, and animation adjustments (see above post). I am debating however the possibility of removing expressions from sexlab, and making them a separate plugin. They are kind of a mess in current SexLab as screw up the lip sync and are generally unnoticeable.

 

I'll say this to, the rewritten version so far runs like a dream; it's like night and day right now if I switch from 1.39 to my current build. Things right now start up faster and progresses smoother than ever.

 

Will probably finish the rewrite in the next week or so, then release the build as an alpha release so people can give it a try and let me know what breaks as far as backwards compatibility and such.

 

 

[WaxenFigure]

 

Ashal,

 

Since Papryrus Utility allows you to store data in files you can use that to store custom positioning information by race. That way custom races with custom skeletons won't have to be out of alignment. I was going to suggest you store it on the form for each race but using the file method the file can be moved to a new game as long as the player's skeleton still matches the adjustments.

 

 

One of my goals with the rewrite is to completely overhaul how the adjustments system works. I can look into storing the adjustments on race instead of animation, but I'm not really sold on that being the best solution.

 

There's more to it than just individual race, there's also combination of races, an adjustment saved on a Nord might align well with a Breton, but using that same Nord adjustment with an Orc might not work as well, then throw in the fact that the Orc's saved adjustment might have been saved for best alignment with a Redguard, throwing it off even more.

 

There's just more to it than a simple "X race uses Y offset," it'd have to be "X race uses Y offset when partnered with Z race" in order to accomplish it's task, and that significantly complicates things a great deal.

 

Though while you have me thinking of it, here's a possible solution to that I just thought of.

 

Storing them keyed by strings of race names rather than race forms. I could get the name of each race as a string, and combine them in the order they appear in the animation. For example; a female Breton and a male Nord would store their adjustment for the Arrok Cowgirl animation in StorageUtil under "ArrokCowGirl.Adjustments.BretonNord" and if the roles were reversed, with the female being the Nord and the male the Breton, than it would be "ArrokCowGirl.Adjustments.NordBreton"

 

That solves the problem of them needing to be combination specific rather than individual specific. But my fear is that it would ultimately have very little pay off and mostly  result in annoyance, most combinations for people who don't have custom or height adjusted vanilla races, would just end up needing to use the same adjustments and they'll find themselves having to readjust in practically every scene as new combinations come up.

 

I thought about it some more too, it's not as much by RACE combinations as it is by skeletons. However if you save the combinations to a file by race combinations you can get some people to create settings files for the combinations they use which could provide another thread for people to share their settings files (leaving it up to others instead of you to create all those settings).

[Dayelyte]

 

 

Ashal,

 

Since Papryrus Utility allows you to store data in files you can use that to store custom positioning information by race. That way custom races with custom skeletons won't have to be out of alignment. I was going to suggest you store it on the form for each race but using the file method the file can be moved to a new game as long as the player's skeleton still matches the adjustments.

 

One of my goals with the rewrite is to completely overhaul how the adjustments system works. I can look into storing the adjustments on race instead of animation, but I'm not really sold on that being the best solution.

 

There's more to it than just individual race, there's also combination of races, an adjustment saved on a Nord might align well with a Breton, but using that same Nord adjustment with an Orc might not work as well, then throw in the fact that the Orc's saved adjustment might have been saved for best alignment with a Redguard, throwing it off even more.

 

There's just more to it than a simple "X race uses Y offset," it'd have to be "X race uses Y offset when partnered with Z race" in order to accomplish it's task, and that significantly complicates things a great deal.

 

Though while you have me thinking of it, here's a possible solution to that I just thought of.

 

Storing them keyed by strings of race names rather than race forms. I could get the name of each race as a string, and combine them in the order they appear in the animation. For example; a female Breton and a male Nord would store their adjustment for the Arrok Cowgirl animation in StorageUtil under "ArrokCowGirl.Adjustments.BretonNord" and if the roles were reversed, with the female being the Nord and the male the Breton, than it would be "ArrokCowGirl.Adjustments.NordBreton"

 

That solves the problem of them needing to be combination specific rather than individual specific. But my fear is that it would ultimately have very little pay off and mostly result in annoyance, most combinations for people who don't have custom or height adjusted vanilla races, would just end up needing to use the same adjustments and they'll find themselves having to readjust in practically every scene as new combinations come up.

I thought about it some more too, it's not as much by RACE combinations as it is by skeletons. However if you save the combinations to a file by race combinations you can get some people to create settings files for the combinations they use which could provide another thread for people to share their settings files (leaving it up to others instead of you to create all those settings).

Are we talking about alignments for customized character sizes or just alignments between characters / races in general ?

[Rabblerouser]

I'm no modder, don't know the code, but I'm curious.. how well does Sexlab handle communications of Sexlab functions to other mods?

 

For example, was thinking if someone wanted to make their own mod, but not use Sexlab animations, but still have the mod tell Sexlab the details of what the other mod did, for example, would the mod be able to 'shout out' to Sexlab the specifics of the sex (oral, vaginal etc) from another mod that used their own animations

 

I'd have another statement, but I think that's more suited to the Mod Ideas thread.

 

 

Again, I'm no modder, just I'd like it to be more than just an animation framework, but also allow mods to talk to Sexlab for info. Both to speak to and to receive info from the framework. Though maybe that'd be a job for a subframework along the lines of Sexlab Aroused.

When more people use a common source, the mods are more likely to get along with one another.

[daedrasp]

How to reset sex journal history? I never want lost my character's virgin!! (But she enjoying rape girls. )

Of course i seen MCM menu but it don't work.

[gooser]

Ashal,

 

It appears GetPain and GetEnjoyment both always return zero. Is there some prerequisite that needs to be satisfied. Others have noticed this as well.

 

Thanks