toys Shout Like a Virgin Evolved SE & LE

[gregaaz]

@Nonseen, how did you determine that SKSE 2.0.19 was the cause of your problems? Given the mods you fingered, I would have expected an asset load order conflict, especially with old versions of FISSES, papyrusutil, consoleutil, and so forth that many mods package without clearly disclosing. So I'm curious to learn more about how you isolated SKSE iteself as the problem so I can learn from your experience.

[VirginMarie]

11 hours ago, knots1353 said:

Hope this gives you some useful info.

It does. You are one of 3 or 4, whom has directly or indirectly led me to understand the following....

 

 

To all who have reported some of the more funky problems that have no clear root cause....

 

I've seen enough evidence now to come to this theory...

• A "bad save" can lead to bad things. Not new news, but the most apparent for SLaVE users (due to more than one report), is delays for animation scenes, and other unexplainable things going wrong for such scenes. This could also be the cause of Cassia sometimes not force greeting as expected, but this is less apparent
• Now here's the key.... We have reports of "saving" the game during Spontaneous Orgasm. Then the save when loaded, being the cause of animation scenes either not working at all, or having very long delays. So the theory becomes...
  • saving during scene = bad save = the other bad things
  • and now your save is toast and cant be used for much else successfully

• One of the reasons I'm looking for such theory, is that these scenes are "tried and proven" all of them working for over 3 to 5 years in LE, and no reports of problems. So something is up, that is new from SE, and not a simple case of the scene being full of bugs
• I've tested a bit to see if I can save during a scene. For Spontaneous Orgasm I was able to save right away. For Standing Stone, I could not. I've not tried other scenes yet, but seeing it can be saved in one case is almost enough

Now here is the kicker...

All SLaVE and Toys scenes, where player controls are disabled, use the very same function to initialize and un-initialize the scene. This function among many other things, disables the ability to save the game!!!!... wtf SE.!!!?.. why do you let the game save?

 

For those interested, this is the line in the code that is supposed to disable saving the game, and works fine in LE... 

Game.SetInChargen(true, true, false)

 

I remember years ago, for LE, in SLaV, it was found that saving during a scene with player controls disabled, was bad and led to nasty things. So I implemented this. Our problem does appear to be that SE is not behaving correctly for this command while it works in LE. You should not be able to save when its bad to save, and you can't in LE but you CAN in SE.

 

Auto save can be in play, both mods for it, and the vanilla.

 

Going to have to do some digging and research, unless I get lucky with someone reading this who knows how to prevent the damn game from being saved. I hope to find and release a fix soon. Right now I don't know a solution.

[VirginMarie]

7 hours ago, Simplicitas Sancta said:

"Earlier" this cry was freely accessible ... but now you've blocked it - right? If not - this cry is stuck. 

I think you are talking about one of the Virgin Shouts? Maybe you mean the 3rd word for Virgin Strip Shout?

If so, no, I've not blocked it.

What is happening for you? Do you go to the word wall and nothing happens? I need some step-by-step details on the issue you see.

 

Quote

The powers are not transferred to the VIRGIN mask, the quest level "Find all nine masks" is not recognized.

Does this mean, when you put a mask from a priest on, the scene does not happen? What do you see, if anything?

 

 

Also please read this, in case its effecting you.

[Nonseen]

1 hour ago, gregaaz said:

how did you determine that SKSE 2.0.19 was the cause of your problems? Given the mods you fingered, I would have expected an asset load order conflict, especially with old versions of FISSES, papyrusutil, consoleutil, and so forth that many mods package without clearly disclosing. So I'm curious to learn more about how you isolated SKSE iteself as the problem so I can learn from your experience.

 

i not know skse 2.0.19 is issue or not.

i put here the list of things i changed and things started work. 

 

I removed SKSE 2.0.19 becuse Sexlab Framework say here: 

 

 

Quote

 

Requirements: 

• Skyrim SE 1.5.97
• SKSE SE v2.0.17
• SkyUI SE

 

 

i dont know exactly what the difference beatwen 2.0.17 and 2.0.19.

 

