Skyrim SexLab - Sex Animation Framework v1.62 - UPDATED Jun 3rd 2016

[RogueMage]

As I lost my stats as well I would like to change the values manually (set xxxx to xx). I tried to figure out the variablenames, but there are a lot of quest and guessing the names didn't get me any further. Does anybody know in which quest/variables the values for number of anal/vaginal/oral/beast etc. are stored? Every hint counts. Just need a starting point and I don't mind doing manual stuff. Thx in advance guys.

[h38fh2mf]

SexLabUtil.GetAPI().Stats.SetStat(Game.GetPlayer(), "bla", "123")

 

Open sslActorStats.psc file to see what the deal is, I don't know the variable names sorry.

[Ashal]

I know what the loops do. My wait loop merges your loop in ActorAction with the one in ActorWait. (It also needlessly returns a bool, but hey it was a quick hack). I just called it in ActorAction instead of the wait loop. I also stretched the failsafe up to 60 seconds (hey it's a failsafe and the wait doesn't take that long anyway).

 

The double loop isn't strictly wrong, it's just costly. Which means Skyrim will have to spend a little more time running the double loop instead of actually performing the state change your waiting for. That's also why I increased the wait time to 0.5 seconds. That way Skyrim will have more time during the wait to do what you are waiting for.

 

I just did a quick count and it takes considerably more than 7 seconds to go from selecting the dialogue option that starts the process to the fully undressed state.

This has little to do with script lag, just having a character with boots, gauntlets, ring, amulet, armor, backback, cloak, weapons and a circlet and a decorative dagger triggers the undress anim a number of times. And while it seems to stay under the 15 second failsafe, it still breaks.

 

~0.20 seconds per strip * 33 potential slots = 6.60 seconds. ~5-10 seconds max given the precarious nature of Debug.Wait(). This is again saying you literally have an item equipped in all 32 biped slots + weapon, which is insanely unlikely. The 15 second failsafe is waiting for Prepare -> Ready state, The stripping is by far and away the most costly of action done in the prepare state, if you think the rest of the contents of  the prepare state will take more than 5-10 seconds to surpass the 15 second failsafe, you are either delusional or still running a Pentium 4 CPU; in which case Skyrim mods are the least of your worries. The countdown absolutely does entirely consist of entirely dialog to animation. 

 

To put it into perspective, you are a literally the first person to report any such issue even semi related to the opening sequence since 1.30. Everybody else who had issues with slow startup sequences on  < 1.30, have since reported success with >= 1.30.

 

If you're taking 7 seconds to go from dialog to sex, either your Skyrim install or the sexlab mod your using to start the sex has some serious issues that need to be worked on.

[TMPhoenix]

I did not have the problem in 1.31. It only started after I upgraded to 1.32b. My computer is not the problem I assure you.

 

One thing you might want to consider is that I am using Fus-Roh-Doh (adds a delay to dialog options without audio). This means there is an additional delay before the undress starts.

 

Okay. Let me put it this way. Even without any other code changes why not increase the failsafe time. It's a failsafe. Under normal circumstances you'd never even reach the failsafe, since the ActorWait would cause an early-out. And in the case of a serious issue waiting out the failsafe is probably the least of your issues.

 

The code change I suggested just makes the loop a little more efficient and is not strictly necessary.

 

[Ashal]

As for disappearing stats, all my tests of going 1.31 to 1.32 have carried over stats fine. I specifically tested for this as handling of player stats were one of the things I changed significantly with 1.32.

 

I need to see debug logs of 1.31->1.32 updates to be able to really tell any more.

[Ashal]

I did not have the problem in 1.31. It only started after I upgraded to 1.32b. My computer is not the problem I assure you.

 

One thing you might want to consider is that I am using Fus-Roh-Doh (adds a delay to dialog options without audio). This means there is an additional delay before the undress starts.

 

Okay. Let me put it this way. Even without any other code changes why not increase the failsafe time. It's a failsafe. Under normal circumstances you'd never even reach the failsafe, since the ActorWait would cause an early-out. And in the case of a serious issue waiting out the failsafe is probably the least of your issues.

 

The code change I suggested just makes the loop a little more efficient and is not strictly necessary.

 

I've never not had Fuz-Roh-Doh install, and I still 100% disagree.

 

Your function makes it less efficient and spend a an excess amount of time performing actions that shouldn't take 60 seconds to begin with. An actor not making the failsafe in time isn't even a major problem, the animation will continue on regardless, the only difference will be voice handling. Meanwhile holding them for 60 seconds in a failed thread is a lot of time that is going to break other mods attempting to claim the actor.

 

If your "fix" for actorwait resolved your issue, I assure you your problem lies elsewhere, and not actually with actorwait itself. All you did was sweep the problem under the rug.

 

But what do I know, I only hand wrote every scrap of code that exists in the mod.

 

EDIT: If I'm coming off as an asshole here, I apologize, entirely not my intention.

[RockMic]

Meanwhile, I wish you a happy birthday and thank you for this great mod.
Then even if I think it is the least of her worries could read my PM ​​thank you.

