xkkmEl

Yes, delete the script instance is done via the resaver tool. The goal is to get rid of the script that is generating too many active stacks which triggers the "dumping stacks" problem. Once that is done, the game will eventually sort through the suspended stack, resuming them. Depending on the number of suspended stacks, it'll take more or less time. Often seconds, but can take 20mn or more as it did in my 23000 stacks case. With 628... It's not clear you have a problem there. It's definitely abnormal, but I'd recommend this action only if you see that it's still increasing. It could also be on the way to resolving itself naturally without risking more breakage if you happen to delete a critical script instance. Like I said, chances are low that the suspended stacks are related to your CTD.

In the spirit of being more concrete. Some mods don't react well to changes in the mod list or load order. If it happens, it can't be fixed. Running without SKSE when you have skse-dependent mods active usually irremediably breaks most save files. Can't be fixed. The 628 suspended stacks likely indicated a case the "dumping stacks", which may or not be related to the CTD. The procedure I know to get out of this situation is to delete a "script instance" related to a dominant entry in the suspended stack list (don't delete the suspended stack, delete the script instance that corresponds to it). It sometimes breaks something important, often not. I've fixed a 23000 suspended stack situation like this. It'd fix your CTD only if you happen to delete the faulty script instance. In any case, frequent CTDs are more often caused by faulty nif files or textures. The single piece of wisdom I can share on this, is: the culprit is the last mod you installed before noticing the increase in CTDs.

Hey, perhaps you're being too persistent. Virtuous to a fault, as they say. You've done everything possible, sometimes that's just how it goes. Save files get corrupted, occasionally. Buggy scripts create impossible conditions that get baked into the savefile, and such. Let that poor Dragonborn have his restful sleep and honor him by remembering and retelling his many adventures and CTDeeds.

Unsurprisingly, t'was my own fault. A bad interaction with a keyword condition on the package and some periodic process in my mod. I did not expect the package conditions to be reevaluated spontaneously. This does not happen in my experience with AI packages placed through other means (or was it the keyword that caused the reevaluation?).

I use both. No complaints.

Anyone have experience with ActorUtil packages? I'm experimenting with it to place quest packages on a number of NPCs, so I don't have to count them and create an alias for each one. I'm finding the packages don't work quite right... it looks like the package is timeshared by the NPCs... for a few seconds, the NPC is behaving according to the package, and then not, and then again, and then not... If I put the same package on an NPC using an alias, the behavior is consistent. I am currently testing a follow package, but I was having the same doubts with a travel package. The destination is in an alias, so the package does refer to a parent quest. Should I conclude that ActorUtil.addPackageOverride is broken and just create dozens of aliases?

A form, such as LvlGiant or LvlDragon, represents a "class" of objects. An ObjectReference is an instance of such a class, a specific one. Aliases can only hold one ObjectReference, and so that approach will only work for detecting the death of that one instance you put in the alias. "Create reference to object" creates a new ObjectReference. It will not help you detect events on pre-existing references.

There is the "isSmallBump" condition... but the documentation is scant and I have never used it except in actor-actor collisions.

You tested on a new game? Properties on quests won't update on a running save file. EDIT: Hmm... this is a furniture script, not a quest, but same result.

Is there not a "(next page)" link at the bottom of the page? A search box at the top right? I use it all the time and wish it was more complete and accurate, but it does cover the basics you are looking for.

I ran into difficulties using events in SL. Sometimes, you get a successful start (from return code) but no AnimationStart or AnimationStarted event. Sometimes you get a successful start, AnimationStart, AnimationStarted, but no AnimationEnding or AnimationEnded. I've had to patch SL to make my mod work consistently. Using the SexLabActive keyword is simpler and more reliable if you can test it in a scene end condition; I am still patching because there are cases in which I don't want to have a 15 scenes hanging on SL threads. Hopefully OStim provides a keyword or handles the events better than SL.

In LE, makes no difference whatsoever. Only the ESM flag matters.

