SexLab Framework Development

[Teruke]

Suggestion: The creature part of lovers lab seems to have went up a notch... Some support to accommodate that would be welcomed. The way i see it, it should be about creature genders. Mostly every creature seems about male, but then there's the Flame Atronach, Spriggan which are females and werewolfs which can be either gender. Animations are also differentiated now... dogs for example include both consensual and non-consensual animations... Not only that, but there's even another class of animations to be considered.. ones where penetration occurs and those where penetration does not. I suppose an owner can help their pent up pet, but not necessarily going all the way..

[jianshi051]

May I ask a question... I've download a mod that add some zombie to skyrim, all their appearances just like normal human,....

 

but because the anthor put them in zombie race, so they cannot play any SL animations like human,  is there a way to let them share human race animation?   

[Sabielin]

Lol, I completely broke my Skyrim. x]

 

Installed one-two many mods and realized some strange trianglar-shaped pattern polygon in the place of the blacksmith/bench areas.

 

So...I just decided to reinstall everything. EVERYTHING. Gonna be a pain but eh...well worth me not being bored.

 

While I'm here, might I suggest more realistic-looking sex transition animations? Ranging from casual, romantic and forced; whichever you guys' are capable of creating.

 

Some animations are beginning to look as bad as the AP animations...that can't be good.

[Ashal]

May I ask a question... I've download a mod that add some zombie to skyrim, all their appearances just like normal human,....

 

but because the anthor put them in zombie race, so they cannot play any SL animations like human,  is there a way to let them share human race animation?   

 

Not unless the zombie race specifically uses the regular human character skeleton. I'd assume they are probably using the draugr skeleton, and could thus share animations with the draugr if added to the race list for those animations. If by chance they are in fact using the regular character skeleton, then they are probably missing the ActorTypeNPC keyword on them, which would prevent SexLab from seeing them as characters and instead look to the creature animations for a fitting animation to use.

[Kinky]

New build on git... something is happening

[Ashal]

I'm trying to flesh out some new ideas for handling animations/voices/expressions in SexLab to provide more than the current limited 128 animation slots limit and could use some feedback on direction and the current plan I'm playing with, good or bad.

 

Mainly I'm just brainstorming here, so I may ramble, but if I'm going to write out plan I might as well make it public for the sake of feedback.

 

This will apply to sslBaseAnimation, sslBaseVoice, and sslBaseExpression objects in SexLab, animations however are the only ones currently really bumping up against the limit making this a necessity for future updates.

 

Main goals/requirements of rewriting the animation/voice/expression object system:

• NOT simply creating another object registry quest and chaining the search functions together between scripts to double the limit - if I'm going to fix a problem with SexLab limits, I'm going to solve it for the foreseeable future, not sweet it under the rug to be a problem once 256 animation slots are not longer enough.
• Backwards compatible with current object system, so unmaintained mods get broken. Likely will need to be through an abstraction layer
• It may out of necessity require object search functions in SexLab become slower, probably unavoidable unless the new method is significantly faster.

 

Current Idea - Individual blank objects on every thread that can be molded and reset as needed by SKSE:

• Store the animation information in the SKSE plugin after creation.
• All sslBaseAnimation/Voice/Expression objects will effectively become "blanks" with no animation data stored inside.
• Instead of the objects being kept in a large pool and then passed to the actual sexlab scenes to read their stored data, the sexlab scenes will have their own individual pools of blank animations, voices, & expressions.
• These blanks are then told by the thread as setup by the modder what animations they should be.
  • For example:
  • Scene thread is given a string array of 2 animations the scene should allow the user to cycle through.
  • The thread goes to it's personal pool of blank animations and tells animation 1 "Hey, you are 'ArrokCowgirl'"
  • thread animation 1 pings the SKSE plugin for whatever the hell "ArrokCowgirl" is and copies it's relevant stored information
  • thread animation 2 is told "Hey, you are 'SexLabRoughBehind'" and does the same.
  • the rest of the threads animation pool are left blank, and thus ignored by the scripts.
  • The scene ends and the animation 1 and animation 2 return to being blank
• Currently the scene threads in SexLab already have their own 5 "actor objects" for storing information and handling the 5 possible actors in a scene - these could serve triple duty and have sslBaseVoice and sslBaseExpression attached to them as well, no sexlab scene should have ever have a sensible purpose for more storing more voices or expressions than it can have actors.
• Since the number of aliases you can have on a quest is limited (hence the initial problem) this leaves a max 123 animations able to be passed to a sexlab scene at one time. This is massive overkill, will probably hard cap the animation pool in threads to 64 or possibly even lower.
  • Possible idea: if the process of blanking an animation and loading in the data of a different animation is fast enough, may be able to get away with not having an animation pool at all, and just having a single sslBaseAnimation cycle/load it's data as necessary.