[h38fh2mf]

There's no save bloating, it's not even saved to save file that's the whole point of export and 5-10 kb is hardly bloat

[TMPhoenix]

 

I did not have the problem in 1.31. It only started after I upgraded to 1.32b. My computer is not the problem I assure you.

 

One thing you might want to consider is that I am using Fus-Roh-Doh (adds a delay to dialog options without audio). This means there is an additional delay before the undress starts.

 

Okay. Let me put it this way. Even without any other code changes why not increase the failsafe time. It's a failsafe. Under normal circumstances you'd never even reach the failsafe, since the ActorWait would cause an early-out. And in the case of a serious issue waiting out the failsafe is probably the least of your issues.

 

The code change I suggested just makes the loop a little more efficient and is not strictly necessary.

 

I've never not had Fuz-Roh-Doh install, and I still 100% disagree.

 

Your function makes it less efficient and spend a an excess amount of time performing actions that shouldn't take 60 seconds to begin with. An actor not making the failsafe in time isn't even a major problem, the animation will continue on regardless, the only difference will be voice handling. Meanwhile holding them for 60 seconds in a failed thread is a lot of time that is going to break other mods attempting to claim the actor.

 

If your "fix" for actorwait resolved your issue, I assure you your problem lies elsewhere, and not actually with actorwait itself. All you did was sweep the problem under the rug.

 

But what do I know, I only hand wrote every scrap of code that exists in the mod.

 

EDIT: If I'm coming off as an asshole here, I apologize, entirely not my intention.

 

 

No need to apologize. I am not trying to attack you or your work. I just offered the snippet to give you an idea how I solved the issue is was having.

Let's just agree to disagree, if that makes you feel happier. I'll keep my changes and I won't have the issue, which makes me happy.

 

I assure you my changes are not less efficient. My loop is O(N), yours are in fact O(N^2). (for notation look up http://en.wikipedia.org/wiki/Big_O_notation)

 

Both our approaches kick out of the loop at the end of the failsafe, so they do not differ there.

 

My approach only checks each ActorSlot until it is in the desired state and if not it will wait half a second giving the actor thread hopefully enough time

to finish whatever it was doing and going to the state we are looking for. During that time one (and possibly more) actor threads will get a chance to run.

 

Your approach checks all slots up to the "failing" slot again (because of the inner loop) and if it encounters a failing slot it will wait 0.1 seconds in the outer loop. While 0.1s should certainly be enough to give papyrus the chance to have another thread to run, I personally feel it is better to wait fewer times but perhaps a little longer, as that should give other threads more time to do their thing.

 

I completely agree the actions should not take 60 seconds, and they don't. I just feel that a failsafe should not be too close to the line. I could have gone for 30 seconds and it probably would have been fine as well. The failsafe itself should ideally never even be hit. It's just there to break the characters out of a potential infinite loop.

[demack]

 

There are issues once again with the free camera but there's nothing you will be able to do about it because it's a limitation of the engine itself.

 

I ran multipule tests on TFC. (10 total)

 

Using auto TFC will sometimes cause both characters facial animation to lock if you change positions.If you don't change positions no proble. If you tfc back it fixes this if you change position again. However, once you TFC back it will crash to desktop on exit of the cell.

 

Using TFC auto or manual The player facial animations will never play. Nothing you will ever be able to do about it so don't even try unless you want to write C++ code and hook the engine animation functions. It's a lot of work and wasted time.

 

IF you have TFC disabled and do a console TFC things get REALLY BAD! If you allow the framework to reset it, the camera sometimes (2 of 4 tests) position will be whereever your camera is set at the time. You can not reset it either. You can ready your weapon with R key but can't activate it with the mouse buttons. You will not be able to use console commands to fix it. Save exit will fix it. If you zone out before reloading you will crash to desktop and your save game may crash to desktop several times before finally loading (2 of three times).

 

 

TFC IS a bad thing. I can't stress how bad it is and how many problems it is going to cause you.

 

The rest of this mod is pure Awesomeness!

 

p.S - lost my stats but no biggie

[Dapper Dan Pomade]

I had my stats wiped too.

[LukeDuke]

As for disappearing stats, all my tests of going 1.31 to 1.32 have carried over stats fine. I specifically tested for this as handling of player stats were one of the things I changed significantly with 1.32.

 

I need to see debug logs of 1.31->1.32 updates to be able to really tell any more.

I have the same problem, after updating to v1.32 from v1.31 I've lost all my stats... But I can live with it ;-P

 

 

P.S. I'm also using ''Fus-Roh-Doh'' but no problem with this mod I guess...

[Saeros]

I want to know what is the correct procedure to upgrade to the latest version (1.32b).

(always I use the Mod Manager to install and uninstall SLMods)

 

I installed this for now:

- SexLab Framework 1.30 (full)

- SexLab Framework (Update v1.30 to v1.31)

 

I can use the update 1.30 -> 1.32b directly or do I remove the previous (Update v1.30 to v1.31) and then upgrade?

tnks! 

 

[kurisu7885]

Anyone else getting invisible creatures?

[dje34]

Ow how I like being a FORMER-developer right now ! Anyway, don't get mad guys ! It's just a game and Ashal is doing some great work with the framework, maybe needs a lil backup there, but surely not your rage and anger.

 

Keep up the good work, Ashal ! Btw, are you alone programming this framework ?! If so, maybe you should think about taking another programmer to help you with this big project or at least an apprentice...

[trueinfernus]

none of my animations are playing with 1.32b

[h38fh2mf]

That's a bad idea, if he does it alone he knows exactly how every little part of the mod works - easy to fix and easy to add new stuff without breaking anything.

[dkatryl]

 

SexLab v1.32  changelog:

• Added: Ability to export/import configuration + animation adjustments to an external file so it can be carried over between different characters or restored later
• Fixed: player as werewolf not animating properly

Thank you so very much for the first line item.  I hated updating the Framework unless it was for a major bug fix that made updating required, simply because I hated having to reset ALL of the damn selections.  The free camera default hotkey, NP3, was my "strafe right" button, half of the default animations had to get turned off/on from the default, etc etc.

 

The only thing that didn't seem to get carried forward was the journal details.  Between the two, I'd take my journal getting wiped every time if it just remembers my settings, but if you make it so the journal's info got carried forward as well, that would be spiffy!

 

The second line item?  Heh, today I was trying to figure out WTF I did in my mod, wondering how the hell I managed to break werewolf/vampire lords as a player when they were working just fine.

 

Then I decided to take a break from it, curious to see if you acknowledged the stuff about the invalid beds, saw the Framework had updated since 1.31, and saw the exact issue (Werewolves/Vampire Lords) was fixed!  At least, now I can stop futzing with it.

 

Anyways, thanks for the update!

[volfin]

I upgraded from 1.31 to 1.32b, and can report the following issues:

 

- Stats are gone. Or at least, not displayed. I reverted back to 1.31 and the stats returned. So the data is still there, 1.32b just can't seem to read it properly.

 

There's also one addon that uses Sexlab (TDF prostitution) which worked with 1.31, but now has issues with 1.32B (specifically, once the animation starts, all controls are frozen, and even after the animation concludes, they aren't released). So not sure what changed in Sexlab to cause that.

 

