Welcome to the AFK Mods bug tracker. In order to report an issue, you need to have a VALIDATED account to post one. Once you have followed the link the registration email sent you, please select a project from the drop down menu below. Select “Open New Issue” and fill out the form with as many details as possible.

Please also consider sending your bug report to Bethesda if you are reporting on an issue with Skyrim Special Edition, Fallout 4, Starfield, or Oblivion Remastered. Doing so will help everyone on all platforms.

Issue Data
Status: Investigating
Issue Type: Bug Report
Project: Unofficial Skyrim Special Edition Patch
Component: Skyrim SE: Vanilla
Category: Papyrus
Assigned To: Nobody
Platform: All
Severity: Low
Votes: 0
Watching: N/A
Opened By BlackPete on Jul 3, 2024 6:26 pm
Last Edited By Arthmoor on Aug 16, 2026 2:37 pm

Issue #34190: WE triggers sometimes don't rearm themselves after previous WE unloads

 
It doesn't happen very often, but occasionally a WE trigger will get stuck and not spawn the next encounter like it should even though the previous one has shut down. I've been trying to figure out what causes it but haven't been successful so far. There's a possibility it's related to a few specific world encounters, but I haven't been able to find any definitive proof of that. I should note that the WE spawn point isn't "broken" for the rest of the game, but you have to stay away for 10 in-game days for it to "fix" itself, which is obviously not normal. The same thing happened to the spawn points way back when certain WEs weren't unloading due to having the "run once" flag. The difference here is that the previous encounter reaches stage 255 (its shut down stage).

WE04 (Dragon vs Player) is one that I think "may" cause the problem; it was the last WE before the trigger box quit working in at least two cases. DLC1WE05 (Vampire and Death Hounds) is another where it happened at least once. One theory I have is that the encounter related NPC(s) get too far away from their original spawn point. Again, it may just be a coincidence that (I think) these two may be responsible. It's possible that there's something else going on.

Using sv on the trigger box's reference doesn't show any obvious problem from the output, as far as I can tell (but I have pasted the output in the spoiler below). In this case, the broken trigger box is 9DF36. The problem has happened at least twice to this particular trigger. Another trigger where the problem has occurred at least a couple of times is 000DC3E0. Neither of these trigger boxes are disabled at any point (either temporarily or permanently) during the game (ex. for civil war battles), so that can't be related.

Spoiler:
prid 9df36

WETriggerScript:
Script state = "off"
::CW_var = CW (00019E53)
::CWS_var = CW (00019E53)
::EventNum_var = 0
::EventNumClearedAfterSpawning_var = True
::myHold_var = 6
::myHoldIsContested_var = False
::myHoldLocation_var = (0001676D)
::myHoldOwner_var = 2
::off_var = True
::RoadEncounter_var = True
::TriggerOnLoad_var = True
::WEHoldImperialContestedRef_var = (0004A605)
::WEHoldImperialRef_var = (0004A603)
::WEHoldSonsContestedRef_var = (0004A606)
::WEHoldSonsRef_var = (0004A604)
::WERoadStart_var = WERoadStart (001027A6)
::WEStart_var = WEStart (0004A600)
--- Papyrus - Alias TRIGGER on Quest WERoad06 (00105D1D)
ReferenceAlias:
Script state = ""
No variables
No papyrus scripts attached


It looks like the trigger is planning to to run WERoad06 (Adventurer on the Way to Nearby Dungeon) next, but said NPC is not spawning because something is broken. I do have a game save available if that would be helpful.

Comments

4 comment(s)
DarthVitrial said:
 
MAYBE the issue - the DeleteWhenAble is *before* the ReArmTrigger() calls. DeleteWhenAble will not run until all the relevant cells and npcs have unloaded, and the script pauses until then. I reordered it so now DeleteWhenAble happens after the rearm.
Oddly about half the WE quests already had them in the correct order and half didn't.



Attached Files:

we Order of Operations source fix.7z
compiled.7z

