[RELz/WIPz] Unofficial Skyrim Patch

[Arthmoor]

I'll add more later. I found theses earlier today and meant to do more debugging, but you weren't online, so I waited, and now that it's later, I'm tired.

All that's been fixed now.
 

I went through most of the changelog for 1.3.3 beta and noticed some things.
 
<snip>
 
Lastly, just a question, where did the information for this fix come from?
"Hemming mistakenly refers to Sibbi and Ingun as his children when they're actually his siblings. Corrected their relationship settings to match."

All fixed. The Hemming thing was reported directly by Shroob, it never had a tracker entry. Not everything will.
 

I think you fixed the Say Once flag bug, but I'm not sure until someone can confirm this or not.  My loadorder is the same as before except that I updated USKP before I did this test.

Oh, I wish we could say we fixed the actual bug with the say-once flag. We didn't. In this case applying it to her probably fixed the issue in this one instance. The underlying bug is an engine issue though and can't be fixed by users.

[Leonardo]

Oh, I wish we could say we fixed the actual bug with the say-once flag. We didn't. In this case applying it to her probably fixed the issue in this one instance. The underlying bug is an engine issue though and can't be fixed by users.

Damn...  I was hoping that my playtest would be enough for confirmation.

[tyrel68]

Nvm thought i saw an error but doublechecked it was nothing

[bt48]

A bit of an old bug, but I still face issues with http://www.afkmods.com/index.php?/tracdown/issue/12540-breezehome-top-stair-step-snag/. (Whether with 1.3.2c or 1.3.3 beta, old save, new game, etc.)

 

I see that USKP aligns the top step with the upper floor, however, getting temporarily stuck (on the upper most steps) still occurs when moving up the stairs regardless of speed.

 

Stopping midway on the steps prevents the snagging, so could it be a(n) engine/physics/something-CK-can't-fix issue?

 

Or could the stairs need more adjustment?

[Arthmoor]

It's been as adjusted as we can make it. The collision bounds on NPCs sticks out substantially in front of them and that's what you're ultimately getting hung up on. It isn't something that can be corrected further without generating an unnecessarily large number of compatibility problems.

[bt48]

Oh, thanks anyway.

[PrinceShroob]

Has Isabelle Rolaine's new facegen been exported?

[Arthmoor]

Looks like a much better beta run than 1.3.2, though we're finding some oddities that resulted from copy/paste oversights and also a few refinements to some stuff.

• Updates to the weapon and shield rack fixes to handle Ysgramor's Shield as well as staffs whcih were NOT being handled properly for weapon display cases.
• Forgot to add facegen files for NPCs which had their facegen data updated.
• Forgot to copy the dialogue files (and some text matching too) for the Delvin/Vekel dialogue fix.
• Forgot to copy dialogue files and matching text for one of Jon Battle-Born's lines.
• Several entries in the changelog were also left out.
• Weapon/shield racks and display cases have received a major overhaul to fix numerous bugs:
  
  • Shield nodes for Dwemer, Daedric, and Dragonplate have been added to correct for several floating shield placements. (Meshes\Clutter\WeaponRack\WRPlaqueShield01.nif)
  • Completely fixed all of the problems with missing or incorrectly used staff nodes for display cases, wooden racks, and the red wall mounted racks. (Meshes\Clutter\WeaponRack\WRSingle01.nif, Meshes\Clutter\WeaponRack\WRDisplayCase01.nif, Meshes\Clutter\WeaponRack\WRPlaque01.nif)
  • Special handling for various unique shields and staves to ensure that they will properly fit and not end up floating.
  • Fixed issues with weapons falling off the racks in places like Riverwood where the game preplaces weapons.
  • Fixed errors that were causing Papyrus to complain about enable parent settings.
  • Due to the Ebony Blade and Keening being quest items, they will no longer be accepted by the racks, in part because they simply fall to the floor and can get lost.
    

  
  

Yep, mostly "I forgot stuff" But the major thing is the huge updates to the weapon rack scripts. These really should get pounded to make sure nothing is horribly broken somewhere.

[NightStar]

Only found one typo in the updated version history

damageset -> damage set

[PrinceShroob]

• Due to the Ebony Blade and Keening being quest items, they will no longer be accepted by the racks, in part because they simply fall to the floor and can get lost.

Keening is a quest item until the quest is done; then the player can keep it. The Ebony Blade is never a quest item.

Yep, mostly "I forgot stuff" But the major thing is the huge updates to the weapon rack scripts. These really should get pounded to make sure nothing is horribly broken somewhere.

[Arthmoor]

Wrong. Ebony Blade is held in a quest alias in DA08. We've already proven it isn't a mesh defect because a copy of the weapon made using the same model doesn't fall off the racks, but the blade does. Same with Keening. Apparently Ghostblade also has the issue too.

[PrinceShroob]

Wrong. Ebony Blade is held in a quest alias in DA08. We've already proven it isn't a mesh defect because a copy of the weapon made using the same model doesn't fall off the racks, but the blade does. Same with Keening. Apparently Ghostblade also has the issue too.

 

Stage 60 of DA08 explicitly clears the Ebony Blade quest alias; this stage is set when Mephala explains how to power the Blade. Even if that weren't so, the USKP will stop the quest and thus clear the alias when the Blade is fully powered.

 

Keening is a quest item until MGRArniel04 stops; however, the sword that the player can pick up from the floor afterwards is a different reference that is enabled when Arniel disappears, not the Keening held in the quest item alias.

 

