Jump to content

[Relz] Unofficial Skyrim Special Edition Patch


Arthmoor

Recommended Posts

On 5/9/2020 at 1:37 PM, Arthmoor said:

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.

Aha, might help to be mentioned in USSEP Fixes, with the usual strikeout in UDBP. I know most folks never read it, but a few of us do.... ;)

Link to comment
Share on other sites

  • 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

54 minutes ago, DayDreamer said:

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.

 

You probably have to track this for each driver and store the tracking variable. OnActivate() events on the carriages should reliably work to tell you whether the driver is sitting (and in which carriage). OnSit() is not reliable and may even pass a wrong furniture ref (apparently an engine bug, according to the notes on the CK Wiki). OnGetUp(), on the other hand, is reliable,

Link to comment
Share on other sites

8 hours ago, Sclerocephalus said:

OnSit() is not reliable and may even pass a wrong furniture ref (apparently an engine bug, according to the notes on the CK Wiki).

Interesting. That's a vanilla script: CarriageDriverScript. The Bug note is 2015. Anybody know whether that bug has been formally reported to Bethesda?

The bSitting conditional variable is only relied upon in one line of code. Since the vanilla driver only ever sits in one place, this bug may not have occurred in the past.

ICAIO claims (on its description) to have been QA'd by Bethesda. Arthmoor's target practice is on the same Bethesda page, so he could tell us how much vetting is actually done....

What should be done for US*P?

Link to comment
Share on other sites

I would take any claims of being "QA'd" by Bethesda with a grain of salt. As far as I know the only testing they do is enough to make sure it loads. Maybe they do more than that, but they never told me what that was. I seriously doubt they'd have spent any serious time running a much more complex mod like ICAO through any sort of formal testing.

As far as USSEP is concerned, there's no bug because the carriage drivers never stay off the carts for very long if you manage to be able to dislodge them in a vanilla setup. They certainly don't go running off to hide in a building or whatever, even if you attack them directly. The only thing we did for the dialogue itself was to make sure you couldn't initiate a cart ride while he was out of his seat, and so far I've seen no indication that this is broken unless ICAO is installed.

Link to comment
Share on other sites

On 5/11/2020 at 3:11 PM, Arthmoor said:

They certainly don't go running off to hide in a building or whatever,

IIRC, we added that condition because of Run For Your Lives; actually When Vampires Attack at the time, driver ran and hid in Windhelm City, and trying to take a ride from him caused a reproducible problem. Ensuring he was sitting was enough to fix it, because the only place he sat was on his linked seat.

On 5/11/2020 at 3:11 PM, Arthmoor said:

so far I've seen no indication that this is broken unless ICAO is installed.

Agreed. Personally, I don't run ICAIO (I've always used Run For Your Lives), so I've no good reproducible tests. It's just user reports. (Many of them.)

Thanks for all the assistance. At least I've learned something about failures of the OnSit() event and the "link.IsInFurnitureState Sit" conditional. Maybe they'll work in some future game engine.

Reported bugs in tickets 200515-007256 and 200515-07347 respectively. No idea how to access anybody else's tracked bugs.

Link to comment
Share on other sites

That may have been the case with really old copies of RFYL or WVA, but that issue with the carriage drivers was fixed long ago before SSE was even a thing. So nobody playing on SSE should be having any trouble with those drivers today because their faction is exempt from consideration as one of the aliases to fill. So unless they're directly attacked they'll sit on that carriage ignoring the world around them. Unrealistic? Indeed, but better than them running off somewhere and never coming back.

Link to comment
Share on other sites

  • 4 months later...

Getting the Kahvozein's Fang early in the game will always increase encumbrance by 5 and the player cannot remove that blade from the inventory due for being a quest item.

That blade is required for the Alteration Ritual Spell quest when the player reach level 90 in Alteration and according to UESP Forelhost is one of six possible dragon priest locations.

In which Arngeir doesn't send the player to during his radiant word of wall quest, so it would make sense if Tolfdir directed the player there just to avoid the player for having increased encumbrance by 5 early in the game.

Another thing I find it odd is that the quest for finding Tolfdir's alembic is repeatable and so is the aftershock quest, but the latter quest is more logical to me due to the nature of such a quest.

Link to comment
Share on other sites

What should we do about Redbelly Mine? We did a lovely job with the mist and swapping ores, and a red mist makes more sense for an iron mine. But I've just noticed on UESP that ESO has it as an ebony mine. Maybe the current correct answer would be to swap back and change Grogmar's Mine Ore to pay for ebony instead?

[EDIT] Nevermind, a whole host of other voiced dialogue would have to say ebony, too. Should we file a bug report with Bethesda?

Link to comment
Share on other sites

You can file one but it won't be addressed given that it involved a sizeable portion of dialogue and they'd need to run it all through translations for every supported language.

You can see now why we went with the solution we did, since splice-acted lines will sound like absolute shit, and no voice actor is ever going to be able to mimic the real actors closely enough to fool anyone.

And keep in mind that ESO is ~900 years ago in Skyrim's timeline, so it's likely the old Ebony deposits are long gone anyway and the town made due with what they could dig up below them.