i just trying out things until it seems work.

 

if wish pin point what is exact cause i need re install this mods one by one and test it out see what mod or mods behind the problem. 

i suspect engine fixes may one of the problem but not 100% sure here is the reason my suspition:

 

Quote

E:\Repos\skse64\EngineFixesSkyrim64\src\patches\miscpatches.cpp(125): [warning] Error occurred trying to open file: fopen_s([EDITED OUT]\Documents\My Games\Skyrim

Special Edition\__MO_Saves\Save297_47992419_0_5261686561_Tamriel_001509_20210424172949_18_1.ess.tmp, r+b), errno 2

This one come from SKSE\EnginFixes.log

Evry time i save a game this type of message put into the log.

 

my thinking behind my actions:

remove all mods that not essential to SLaVE work, and see what happens.

 

 

25 minutes ago, VirginMarie said:

All SLaVE and Toys scenes, where player controls are disabled, use the very same function to initialize and un-initialize the scene. This function among many other things, disables the ability to save the game!!!!... wtf SE.!!!?.. why do you let the game save?

 

I dont know the warning mesage i put here how effect slave files.

 

Another thing in my mind, but i not expert on this. I see some times after loading a game toys menus not load fast as usual. this cases evrything toys related feels like lag behind the in game event. what happen if i save a game the time that from toys sperspective i shudunt. But becuse script things lag behind save blocking mechanism not in place.

 

 

Secund wird thing i seen:

if i die and before the "love self to life" scane start i hit load game and start the fight agin where i died. my heat, manna, stamina bar not display enemy hit me and i take no damage.

if i do a realod agin evrything start work as intended, my heat hbar shown and i take damage.

 

I dont know this helps or not. i just try things out see what happens.

[gregaaz]

5 minutes ago, Nonseen said:

 

Secund wird thing i seen:

if i die and before the "love self to life" scane start i hit load game and start the fight agin where i died. my heat, manna, stamina bar not display enemy hit me and i take no damage.

if i do a realod agin evrything start work as intended, my heat hbar shown and i take damage.

 

I dont know this helps or not. i just try things out see what happens.

 

Thanks for the additional information, Nonseen. For what its worth, your second issue may just be a SLaVE spin on an existing vanilla bug. There are a bunch of problems that can occur when loading a game "hot", such as doubling the perks on enemies you were in combat with when you loaded, and this might be a similar thing of the previous game's data being retained in memory when you load.

 

The vanilla issues, like doubled perks, can be solved by quitting out of the game (to desktop, not just to the menu) and reloading "cold" from a new launch. That may help also with the situation you described above - certainly worth a try at least.

[Nonseen]

4 minutes ago, gregaaz said:

The vanilla issues, like doubled perks, can be solved by quitting out of the game (to desktop, not just to the menu) and reloading "cold" from a new launch. That may help also with the situation you described above - certainly worth a try at least.

Thank you for the information.

[knots1353]

1 hour ago, VirginMarie said:

It does. You are one of 3 or 4, whom has directly or indirectly led me to understand the following....

 

 

To all who have reported some of the more funky problems that have no clear root cause....

 

I've seen enough evidence now to come to this theory...

• A "bad save" can lead to bad things. Not new news, but the most apparent for SLaVE users (due to more than one report), is delays for animation scenes, and other unexplainable things going wrong for such scenes. This could also be the cause of Cassia sometimes not force greeting as expected, but this is less apparent
• Now here's the key.... We have reports of "saving" the game during Spontaneous Orgasm. Then the save when loaded, being the cause of animation scenes either not working at all, or having very long delays. So the theory becomes...
  • saving during scene = bad save = the other bad things
  • and now your save is toast and cant be used for much else successfully

• One of the reasons I'm looking for such theory, is that these scenes are "tried and proven" all of them working for over 3 to 5 years in LE, and no reports of problems. So something is up, that is new from SE, and not a simple case of the scene being full of bugs
• I've tested a bit to see if I can save during a scene. For Spontaneous Orgasm I was able to save right away. For Standing Stone, I could not. I've not tried other scenes yet, but seeing it can be saved in one case is almost enough