Also a bug I reported a long time ago in 1.24 (with a fix included) is still in 1.32b:  http://www.loverslab.com/topic/23000-sexlab-124-bug-with-foreplay-weapon-stripping-config/

 

 

About TDF, I finally figured out the reason it was doing that was I was mistaking a *huge* 30 second delay between initiating sex and it actually starting. As a result I would try to initiate it a second time.

 

So the question is, why is Sexlab taking 30 seconds to start now?

[dje34]

That's a bad idea, if he does it alone he knows exactly how every little part of the mod works - easy to fix and easy to add new stuff without breaking anything.

 

1st : It's not a mod, it's a framework. It makes a big difference ! If you know programming (and as I read you know it...) you should know the difference when it comes to programming. It's not easier, it's not more difficult, it's just different.

 

2nd : Releasing a framework not working 100% (if it is even possible) with all the mods surrounding the LL forums and all the people using it gets to people being testers with their own saves and so being a lil aggressive. I know that feeling but I can easily imagine what it is like to be at Ashal's place reading all the comments about this or that not working perfectly. It's like your job isn't appreciated even if it is made FOR FREE !

 

3rd : Backup doesn't necessarily mean programming ! Could be testing, checking code, or simply giving advices !

 

That said, if Ashal gives up on this project (I don't even want to think about it !!!!!!) who would be able to take his/her place ?

[dkatryl]

I upgraded from 1.31 to 1.32b, and can report the following issues:

 

- Stats are gone. Or at least, not displayed. I reverted back to 1.31 and the stats returned. So the data is still there, 1.32b just can't seem to read it properly.

Stats, as in the Journal?  Ah, so that's why it looks like it got reset.

 

You know, I did notice upon loading a save that had to upgrade, during the update spam at the top, one of the first ones said: "SexLab - Player Stats Updated[Actor" exactly as written.  This message was immediately followed by the Exporting Settings one, and those all seemed to be carried over properly.

 

So perhaps whatever is causing it to put the '[Actor' in the message is also why the stats aren't there?

 

[h38fh2mf]

I don't know what the 1st or 2nd thing you said have anything to do with what I said

 

Also why does he need someone to test or tell him advice isn't that what we are all doing here?

[EternalDamned]

Just wondering if the SexLabLocationMarker is still being used before I place several hundred of them around Skyrim.

[dje34]

I don't know what the 1st or 2nd thing you said have anything to do with what I said

 

Also why does he need someone to test or tell him advice isn't that what we are all doing here?

 

 

Absolutely and, as I see, a lot of people forgot this fact : all LL members ARE testers ! So please people, act more like testers and less like users !

[lorm42]

So nobody can confirm my "stay in combat" problem ?