Link to comment
Share on other sites

11 hours ago, Arthmoor said:

And keep in mind that ESO is ~900 years ago in Skyrim's timeline, so it's likely the old Ebony deposits are long gone anyway and the town made due with what they could dig up below them.

Aaaannd, they just found a mystery ore in there. (Quicksilver I think) so it could be changing again.

Link to comment
Share on other sites

21 hours ago, Jebbalon said:

Aaaannd, they just found a mystery ore in there. (Quicksilver I think) so it could be changing again.

Good logic, I like it. :) Besides, I've never played ESO. Just noticed it on UESP, was thinking we'd made a mistake. Since we've done a fair job of documenting, and we know that Bethesda sometimes checks UESP for Lore, the onus is on them. I'll see what UESP folks will allow in the Lore section.

Link to comment
Share on other sites

MGCollegeLectures still have some bugs after all these years. I've got some script fixes.

The original was an OnUpdate that ran every 30 seconds forever after you joined the college (MG01). Other scripts used OnUpdateGameTime. Shroob fixed that stuff. But his script doesn't have needed tests to prevent infinite loops in several (admittedly rare) conditions. Just basic defensive programming.

Also, there's a bug fix for Arniel Gane, preventing attending lectures during Under Saarthal. Tolfdir is in even more scenes. Shouldn't he also be prevented from attending?

Moreover, if a scene fails for any reason, the chain of registrations fails, as the registration is in the final stage of each scene. There's no way to restart the lecture series.

Therefore, I've a nagging feeling that it should be a Story Manager event, whenever the player re-enters the college location after joining, that quits when the player leaves. It cannot be good to run scenes over and over in the background forever.

Any interest in that change? Or should we just leave it to fail?

Edited by DayDreamer
ask for guidance
Link to comment
Share on other sites

  • 1 month later...

Inside Ustengrav interior, which never resets, US*P fixed the cleanup problem. The spawning leveled NPCs cleanup after a day or so, although the initially dead bodies remain.

My recent "Issue #29339: Ustengrav exterior NPCs not cleaning up" was closed as not a bug. These leveled NPCs (2 bandits and a wizard) outside are in UstengravZone, which never resets. Is there no similar way to cleanup?

Moreover, inside Ustengrav the wizards and bandits are fighting. Outside, according to UESP, "When you first approach the campsite, the bandits will be attacked by a necromancer." Now they do not attack each other, and all attack the player instead. Is a US*P change responsible?

 

Edited by DayDreamer
resolved, inside they fight draughr and player, outside they fight player
Link to comment
Share on other sites

On 11/14/2020 at 6:36 AM, DayDreamer said:

Moreover, inside Ustengrav the wizards and bandits are fighting. Outside, according to UESP, "When you first approach the campsite, the bandits will be attacked by a necromancer." Now they do not attack each other, and all attack the player instead. Is a US*P change responsible?

The bandits you are talking is actually summoned by the necromancer due for being already dead before the player arrived.

Link to comment
Share on other sites

Quote

The bandits you are talking is actually summoned by the necromancer due for being already dead before the player arrived.