Now here is the kicker...

All SLaVE and Toys scenes, where player controls are disabled, use the very same function to initialize and un-initialize the scene. This function among many other things, disables the ability to save the game!!!!... wtf SE.!!!?.. why do you let the game save?

 

For those interested, this is the line in the code that is supposed to disable saving the game, and works fine in LE... 

Game.SetInChargen(true, true, false)

 

I remember years ago, for LE, in SLaV, it was found that saving during a scene with player controls disabled, was bad and led to nasty things. So I implemented this. Our problem does appear to be that SE is not behaving correctly for this command while it works in LE. You should not be able to save when its bad to save, and you can't in LE but you CAN in SE.

 

Auto save can be in play, both mods for it, and the vanilla.

 

Going to have to do some digging and research, unless I get lucky with someone reading this who knows how to prevent the damn game from being saved. I hope to find and release a fix soon. Right now I don't know a solution.

 

Hmmn...  While I agree that saving *during* a scene can be an issue, I don't think it's the root cause of the ones I'm seeing, as I don't do saves mid-scene, ever.   I actually try to have as little as possible going on at the time I'm saving, not because it can corrupt things, but because a lot of mod authors do upgrades without understanding how thread saving and loading in papyrus works.

 

(The quick, simplfied version - during a save, Skyrim saves not only the thread context and stack for each thread, but it also saves the script store for any function in one of those stacks.  When Load occurs, it resumes running those functions - not the new ones in the data folder, but the *original* ones that existed when the save was made, from the saved script store.  It does this all the way up the call chain, but if one of those functions calls another function in a different script, that one calls the *new* version of the function from the data folder.   Net effect, during updates of a module, you might have a combination of new and old code running at the same time - a recipe for corruption if the mod wasn't designed for it.   I believe a great deal of buggy behavior, including most save game corruption, derives from this and from not understanding Skyrim threading in general.)

 

(Side note - this is also a very good reason never to try to resume from Auto-saves -- those saves are often done at times when a lot of threads are going on.   Quicksaves, on the other hand, are okay if you wait until things are relatively quiet.  I also don't recommend saves immediately after a combat or cell transition - give it a few seconds for the threads to finish up.)

 

However, I do have an alternative guess as the root cause -- you have a lot of situations where scenes are expected to trigger on a forcegreet.  In all of the tests I found with the issue, there was some kind of forcegreet involved that was either delayed because of a scene or save/load or didn't work because of missing dialogue.   I suspect the problem may be relating to the forcegreet being interrupted in some fashion.   Forcegreets always seem to be involved in some way in the later issues -- Cassia trying to forcegreet with no dialog, the ghosts trying to forcegreet when I'm in a spontaneous orgasm scene or doing a worship scene.   They often are triggered with mobs which aren't even in view, so it's very easy to save or trigger some other action/behavior/animation.

 

[VirginMarie]

55 minutes ago, Nonseen said:

I see some times after loading a game toys menus not load fast as usual. this cases evrything toys related feels like lag behind the in game event. what happen if i save a game the time that from toys sperspective i shudunt. But becuse script things lag behind save blocking mechanism not in place.

 

The function I call, to disable the ability to save a game, is before any scene can start, and then the call I make to turn that off, is after the scene ends. The order of this is of course very important. But no matter how much things are lagging, my "disable" has happened before the scene does anything. I will still be looking at that, and perhaps try a tiny delay, but I'm hopping to find something that says "yes this problem exists in SE and here's a known solution".

[VirginMarie]

18 minutes ago, knots1353 said:

I suspect the problem may be relating to the forcegreet being interrupted in some fashion.   Forcegreets always seem to be involved in some way in the later issues 

 

Keep in mind:

• all this quest and dialogue stuff as been working without problems for 3-5 years in LE. there is no new stuff. no experiments. its tried and proven
• SLaVE has no role to play directly in Story Manager (getting the NPC to come to you) and forcegreet, its all vanilla using AI Packages and conditionals, until a dialogue line runs a script. When Cassia wont talk to you, its Skyrim Engine going wrong, unless I have the wrong conditionals, but the conditions have worked for 3-5years

Conclusion: Your scenarios you are seeing are the symptom of something that went wrong before you got to this point. They are not cause. Cause is something that happened prior, and its going to be related to SE differences. I wish to eliminate the possibility of creating a corrupt save by saving at the wrong point. Then this would be ruled out. But the function to do this, appears to not work consistently in SE, which is in fact what I believe is the cause, of at least some problems.

 

[knots1353]

1 hour ago, VirginMarie said:

 

Keep in mind:

• all this quest and dialogue stuff as been working without problems for 3-5 years in LE. there is no new stuff. no experiments. its tried and proven
• SLaVE has no role to play directly in Story Manager (getting the NPC to come to you) and forcegreet, its all vanilla using AI Packages and conditionals, until a dialogue line runs a script. When Cassia wont talk to you, its Skyrim Engine going wrong, unless I have the wrong conditionals, but the conditions have worked for 3-5years

Conclusion: Your scenarios you are seeing are the symptom of something that went wrong before you got to this point. They are not cause. Cause is something that happened prior, and its going to be related to SE differences. I wish to eliminate the possibility of creating a corrupt save by saving at the wrong point. Then this would be ruled out. But the function to do this, appears to not work consistently in SE, which is in fact what I believe is the cause, of at least some problems.

 

As someone who's been programming over 40 years, I have to disagree.   *Climbs on soapbox*  All the scripting is NOT the same as what you've had for 3-5 years, since you've converted to using a new framework, Toys.   Starting with the assumption that it all still works, even if you wrote it yourself, is violating the first rule of programming - you can never assume code you haven't changed still works if you've changed ANYTHING else, even if it seems completely unrelated.    A compiler, library, heck, I've had a major issue which took days to track down due to a stupid extra semicolon in a module completely unrelated to the code which was breaking.   *Anything* can trigger an unknown bug because edge condition bugs need that edge condition to happen - and might stay buried for years.    This is why we have unit tests and regression tests, although having spent months writing for Skyrim, I'll say it's a lot harder to write those than it is in other environments. 

In your case, you have a whole new framework of Toys - a very complex mod, being used by another very complex mod, both of which can trigger a whole new slew of bugs, and whose interactions can trigger even more bugs.  It doesn't require anything as arcane as a save game corruption or an engine difference to cause the problem.  I don't know your code well enough to identify the root problem for certain, but when I read your post, I started looking at the source, and was easily able to identify *part* of it given what I've already learned and reported, and an open mind that there *are*, in fact, bugs to find.   I found one easy bug, at least:

 

Why does Force Player Reset not fix things?   Why is it reporting the player as busy afterwards:?   Well, that's not hard to find - I looked up the "combat or busy" message dialog, found out it was calling Virgin.VirginIsBusy(), which calls Toys.IsBusy().   Toys.IsBusy() is checking StorageUtil for a "Toys_SceneRunning" flag, and since none of the other conditions seemed relevant, I tracked that down.   It's set to 1 by InitSceneStart() or SetBusy(), and set to 0 by InitSceneEnd() or SetBusy().   SetBusy() isn't called by anything in either Toys or SLaVE, FYI -- the ForcePlayerResetToggle script calls ToysLib's ToysBusy.SetValue(0), but that doesn't turn off the Toys_SceneRunning flag = it instead affects a global variable in ToysLib .   Toys InitSceneEnd() is ONLY called by VirginInitSceneEnd(), which is called by many many places in the SLaVE code, but none of them appear to be called from the ForcePlayerResetToggle state.    Since it's not calling either of the functions which can turn off Toys_SceneRunning, after a Force player reset, it will ALWAYS assume that toys is running a scene, since it doesn't start new scenes if it's busy.  Best guess here is at one point you were using the ToysBusy flag, and later changed it to use Toys_SceneRunning, but never caught all the places you were using ToysBusy.

 

Now, does this fix the root problem?  Not even close.   I suspect that's a much more complex interaction between different scenes, toys, timing, and perhaps threading.   I don't envy you the job of finding it... but if this were my mod, I'd never in a million years assume it wasn't my own bug until I eliminated all other possibilities.

If I had a lot more time on my hands, I'd try adding Debug.Trace() calls all over your code and see if I could track it down better, but I have my own projects to work on which take up enough of my Skyrim programming time.

[gregaaz]

Hi folks, if you have been following the Monilee's Adventure blog, there are two new entries for today.

 

Chapter 18: A Quest for Dibella

Chapter 19: The Iron Mask (partial)

 

Sadly, Monilee has now succumbed to the "animation delay/actor freeze" bug described by several others and her game is now in an unplayable state. While I could concievably roll back to an earlier save, after discussions with VM I am going to hold off on further testing until the next SLaVE release comes out. I'm also going to be setting up a parallel "minimum implementation" test to try and nail down which issues, if any, will affect users with small load order to help in prioritizing bug targeting and hopefully to filter out noise and unrelated variables.

[VirginMarie]

21 hours ago, knots1353 said:

Hmmn...  While I agree that saving *during* a scene can be an issue, I don't think it's the root cause of the ones I'm seeing, as I don't do saves mid-scene, ever.

I think it would be pretty rare. It can happen for auto. I get that you are not using auto, or choosing to save during a scene. But that does not rule out what I'm trying to prevent or potential cause of the issues reported.

 

 

First, why am I hunting this down?  Because it's a known problem...

 

The reports of strange SLaVE scene issues, is deja vu for me. I had the same issues in early releases of SLaV 4 years ago. I fixed it by implementing "prevent save when player controls are modified" (which happens during scenes). This is now in Toys and SLaVE uses it but is not always working in SE. We know this because I can recreate it, and for whatever reason, others have reported that they can save during a scene. In at least one case the report was from a mod author who likely knows that allowing a save during that scene is bad, and so was testing it. This is a known thing.

 

I might be barking up the wrong tree, but probably not. It might not be the only cause of issues, but it's definitely an issue.

 

 

Is it possible that it can effect users with no auto save, who are careful to not save during a scene?  Yes, it can actually happen fairly easily, and all it takes is once. I shall explain...

 

The bad save problem is fixed by "prevent save when player controls are modified". This is about the state of player controls, not animations or a scene. The objective is to prevent a save, while the player controls are not in the normal state. This is why the Skyrim vanilla startup quest does not let you save and why the SetInChargen exists. While you CAN avoid manually saving during a scene, you CAN"T know if a player control state was left in the wrong state, thus after the scene ends, you could save while still in that state, assuming the scene has finished shutting down when it's not yet.

 

One example would be just lag. Another example... some scenes will "cascade", so SLaVE might do the word wall love, then by chance, put you into the exhausted scene shortly after, but not immediately, and in this case its not resetting all the player controls in-between, just some. A save in between could be that save that kills the next scene, and is normally prevented, but that prevention is sometimes failing in SE.

 

You can attempt to manually avoid saving when you should not, but you cannot be sure, nobody can. It should be not possible in the first place, but sadly I don't yet have a solution to prevent it consistently in SE. Working on it, and people during beta who understand the issue can help by reporting. 

 

 

Quote

However, I do have an alternative guess as the root cause -- you have a lot of situations where scenes are expected to trigger on a forcegreet.  In all of the tests I found with the issue, there was some kind of forcegreet involved that was either delayed because of a scene or save/load or didn't work because of missing dialogue.   I suspect the problem may be relating to the forcegreet being interrupted in some fashion. 

 

This is how those scenes with force greet work...

1. SLaVE decides its time to send an NPC out to find and greet. Is uses preset conditionals in the ESP suing Skyrim's native feature called Story Manager. Very little script involved and the scripts runs long before you see any thing. [this step does not get used in all cases, some start with #2]
2. The Skyrim Engine (or sometimes script) triggers the quest and sends the NPC to the right location. An AI Package is used with conditions that SLaVE has preset, in the ESP (no script involved, nothing has changed in 4 years)
3. The force greet, entirely driven by the Skyrim engine, occurs, and another set of preset conditionals in the ESP (no script) is used to determine which dialogue branch to start (conditions here, is the only thing that SLaVE is responsible for, preset, in the ESP,  and no changes in 4 years)
4. Different things now happen based on dialogue, by calling script

The most reported issue has been that #3 is not working. We know that 1 and 2 work fine. 3 is the most reported. And was not fixed by regenerating the SEQ file.

 

#3 its controlled entirely by Skyrim Engine, and conditionals that I put in the ESP 4 years ago and have not changed. There is no SLaVE script involved. if you understand this then you know that either the conditionals are wrong (but they worked for 4 years), or the Skyrim engine itself is floundering somehow (theory is due to a bad save.   i.e. it can't read those conditional or something internal like that).

 

18 hours ago, knots1353 said:

*Climbs on soapbox*

Regarding this, I do agree with everything you said when it's script. But the Force Greets failure point is not about script. Its very independent and self contained. But we ARE testing the living crap out of it. Gregaaz and I spent over 4 hours just the other day, walking though every condition that cassia uses in a sample force greet that was not working. Everything checked out, yet the Skyrim engine is still failing to make (#3) above happen. And Gregaaz's save is now toast. The cause is whatever made his save bad. The symptom is the the engine unable to make the force greet work. We need to fix the cause, not the symptom.

 

(Unrelated to any of the above)

Yes there is one bug (maybe a bug?) you found.

Toys_SceneRunning in Toys will not get reset by the SLaVE's Force Player Reset. But should it?

Toys_SceneRunning is a new feature for mods to see a if scene is active, without a hard dependency. Its not in use yet, and not documented, and its questionable as to if SLave should reset a feature this is part of the shared framework. So is it even a bug? I'm not sure it should do it. I'm not aware of a mod using that feature yet (its not even documented yet, too new and not ready). Also there is no implied guarantee that the SLaVE force player reset can magically fix all problems.

 

Finding this and reporting this was helpful, because I do need to decide what it should do. I just want you to understand that I do understand testing, the need for it, and that I do a whole lot of it. For every 1hour of dev there is at least 4 of testing. I spent some time working in an EA Motion Capture Studio, where my function was largely about QA.

 

[knots1353]

6 hours ago, VirginMarie said:

Toys_SceneRunning in Toys will not get reset by the SLaVE's Force Player Reset. But should it?

Toys_SceneRunning is a new feature for mods to see a if scene is active, without a hard dependency. Its not in use yet, and not documented, and its questionable as to if SLave should reset a feature this is part of the shared framework. So is it even a bug? I'm not sure it should do it. I'm not aware of a mod using that feature yet (its not even documented yet, too new and not ready). Also there is no implied guarantee that the SLaVE force player reset can magically fix all problems.

 

Finding this and reporting this was helpful, because I do need to decide what it should do. I just want you to understand that I do understand testing, the need for it, and that I do a whole lot of it. For every 1hour of dev there is at least 4 of testing. I spent some time working in an EA Motion Capture Studio, where my function was largely about QA.

 

 

So... I'm not going to address most of that as I honestly have no idea what debugging tools you've created for Toys or SLaVE or how you're approaching debugging in general.   I simply wanted to point out that you can't ever assume that code which used to "work" was bug free and should always keep an open mind about there being bugs in it.   I'd be examining those conditionals closely in your shoes, but perhaps you have a different approach.

 

Regarding the specific Toys_Scenerunning issue -- I agree the better solution isn't to just reset Toys_Scenerunning - but *something* has to do so or it will never be able to continue if Force Player Reset is done during a scene.   I suspect it might be better to trigger Toys.InitSceneEnd() for the SLaVE scene which had been running... but I don't know what the side effects of doing that are - it depends a lot on the scene which was running.   From what little I've looked into it, your scenes appear to be mostly monolithic procedural routines driven by waits - but that kind of design doesn't really lend itself to any sort of safe abort mechanism.  If I were writing scenes like that, they'd be fully event driven with a cleanup routine which could be called to unwind the scene no matter what state it was in, but Skyrims event driving model is limited, and that's far more difficult than I want it to be.   (Which is where my main Skyrim development focus currently is, but it's a *long* way from being ready...)   Perhaps a "cleanup" flag which  each scene can periodically check during/after each wait which will skip the rest of the scene if it's set?   I'm just throwing suggestions out there to trigger ideas. 

 

 

[VirginMarie]

3 hours ago, knots1353 said:

 I simply wanted to point out that you can't ever assume that code which used to "work" was bug free and should always keep an open mind about there being bugs in it.   I'd be examining those conditionals closely in your shoes, but perhaps you have a different approach.

I already stated that I've worked 4 hours with Gregaaz on checking those conditions. Conclusion: The force greet is the symptom not the cause.

 

Quote

Perhaps a "cleanup" flag which  each scene can periodically check during/after each wait which will skip the rest of the scene if it's set?   I'm just throwing suggestions out there to trigger ideas.

Thanks I appreciate it.

 

 

 

 

[joenothing12]

I'm having word wall troubles, retrieving the dragon stone everything went as expected, but in ustengrav, and in the sepulcher i'm unable to trigger the wall.

removing slave_se 8.01 clears the trouble (at ustengrav anyhow) , i'm suspecting a conflict someplace, but that's going to take a while to eliminate as a possibility.   suggestions on things to try would be appreciated, tried whirlwind sprint, and tpc, no joy.  otherwise may just need to use the console to add the shouts.

[gregaaz]

3 hours ago, joenothing12 said:

I'm having word wall troubles, retrieving the dragon stone everything went as expected, but in ustengrav, and in the sepulcher i'm unable to trigger the wall.

removing slave_se 8.01 clears the trouble (at ustengrav anyhow) , i'm suspecting a conflict someplace, but that's going to take a while to eliminate as a possibility.   suggestions on things to try would be appreciated, tried whirlwind sprint, and tpc, no joy.  otherwise may just need to use the console to add the shouts.

 

Thanks for reporting this, Joe. A couple of questions for you about this behavior:

1. Are you playing in LE or in SE?
2. Which version of the Toys framework are you running?
3. When you installed SLaVE, did you start a new game or did you continue an existing save? 
4. If you are using MO2, please right click on SLaVE (on the left side menu) and click "information" - is there anything in the conflicts section? SLaVE includes updated versions of the word wall controller script, so if its getting overwritten by something else that could cause unexpected results.
5. Before you started running into trouble with the word walls, did you at any time save during or immediately after an animated scene, and then later load that save?
6. Do the other Toys and/or SLaVE animations (spontaneous orgasm, Noctural rescue, Standing Stone love, etc.) play promptly and without freezes or delays?

This info will be helpful to VM in better understanding the trouble you are running into.

 

[joenothing12]

5 hours ago, gregaaz said:

 

Thanks for reporting this, Joe. A couple of questions for you about this behavior:

1. Are you playing in LE or in SE?
2. Which version of the Toys framework are you running?
3. When you installed SLaVE, did you start a new game or did you continue an existing save? 
4. If you are using MO2, please right click on SLaVE (on the left side menu) and click "information" - is there anything in the conflicts section? SLaVE includes updated versions of the word wall controller script, so if its getting overwritten by something else that could cause unexpected results.
5. Before you started running into trouble with the word walls, did you at any time save during or immediately after an animated scene, and then later load that save?
6. Do the other Toys and/or SLaVE animations (spontaneous orgasm, Noctural rescue, Standing Stone love, etc.) play promptly and without freezes or delays?

This info will be helpful to VM in better understanding the trouble you are running into.

 

1) SE

2) SE V0.5

3) New game

