Search the Community
Showing results for tags 'bug fixes'.
-
It has been over a decade since several different attempts by several programmers. Having just reviewed and repaired them again, best to write things down for posterity. Weapon racks have 2 main parts: a visible part. It uses WeaponRackTriggerSCRIPT. Unlike most visible actuators (such as seats), it does not cause any action. Instead, it merely triggers as a weapon is passed near it. Usually, that trigger is something being added to the rack, or to another rack nearby, and must be ignored. Sometimes, that trigger is a player removing a weapon or armor item from the rack. an invisible trigger marker placed directly in front of the visible part. It uses WeaponRackActivateSCRIPT, and has ACTIVATOR in its name. When triggered, the script places a weapon into the front of the visible part using MoveToNode(). The visible part has many such named attachment "nodes". Because of the unusual design, there were many locations that simply had the wrong script on the objects. It became apparent that various designs were attempted, and some old designs with the wrong scripts or variables remained in the files. So a significant US*P change to the scripts was adding a CheckConfiguration() function to log places with bad setup so that they could be repaired later. Although the design expects that the visible part has a pointer to the invisible part, and vice versa, there was no check. (A check was added.) Many locations have no invisible part. Others had/have the invisible part in front of the wrong rack, or even underground. Again, there is no easy check. There are many flavors of racks. Most do not actually allow a player to add a weapon to the rack. But they use the same scripts, so the scripts have to account for all possibilities. Some have PlayerHouse in the name, and allow a player to add a weapon to the rack. Others are specific to locations. A few OLD and Nor designs are unused. Some are used as backing plaques, or as decorations, and their scripts were deleted from them. Others used another technique to disable the rack parts, such as pointing the rack to itself, or to the player object. There is not much implementation consistency. Finally, the ACTIVATOR can point to a StartingWeapon. This can also be armor. All of the item pointers are stored in the invisible WeaponRackActivateSCRIPT property PlayersDroppedWeapon, instead of the visible rack itself. Therefore, every rack with a starting item requires an invisible ACTIVATOR, even though most racks do not accept player weapons so the activator is otherwise unused. Inefficient and cumbersome, and not all Bethesda developers understood the design. Many racks were missing an ACTIVATOR. Many more have an unused ACTIVATOR that does nothing. Unfortunately, there were originally two methods of pointing to the StartingWeapon: GetLinkedRef() or GetLinkedRef(WRackStartingWeapon). However, only the rare WeaponRackDaggerDisplayACTIVATORPlayerHouse specified the latter, and it was never used. So that complication was removed from the scripts.
- 8 replies
-
- weapon racks
- scripts
-
(and 3 more)
Tagged with:
-
It's been 4 years and I cannot remember where (or even which forum) we had the old thread, so here's a new place to discuss. AFAICT, this hasn't been improved in the SE CK. The first principle of navmesh modding is: never delete or merge navmeshes! That way lies CtD (crash to desktop). The second is like unto it: to reduce the number of conflicts, border triangles should not be renumbered! Every adjacent cell navmesh has a link table with pointers into these border triangles. If a navmesh is deleted, or merged, or a border triangle is renumbered to be anyplace else, creatures/NPCs will "jump" into that triangle number as they cross the cell border. Sometimes they become stuck in place. Sometimes this also may make it impossible for the PC to move. If possible, have the same number of triangles as the original. When you delete any triangle, the CK renumbers. This often changes border triangles. Therefore, great care must be taken. It is usually better to first create a new triangle over the old, then delete the old triangle so that the new triangle is renumbered with the old triangle number, then join/merge the final vertice in place. (This technique is also used to repair border triangles.) When you "Find Cover" for a cell, sometimes the CK renumbers triangles. Up to 2 sides of cover are saved (the 3rd side is assumed to be flat to the adjacent triangle), so triangle vertices sometimes need to be rotated to allow the cover data to be in side "0-1" and/or side "1-2" (as shown in xEdit). Apparently, the CK deletes the triangle (causing renumbering), then adds a new one in the proper orientation. Yet the CK already has a user tool for rotating a triangle without renumbering; it fails to use it internally. When you Finalize a navmesh, the CK doesn't just touch the one you are changing. It also saves adjacent cell navmesh. In the outdoors, this results in 4 cells around the square. Presumably, this is to update border links caused by deletion or renumbering -- even when there have been no changes. The CK works reasonably well only having Update.esm, but is a disaster waiting to happen with multiple modders updating adjacent cells. Each changes 5 cell navmesh, so the conflicting border link tables cause massive confusion. (Following posts have more detailed information.) See also: https://www.afkmods.com/index.php?/topic/3337-skyrim-fixing-navmesh-deletion-using-tes5edit/ https://www.afkmods.com/index.php?/topic/4072-navmesh-audits/
-
Version 0.2
69 downloads
This is an attempt at a re-compiled Legendary Edition version of wSkeever's mod, High Gate Ruins Puzzle Reset Fix. While I believe this has been compiled correctly, I make no promises that it will work the way it is supposed to, as it was built for Skyrim Special Edition. My modding experience with Skyrim is limited, so troubleshooting will likely not happen. This mod should be compatible with anything that doesn't modify the following file: highGateRuinsLeverPuzzle.pex For anyone wondering if my backport of wSkeever's mod is allowed, here is a screenshot of their mod permissions: All files provided in this mod have been ported over from their Skyrim Special Edition counterpart. To avoid any permissions issues with wSkeever's mod, all permissions will be restricted on this mod. Please defer to wSkeever's mod permissions if you would like to use any assets from that mod in your mod. Original (Slightly Modified) Description Background High Gate Ruins is a Nordic Ruin featuring a puzzle where the player pulls 4 levers in sequence to light 4 braziers. Once the 4 braziers are lit, a trap door opens, allowing you to proceed further into the dungeon. However, when the location resets, the door is reset and closes, but the puzzle will not reset and remains in a solved state, preventing you from opening the door again. This bug is detailed on UESP: This bug locks you out of the latter half of the dungeon, preventing you from accessing the boss container and completing radiant quests which use High Gate Ruins as the location. Description This mod fixes this bug by doing the following: OnReset is implemented to reset the puzzle when the dungeon resets If you don't want to wait that long. I've also set the puzzle to reset when you pull any of the levers after the puzzle is solved, allowing you to solve it again. No esp. Minor edits to existing USSEP script Installation/Uninstallation Install at any time Uninstall at any time Implementation Details Script edited is highGateRuinsLeverPuzzle "KillSwitch" function edited to allow puzzle reset even after it is solved: Added OnReset Event to reset the puzzle when the dungeon resets: FAQ Credits wSkeever for High Gate Ruins Puzzle Reset Fix I've also created a forum for this topic if you want to give any feedback.-
- quests
- lore-friendly
-
(and 3 more)
Tagged with:
-
This is an attempt at a re-compiled Legendary Edition version of wSkeever's mod, High Gate Ruins Puzzle Reset Fix. While I believe this has been compiled correctly, I make no promises that it will work the way it is supposed to, as it was built for Skyrim Special Edition. My modding experience with Skyrim is limited, so troubleshooting will likely not happen. This mod should be compatible with anything that doesn't modify the following file: highGateRuinsLeverPuzzle.pex For anyone wondering if my backport of wSkeever's mod is allowed, here is a screenshot of their mod permissions: All files provided in this mod have been ported over from their Skyrim Special Edition counterpart. To avoid any permissions issues with wSkeever's mod, all permissions will be restricted on this mod. Please defer to wSkeever's mod permissions if you would like to use any assets from that mod in your mod. Original (Slightly Modified) Description Background High Gate Ruins is a Nordic Ruin featuring a puzzle where the player pulls 4 levers in sequence to light 4 braziers. Once the 4 braziers are lit, a trap door opens, allowing you to proceed further into the dungeon. However, when the location resets, the door is reset and closes, but the puzzle will not reset and remains in a solved state, preventing you from opening the door again. This bug is detailed on UESP: This bug locks you out of the latter half of the dungeon, preventing you from accessing the boss container and completing radiant quests which use High Gate Ruins as the location. Description This mod fixes this bug by doing the following: OnReset is implemented to reset the puzzle when the dungeon resets If you don't want to wait that long. I've also set the puzzle to reset when you pull any of the levers after the puzzle is solved, allowing you to solve it again. No esp. Minor edits to existing USSEP script Installation/Uninstallation Install at any time Uninstall at any time Implementation Details Script edited is highGateRuinsLeverPuzzle "KillSwitch" function edited to allow puzzle reset even after it is solved: FAQ Credits wSkeever for High Gate Ruins Puzzle Reset Fix Download Link
-
Update: After reports of issues with Dragon Souls not being absorbed and personal testing of this mod, it appears recompiling the script in the original Creation Kit does not work. Please use Fixed Dragon Stalking Fix (Re-Upload) instead, it should work with the original Skyrim since it is only a script: https://www.nexusmods.com/skyrimspecialedition/mods/54625
-
- gameplay
- modders resource
-
(and 4 more)
Tagged with:
-
When I do the skyhaven temple part of the main quest in the storyline, esbern and delphine just stand there and do nothing. The dialogue is glitched and when we get to alduins wall , they still are glitched out.I had to do unrelenting shout to push them both by the wall and its still the same dialogue. Not sure if its a bug to do with the mod or just the game in general.( i can post a video on what theyre exactly doing )
-
Break of Dawn Death Fall Question
Ai Elias posted a topic in Unofficial Skyrim Special Edition Patch
I was hoping that someone here (Arthmoor perhaps XD) could tell me what steps USSEP takes to address the faulty scripting in the Break of Dawn quest where the player has the potential to fall to their death from the sky and potentially explain the issue further to me. More specifically why this issue can reappear in the presence of other mods that don't overwrite the DA09Script. From my limited research into the problem, it seems that it's being caused by the use of the utility.wait() function and is either a result of an overloaded game or an error in the calculation of the player fall time. Or a combination of those? In any case, if this is the case (which it very well may not be) why doesn't the USSEP replacement script edited in such a way to prevent the fall entirely instead as that seems like the more solid fix in my humble opinion. Thanks! <3 -
Bug Fixes Recommended in Addition to the Unofficial Patches
Arthmoor posted a topic in Unofficial Skyrim Patches
Fixes Recommended in Addition to the USKP Lip Sync Fix - A fix for the long standing lip sync bug introduced by Patch 1.9. Yes, this one is the real deal unlike all the other placebo/fake versions that have come before it. A very simple SKSE plugin changing literally ONE BYTE of memory to fix one of the most glaring issues left in the game. Since it requires SKSE, it is not a suitable candidate for USKP inclusion. SkyUI - A PC-centric reworking of the major components of the game interface. Yes, we do in fact consider this to be within the realm of bug fixing because the vanilla PC interface is simply not designed with actual PCs in mind. For obvious reasons, it's not something that would ever become part of the USKP. Since SkyUI is pretty much ubiquitous, the USKP defers all UI related fixes to them, and there are plenty of legit fixes included in SkyUI. Flora Respawn Fix - This is a clever workaround for the bug introduced in Patch 1.3 where most flora objects in the game won't respawn no matter how long you wait for them. Requires unsupported TES5Edits and so is not suitable for inclusion in the USKP. Wiseman303's Flora Fixes - An alternative to the Flora Respawn Fix. Uses the same methodology but covers a bit more than the previous mod. Since it uses the same kind of unsupported TES5Edit changes, it is also not suitable for inclusion in the USKP. Bring Out Your Dead - Extends the vanilla graveyard support to all vanilla NPCs who should have had one. Was originally planned to become part of UKSP 1.1 but had been overruled due to the requirement to place extra grave containers for those NPCs who didn't have one yet. Brawl Bugs Patch - Additional bugfixes that pertain to brawling while also under the influence of cloak spells of various types. Jonwd7 determined these would not be suitable to include directly in the USKP so the module is distributed separately for those who may want it. Fuz Ro D-oh - Silent Voice - Fixes issues with dialogue that has no recorded audio and also corrects a bug in the engine where the "Force Subtitle" function does not work correctly. Since it requires SKSE, it is not a suitable candidate for USKP inclusion. Enchantment Reload Fix - Fixes a bug where enchanted items will jump in value and drain their charges much more quickly if the game is saved and then reloaded. Requires SKSE, so is not suitable for inclusion. Invisibility Eye Glitch - Fixes a bug where the player's eyes get corrupted when an invisibility spell is cast and then wears off. Requires SKSE, so is not suitable for inclusion. Better Dialogue Controls - Fixes a minor but annoying bug with being able to select the proper dialogue options with the keyboard and/or mouse. Alters the UI, which is one area we do not cover to avoid conflicts that would not be easy to resolve. Complements SkyUI as this is not an included feature there. Better MessageBox Controls - Fixes another minor but also equally annoying bug with clicking on text in a message box. Also not suitable due to editing UI files. Complements SkyUI as this is not an included feature there. Landscape Texture Transition Fix - Corrects a number of transitions in landscape that don't blend together properly. Since this obviously involves landscape edits, it is not something that would be included in the USKP due to the high potential for conflicts that would then need other compatibility patches to resolve. Fixes Recommended in Addition to the UDGP Vampire Lord Drain With Serana Fixed - Removes the nerfed vampire drain life spell. Bethesda did this intentionally for reasons unknown, so it technically is not a bug fix, but for those who don't think their decision was appropriate, this will correct that. Fixes Recommended in Addition to the UHFP Hearthfire Display Case Fix - Places activation triggers around the display cases Bethesda chose not to make available to the traditional weapon rack system. This technically isn't a bug fix but many people consider it one anyway. Keep in mind this will limit the use of the display cases to ONLY weapons, rather than Bethesda's intent of letting you put anything you want in them.- 101 replies
-
Courier not associating with crime faction
korodic posted a topic in Unofficial Skyrim Special Edition Patch
Hi all, I'm working on a mod to improve the courier and while integrating fixes from the unofficial patch, I realized the courier didnt seem to be affected by crime. I've modified the script below to use IsChild since holds themselves are not the primary location of the cells the courier spawns in, which is likely the cause of the lack of crime association. Scriptname WECrimeFactionAliasScript extends ReferenceAlias {Based on the HoldLocationAlias property, puts the actor in this alias in the correct crime Faction} LocationAlias Property myHoldLocation Auto Location Property HaafingarHoldLocation Auto Location Property ReachHoldLocation Auto Location Property HjaalmarchHoldLocation Auto Location Property WhiterunHoldLocation Auto Location Property FalkreathHoldLocation Auto Location Property PaleHoldLocation Auto Location Property WinterholdHoldLocation Auto Location Property EastmarchHoldLocation Auto Location Property RiftHoldLocation Auto Faction Property CrimeFactionHaafingar Auto Faction Property CrimeFactionReach Auto Faction Property CrimeFactionHjaalmarch Auto Faction Property CrimeFactionWhiterun Auto Faction Property CrimeFactionFalkreath Auto Faction Property CrimeFactionPale Auto Faction Property CrimeFactionWinterhold Auto Faction Property CrimeFactionEastmarch Auto Faction Property CrimeFactionRift Auto Event OnLoad() Location myHold = myHoldLocation.GetLocation() Faction myCrimeFaction = GetCrimeFactionForHold(myHold) Actor selfActor = GetActorReference() ; debug.trace(self + "OnLoad() myHoldLocation: " + myHold + " means I should get the crime Faction: " + myCrimeFaction) selfActor.SetCrimeFaction(myCrimeFaction) EndEvent Faction Function GetCrimeFactionForHold(Location HoldLocation) {Returns the normal crime Faction for the hold} Faction ReturnFaction If HaafingarHoldLocation.IsChild(HoldLocation) returnFaction = CrimeFactionHaafingar ElseIf ReachHoldLocation.IsChild(HoldLocation) returnFaction = CrimeFactionReach ElseIf HjaalmarchHoldLocation.IsChild(HoldLocation) returnFaction = CrimeFactionHjaalmarch ElseIf WhiterunHoldLocation.IsChild(HoldLocation) returnFaction = CrimeFactionWhiterun ElseIf FalkreathHoldLocation.IsChild(HoldLocation) returnFaction = CrimeFactionFalkreath ElseIf PaleHoldLocation.IsChild(HoldLocation) returnFaction = CrimeFactionPale ElseIf WinterholdHoldLocation.IsChild(HoldLocation) returnFaction = CrimeFactionWinterhold ElseIf EastmarchHoldLocation.IsChild(HoldLocation) returnFaction = CrimeFactionEastmarch ElseIf RiftHoldLocation.IsChild(HoldLocation) returnFaction = CrimeFactionRift Else EndIf return ReturnFaction EndFunction -
SharedInfos are voiced response lines used in more than one place, so that they didn't need to record the same lines over and over. Simple enough concept. However, make sharedinfo on an existing INFO creates a new INFO, then moves the new INFO into the sharedinfo list, and points the old INFO at the new INFO. That means the voice line would need to be re-recorded for the new INFO formid. Fixing requires xEdit. Swap the formids. Find the original INFO. Select change formid, control-C copy the original, change to any low unused number such as xx000888 (anything less than the next object id in the header). Control-click the DNAM response formid. (Write down that new response formid.) Select change formid, control-V paste the original formid. Go back to the unused number, and change it to the new response formid. Load up the CK again, check that it now is voiced. Also, a second CK bug is make sharedinfo doesn't clear the number of response lines. Go back to the now renumbered INFO, and re-select the same named response. That clears the number properly. (Or do it in xEdit, but I'm always worrying that the CK is doing something else we don't know about.)