The topic itself is just a player dialogue topic. If you can activate the NPC and see it offered, it will work for the forcegreet. You can also make the topic branch "normal" (instead of "top level") so you don't see it when activating the NPC. The AI is equally simple. Use the forcegreet template, point it to your topic. For all the locations it wants you to configure, just center them on the player, radius 5000. All the magic will happen in a scene. So create a new scene, add your two actors (player and NPC), and update your initial dialogue so that it ends with a script fragment that starts your scene. The scene itself is a list of phases with script fragments, conditions and actions. It should look something like this: phase 1 start - script starts OStim phase 1 end - use end conditions to wait for the end of sex (not sure how to do this with OStim; likely a keyword test). phase 2 start - add a package action to the NPC in which you add your forcegreet package phase 2 end - wait until forcegreet ends (isSceneActionComplete myscene,1 == 1.00 AND NPC.isInDialogueWithPlayer != 1.00 AND NPC.isGreeting != 1.00 AND NPC.isTalking != 1.00) That should be it... In general, AI packages have to be "placed" on the Actor... either in its CK record, in a reference alias, or a scene, or via ActorUtil.psc. Using AI packages is confusing at first, but mostly because the documentation is so fragmentary. In the end, they are fairly simple... just a matter of placing and removing them just at the right time (CK record if it's about being live or dead; quest alias when it's quest start / stop; or a scene if you have a specific sequence of events to wait for).

Have your scene, after starting sex, wait for the end of sex. Then have your scene place the forcegreet package on the NPC. I haven't used OStim... in Sexlab, have the scene wait on a "Alias: NPC hasKeyword SexLabActive != 1.00" before setting the forcegreet package. Or perhaps I misguessed where you are stuck...

SKSE does not provide any additions to the condition system. Sometimes, you can use scripts that use SKSE to feed things into the condition system by setting a faction, or a quest/objectreference property, which then can be tested for. Not for the faint of heart.

The alias will remain filled when the NPC dies. It just can't be dead when filling the alias (at Quest start) unless you flag "allow dead". Your alias fill conditions though will grab any random object in the player's immediate vicinity when the quest starts. You likely want to use the "specific reference" fill type instead and select your target NPC. If you want ANY npc's death to be detected, that's a tougher job. It can't be done through the alias mechanism. You may also want to share details on how the quest is started... aliases are filled when the quest starts... so that won't work if you don't, or do it at the wrong time. In game, use the console's "sqv myquest" command to check on the quest's status (started or not) and what got filled in the alias.

Math.logicalAnd( mything.getFormId(), 0xFFFFFF)

Many ways of doing it. Here's one: Event OnContainerChanged(ObjectReference akNewContainer, ObjectReference akOldContainer) If akNewContainer == PlayerREF && playerREF.getItemCount( ItempieceX) && playerREF.getItemCount( ItempieceY) && playerREF.getItemCount( ItempieceW) && playerREF.getItemCount( ItempieceZ) MyQuest.SetStage(10) EndIf EndEvent

Well, ok. I underuse this "all" category in the CK. In my defense, it still misses idles, cells, worldspaces and object references.

Tested it again on my end, and it does appear to work: 1- Delete the script .pex and .psc 2- Launch CK, blank out the fragment boxes, then remove the script, and save and exit. 3- Re-delete the script .pex and .psc (not sure how/why they reappeared). 4- Load it up once more in the CK. 5- Create new content for the fragment boxes, and save and exit. I'm testing this with the LE version of the CK. If it still don't work... double check the timestamps on your TIF script files and make sure the CK is able to write in the output directory (...\MO2\overwrite in my case).

Searching in the CK is dicey. You have to guess the type of record you are looking for. You ought to use xEdit to search for reference and form IDs.

I think you just need to blank out the two fragments before removing the script in the CK. Delete ";CODE NOT LOADED", then hit the remove button. Or maybe I didn't test this fully enough...

To complement what Scorrp10 wrote, The "Voice File Reference Tool" can help you locate the original sound files you need to duplicate and rename (when they are not accessible as SharedInfo): https://www.nexusmods.com/skyrimspecialedition/mods/18819 https://www.nexusmods.com/skyrim/mods/28462

That likely is because of a body slot mismatch between the Armor and its component AddOns.

A few things to check: Dialogue's quest is running. You are using a top-level branch in the player dialogue tab. Make it work with that first; you can change it after. Remove all conditions (from the quest's data tab, and in the topic info). This should make the dialogue work for everyone. If it works for everyone, except your target NPC, it must be because your NPC is in a exclusive or blocking branch from somewhere else. If it does not show for anyone, keep looking for conditions to remove!