4) SLave overwrites unofficial patch wordwalltrigger

5) this is a difficult question, not knowingly. I may start another new game to test more carefully.

6) the SLave animations can get stuck/loop especially if they trigger near a word wall.

[joenothing12]

1 hour ago, joenothing12 said:

1) SE

2) SE V0.5

3) New game

4) SLave overwrites unofficial patch wordwalltrigger

5) this is a difficult question, not knowingly. I may start another new game to test more carefully.

6) the SLave animations can get stuck/loop especially if they trigger near a word wall.

Started a new game and rushed it with coc/speedmult. arrived at the barrow and word wall didn't work, ran mcm install tests and suddenly it did.  will continue testing to see if i can get a better clue, not satisfied with this as a problem desc yet.

[VirginMarie]

1 hour ago, joenothing12 said:

Started a new game and rushed it with coc/speedmult. arrived at the barrow and word wall didn't work, ran mcm install tests and suddenly it did.  will continue testing to see if i can get a better clue, not satisfied with this as a problem desc yet.

 

 

To Everyone having/reporting issues such as:

• NPCs trying to greet but being bimbos with nothing to say
• having animation scenes (any of them) not start or slow

I believe this, and other strange but similar problems, at least most of them, will go away with the next release, which is targeted for tomorrow.

 