If these items are excluded from being placed on weapon racks because they always fall off, then fine, but they do not fall off because they are quest items.

[tyrel68]

I think what they mean is even after the quest is finished like you said, the sword still is rejected from the racke but if you make a copy of the exact same blade, the rack will accept it fine.

 

It is probably something to do with the status being hardbaked into the save, usually is.  I do agree it SHOULD work like you say though.

[Sclerocephalus]

I ran a test in Hjerim with a modified script version (where racks will accept multiple weapons, without "eating" them; this is not intended for release, of course), which will clarify matters:

 

The CoA rack in the player's bedroom starts with two iron gretswords and a shield on it. I sold the shield some time ago, but still had the greatswords, and while I was testing the weapon rack modifications, I put a bunch of other items on the CoA rack and moved the greatswords to the wooden rack:

 

http://www.afkmods.com/index.php?/gallery/image/1090-before-leaving-hjerim-1/

http://www.afkmods.com/index.php?/gallery/image/1091-before-leaving-hjerim-2/

 

Then, I left Hjerim amd returned immediately. The two slots on the wooden rack where the greatswords had been were empty, and the swords were back on the CoA rack where they had started their life in the game:

 

http://www.afkmods.com/index.php?/gallery/image/1092-after-returning-to-hjerim-1/

http://www.afkmods.com/index.php?/gallery/image/1093-after-returning-to-hjerim-2/

 

The engine strongly dislikes persistent references that are placed anywhere else than at their editor location (unless they are put in a container), and it will try to move them back without saying (the process was perfectly repeatable and there was no message showing up on the log at all). The latter behaviour is also the reason why the fix from USKP 1.3.2c could only make them stay temporarily, if at all.

[Arthmoor]

And thus, I am correct in asserting it's due to being quest items. That's the ONLY method that exists in the game engine (according to the developers, we asked them specifically about this during the CK beta) to generate persistent references. They have to be held by aliases. Apparently it doesn't matter if that alias is later cleared.

 

Whether or not the specific "quest item" flag is set is not material to this. The result is effectively the same other than allowing you to drop the item manually.

[PrinceShroob]

And thus, I am correct in asserting it's due to being quest items. That's the ONLY method that exists in the game engine (according to the developers, we asked them specifically about this during the CK beta) to generate persistent references. They have to be held by aliases. Apparently it doesn't matter if that alias is later cleared.

 

Whether or not the specific "quest item" flag is set is not material to this. The result is effectively the same other than allowing you to drop the item manually.

 

Now that you mention it, all those problem items are persistent references that exist in the world and are held in quest properties.

 

But wouldn't that mean the Thane weapons, being generated then held in aliases, be problematic, too?

[tyrel68]

I think since they are just randomly generated and named means they are exempt

[Arthmoor]

It likely depends on the type of alias. As Tyrel says, Thane weapons are generated records. Like a PlaceAtMe call. Ebony Blade and Keening are specific references, which means they have no choice but to be used as forced references.

 

So perhaps at least in SOME cases these types of references really do remain permanently persistent. I know they don't always remain so for things like XMarkers though because I've been able to freely manipulate the positions of them when the quests holding those aliases aren't running.

[Kislupus]

Hi!

 

I want to start playing with Skyrim, but I want to wait the 1.3.3 USP. When will the new USP testing finished? Sorry for my bad English

[Leonardo]

Welcome to AFK Mods! :cookies:

 

Have A Horker Stick!

 

 

If the USKP-team find anything that's similar to this report then they'll release a new USKP version.  Also check the other Unofficial Skyrim Patches in this forum.

[VaultDuke]

Hi Kislupus, and welcome to the forums.

 

i doubt new bug reports will have anything to do with a delay in the next USKP.

 

the current beta is held back by a massive overhaul of the weapon rack scripts, which should hopefully be fixed by now. the next step is another beta of 1.3.3 to test whether everxthing is really fixed now. should this be positive, the 1.3.3 version will go live.

 

should no issues arise, you maybe can expect this before next month.

[NightStar]

Welcome to the forums Kislupus!

 

New bug reports aren't holding the release back, it's the overhaul of the weapon rack scripts like Gruftlord said. They will require another beta period and if it's successful, then it will go live.

[Arthmoor]

3rd round beta for 1.3.3 is up.

 

* More fine tuning on the weapon rack fixes.

* Added Sclerocephalus' fix for the predator script that threw errors.

* Fixed the issue with The Wolf Queen Awakened so that the courier won't jump you the moment you leave Solitude after clearing Wolfskull Cave.

 

Provided this goes well in testing, I see no reason we couldn't go live on this by Saturday. The weapon rack stuff is a big fix, so it needs big time to make sure it isn't going to completely screw something up.

[Kislupus]

Thanks for the info guys, and sorry for my impatience. I'm looking forward to Saturday

[PrinceShroob]

Error-checking:

DialogueWhiterunElrindirTopicsBranch2 in DialogueWhiterun, second response: text not changed to match new audio. ("Try Olfina, the new innkeeper..." -> "Try the new innkeeper..." -- Mikael is now the Bannered Mare's backup innkeeper, not Olfina); also, change the GetDead check to Mikael's ref.

Favor013PersuadeSpeech in Favor013, Mikael’s first response: text not changed to match new audio. ("...one Nord lass..." -> "...one lass..." -- Carlotta is an Imperial, not a Nord)