Fighting the Slavery/Tryout Stutter

[zippy57]

If the scanner clears it itself it could end up clearing it before the plugin is done cycling through it.

[theskid]

Ah that would be it, i didn't notice working girl was missing, I'll put it back in and see if my saves don't explode this time

[Snoopy911]

Patched the corresponding scripts.

The only script I'm not sure about is the one in SexoutLegion.esm - I had to rewrite it a little bit as it has multiple return points. The thing I'm not sure about is if it's legal to use a return statement in a labelled block. Test please. (I guess if the game doesn't crash immediately' date=' then it's legal. )

[/quote']

 

Travelled around a little bit and finally tried the Gomorrha which always gave me the worst trouble. I still get a stutter effect when i'm inside for some time but it's fine again if i change the area. Seems the new plugins work very well.

[Masthiste]

I tried the new plugins with the new slavery esm and my stuttering problem seems to have vanished. I haven't tried the Freeside/New Vegas areas yet but it seems these edited plugins are on the right track to finally end this issue.

[astymma]

These problems with the scanner make me wonder why the scanner itself doesn't just clear out the lists for you. Are there any good sides to it leaving it up to the plugin?

 

The lists don't work that way. What you have is a list in sexout. You put your list in that list. When the scanner runs it takes every list in the scanner list and fills every one of them with all scan targets it found. Basically each plugin is saying "hey, here's my list, put the scan targets in here". So each plugin is responsible for clearing its own list of scan targets. Sexout can't clear them because it won't have any idea if you've actually done what you need to do with the data.

[ruddycray]

I understand what the scanner is doing. I still don't understand why it can't handle clearing the lists. Is it that the spell start script block won't run until after the scanner script is done? If that's true, does it run on the next frame, or does it just happen at some point in the future? If it runs on the next frame, couldn't the scanner clear out the list before adding new things to it? If the scanner is running so often that the spell scripts aren't sure to run before the next time the scanner does then you'll have a slow build up of references in the form list and will get back into the same problem, just a little more slowly. The way the scanner works, it doesn't seem like it is expecting the spell scripts to hold onto the list for very long, and if they do you get growing lists.

 

Edit: I guess you wouldn't get forever growing lists, but you would have to worry about two or more copies of the same actor reference in the list.

[astymma]

I understand what the scanner is doing. I still don't understand why it can't handle clearing the lists. Is it that the spell start script block won't run until after the scanner script is done? If that's true' date=' does it run on the next frame, or does it just happen at some point in the future? If it runs on the next frame, couldn't the scanner clear out the list before adding new things to it? If the scanner is running so often that the spell scripts aren't sure to run before the next time the scanner does then you'll have a slow build up of references in the form list and will get back into the same problem, just a little more slowly. The way the scanner works, it doesn't seem like it is expecting the spell scripts to hold onto the list for very long, and if they do you get growing lists.

 

Edit: I guess you wouldn't get forever growing lists, but you would have to worry about two or more copies of the same actor reference in the list.

[/quote']

 

OK, this is how it works:

 

1 - Sexout has a scanner list

2 - The mod has a scanner list

3 - The mod places its list inside the Sexout list

4 - Sexout has a scanner spell list

5 - the mod places a spell in the Sexout spell list

6 - The Scanner finds results

7 - Sexout checks its list and puts the id's of the scan results in every list it finds in its list

8 - Sexout casts the spell from the mod on the player

9 - the spell runs a script on the player

10 - the spell checks the count of id's in the list and iterates over each member

11 - if it meets the criteria, it casts a new spell on the target to "do something"

12 - after it checks every id in the list, it then empties the list

 

To have sexout clean the lists is an extra overhead. Every mod using the scanner would have to tell Sexout it's done and Sexout would have to wait for word that the mod was done before cleaning that mod's list. It's safer and simpler and less overhead for each mod to clean its own list.

 

As far as duplicates, that's not possible given the list implementation. List add functions check for the id in the list and either move it to the 0 position or the last position unless a specific index is stated. It only adds the id to the list if it isn't already present. Now it is possible to add a reference id to a list that already contains the base id for that object. As an example Player [00000007] and Player [00000014] can both be in a list.

[ruddycray]

I already understood steps 1 - 12. That doesn't answer why the mod would need to tell the scanner anything. If you can't be sure that the spell script has run before the scanner runs again, that's the only thing that would make sense to say that the scanner couldn't just empty the list itself. If you can be sure that the spell script has run before the scanner runs again, then it isn't extra overhead because the mods have to clear the list anyway, and there is no need for any extra talking between the scanner and the mod.

 

I'm not sure I even understand why the scanner needs to run more than once every 5 seconds, lets alone 10 or more times per second. I have written approach scripts in Oblivion that only ran at the normal quest script interval and they worked fine. What can happen in 100 milliseconds or less that is so important?

 

As far as duplicates' date=' that's not possible given the list implementation. List add functions check for the id in the list and either move it to the 0 position or the last position unless a specific index is stated. It only adds the id to the list if it isn't already present. Now it is possible to add a reference id to a list that already contains the base id for that object. As an example Player [00000007'] and Player [00000014] can both be in a list.

 

That isn't true in the NVSE code that I have. The ListAddForm function adds to the end of the list without looking for duplicates. Also, if that were true, the problem that is the subject of this thread wouldn't happen. With my changes to the scanner, I saw with my own eyes the list counts growing and growing while just standing there in the same area. If the list functions checked for duplicates, you wouldn't see the list counts grow until you went into a new area, and it would take much longer for this problem to be noticed.

[zebop117]

If you can't be sure that the spell script has run before the scanner runs again

 

You can't be sure of anything unless you've got a documentation-provided guarantee or the sources, or disassembled the binary. Neither is true in this case, all you've got is a blackbox you can poke to see how it reacts, and *assume* you'll get that same reaction every time you poke it that same way. And then you have to repeat the experiment a number of times to make your assumption less unreliable (but still unreliable). At the same time, there's a simple and guaranteed to work way to get the job done. Do you really want to trade it for a wild-goose chase?

[astymma]

That would be an error in NVSE if it allows for duplicate list entries and should be labeled as a bug and reported.

 

As for the mods cleaning THEIR OWN list, how is that hard to understand as best practice?

 

As for why does the scanner run so often... I'm on your side of the fence on that argument. I don't think it does need to run that often.

[ruddycray]

At the same time' date=' there's a simple and guaranteed to work way to get the job done. Do you really want to trade it for a wild-goose chase?

[/quote']

 

That would be an error in NVSE if it allows for duplicate list entries and should be labeled as a bug and reported.

 

As for the mods cleaning THEIR OWN list' date=' how is that hard to understand as best practice?

[/quote']

 

It looks like AddFormToFormList is the GECK function and does say it will check for duplicates. The scanner uses ListAddForm instead and I don't see any promises that it will check for duplicates.

 

As for mods cleaning their own lists, I didn't say it was hard to understand as best practice. It may also be simple and guaranteed to work. But in reality it looks to me like 100% of the mods I have tried that use the scanner have done it wrong. Even the API guide post says the scanner is easy to use wrong. If there is a way to make the scanner easier to use, why not do it?

 

It might be assuming to say that the spells will run before the scanner runs again, but if the scanner rate is set to something that isn't crazy then it is probably safe to assume it.

[astymma]

At the same time' date=' there's a simple and guaranteed to work way to get the job done. Do you really want to trade it for a wild-goose chase?

[/quote']

 

That would be an error in NVSE if it allows for duplicate list entries and should be labeled as a bug and reported.

 

As for the mods cleaning THEIR OWN list' date=' how is that hard to understand as best practice?

[/quote']

 

It looks like AddFormToFormList is the GECK function and does say it will check for duplicates. The scanner uses ListAddForm instead and I don't see any promises that it will check for duplicates.

 

As for mods cleaning their own lists, I didn't say it was hard to understand as best practice. It may also be simple and guaranteed to work. But in reality it looks to me like 100% of the mods I have tried that use the scanner have done it wrong. Even the API guide post says the scanner is easy to use wrong. If there is a way to make the scanner easier to use, why not do it?

 

It might be assuming to say that the spells will run before the scanner runs again, but if the scanner rate is set to something that isn't crazy then it is probably safe to assume it.

 

As far as I know, the default is 10Hz, or 10 scans per second. It can go as low as 1Hz and, I'm assuming from the MCM scripts since the slider max isn't defined in Sexout, as high as 255Hz.

 

There are plenty of people who do know how to use the scanner correctly. If you find a mod using it incorrectly, report it as a bug in the mod's thread and perhaps one of us who do know how can instruct the mod author in how to use it correctly. Or, failing that, just tell them to PM me and I can help them.

 

What I've seen isn't so much an incorrect usage of the scanner so much as incorrect use of a scripted effect, specifically the start-update-finish cycle.

[Tasha69]

windows 7

3.6 quad

gtx 550ti

4gb ram

 

I run pregnancy, tryouts, breeder, brutalrapers, etc. all with no stutter. Though, Brutal will do it sometimes (depending on approach chance settings and overriding from other mods)

 

But, I don't run max settings and always disable vsync on any game (usually the biggest culprit of lag/stutter...)

 

I've also done away with graphical enhancement mods. Personally they're not that impressive to me and serve little purpose other than to drop your fps. A pretty noticable drop in CTD's after removing them...

 

But my best advice is to lower your graphic LOD's in settings. You're gonna have tremendous lag/stutter with everything set to max running 50 mods, regardless of your rig.

 

I'd rather scripts run smoother than be able to see tree's further away =P

[ChancellorKremlin]

By the way, I stopped following this thread a while ago, so pardon me if this has already been brought to your attention, but Slavery still seems to produce stutter. This has been confirmed on another user's game also.

[Halstrom]

By the way' date=' I stopped following this thread a while ago, so pardon me if this has already been brought to your attention, but Slavery still seems to produce stutter. This has been confirmed on another user's game also.[/quote']

I believe someone found the issue and they have uploaded fixes for Slavery & Tryouts causing Stutter due to a list not being cleared.

[zebop117]

Even the API guide post says the scanner is easy to use wrong.

 

The guide also says right in the preceding sentence that you must clear the list yourself. Let me quote it for you:

Again it is important that whenever your spell is invoked that you empty out your formlist after you've processed it' date=' or it will fill up with every NPC the player goes near.[/quote']

Probably it should be rewritten as "[...] that you always empty out your formlist, or [...]" (probably with the word "always" in caps, bold, red and an

tag) so that those who have trouble with common sense (or those raised by lawyers) would have one less formal excuse/loophole to shoot themselves in the leg.

[ChancellorKremlin]

By the way' date=' I stopped following this thread a while ago, so pardon me if this has already been brought to your attention, but Slavery still seems to produce stutter. This has been confirmed on another user's game also.[/quote']

I believe someone found the issue and they have uploaded fixes for Slavery & Tryouts causing Stutter due to a list not being cleared.

 

I tried the new slavery update by Chase and that still had the problem - wasn't that the fixed file?

 

Or did the newest version not get passed along to him?

[zebop117]

I tried the new slavery update by Chase and that still had the problem - wasn't that the fixed file?

 

If anything, I doubt it's related to the SexoutSlaveryLocalActors list because it's now cleared in the SexoutSlaveryPlayerQScript script.

Try using the attached esp - it'sa modified version of the scanner (SexoutScannerQSCRIPT) that will spam complains to the console if a list is not empty. The Slavery's list is cleared in the quest script that runs every 250 ms, so depending on your scanner frequency settings, you may get occasional complains, which is okay unless the list builds up constantly, i.e. if the scanner is set to the default 10 Hz, then there will be 2 complains before the list gets cleared.

z117_SexoutScannerQSCRIPT_dbg.esp

[ChancellorKremlin]

I'll give this a try. Also, did Tryouts get "fixed"? I ask because while Loogie updated his tryouts to reflect the addition of clearing lists... well, does it work?

 

Or will the same issue with Slavery repeat itself?

[zebop117]

Also' date=' did Tryouts get "fixed"? I ask because while Loogie updated his tryouts to reflect the addition of clearing lists... well, does it work?[/quote']

 

It does.

 

Or will the same issue with Slavery repeat itself?

 

Before speaking about repeating, you should have a proof. Scanner complains coupled with the evergrowing list will do. I didn't have them with Slavery version 1.4.11 when I tested it.

[ChancellorKremlin]

Appears I was running the wrong version of Slavery.

 

Tried running Legion and all the Tryouts with it and no sign of stutter.

 

The console reported one complaint, but no more after that. Seems like you've actually managed to nail this one down together with Ruddycray.

 

I don't know how to thank you guys enough.

[Contessa]

These fixes have been a godsend to me! I'm so happy I could burst!

[zebop117]

Seems like you've actually managed to nail this one down together with Ruddycray.

 

Well' date=' thank you for your kind words, but I did nothing, really. It's [b']ruddycray[/b] who did all the dirty job.

[wardminator]

Ummm. I went into the Gomorrah courtyard and check the debug messages and found this.

 

 

Those five form list are all Scanner Lists for Legion.esm, Powder Ganger Tryout, Violet's Scanner in Fiends Tryout, Kahn's Tryout, and Sexout Rapist. Not good.

[astymma]

Unrelated to the list clearing aspect of the scripted effect but still important should be that I see a lot of them, like SexoutRapist, are trying to terminate the scripted effect with RemoveMe in the ScriptEffectUpdate block. RemoveMe has no effect on a scripted effect and will not terminate it. Mods should be using Dispel instead. This is easy to verify... go to an empty room, open the console and run "Player.IsSpellTarget xx009CF8" as an example using SexoutRapist. It will, if the SexoutRapist scan target spell has been cast on you, return a value of 1.00 for the SexoutRapist spell still being on you. you can check for any plugin by finding the Actor Effect id for its target scan handler spell and running IsSpellTarget. Go by some NPCs to make sure it's been cast on you at least once, then go to an empty room and wait say 30 seconds, then check IsSpellTarget. The scripted effect *should* be gone, but if it's using RemoveMe, it won't be.

 

As for list clearance, imo, the basic structure of the target scan scripted effects is incorrect. Scripted effects, on frame 1 of the effect, run BOTH scripteffectstart and scripteffectupdate and then on all subsequent frames run scripteffectupdate until dispelled in which case the next frame it runs scripteffectfinish. the target scans should follow a plan something like the following:

 

start block
   copy the sexout target scan list members to a new list 
   while deleting each list member as it is copied
   set up any needed script variables like counts and target actor
   set stage to 1
end start block

update block
   in stage 1
       check each member of target list
       CIOS the desired effect if meet criteria
       delete each member from target list as they are checked
       only check 1 list member each iteration of update block
       once done checking entire list, set stage to 2
   in stage 2
       Dispel this spell from actor
end update block

finish block
   clean up any variables left behind
end finish block

 

Some may disagree and that's fine, there are always multiple ways to factor something like this. I just think the existing approach is not stable and not using the scripted effect design correctly.