The release fixes 3 core issues, two of them in Toys, two of them are SE differences that don't affect LE, one of them affects both SE and LE. SE differences are HARD, but I always like to say its better when it is hard

 

And thanks to everyone reporting. Could not have done it without you.

[VirginMarie]

SLaVE v8.02 (Beta) Has Released for LE and SE

 

What's New see... Change Log

 

• The release is focused mainly on critical problems, with a few easy things thrown in too. Thanks for the reports!
• The most critical fixes are within Toys. You need the updated Toys along with this release.
• Please pay close attention to the cases where a new game must be started.

 

I figured the picture with the dragon is fitting because if you can successfully get the dragon scene animating, you can animate anything!

 

 

 

 

 

 

A new section has been added:  Known Issues for V8.02

[gregaaz]

Thanks to Project Proteus, Monilee has survived her journey through Oblivion and emerged in the world of SLaVE 8.02. You can find my initial pre-playthrough analysis here (nothing exciting though). Monilee's adventure will continue soon!

 

[darthnoldor]

Hi Firends, I have two question:

 

1) Do you already have an approximate date for the final version of the mod (no beta)? ☺️

2) if I install Shout and Toys during the game (a game where I have never installed any version of these mods), do I leave the ESM and ESP files at the bottom of the order of loading of the esm / esp files or do I bring them up? ?

 

