Jump to content

DayDreamer

Members
  • Posts

    816
  • Joined

  • Last visited

Everything posted by DayDreamer

  1. It's strange that so many very badly done mods get a lot of endorsements. There's no good way on nexusmods to downgrade or warn anybody. It's not technically "Abuse", so I'm reluctant to use that report button. Am I wrong? In another case, Leaf Rest, it isn't obviously broken until you load it in CK and xEdit and study what they've done (after confiict reports over 8 years). Breaking 2 significant quests, because they accidentally cut and pasted (instead of copy and paste) doors they wanted to use, so those doors are now missing in Riften. All the NPCs gradually congregate (get stuck) in the middle of Riverwood, because the navmeshing is a nightmare. The modder closing comments and deleting all negative comments, saying it is bug-free. What should we do to prevent folks from using bad mods?
  2. I'd thought I'd attached a pair of save files, before and after. My mistake. I'd reported it in the bug tracker, but I'm unable to find the connection either. Hoping that others will test. I'm raising it here, because we don't get enough eyeballs on the tickets. Also you closed it saying I'm using a save editor, which is false. That new runthrough does use SSE Engine Fixes. I'm unsure how it could have bolloxed any setstage across quests. But it does fix the savegame issue that ended my previous long run. There are some terrible programming errors in the vanilla game. Did you actually test killing Nihme before talking to the Jarl, then checking the stages as described in the bug report? I'll do that myself with a new runthrough to see whether it is reproducible across runs.
  3. A smaller trigger works much better, for several reasons. Malthyr doesn't have far to go, so 7.75 works well. Brunwulf has farther, but stops several times and looks back and forth as he walks, so 7.25 is about right. However, Brunwulf's regular 7 am package has him walking toward the inn for breakfast, and at 7:15 (7.25) he turns around and walks back. Setting 7.5 for Malthyr and 7.0 for Brunwulf gets them to their markers a bit early, but looks more natural. Yet there's another bug. The script merely checks: if (triggerActor == None || actronaut as actor == triggerActor) The triggerActor field documentation says {by default, the player}. But default is None, and it never checks for the player. A passing guard will start the scene. For the original huge trigger size, Viola could start the scene. Instead: ; USSEP check for player to match documentation Actor acroActor = actronaut as actor if ((triggerActor == None && game.GetPlayer() == acroActor) || triggerActor == acroActor) ;USKP 2.0.4 - Sanity check added to be sure the scene's quest is still running. if (PrereqQuest == None || prereqStage == -1 || (PrereqQuest.GetStageDone(prereqStage) && PrereqQuest.IsRunning() ) ) Hopefully, this fixes the obvious bugs, so that obscure ones can be uncovered.
  4. USKPChangeLocation10 has an alias for the trigger, making it persistent, throwing an error in the log.... But that's not the main problem. This scene is incredibly hard to hear. This trigger box is so large, the conversation is nearly over before the player is within hearing distance. Another problem is that it is timed. But the trigger box start time is the same as the package start times. So Malthyr and Brunwulf begin walking toward their markers at 8. They arrive at different times within the hour. If the player has entered the trigger at any time before they arrive at their markers, they begin speaking their lines as they walk. Not even within hearing distance of each other and not usually hearing distance of the player. (Testing shows it possible to be near Brunwulf as he starts talking, quite weird to hear only his half of the conversation.) The trigger needs to be smaller so the player is closer to the markers. But the trigger times are script persistent, so changes are needed to the packages. The good thing is that US*P has already fixed the package conditions, so already responsible. (One was DialogueWhiterun kid fight variable, what were they thinking?) Now the packages need to start earlier, so that they have arrived by the 8 am trigger time. Finally, the delete() line should be removed from StartSceneTriggerSpecificTime. The disable() is sufficient. USKP 2.0.4 has already added a sanity check, so it is already in our wheelhouse.
  5. I've never used a save editor. Arthmoor is confusing me with somebody else. Anyway, I'd included 2 saves. And the console command to verify the quest status. Easy to reproduce.
  6. Location change. https://afktrack.afkmods.com/index.php?a=issues&i=30480
  7. Yes. Sadly, I'd just started my new run the day before this came out. If I'd known, I'd have started again. Now, I'm too far down the road to test it. Oh well, what's another 144 hours. Starting a new runthrough. Aren't meh321 and aers - Nukem - Ryan working together anymore? Combined with SSE Engine Fixes patch would be better and easier to document.
  8. I've gotten reports that it no longer works with Touring Carriages, the horse comes to a dead stop. I've checked the navmesh, and there are a lot of missing Found flags. Applying script "Skyrim - Check edge links in navmeshes"
  9. Sadly, Bethini prioritized performance over function. As an example, as you ride/run down vanilla roads, vegetation will gradually fill in before you. Bethini makes things pop-in instead. And of course, I'm biased. Bethini doesn't work with Touring Carriages (it slows the NPC package execute rate).
  10. Converted it to Story Manager, with condition CWGarrisonEnableMarkerSonsDawnstar [REFR:0002C77C] is enabled, to match what US*P had already done. Control-F changed to defaultSetStageTRIGPlayerOnly using defaultSetStageTrigSCRIPT, copy over the script fields, initially disabled. Works perfectly the next time you enter Dawnstar exterior. (Didn't bother to move the NPC packages to the scene, although it would make the game slightly more efficient.)
  11. Turns out, that's how this one is already setup. It simply has the wrong trigger box. Control-F changed to defaultSetStageTRIGPlayerOnly using defaultSetStageTrigSCRIPT, copy over the script fields, works perfectly.
  12. As I'd mentioned, my conclusion is based upon instrumentation. There are several vanilla debug lines that can be activated, and I'd added others. But nothing readily showed that bAllTargetsInTrigger stayed forever true. That's some kind of game engine bug. I'm fairly sure we've seen that in the past, but so many bugs over so many years.... Thus, all of these problems are because of a pair of game engine bugs as mentioned above: a property staying forever true, and the 2016 discovery that NPCs entering a trigger via teleport won't run the event. I've begun a survey of all the other places using this trigger. There are 13. Only a few set bAllTargetsInTrigger to true: DawnstarExterior01 DawnstarExterior04 DA07IntroTrigger HelgenKeep01 MQ101SetStage500 LeftHandMineExterior02 LeftHandMineSceneTriggerREF (DialogueLeftHandMineIntroScene) MarkarthMines (DialogueMarkarthIntroBlacksmithSceneView) MarkarthArnleifandSonsTradingCompany ArnleifandSonsIntroTrigger (DialogueMarkarthIntroArnleifandSonsScene) In two cases, Bethesda (in Skyrim.esm) long ago deleted the script and replaced it. MQ104TowerGrabTrigger MQ105GreybeardOutroTrigger I've also begun a survey of other triggered scenes (at least the common ones) to determine best practices. AFAICT, there are two best practices: (mostly entering cities) Start Enabled quest. Some use a trigger to start scene, others have Phase 1 GetDistance to player < 1000. Story Manager starts quest, quest fragment_0 moves the NPCs to the scene markers. Trigger, or Phase 1 has GetDistance to player < 1000. In most cases, NPC stay at marker packages are in the scene itself. Also, US*P has modified the underlying defaultSetStageTrigSCRIPT to prevent scenes from running more than once. The Dawnstar scenes have the NPC marker packages in the NPCs. In Skald's case, the marker package is in both the NPC and the quest alias. This duplication is definitely not best practice. US*P has modified these NPC packages to check CWGarrisonEnableMarkerSonsDawnstar. That wouldn't have been needed with the packages being in the scene, as the scene itself could be prevented from running with a single check in Story Manager.
  13. Incorrect. The targetCountCurrent includes all 3 NPCs plus the player. See onTriggerEnter() and modTargetCount(). The script is running before the player arrives. The log shows that it runs for 2 NPCs, then later for the player. Presumably the NPC that isn't triggering it arrives via loading door (Skald). However, the setstage 10 running the scene only happens at the first NPC. That's when they start talking, even though nobody else is yet present.
  14. The property bAllTargetsInTrigger is persistent. Once the game is started, or more precisely the cell is loaded and OnInit() has run, clearing the property doesn't fix this.
  15. I'm documenting a design flaw that I've been unable to fix thus far. Some time ago, I'd posted a bug report about: https://afktrack.afkmods.com/index.php?a=issues&i=26482 defaultOnEnter.psc script issues with trigger enable parent There are 2 instances in Dawnstar. In both cases, the scenes run before the player arrives. If you run there fast enough, you can hear them in the distance talking as they walk toward their markers. I'd instrumented them, and discovered that they were running with no actors. This should be impossible. I'd thought that the problem was the changes US*P made long ago to one of them, setting enable parent. The log does spam out that error: [04/21/2021 - 02:34:20PM] Error: (00087792): cannot disable an object with an enable state parent. stack: [ (00087792)].DefaultSetStageOnEnter.Disable() - "<native>" Line ? [ (00087792)].defaultOnEnter.TriggerMe() - "defaultOnEnter.psc" Line 145 [ (00087792)].DefaultSetStageOnEnter.TriggerMe() - "defaultSetStageOnEnter.psc" Line 21 [ (00087792)].DefaultSetStageOnEnter.OnTriggerEnter() - "defaultOnEnter.psc" Line 67 [04/21/2021 - 02:34:20PM] Error: (00087792): cannot disable an object with an enable state parent. stack: [ (00087792)].DefaultSetStageOnEnter.Disable() - "<native>" Line ? [ (00087792)].defaultOnEnter.TriggerMe() - "defaultOnEnter.psc" Line 145 [ (00087792)].DefaultSetStageOnEnter.TriggerMe() - "defaultSetStageOnEnter.psc" Line 21 [ (00087792)].DefaultSetStageOnEnter.OnTriggerEnter() - "defaultOnEnter.psc" Line 67 [04/21/2021 - 02:34:20PM] InitWidgetLoader() [04/21/2021 - 02:34:20PM] Error: (00087792): cannot disable an object with an enable state parent. stack: [ (00087792)].DefaultSetStageOnEnter.Disable() - "<native>" Line ? [ (00087792)].defaultOnEnter.TriggerMe() - "defaultOnEnter.psc" Line 145 [ (00087792)].DefaultSetStageOnEnter.TriggerMe() - "defaultSetStageOnEnter.psc" Line 21 [ (00087792)].DefaultSetStageOnEnter.OnTriggerEnter() - "defaultOnEnter.psc" Line 67 The US*P added parenting of trigger 00087792 is incorrect. Instead, it should be disabled by script where CWGarrisonEnableMarkerSonsDawnstar [REFR:0002C77C] is disabled. But why 3 times? It should only TriggerMe() once. That's a clue! After examining these and 3 others that I've rarely or never heard, I've found that the trigger properties have set bAllTargetsInTrigger to true (default is false). Apparently, when a property is set, code in the parent script (in this case, defaultOnEnter) cannot modify it. The defaultOnEnter function modTargetCount() is busily checking and updating bAllTargetsInTrigger, but it always remains true. So TriggerMe() runs with no actors present. Why would Bethesda have set bAllTargetsInTrigger? I'm guessing that otherwise it didn't ever run. A note from 2016 is currently on https://www.creationkit.com/index.php?title=OnTriggerEnter_-_ObjectReference: "If you set a trigger around a teleport door marker this event will fire for the player but not for NPCs." These all have NPCs arriving via teleport door. The easiest bugfix approach would be modifying the triggers to avoid the teleport doors. It looks possible. A better approach would be redesign using Story Manager along the lines of the Whiterun scene for Fralia. There are only a few other uses of this script.
  16. The simplest fix worked OK, although the window for them is after Brynolf and before Tonilla. Later conversations now make more sense after hearing the background. Comments such as "You're making waves around here" are conditioned on completion of TG01. That is rather early, as you will never even meet them before then. Any opinions on changing to completion of a later quest, such as TG02, 03, 04? What should be the condition for "I've never seen anyone with skills like yours"? It's Rune, who is not a trainer. Nevertheless every other person in the room has better skills than mine at the beginning of the game.
  17. Definitely US*P. I've found various Trainer edits where US*P already checked whether the player was currently in good standing with the guild. These affect the same entries. They shouldn't provide training until you've achieved good standing, but it's a different global. However, Niruin was missed. So I'll include him in the fix. Of course, a better design would not have used globals, and checked for a stage completion. But that would be a lot more edits now.
  18. I've just discovered a huge pile of never heard TGHellos dialogue, after wondering why I'm asking Thrynn about a bandit clan. How did I know to ask? Turns out he was supposed to tell me. There's a lot of introductory Hellos (for all thieves) conditioned by [000E595A] TGTalkGate. [000E50DD] Used to run with a bandit clan in The Pale. Turns out I didn't like them and they didn't like me, so we parted ways. Note that US*P changed "The Pale" to "the Pale" on a line never heard. TGTalkGate is set by [00084ABD] TG02B at startup (you join). This is probably a mistake, as you never have the chance to meet any others before that is set. This mistake also explains why they are saying things that aren't true yet: "I've never seen anyone with skills like yours." "You're making waves around here." "I think you're all right. In fact, I'm kind of impressed how well you're doing around here." It probably should be set at completion of either TG02B Meet the Family or even more likely TG02 Loud and Clear (as you've done something after Vex failed). Is this better for US*P, or CRF as cut content?
  19. Bethesda Support wasn't any help. They went round after round asking about how much file space remaining, and anti-virus, and having me reinstall, and asking for more copies of the DxDiag, msinfo32, etc. Eventually, they agreed it was something that needed to be forwarded to the developers, as I'd originally stated. Since then, nothing. So I've started over, this time with SSE Engine Fixes. Hopefully this will prevent this specific crash, and any build-up of bad saved data. Now that Zenimax is owned by M$, we need to lobby for a 10th aniversary edition with bug fixes. Or just open source the whole kit and caboodle.
  20. Asking in general, but have a specific case. I'm re-checking my personal list of plugins, before starting a new run with SSE Engine Fixes. Hoping this will allow me to actually finish the game someday.... One of the USSEP changes to [0001B078] Urog is 13 Skin Tone (6). When I copy this change, then load and save in the CK, it reverts this. I've been unable to find an entry in the Version History. Although this probably isn't a crashing issue, still wondering how it came to be? What is it fixing?
  21. After another year, it's time to add SSE Engine Fixes. We'd held off because @alt3rn1ty and @drizzanhad reported problems in May 2018. But it's been continuously updated, the most recent being 23 Jan 2021. This fixed my 500+ hour saved game. Wishing that I'd been using it all along.
  22. Thanks again! It had only been mentioned once here, on a thread that I'd never read before. Using it was somewhat enlightening, although the stack trace is for the save routine as I'd expected. In the bowels of "BGSSaveLoadManager::unk_586DE0+190", specifically "(SkyrimSE.exe+FE434D) unk_FE42D0+7D". I'd previously contacted Support, and hopefully this will spur them to a technical solution. I've loaded it via the "DLL Plugin Loader". But the description prompted me to try "SSE Engine Fixes (skse64 plugin)". Something there fixes this bug, although its log doesn't mention anything specific. So it's a known bug.... Maybe we need to update Fixes Recommended in Addition to the USSEP. That would have saved me weeks of grief over a 500+ hour save.
  23. As it turns out, he was dying (February 3, 2021). I'm more concerned that future games won't be readily fixable. Contrary to so many posters, I'm not at all convinced that BGS or M$ are concerned about modding. They make so much money in the first few weeks that the rest is just gravy. The reason that M$ is better these days at Windows security updates is various government entities sued them. I'm not expecting governments to be concerned about fixing games. Indeed, I was unable to get the FTC interested, even when a friend was CTO there and various game platforms were C&C for Internet attacks. There are too few resources and too many problems. Instead, we need a law that allows consumers to sue collectively, regardless of contracts of adhesion.
  24. I'm not sure about the number of dragon scripts running. But there are a lot of scripts running. So it could be something else entirely, running in the background, that just happens to do something that makes the game un-savable at that point in time. I've tried only taking a few specific objects from the dragon, one at a time. Tedious testing. Doesn't help. But again, not on the save after taking anything. Only after quitting to desktop and then loading that save. So there's an apparently good load, that won't save, even though I've done absolutely nothing! Also, this ony happens on a load after quit to desktop. It doesn't happen on a continue/load from Main Menu. Although eventually I'll quit the game, and then will experience the crash on my next save another day. (That's what actually happened, it took me days to work backward to the crashing point.) Moreover, I'd never load from System Menu, because I'd read long ago that was bad. Skyrim doesn't clean itself up entirely. Now we know it doesn't clean itself entirely at the Main Menu either. Oh how I wish we had better debugging tools. And that Skyrim itself didn't crash without leaving a messagebox explanation. What we need is a law that says "If the vendor doesn't fix bugs, they have to release the source so that users can debug and fix them." We've been talking about that for years in security circles, because of so many worms infecting non-updating consumer devices. But it should also apply to other software.
×
×
  • Create New...