Comment #1 Aug 12, 2026 10:02 pm  Edited by DarthVitrial on Aug 16, 2026 12:20 am
BlackPete said:
 
I kind of forgot about this ticket. Something I should have mentioned here a long time ago is that these encounters not rearming is related to NPCs routing to some destination (probably due to their travel packages) and not unloading. One case is the two Thalmor encounters mentioned in Issue #35509. I could give you a examples of others that regularly do the same thing, if it would help. The issue seems most likely to happen if the encounters load a few cells away without the player's knowledge. Like is the case with the Thalmor, they get stuck in a specific or random location and aren't removed by the game until interacted with in dialogue (or some other way). You may be on to something with the calls being in the wrong order, but I don't understand the specifics related to the scripts and other variables involved.

Comment #2 Aug 13, 2026 6:00 am  Edited by BlackPete on Aug 13, 2026 6:11 am
Arthmoor said:
 
The order of the calls for DeleteWhenAble() in relation to the Rearm call is not relevant. Something else must be blocking them from resetting properly. I'd also expect that when they do so by way of the cell reset that any NPCs or objects spawned by these are still out there somewhere, now detached from what they should have been doing.

It should not matter how far away from the initial trigger they get. They're in aliases, and thus persistent across the world. So calling on them to be deleted will always work. It also seems very likely that the rearming worked as well since the example triggers in the original ticket show a new quest has been queued up for the trigger.

We'd need a consistent means of reproducing this over time to be sure of which ones are breaking.

Comment #3 Aug 16, 2026 2:36 pm
BlackPete said:
 
After testing the status of the triggers with the console (using the sv command), I discovered that the triggers do rearm themselves if you've been away from the general area for 10 days. After that 10-day period the trigger will reference two encounter quests, so I was wrong that they break permanently. The problem is that the stuck (blocked) encounter can't repeat again until the aliases are somehow cleared, which in some case may not happen despite it being one that is meant to repeat. You know more than I do about how these quests are meant to work, but even with the information I've discovered it still seems like the process isn't working as was intended.

The bad news is that there doesn't appear to be a consistent way to reproduce the problems. Using sqv <QuestID is the only way I'm aware of to check if one hasn't unloaded. As mentioned using sv <FormID> on a seemingly broken trigger will reveal which quest it is currently associated with. I do have some saves where some of these are stuck, but it's possible that won't provide any further information than I've already provided.

Most world encounters don't break (or whatever you call it) and clear the aliases and shut the quest down after leaving the general area. I've compiled a list below of those that I'm aware of that can get stuck.
WE09 - Imperials with Stormcloak prisoner get stuck in random places on the map; could be related to the prisoner getting loose somehow without the player's help.
WE32 - Thalmor with Stormcloak prisoner get stuck at (or on the way to) the Embassy.
WEDLVigilOfStendarr04 - Vigilant patrols get stuck at (or on the way to) Stendarr's Beacon.
WEJS10 - Faldras gets stuck at (or on the way to) Azura's Shrine.
WERoad01 -The farmer and his wife get stuck in a random inn.
WERoad03 - Thalmor get stuck at (or on the way to) the Embassy.
WERoad07 - The taunting adventurer get stuck in a random inn.
WERoad10 - The giant and/or cow get stuck at a random giant camp.
WERoad11 - The farmer and/or cow get stuck at a random giant camp.
WERoad12 - The headless horseman gets stuck at (or on the way to) Hamvir's Rest.
DLC1WEJS02 - Vampire gets stuck in a random dungeon.

Regarding two encounters mentioned in the original part of the ticket:
WE04 - This one isn't problematic after all based on further testing since opening this ticket.
DLC1WE05: The cause for this one not unloading was identified and fixed in v4.3.7. It's definitely no longer a problem after testing since then.

Comment #4 Aug 18, 2026 7:03 am  Edited by BlackPete on Aug 18, 2026 7:17 am
Showing Comments 1 - 4 of 4