The final result of this should be, effectively unlimited animations, voices, and expressions, can be registered to SexLab by any number of mods, solving the current problem. The limit is then passed down to the number of animations you can make available during an active sexlab scene to cycle through.

 

Main concern from this idea is I'm unsure how exactly to best make it backwards compatible. Have some vague ideas right now, but they all sound kinda dirty.

[germanicus]

Ashal - the idea of expanding sex animations is brilliant, although as I understood (with my limited English), it requires a lot of hard work.  I wish yu luck and success in this project.

[userdude]

May I ask a question... I've download a mod that add some zombie to skyrim, all their appearances just like normal human,....

 

but because the anthor put them in zombie race, so they cannot play any SL animations like human,  is there a way to let them share human race animation?   

 

I'm curious to see this mod , in question...

Would you mind ,sharing the link ,with us ?

 

 

 

 

Thank you

[lapponia]

I'm trying to flesh out some new ideas for handling animations/voices/expressions in SexLab to provide more than the current limited 128 animation slots limit and could use some feedback on direction and the current plan I'm playing with, good or bad.

 

Mainly I'm just brainstorming here, so I may ramble, but if I'm going to write out plan I might as well make it public for the sake of feedback.

 

[...]

 

The final result of this should be, effectively unlimited animations, voices, and expressions, can be registered to SexLab by any number of mods, solving the current problem.

I'll chip in to the brainstorming, about voices specifically. First let me clarify something, so the plan is to make it possible to add "custom non-registered animation, voice & expressions".

 

Is this about having more slots available (especially for the animations) or is there more to it like providing automatic registration of these objects, making some of the separate mods that do this unnessary, making things more convient for the user? For example, if the user wants to add new voices they have to either replace the original voices, have a separate voice+ mod or use "Sexlab Extra Voices" to provide more of these slots. As this was my original understanding, but the second part of the quote makes me think otherwise.

 

But if it's also about this, how is it actually accomplished with PapyrusUtil?

• Use a global voiceslots.ini file where you write a reference to any voice slots you add + how many samples each of them have (in every category) and built a voice registry from this? Or require new voices to come with a voice.ini file and then have Sexlab to check for 99 vMaleMoanXX/vFemaleMoanXX folders if there exists such a file?
• Automate this with batch file that does IF EXIST for vFemaleMoan09 ... 10 ... 11 to figure out how many voice slots there are and then IF EXIST for 001.wav, 002.wav etc. to get the number of samples in mild/medium/hot (and finally, write to file this data to some .ini and read it with PapyrusUtil and register)?
• A more elegant solution?

 

Few ideas on improving voice functionality (made possible by removing limitations on slots) :