Thanks ?

[VirginMarie]

1 hour ago, darthnoldor said:

Hi Firends, I have two question:

 

1) Do you already have an approximate date for the final version of the mod (no beta)? ☺️

Really it needs to be Toys and SLaVE out of beta, which is the plan, that they reach that point together. We've been targetting May, but it will be more likely June.

Quote

2) if I install Shout and Toys during the game (a game where I have never installed any version of these mods), do I leave the ESM and ESP files at the bottom of the order of loading of the esm / esp files or do I bring them up? ?

 

It's safe to add SLaVE at the end of your load order, but since you need Toys, you must start a new game. This is because its impossible to put an ESM at the end (if you do, Skyrim forces it up before the ESPs when it starts). This is explained some more in the change log, and in the FAQs.

[gregaaz]

First 802 test report (and actual legitimate entry in Monilee's adventure!) is up. So far things seem to be generally running smoother, with less script lag and no CPU race condition freezes at all despite a fairly long session. Thanks to liberal use of COC, the party is mostly assembled and the SLaVE main quest is started. 

[darthnoldor]

7 hours ago, VirginMarie said:

Really it needs to be Toys and SLaVE out of beta, which is the plan, that they reach that point together. We've been targetting May, but it will be more likely June.

It's safe to add SLaVE at the end of your load order, but since you need Toys, you must start a new game. This is because its impossible to put an ESM at the end (if you do, Skyrim forces it up before the ESPs when it starts). This is explained some more in the change log, and in the FAQs.

 

Thanks!! ??