This is correct. The bandits are placed dead and are reanimated by the necromancer once the player approaches the area and/or is detected. I've found that they often times turn into ash piles afterwards, but this isn't always the case for reasons I don't understand. As we've discovered, ash piles from NPCs that are placed dead at the beginning of the game don't ever clean up due to an engine issue. NPCs that are placed dead seem to remain in the game forever even if they aren't reanimated and turned into an ash pile, unless they are culled by the game engine (which only happens in a few cases that I'm aware of).

To the best of my knowledge, UESP is incorrect about the necromancer and bandits fighting each other outside the dungeon. What I described above was the case back when I played Skyrim on the Xbox 360 console, so I'm rather sure the patch didn't change anything. Maybe what UESP describes was the original intent of the developers, but I don't know how you'd go about making that determination with any degree of certainty, unless there is some sort of evidence in the Creation Kit to point to that being the case.

Link to comment
Share on other sites

10 hours ago, BlackPete said:

The bandits are placed dead [...] evidence in the Creation Kit to point to that being the case.

No, this is only partially correct. I've checked. There are 2 living bandits (000299f7, 0008b706) and 3 initially dead bandits (000299f5, 000235db, 000235dd); one with her head poorly placed under the bed.

The necromancer (000235d6) has a script defaultOwnZombie that adds the living bandits to its faction. They will not fight each other. UESP is wrong. I'll fix it.

The necromancer will also resurrect one (and only one) of the dead bandits. The problem that I'd reported is the killed necromancer and 3 killed bandits do not ever cleanup. After looting, they all reload with the cell 10 days later, naked with a pickaxe. Very strange.

Inside Ustengrav, there are 4 living bandits. Likewise, they are all defaultOwnZombie of a necromancer (0002820e). After death, these killed necromancers and killed bandits do clean up after only a day or so, even though they are also in a no reset zone.

In both places, the initially dead bandits never cleanup.

My desire was that the killed exterior NPCs cleanup the same as the killed interior NPCs. Maybe that's not possible? Maybe the killed interior NPCs aren't supposed to cleanup?

Link to comment
Share on other sites

I see. It's been a few years since I've played the game all the way through, so I'm probably forgetting about the two living bandits. Now that you mention it, I do recall the necromancer only raising one of the dead bandits. The issue with them respawning naked is probably the same engine bug that occurs elsewhere in other locations in the game. The exterior NPCs are part of the Ustengrav "no reset" encounter zone and the references are even properly flagged to be a part of that zone, so an engine bug is the only explanation I can think of as to why they reset anyway like you've observed.

It may be possible to get the exterior NPCs to clean up if they were tied to the Ustengrav control quest like the ones inside. I'm pretty sure I also brought that up at one point years back and the determination was that they were likely meant to be handled separately from the ones inside. That's all I can remember since it was a long time ago.

The NPCs inside were definitely intended to be cleaned up. The reason why that didn't happen was because the control quest was never shut down like it was supposed to be, which as you likely know was corrected by the patch. Ustengrav is just one of several locations with control quests that the developers forgot to script to shut down after the associated dungeon quest was completed, resulting in the same issue with the NPCs persisting forever.

Link to comment
Share on other sites

Just for clarification...
There are no "Living" bandits at Ustengrav (or should not be) - the bandits used as properties in the script defaultOwnZombie.psc are placed alive and that script turns them into zombies (undead).
The Dead-dead bandits are there for looks and the necromancers are able to cast Raise Dead on them.
Looks as if Beth wanted multiple raised dead and used the script to get by the necros limit of one per caster.

If there are Living bandits that fight with the necromancers and/or their pets then that should not be happening or they are from a mod.
If the necromancer raises a dead bandit then that bandit needs to be in that faction with the rest of them or friendly with it.

FYI: The story is that the Necromancers are raising the dead bandits to use them as labor, digging in the dungeon. When the player arrives and interrupts the operation that is when the necros further in meet the draugr.

Link to comment
Share on other sites

4 hours ago, Jebbalon said:

The Dead-dead bandits are there for looks and the necromancers are able to cast Raise Dead on them.
Looks as if Beth wanted multiple raised dead and used the script to get by the necros limit of one per caster.

From what I've seen, Serana are sometimes too keen of using the Raise Dead spell even when she seems to be safe, so if getting the chance she always cast the Raise Dead and that could also trigger the engine bug that BlackPete mention.

Unfortunately, that also affect followers if they have a staff of raising dead or know the Raise Dead spell.

Link to comment
Share on other sites

On 11/19/2020 at 2:47 AM, Jebbalon said:

There are no "Living" bandits at Ustengrav (or should not be) - the bandits used as properties in the script defaultOwnZombie.psc are placed alive and that script turns them into zombies (undead).

Not exactly. The raised dead properly turn into piles of goo, the pseudo-zombies lie around as dead bodies, as does the necromancer.

On 11/17/2020 at 3:09 AM, BlackPete said:

an engine bug is the only explanation I can think of as to why they reset anyway like you've observed.

Sadly, not much we can do about an engine bug.

On 11/17/2020 at 3:09 AM, BlackPete said:

brought that up at one point years back and the determination was that they were likely meant to be handled separately from the ones inside.

Thought they needed the dead body cleanup script or something. There's a spot East of Stonehills where a wizard fights a couple of bandits (and usually loses) near a crashed wagon the first time you pass by, and those all cleanup nicely. (While the dead horse and dead wizard in the wagon do reset, although that's a bit odd.) I'd hoped there was something we could do here to match.

The only reason that I'd noticed was my Touring Carriage runs over them as speed bumps to and from Windstad.

This is actually my very first comprehensive play through, although I've played up to various stages in the past to test....

Link to comment
Share on other sites

Version 4.2.4 of the USSEP is now in beta. It's been awhile, I know, but here we are :P

This should be in beta for at least a week just to be sure any issues are shaken loose. There are some changes to the way the retroactive update scripts work which may produce some odd Papyrus log errors. We are aware of this and there should be no issue with it once they've been seen the first time.

Link to comment
Share on other sites

About Ugor: USKP 1.1 made her Protected in the related DA06 quest. She was not protected in vanilla. You might make a note of that in your summary.

Atub was also made DA06 Protected, but that doesn't show up in the version history.

In USKP 1.2.5, Ugor's level was raised to match Atub, because she dies too easily against the fixed level 32 giants.

For some odd reason, the Protection state doesn't always kick in on time? This problem only occurs when the player passes by at low levels. (Such as riding a Touring Carriage from Riverwood to Riften the first time.) It was readily reproducible.

Note that Gularzob was made DA06 essential in USKP 2.0.8.

Contra USKP 1.3.3, Ugor is a female.

Link to comment
Share on other sites

  • 2 weeks later...

There was a missing script in one of the retro aliases that needed to be added and some other minor stuff with the retro scripts in general that needed to be addressed. The patch will probably go live this weekend assuming nothing else is out of place.

Link to comment
Share on other sites

Cool. Didn't understand the necessary changes in the retro script anyway. This is the third time around. Perhaps an explanation, here or in the source?

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...