Jump to content

[Relz] Unofficial Skyrim Special Edition Patch


Arthmoor

Recommended Posts

Version 4.2.2 of the USSEP has been released. First post has the details. Enjoy!

Link to comment
Share on other sites

  • 1 month later...
  • Replies 482
  • Created
  • Last Reply

Top Posters In This Topic

  • Arthmoor

    149

  • Leonardo

    44

  • alt3rn1ty

    41

  • DayDreamer

    25

Top Posters In This Topic

Posted Images

Quote

Diadem of the Savant [dunLabyrinthianMazeCircletReward] is missing the 'ArmorJewelry' keyword like other circlets. (Bug #18863)

The Amulet of Articulation (TGAmuletofArticulation01/02/03/04/05/06/07) was missing the ClothingNecklace and ArmorJewelry keywords.

Is that the reason why those Jewelry can't be improved on an armor workbench? If so maybe that was intended because Beth didn't want them to be upgraded because they are Jewelry despite they have small armor value. Doesn't seem to be a concidence those two missed the same keyword.

Quote

Exploding steel crossbow bolts were still recoverable after being fired. (Bug #18930)

As far as I know, they are still recoverable. Could anyone check this?

Link to comment
Share on other sites

Quote

Sunhallowed and Bloodcursed Elven arrows lacked the material keyword designating them as Elven arrows. (Bug #21705)

Actually, PS4 version of USSEP adds the proper keyword to sunhallowed arrows only...

Link to comment
Share on other sites

Any thoughts on implementing the fixes in these mods? Or your own versions of the fixes?

Assorted mesh fixes has open permissions.

Skyrim Worldspace Fixes (WIP) says it's open source.

MEZF - Missing Encounter Zones FIXED requires permission to use the assets if your mod is opted in to donation points, which I guess USSEP is, so maybe not this one?

Hope this is the right place to put this. Otherwise I'm sorry.

Link to comment
Share on other sites

We'd need to look at what the first two even do, but MEZF is unnecessary and entirely placebo. Those encounter zones are assigned to locations through a different means and don't need to be tacked on to the individual cells.

Link to comment
Share on other sites

Wish they'd have reported them for US*P. It's not like they won't have heard of us. Some of the 'WIP' change landscape instead of adding rocks, but seems to have nailed a few we've missed, so a rock solution could be tried. Nicely documented with pictures.

How do encounter zones work? It seems a legitimate complaint.

Link to comment
Share on other sites

An encounter zone record has a drop menu to assign a location to it. All one then needs is for cells to be assigned to the location for the zone settings to apply. In every case that mod covers, the cells are assigned to locations that have an encounter zone attached to them. So there's nothing to be done with that mod and what it proposes to accomplish is already part of the vanilla game.

Link to comment
Share on other sites

Version 4.2.3 of the USSEP is now out. First post has the details. Enjoy!

Link to comment
Share on other sites

Quote

When the player kills an NPC, the game has the chance of generating a "letter of gratitude" from one of the NPCs enemies [Quest WIKill04]. It was apparenly possible for the player themselves to be set as the enemy which would make collecting the reward for the kill impossible. The "Enemy" alias will now prevent the player from satisfying the conditions. (Bug #28980)

That fix also corrects my report - Issue #26714

... the only way for player to fill that alias was to have valid voice type. I am glad it is fixed though.

Link to comment
Share on other sites

On 10/26/2016 at 10:42 PM, Arthmoor said:

The room boundings for Angarvunde near the word wall needed to be expanded slightly to make sure portions of that part of the dungeon don't disappear from the screen. (Bug #28493)

Small mistake in changelog: The correct bug entry is #28943, not #28493

Link to comment
Share on other sites

On 10/26/2016 at 10:42 PM, Arthmoor said:

NPCs in Solitude sometimes fall through portions of the city due to it being too large to load all of the cells into memory at the same time. Usually this will result in their deaths as they fall through and hit the landscape below, but it can sometimes also lead to them being permanently stranded in the water below the arch. A possible solution has been implemented in the form of a giant trigger box that encompasses the city from one of the cells which always loads. If an NPC falls into the box, they will be returned to their editor location and then be able to resume their schedule as normal from there. (Bug #28929)

Just a side note:

I remember seeing this issue in Windhelm and Whiterun as well: dead NPCs found below the ground (by using the 'tfc' console command). If I remember right I had Open Cities installed.

Link to comment
Share on other sites

I'd just like to point out that while technically possible for the player to have filled that alias even in the vanilla game, it's not something that's been widely reported outside of those using mods to make it more likely for the conditions to pass. The player record has a valid voice type set, and always has, because the default player is of the MaleNord type.

Link to comment
Share on other sites

Lately, I've been getting a lot of complaints about interactions between Touring Carriages and Immersive Citizens and the Unofficial Patch.

Long ago, we added a dialogue test (to USKP and copied to TC) that every driver was sitting, because there were other patches that had the driver leave during a dragon or vampire attack or during the night. But I don't remember why we didn't use the driver's bSitting conditional script variable. That would require the driver be sitting on the carriage itself. Right now, he can be sitting anywhere, including inside a building somewhere.

Immersive Citizens changes the US*P (and TC) test to anywhere in Tamriel. That solves the sitting inside problem, but is really overbroad. And probably a problem with Open Cities.

What would be the best overall solution? I'm leaning toward bSitting, but surely there's a reason that we didn't use it?

Link to comment
Share on other sites

Is the modding process of Skyrim Special Edition the same as Oldrim? Specifically, can I use the same Vortex -> LOOT -> xEditQuickClean method I used before?

Link to comment
Share on other sites

Yes, other than the annoyance of not being able to generate LIP files for voice acting, the CK and all other tools behave exactly the same for SSE as they do for LE.

Link to comment
Share on other sites

15 minutes ago, Arthmoor said:

Yes, other than the annoyance of not being able to generate LIP files for voice acting, the CK and all other tools behave exactly the same for SSE as they do for LE.

Amazing! Thank you. Also, I recently discovered that LOOT is integrated in Vortex. I do not have to run them separately now. :)
Say, does this forum have a Guide section? I am new to all this and I could use a "Modding Skyrim for dummies". I have looked online for some, but they are either outdated or incomprehensible. Most of them made references about old versions of the softwares needed. The QuickClean is not even mentioned in all of them.

Link to comment
Share on other sites

On 4/29/2020 at 4:55 AM, DayDreamer said:

What would be the best overall solution? I'm leaning toward bSitting, but surely there's a reason that we didn't use it?

ANSWER:

Although bSitting is set by the vanilla drivers in their script, available game engine dialogue conditions are not able to easily access it. GetVMScriptVariable only works on a specific reference, so every destination would need to be duplicated for each and every driver. Not practical.

The vanilla alternative that was only partially implemented was using Subject:Variable01. 0 means ready for dialogue, 2 means ready for chatter on ride. US*P already has a bug fix using these values.

But there now exists a popular Better Vampires that alters Variable01. There may be others. Modders who didn't read the CK documentation.

https://www.creationkit.com/index.php?title=Actor_Value

My advice has always been:

Quote

If you're not running all the appropriate Unofficial Patches, you are not supported. If you haven't cleaned dirty plugins with TES5Edit, you are not supported. Please don't even ask.


Perhaps a bit rude, but these are nearly impossible to debug. They don't show up as conficts in xEdit, because they are scripted.

Link to comment
Share on other sites

2 hours ago, DayDreamer said:

The vanilla alternative that was only partially implemented was using Subject:Variable01. 0 means ready for dialogue, 2 means ready for chatter on ride. US*P already has a bug fix using these values.

There's another value specified later in the unused StopRiding() myDriver.SetActorValue("variable01", 1); reset "home" to be here.

Would folks be willing to add a similar line to CarriageDriverScript OnSit() to parallel bSitting?

Known values: 0 = off (unknown), 1 = home (idle), 2  = chatter, 3 = pausing ride

Link to comment
Share on other sites

On 5/7/2020 at 11:30 AM, DayDreamer said:

Would folks be willing to add a similar line to CarriageDriverScript OnSit() to parallel bSitting?

I've tested, and it works reliably. The downside is that it requires the driver to re-load and re-sit before it works. So only after leaving a city. Not as user freindly as I'd like.

After much hair pullng, tried pairing the existing "subject.GetSitting == 3 AND" with "link.IsInFurnitureState Sit == 1 AND". The driver links to the furniture. You don't know where the driver is sitting, and you don't know who is using the furniture, but the pairing should work. Yet it didn't.

Could somebody else test and tell me what I'm doing wrong?

Link to comment
Share on other sites

Been years since I've been staring at papyrus logs, but recently a new warning has been showing up:

[05/09/2020 - 06:09:04AM] warning: Variable ::DLC2NordicArrow_var on script udbp_retroactive212script loaded from save not found within the actual object. This variable will be skipped.
[05/09/2020 - 06:09:04AM] warning: Variable ::LItemBanditWeaponArrows_var on script udbp_retroactive212script loaded from save not found within the actual object. This variable will be skipped.

Not seeing a change notice in the USSEP history for the most recent release.

Link to comment
Share on other sites

The fix for 19338 was moved to the retro script for 4.2.3 instead of UDBP 2.1.2 to correct that it wasn't setting the right levels and amounts.

Link to comment
Share on other sites

On 5/7/2020 at 3:19 PM, DayDreamer said:

Although bSitting is set by the vanilla drivers in their script, available game engine dialogue conditions are not able to easily access it. GetVMScriptVariable only works on a specific reference, so every destination would need to be duplicated for each and every driver. Not practical.

If I got this right, you're looking for a way to store the driver state. You want it to be easily accessible by condition functions and you also want to protect it from being manipulated by unsuspecting mod authors.

 

SOLUTION:

Make a custom faction, count all drivers in, and store the information in the faction rank. Tthis also enables you to use more than two states (in case you need them).

There are condition functions for both the adherence to a faction and the faction rank.

Link to comment
Share on other sites

Hi,
 
After posting the request to reopen Issue #29046: 'Night Eye/Vampire's Sight flicker when activating' with a new and what I thought "more elegant fix". I noticed an incredibly small flicker whilst doing some more testing on it (barely perceptible and once I saw it I couldn't unsee it). I realised that the reason the devs put in that 0.96 second delay was to prevent that flicker in the first place (it fixes the flicker at some framerates but not others). My newer fix removed that 0.96 override and uses the default script's (magicNightEyeScript.psc) delay of 0.83. This results in what I said in the beginning (barely perceptible flicker). My original fix (1.5 second duration modification) funnily enough actually doesn't have any flicker (large or even barely perceptible). So that is in my opinion is still the best fix. So please ignore my request to re-open the issue and continue to push out my original fix for USSEP 4.2.4.
 
Sorry about that :(.
Link to comment
Share on other sites

21 hours ago, Sclerocephalus said:

If I got this right, you're looking for a way to store the driver state.

Not exactly, although your idea is very clever, and I'll look into it for the future. (There already is CarriageSystemFaction and unused JobCarriageFaction.)

The problem at the moment is no way to decide whether the vanilla driver is sitting in his carriage seat. ICAIO moves the driver around, and has him sleeping. The long-time US*P solution is checking that he's sitting anywhere, fixing a lot of grief, but there are cases of that not being quite correct (sitting inside, sitting on a bench outside). Still, it's much better than nothing!

What I'm currently doing in Touring Carriages is after the player selects "Where do you want to go?" checking bSitting. Unfortunately, because that test happens afterward, the player sees only "Never mind."

I was looking for a definitive early test (such as the aforementioned "link.IsInFurnitureState Sit == 1 AND"; that works in scripting). Apparently, even though documented, it doesn't work properly in conditions. Or I'm doing it wrong.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...