• In addition of gender-specific voices, there could also now be race-specific voices. This would make it possible for Khajit, Orcs and so on to have their own specific male and female voice (although I'm not sure how multiple choices could be handled without making it too complex, if needed/wanted). And I think more importantly, introducing creature voices (dogs/wolves, trolls...). For backwards compatibility, if no specific voice exists for a race/creature, then go with the normal male/female voice (or none for creature).
• Add a 4th category for samples, "victim". As currently in the event of rape, "medium" samples are used which still basically are moans of pleasure. Quite different from screaming, sobbing or dialogue (pleading for mercy). For backwards compatibility, voice slots that haven't defined/lacks samples for victim, the default medium would of course be used.
• If we have "victim", we could also have "offender". For laughing, grunting or dialogue where the victim is taunted.
• Still running with the idea, same would work for consensual sex, with DOM/sub (or TOP/bottom) themed moans/dialogue. These would be used only during certain animations like intercourse as for foreplay (like kissing) the default mild samples would still be valid (or, new sound effects?). Regardless, this DOM/sub would be quite complex thing to add, and would most likely require (re?)introducing the tagging system to sslBaseVoice.
• Dynamic voice delay, based on sample length. Because some voice slots contain long samples and some have only really short ones (also, the sample length isn't really uniform inside the same slot), you can end up with either too frequent (overlap) or infrequent (ackward silence) moans. The "seconds between" option could still be there to set your preferred intensity, instead of a tweak setting we NEED to have at the moment to fix the problem mentioned before. To figure out the individual sample length, it could be stated in milliseconds inside an .ini file or it could be built with a batch file (getFilesize) and calculated, all samples are 16bit/44.1khz/mono .wav anyways. A random amount of short delay could be nice to make timing less predictable?

 

So here's my ramble, so take it as such. This isn't what I expect to be added anytime soon, but more as a food for thought for the day when you might consider redesigning & rewriting voice functionality so it will be more future-proof for this kind of things. Or if someone wants to expand on it and make a separate voices/fx module.

[Sabielin]

Don't get me wrong, the HDT Havok is a really nice way of practicing collision tutorials, but it's time to get out of this tutorial stage and unto something advanced.

 

We don't even have the animations set to spread the woman's labia yet and the penises still go through their backs.

 

It's time to step it up.

[Ashal]

First let me clarify something, so the plan is to make it possible to add "custom non-registered animation, voice & expressions".

This is already possible, through the factory/ephemeral object system added a few updates ago. Animations/voices/expressions created through the factory functions such as "sslBaseVoice function NewVoiceObject(string ToBken, Form Owner)" and "sslBaseVoice function GetSetVoiceObject(string Token, string Callback, Form Owner)" Allow you to create an object without actually "registering" it, unlike registered or objects created through the other conventional means in SexLab for of adding new animations/voices/expressions, these objects are kept in a seperate list and not returned from normal search results, they have to be called manually by a mod from their assigned token. The purpose of this system as it exists today is to provide mods with a method of creating unique voices sets for actors or one off animations for specific scenarios.

 

 

Is this about having more slots available (especially for the animations) or is there more to it like providing automatic registration of these objects, making some of the separate mods that do this unnessary, making things more convient for the user? For example, if the user wants to add new voices they have to either replace the original voices, have a separate voice+ mod or use "Sexlab Extra Voices" to provide more of these slots. As this was my original understanding, but the second part of the quote makes me think otherwise.

The plan, as brainstormed above, is provide a new way of handling SexLab objects to bypass the current limitation of allowing no more than 125 registered animations/voices/expressions in somebodies game. A limitation the current extra animation packs are starting to bump up against.

 

As for automatic registrartion, I have no plans for making it "automatic" in the sense that they can just load a new animation pack mod and go. Ideally, in my opionion, such packs should require the user reset their respective registry inorder for the additional objects to register. Though this could be accomplished with current versions of SexLab if the author of such a pack wanted it to. They could simply add a line to actually call the registeration function during OnInit() or OnPlayerPlayerLoad(), rather than just registering for the SexLab event to automatically call it later, some additional minor care would be needed aswell to make sure SexLab is actually finished installing/updating before calling their registration function.

 

 

But if it's also about this, how is it actually accomplished with PapyrusUtil?

PapyrusUtil doesn't enter into any of this currently. With the minor exception that it's used to save any adjustments to positioning a user might make with the hotkeys or in the editor.

 

Though in a semi related note, my current plan for the next major update to SexLab is to cut PapyrusUtil out in as many places as I possibly can. Not that there is anything wrong with PapyrusUtil, but I want to transfer as much of SexLab's functionality to the SexLabUtil.dll SKSE plugin as I can and as makes sense. Partially because there is speed benefits to be gained and more complex data structures I can make use of by custom writing that plugin to work exactly as needed for SexLab's direct benefit, rather than limiting myself to PapyrusUtil's structure and interface. But also mainly because, fuck it, the SKSE plugin stuff is new an intresting to me, seeing what I can pull off with it compared to regular Papyrus/Creation Kit stuff is more fun.

 

 

 

• Use a global voiceslots.ini file where you write a reference to any voice slots you add + how many samples each of them have (in every category) and built a voice registry from this? Or require new voices to come with a voice.ini file and then have Sexlab to check for 99 vMaleMoanXX/vFemaleMoanXX folders if there exists such a file?
• Automate this with batch file that does IF EXIST for vFemaleMoan09 ... 10 ... 11 to figure out how many voice slots there are and then IF EXIST for 001.wav, 002.wav etc. to get the number of samples in mild/medium/hot (and finally, write to file this data to some .ini and read it with PapyrusUtil and register)?
• A more elegant solution?

I could scan the folders for wav files easy enough, but I know of no method to then properly play them in game or add/remove them from SoundDescriptor forms. There is currently no methods for adding/removing wav files from a SoundDescriptor, atleast not as far as I could find searching SKSE's source files. It's possible it's there and just hasn't been fully decompiled, I saw no hints of it though and my attempts at trying to learn how to further decompile the objects in SKSE has all ended in being more confused than when I started. So unless there is another method of playing sounds in-game that let a list of wav files be loaded at run time is known, I don't see this happening. Voices are most likely going to be forever restricticted to having to preload them into SoundDescriptor's.

 

Few ideas on improving voice functionality (made possible by removing limitations on slots) :

 

• In addition of gender-specific voices, there could also now be race-specific voices. This would make it possible for Khajit, Orcs and so on to have their own specific male and female voice (although I'm not sure how multiple choices could be handled without making it too complex, if needed/wanted). And I think more importantly, introducing creature voices (dogs/wolves, trolls...). For backwards compatibility, if no specific voice exists for a race/creature, then go with the normal male/female voice (or none for creature).

I've messed around with the idea of using the creatures existing combat sounds to provide voices for creatures, however I don't want to do any sort of implementation that requires duplicating or editing the wav files for these creature noises into a new SexLab/vDraugrMoan01/ folder for each and creature supported, this adds a lot, unnecessarily, to the overall download size for a relatively minor payoff not everybody who uses the framework will ever make use of.

 

There already exists voices and lip-synced topics for these creatures, I'm hoping to figure out a decent way of instead being able to pull and play these vanilla assets as they exists in the game currently. The few methods I've tried so far haven't been fully succesfully sadly.

 

• Add a 4th category for samples, "victim". As currently in the event of rape, "medium" samples are used which still basically are moans of pleasure. Quite different from screaming, sobbing or dialogue (pleading for mercy). For backwards compatibility, voice slots that haven't defined/lacks samples for victim, the default medium would of course be used.
• If we have "victim", we could also have "offender". For laughing, grunting or dialogue where the victim is taunted.
• Still running with the idea, same would work for consensual sex, with DOM/sub (or TOP/bottom) themed moans/dialogue. These would be used only during certain animations like intercourse as for foreplay (like kissing) the default mild samples would still be valid (or, new sound effects?). Regardless, this DOM/sub would be quite complex thing to add, and would most likely require (re?)introducing the tagging system to sslBaseVoice.

My problem with this is having to label it as "victim" or "offender" and specifically putting in cries for help, sobbing, and the like. SexLab's framework does not refer anything it plays as rape. Animations are "normal" or they are "aggressive". This is done very specifically on purpose. 1) Because rape is a deplorable act and I have zero intrests in providing a "rape framework" mod. 2) How the term "aggressive" is interpeted can be left up to the individual and applied by the mod author however they see fit. 3) I am very anti any spoken word in any of the default SexLab voicesets, spoken word gives a voice or personality that won't necessarily ever fit the NPC playing it.

 

I'm aware people aren't fans of the "medium" voice samples. I worked with the voice files I had. Quality voice recordings for this type of thing aren't easy to come by without resorting to copyright infringement.

 

• Dynamic voice delay, based on sample length. Because some voice slots contain long samples and some have only really short ones (also, the sample length isn't really uniform inside the same slot), you can end up with either too frequent (overlap) or infrequent (ackward silence) moans. The "seconds between" option could still be there to set your preferred intensity, instead of a tweak setting we NEED to have at the moment to fix the problem mentioned before. To figure out the individual sample length, it could be stated in milliseconds inside an .ini file or it could be built with a batch file (getFilesize) and calculated, all samples are 16bit/44.1khz/mono .wav anyways. A random amount of short delay could be nice to make timing less predictable?

The starting delay is set by the users settings, and its automatically reduced as an animation continues to play, how much so is up to that user setting. It won't allow the delay to get any shorter than 0.8 seconds between plays, which should cover most of the default SexLab wav files, with a few exepections. If you're getting frequent overlaps, the only thing I can really offer is to say that maybe I'll increase the mininum delay next version and that for now you can simply increase the voice delay in your settings one or two seconds to compensate.

 

So here's my ramble, so take it as such. This isn't what I expect to be added anytime soon, but more as a food for thought for the day when you might consider redesigning & rewriting voice functionality so it will be more future-proof for this kind of things. Or if someone wants to expand on it and make a separate voices/fx module.

Improvements to the voice system are coming. Not everything you and others want, and some improvements you might not know you want. With that said however, I'd warn to temper expectations. I consider the voice system as it is now plenty "serviciable" and a minor-ish enough feature to call that good enough. I'd consider adding creature voices a high-ish priority, but the voice system as a whole isn't a real major concern right now.

[blabba]

Apparently in SKSE 1.7.2 you can setup your arrays to go over the 128 limit.

 

Stuff is kinda over my head as I have next to 0 experience with papyrus, and my C isn't that great either.

Though Expired was kind enough to explain it out a bit for me.

 

Anyway more relevant to you is that if you need the 1.7.2 SKSE stuff to compile your plugin you can probably ask Expired for links on pm/chat...

[Expired6978]

http://pastebin.com/ki33eqw6

http://pastebin.com/iULYiGUp

 

Replacing the PapyrusArgs in your SKSE plugin project will let you make use of the VM's CreateArray function, you don't need SKSE 1.7.2 to make new native functions that return arrays since the CreateArray function itself is part of the VM and the PapyrusArgs functions just safely wrap it, which would get compiled with your plugin.

 

Arrays returned from native functions are not bound by the 128 limit.

 

Here's some sample usage for returning arrays

http://pastebin.com/WqvRdXEK

 

VMResultArray is essentially an STL vector that acts as a proxy to transfer data into the VM result of the native function.

[Ashal]

Apparently in SKSE 1.7.2 you can setup your arrays to go over the 128 limit.

 

Stuff is kinda over my head as I have next to 0 experience with papyrus, and my C isn't that great either.

Though Expired was kind enough to explain it out a bit for me.

 

Anyway more relevant to you is that if you need the 1.7.2 SKSE stuff to compile your plugin you can probably ask Expired for links on pm/chat...

 

 

http://pastebin.com/ki33eqw6

http://pastebin.com/iULYiGUp

 

Replacing the PapyrusArgs in your SKSE plugin project will let you make use of the VM's CreateArray function, you don't need SKSE 1.7.2 to make new native functions that return arrays since the CreateArray function itself is part of the VM and the PapyrusArgs functions just safely wrap it, which would get compiled with your plugin.

 

Arrays returned from native functions are not bound by the 128 limit.

 

Here's some sample usage for returning arrays

http://pastebin.com/WqvRdXEK

 

VMResultArray is essentially an STL vector that acts as a proxy to transfer data into the VM result of the native function.

Already well aware SKSE 1.7.2 plans on including a create array function. It's the primary reason I haven't released an update to PapyrusUtil in awhile, most of the new functions I've added to PapyrusUtil v2.9 are array related utility functions, but they all require papyrus as a middleman to create the variable sized arrays with slow if/else lookups to make and pass a VMArray argument to the SKSE plugin. Once 1.7.2 comes out I plan on rewriting the update to simply return the arrays directly using the new VMResultArray.

 

The non VMResultArray versions are up on SexLab's Gitlab now (http://git.loverslab.com/sexlab/framework/blob/development/scripts/Source/PapyrusUtil.psc), just been waiting for 1.7.2 to come out in some form to start rewriting them for release. Will probably play with those PapyrusArgs.h/cpp files ahead of time to get a head start though, hadn't seen those posted before now.

[lapponia]

 

This is already possible, through the factory/ephemeral object system added a few updates ago. Animations/voices/expressions created through the factory functions such as "sslBaseVoice function NewVoiceObject(string ToBken, Form Owner)" and "sslBaseVoice function GetSetVoiceObject(string Token, string Callback, Form Owner)" Allow you to create an object without actually "registering" it, unlike registered or objects created through the other conventional means in SexLab for of adding new animations/voices/expressions, these objects are kept in a seperate list and not returned from normal search results, they have to be called manually by a mod from their assigned token. The purpose of this system as it exists today is to provide mods with a method of creating unique voices sets for actors or one off animations for specific scenarios.

 

The plan, as brainstormed above, is provide a new way of handling SexLab objects to bypass the current limitation of allowing no more than 125 registered animations/voices/expressions in somebodies game. A limitation the current extra animation packs are starting to bump up against.

 

As for automatic registrartion, I have no plans for making it "automatic" in the sense that they can just load a new animation pack mod and go. Ideally, in my opionion, such packs should require the user reset their respective registry inorder for the additional objects to register. Though this could be accomplished with current versions of SexLab if the author of such a pack wanted it to. They could simply add a line to actually call the registeration function during OnInit() or OnPlayerPlayerLoad(), rather than just registering for the SexLab event to automatically call it later, some additional minor care would be needed aswell to make sure SexLab is actually finished installing/updating before calling their registration function.

 

Thank you for explaining it more in detail. The possibility to accommodate and call mod-specific animations or having unique voice sets seems very useful for modders to realize their vision.

 

 

Though in a semi related note, my current plan for the next major update to SexLab is to cut PapyrusUtil out in as many places as I possibly can. Not that there is anything wrong with PapyrusUtil, but I want to transfer as much of SexLab's functionality to the SexLabUtil.dll SKSE plugin as I can and as makes sense. Partially because there is speed benefits to be gained and more complex data structures I can make use of by custom writing that plugin to work exactly as needed for SexLab's direct benefit, rather than limiting myself to PapyrusUtil's structure and interface. But also mainly because, fuck it, the SKSE plugin stuff is new an intresting to me, seeing what I can pull off with it compared to regular Papyrus/Creation Kit stuff is more fun.

 

Sounds good! Papyrus is quite basic and as you said, comes with many limitations. It is also already stretched to limit with all the mods people run on Skyrim (Sexlab being one of the heaviest script users), so all improvements to performance (making it also more stable) are welcome.

 

 

I could scan the folders for wav files easy enough, but I know of no method to then properly play them in game or add/remove them from SoundDescriptor forms. There is currently no methods for adding/removing wav files from a SoundDescriptor, atleast not as far as I could find searching SKSE's source files. It's possible it's there and just hasn't been fully decompiled, I saw no hints of it though and my attempts at trying to learn how to further decompile the objects in SKSE has all ended in being more confused than when I started. So unless there is another method of playing sounds in-game that let a list of wav files be loaded at run time is known, I don't see this happening. Voices are most likely going to be forever restricticted to having to preload them into SoundDescriptor's.

 

I thought the problem was lack of low-level access to files, rather than the Sound Descriptor through which Skyrim handles the sounds. Yeah, there probably isn't any way around this.

 

 

I've messed around with the idea of using the creatures existing combat sounds to provide voices for creatures, however I don't want to do any sort of implementation that requires duplicating or editing the wav files for these creature noises into a new SexLab/vDraugrMoan01/ folder for each and creature supported, this adds a lot, unnecessarily, to the overall download size for a relatively minor payoff not everybody who uses the framework will ever make use of.

 

There already exists voices and lip-synced topics for these creatures, I'm hoping to figure out a decent way of instead being able to pull and play these vanilla assets as they exists in the game currently. The few methods I've tried so far haven't been fully succesfully sadly.

 

The creature voices (either repacked vanilla assets or something new), would of course have be provided as an add-on pack by modders, but I understand that the support for playing the already existing vanilla samples natively is a higher priority as they benefit more people. Sad to hear there isn't an easy way to access them as many of them would fit this purpose well.

 

 

My problem with this is having to label it as "victim" or "offender" and specifically putting in cries for help, sobbing, and the like. SexLab's framework does not refer anything it plays as rape. Animations are "normal" or they are "aggressive". This is done very specifically on purpose. 1) Because rape is a deplorable act and I have zero intrests in providing a "rape framework" mod. 2) How the term "aggressive" is interpeted can be left up to the individual and applied by the mod author however they see fit. 3) I am very anti any spoken word in any of the default SexLab voicesets, spoken word gives a voice or personality that won't necessarily ever fit the NPC playing it.

 

I'm aware people aren't fans of the "medium" voice samples. I worked with the voice files I had. Quality voice recordings for this type of thing aren't easy to come by without resorting to copyright infringement.

 

I understand your reasoning behind the policy of not adding actual rape flag. I don't care about that myself and very few of us would want the actual, hadcore sexual violence simulated for the sake of enjoyment, but BDSM and enslavement mods are still quite popular and usually it's the female character that is roleplayed (and even associated to). As voices go, "passive" female and "active" male pairing works fine as it is but if it's female-female, male-female (pegging) or male-male, there ideally would be two set of samples for the same voice (DOM/sub) to better reflect what is happening. But I digress. As you said, it would require labeling/tagging all animations and their stages. Besides, there currently isn't even any voices to support this even if this was implemented. :/ The good thing is, usually the "role" is static so you can just assign the voice you want to the PC/NPC.

 

Dialogue-enriched voices sure add personality and they might not be used for random NPCs, but then again they would be great for a follower or to a central character in Skyrim or in a mod.

 

About the lack of quality voice recordings and the current use of "medium" samples in "isVictim" situation; the 4th voice category could still use these same assets, the samples would just be cherrypicked from all 3 types.

 

 

The starting delay is set by the users settings, and its automatically reduced as an animation continues to play, how much so is up to that user setting. It won't allow the delay to get any shorter than 0.8 seconds between plays, which should cover most of the default SexLab wav files, with a few exepections. If you're getting frequent overlaps, the only thing I can really offer is to say that maybe I'll increase the mininum delay next version and that for now you can simply increase the voice delay in your settings one or two seconds to compensate.

 

I haven't experienced any problems with voice overlapping even with very short delay, so increased minimum delay would be more of an annoyance if anything, at least for me.

 

I was just thinking aloud that if the voice handling is someday getting major overhaul then what are the things that could be improved. If sample length is known, there could be a a lot more variation between sample duration while continous moaning would still be maintained. But this is an non-issue as current voices work fine in this regard

 

 

Improvements to the voice system are coming. Not everything you and others want, and some improvements you might not know you want. With that said however, I'd warn to temper expectations. I consider the voice system as it is now plenty "serviciable" and a minor-ish enough feature to call that good enough. I'd consider adding creature voices a high-ish priority, but the voice system as a whole isn't a real major concern right now.

 

I was only really expecting somekind of support for creature voice mods, rest of the ramble was more about, well, rambling. Working around the animation limit is one of these "might not know you want" things. It only becomes a reality when you get told that you cannot have this or that animation (one that you've eagerly been waiting to be implemented) because there is simply no more room left for it. There's less appreciation towards "invisible" improvements added to the background (optimization, keeping things running) that usually require a lot of work, compared to a shiny new feature.

 

[Sailing Rebel]

With this proposed changes in the animation system will there be API support for creature animations, such as GetAnimationsByTags() and GetAnimationByName()? The available animations are getting a little more varied now and it would be great to be able to make contextual selections.

 

And thanks for doing all the hard work, Ashal, it really is appreciated.

[Sabielin]

Before any further animations are to be focused on, we may want to get intel on better collision data.

 

I don't think you're going to enjoy whatever it is you're trying to do when your characters aren't having realistic sex.

 

If you're focused on a complete sexlab reboot or so, that's one of the main ideas to focus on.

[Ashal]

Before any further animations are to be focused on, we may want to get intel on better collision data.

 

I don't think you're going to enjoy whatever it is you're trying to do when your characters aren't having realistic sex.

 

If you're focused on a complete sexlab reboot or so, that's one of the main ideas to focus on.

Collision details like this have nothing to do with SexLab's functionality. Until HDT, SOS, SAM, or some other mod innovates somes miraculous method that solves penis->vagina collisions, it is NOT something SexLab is, or should, be remotely concerned with. It is well beyond it's technical scope. This is a detail for a different mod from SexLab entirely to solve.

[Fotogen]

Current limit is 125 animations. You plan to remove this limit. That's good. But by how much? New limit will be 250, 10000, unlimited?

 

How much RAM will you use if someone adds a couple of thousand animations? Skyrim is 32-bit app, add lots of other mods ... out of memory?

 

Arrays are fine, if they are small. Adding new record (expand, realloc array, copy elements to new array) is fast if array is small, but gets very slow once array gets bigger. Then there's also 'search'. I never start animation like 'start 10th anim' (so by index), its always 'GetAnimByTag' or GetAnimByName. No problem with linear search (to find anims index/id by tag) if array is small. But if number of animations gets bigger ...

 

I'd go with something that is like a proper database. Records, index, ... if possible even on disk (and with cache for faster access of most/last used animations). SQLite?

 

 

[Ashal]

Current limit is 125 animations. You plan to remove this limit. That's good. But by how much? New limit will be 250, 10000, unlimited?

 

How much RAM will you use if someone adds a couple of thousand animations? Skyrim is 32-bit app, add lots of other mods ... out of memory?

 

Arrays are fine, if they are small. Adding new record (expand, realloc array, copy elements to new array) is fast if array is small, but gets very slow once array gets bigger. Then there's also 'search'. I never start animation like 'start 10th anim' (so by index), its always 'GetAnimByTag' or GetAnimByName. No problem with linear search (to find anims index/id by tag) if array is small. But if number of animations gets bigger ...

 

I'd go with something that is like a proper database. Records, index, ... if possible even on disk (and with cache for faster access of most/last used animations). SQLite?

A proper database would be massive overkill here.

 

For the most part all the objects do is store a list of tags, animation event names, and set of 4 coordinates for each animation event. It would take an unreasonable amount of these to fill up memory in any meaningful way.

I will probably cap the max animation registrations at 500 or so regardless of whatever method I settle on. For reasonable concerns that a mod might go haywire and try to needlessly register a bunch of animations needlessly, and for ensuring the animation searching functions don't get to slow due to larger numbers of animations it has to search tags for.

 

500 is likely to be more than enough for the lifetime of Skyrim and/or SexLab. Famous last words, but in this case future solutions just become a simple change of a variable to increase the limit.

[Sabielin]

 

Before any further animations are to be focused on, we may want to get intel on better collision data.

 

I don't think you're going to enjoy whatever it is you're trying to do when your characters aren't having realistic sex.

 

If you're focused on a complete sexlab reboot or so, that's one of the main ideas to focus on.

Collision details like this have nothing to do with SexLab's functionality. Until HDT, SOS, SAM, or some other mod innovates somes miraculous method that solves penis->vagina collisions, it is NOT something SexLab is, or should, be remotely concerned with. It is well beyond it's technical scope. This is a detail for a different mod from SexLab entirely to solve.

 

 

That was the point..

 

From what it seems, it sounded or appeared as if you were plotting a complete reboot to improve the system.

 

For a more extended/innovative  design, of course. The Collisions are not within Sexlab's range of functionality, this is understood.

 

My comment meant that before you do these changes to Sexlab, these animators and their collision files need to improve to give your framework

better and sound merit. I'm not quite sure if they have the kinks of the present down to tell the truth.

[Ashal]

http://pastebin.com/ki33eqw6

http://pastebin.com/iULYiGUp

 

Replacing the PapyrusArgs in your SKSE plugin project will let you make use of the VM's CreateArray function, you don't need SKSE 1.7.2 to make new native functions that return arrays since the CreateArray function itself is part of the VM and the PapyrusArgs functions just safely wrap it, which would get compiled with your plugin.

 

Arrays returned from native functions are not bound by the 128 limit.

 

Here's some sample usage for returning arrays

http://pastebin.com/WqvRdXEK

 

VMResultArray is essentially an STL vector that acts as a proxy to transfer data into the VM result of the native function.

 

Just eliminated all the non-native functions in my utility script. Oh god, all the array utility functions I've written just got so much easier and faster without having to use Papyrus as a middleman to pass variable arrays as a reference to the SKSE functions. So thanks for letting me know of the scripts pre-release, and PurpleLunchBox, whom as far as I know from the Bethesda SKSE thread is the one who figured it out.

 

Has any important incompatibilities/problems been reported related to arrays >128 that you are aware of? If they are genuinely nothing other than vectors behind the scenes, I can't think of anything that would be a problem among the vanilla/skse functions, but better safe than sorry I suppose.

[Ashal]

 

 

Before any further animations are to be focused on, we may want to get intel on better collision data.

 

I don't think you're going to enjoy whatever it is you're trying to do when your characters aren't having realistic sex.

 

If you're focused on a complete sexlab reboot or so, that's one of the main ideas to focus on.

Collision details like this have nothing to do with SexLab's functionality. Until HDT, SOS, SAM, or some other mod innovates somes miraculous method that solves penis->vagina collisions, it is NOT something SexLab is, or should, be remotely concerned with. It is well beyond it's technical scope. This is a detail for a different mod from SexLab entirely to solve.

 

 

That was the point..

 

From what it seems, it sounded or appeared as if you were plotting a complete reboot to improve the system.

 

For a more extended/innovative  design, of course. The Collisions are not within Sexlab's range of functionality, this is understood.

 

My comment meant that before you do these changes to Sexlab, these animators and their collision files need to improve to give your framework

better and sound merit. I'm not quite sure if they have the kinks of the present down to tell the truth.

 

 

I am not an animator, and I have no control over the animators. I am a scripter, and by extension SexLab is a script mod, I do absolutely nothing but make use of the assets provided to me. If HDT penetration is the vital point to you, the people to bring it up with are the authors of HDT mods and/or animators.

 

Which is the point.

 

With the way HDT is going currently, if that is the solution to penetration animations you and others are looking for, it will happen automagically within SexLab regardless of any update I may or not provide. With the way HDT works, the collisions "just happen" because that's what collisions mods do.

 

The only way SexLab as a framework would come into play with this is if  penetration animations come as the result of animation events similar to how SOS/SAM penis up and down offsets happen.

 

If such functionality ever comes about and requires me to integrate it into the framework like I have SOS/SAM, than I will gladly do so asap. Until then, my point is more that such hopes/suggestions should be directed towards more relevant mod authors.

 

EDIT: To be clear, I am agreeing with you. I'm just saying it's something that would be better served to be brought up somewhere where more relevant modders are likely to take notice.

[Sabielin]

 

 

 

Before any further animations are to be focused on, we may want to get intel on better collision data.

 

I don't think you're going to enjoy whatever it is you're trying to do when your characters aren't having realistic sex.

 

If you're focused on a complete sexlab reboot or so, that's one of the main ideas to focus on.

Collision details like this have nothing to do with SexLab's functionality. Until HDT, SOS, SAM, or some other mod innovates somes miraculous method that solves penis->vagina collisions, it is NOT something SexLab is, or should, be remotely concerned with. It is well beyond it's technical scope. This is a detail for a different mod from SexLab entirely to solve.

 

 

That was the point..

 

From what it seems, it sounded or appeared as if you were plotting a complete reboot to improve the system.

 

For a more extended/innovative  design, of course. The Collisions are not within Sexlab's range of functionality, this is understood.

 

My comment meant that before you do these changes to Sexlab, these animators and their collision files need to improve to give your framework

better and sound merit. I'm not quite sure if they have the kinks of the present down to tell the truth.

 

 

I am not an animator, and I have no control over the animators. I am a scripter, and by extension SexLab is a script mod, I do absolutely nothing but make use of the assets provided to me. If HDT penetration is the vital point to you, the people to bring it up with are the authors of HDT mods and/or animators.

 

Which is the point.

 

With the way HDT is going currently, if that is the solution to penetration animations you and others are looking for, it will happen automagically within SexLab regardless of any update I may or not provide. With the way HDT works, the collisions "just happen" because that's what collisions mods do.

 

The only way SexLab as a framework would come into play with this is if  penetration animations come as the result of animation events similar to how SOS/SAM penis up and down offsets happen.

 

If such functionality ever comes about and requires me to integrate it into the framework like I have SOS/SAM, than I will gladly do so asap. Until then, my point is more that such hopes/suggestions should be directed towards more relevant mod authors.

 

EDIT: To be clear, I am agreeing with you. I'm just saying it's something that would be better served to be brought up somewhere where more relevant modders are likely to take notice.

 

 

That reminds me: A script to build a relationship with character [Target selected by character] via quest would be FAB. I know there's Spouses Enhanced, just only when you're already married.

 

[Heromaster]

That's what the APPS Framework is for. There you modders can build better relationships than the vanilla system could ever provide.