Jump to content

Photo

EngineBugFixes


  • Please log in to reply
780 replies to this topic

#701
Tinien

Tinien

    Enthusiast

  • Members
  • PipPip
  • 211 posts
In response to post #69907368. #69908828 is also a reply to the same post.


Spoiler

Then maybe it's worth trying to disable BackgroundCellLoadFix temporarily and see whether the game runs smoother or not. I disabled it for a time and tried my best to compare smoothness now and before. Well, maybe right after loading a savegame the camera performs its first quick rotation 180 with a bit higher fps (when the location hasn't fully loaded yet) than with BackgroundCellLoadFix enabled. Or maybe it so seems to me, I'm not sure. Will continue testing.

#702
Tinien

Tinien

    Enthusiast

  • Members
  • PipPip
  • 211 posts
I want to mention about some mess with a weight of custom made potions. But first a few words about a small trick with potions' weight: if we have various ingredients and some of them weigh more than others then it's better to first use two lightweight ingredients once - in order to create lightweight potion (make sure beforehand that there's no similar heavyweight potion in the inventory, otherwise all next created potions will have the same weight like this one and stack with it) and only then to change them for all heavyweight ingredients with the same effect. So we get lightweight potions with useful effects and get rid of heavyweight ingredients at the same time. But from a certain moment this trick hasn't been working and created potions now weigh much more than their ingredients. For example Restore Health potion made from Fly Amanita Cap (0.1) + Lavender Sprig (0.1) weighs 1 although earlier, when I created this potion from the same ingredients it weighed 0.1. And before that the same bug occured with Damage Willpower potion created from: Lily Nectar (0) + Morning Glory Root Pulp (0) = DWp (1) although initially this potion also weighed 0 like its ingredients. Who knows if this bug will spread to all potions over time. And yes, I always make sure before creating potions that there's no similar heavyweight potion in my inventory. I remember that EBF somehow changes the inventory so decided to describe this bug here. Maybe someone came across it as well and knows the reason of such mess.

Edited by Tinien, 09 May 2019 - 10:48 PM.


#703
Tiawar

Tiawar

    Enthusiast

  • Members
  • PipPip
  • 193 posts
In response to post #69881848.


Spoiler

Could you upload a save game with a container or actor that is supposed to have one of the capes from OOO but where it isn't showing in the menu?

#704
Tiawar

Tiawar

    Enthusiast

  • Members
  • PipPip
  • 193 posts
In response to post #69907368. #69908828, #69910158 are all replies on the same post.


Spoiler

It shouldn't. I've double checked my docs for the relevant code and also installed a logging patch to compare the cells that get loaded each frame for vanilla code and the fixed code. It's completely identical except for the rare cases when the fix does its job. OSR doesn't do anything that could affect the relevant code.
So, if you're still positive that you get stutter from this patch then the only thing I can suggest is to disable it.

Starting a new game is never required when upgrading or even downgrading EBF. The only thing you have to keep in mind is that some patches like the new ParentCellUpdatePatch are designed to prevent problems but they cannot fix the related problems if they are already in the save game.

#705
Tiawar

Tiawar

    Enthusiast

  • Members
  • PipPip
  • 193 posts
In response to post #69964193.


Spoiler

All relevant code for creating potions is in the Alchemy Menu. Inventory code does not change the weight of ingredients since the weight is defined in the CS. The weight of a new potion is always calculated to the average of all ingredients used when you select an ingredient and gets applied to the potion at the time it is created. Only if you have created a potion with the same name and effects before the game will use that potion instead of creating a new one. The potions in your inventory don't have any effect on this. It's the created base object that counts. This is stored in your save game the time you create the potion.
So either you have something that modifies the AlchemyMenu code for creating potions or you've created a similar potion before.
Try renaming the new potion to see if you get different weight.

#706
Tinien

Tinien

    Enthusiast

  • Members
  • PipPip
  • 211 posts
In response to post #69881848. #70039778 is also a reply to the same post.


Spoiler

Hi, Tiawar! Sorry for the late answer, I just couldn't catch the moment with these disappearing capes for a long time or when I met this bug it didn't persist. I mean sometimes it happens that on caped enemy's corpse its inventory doesn't show this cape only once. Just enough to re-open the inventory so that this cape appears. Saving the game and reloading this save also makes the cape appear in inventory, so such save would be useless for revealing this bug.

But I found another bug - sometimes load doors disappear along with their markers on local map when approaching them from certain direction. This happened with the fort Magia when coming to it from the east (from Cheydinhal) - in such case the load door to fort Magia isn't there and there is only a stone niche behind it so entering the fort becomes impossible. Local map marker is absent as well. But if you come to this fort from another direction (e.g. from the north or west) then everything is OK, the entrance door is in place. Next time this bug occured in Chorrol in its southwest part when I came to it from the east (from Weynon Priory direction) - this time there were as many as six houses with all their entrance load doors NOT missing but non-interactive. You just pass through them and go inside non-loaded premises without walls. It reminds me of the occured here reverse bug with non-loading houses and street surface but with entrance doors in place. AFAIK this reverse bug was fixed by UOP. But this new bug with load doors not loading/not active revealed quite recently. This bug is easy to eliminate just saving right here and reloading this save - then load doors will be in their places as well as their map markers. Nonetheless I'd be very anxious to surface the reason of this bug and to fix it because it's very annoying. It didn't happen before and I suspect that maybe one of new EBF fixes or patches causes it. BackgroundCellLoadFix or ParentCellUpdatePatch for example but I'm not sure. Please, could you check this matter? Here is my save to reproduce this bug:
https://drive.google.com/file/d/1Ez1nveZzYrzm0vWfvG0NKlW3WVZ6kQSS/view?usp=sharing
You need to approach Chorrol from the east for this bug to happen. Oh, and here is my LO:
Spoiler

There are also Darnified UI + Color Map (both installed with OBMM) which don't have esp plugins and RAEVWD + RAEVWD SI Edition (both installed using Master Wizard in Wrye Bash, without esp plugins). EBF v2.21.

Edited by Tinien, 26 June 2019 - 12:27 PM.


#707
Arthmoor

Arthmoor

    Destroyer of Bugs

  • Premium Member
  • 19,842 posts
In response to post #68476181. #68696906, #68697931, #68777601, #68783466, #68786891, #68803231, #68963391, #68975216, #68992201, #69188706 are all replies on the same post.


Spoiler

The UOP says the problem was fixed by adding a road.

Not quite adding a "road" so much as it was I spent time figuring out how ROAD records worked and setting up one in the UOP that should fix issues exactly like this Skingrad bridge problem.

First a bit of background:

For loaded cells you have basically 2 types of path nodes. One colored red or orange, the other colored blue. Blue ones are used to indicate preferred pathing and while in loaded cells, NPCs will try to stick to using those for as long as they can to reach their destinations. The red/orange ones are only used when they represent the shortest path after leaving the blue ones.

For unloaded cells, the game uses a much lower level record that spans the entire worldspace. It's called "roads" in the CS, but it's really a secondary pathing system for long distance use. This secondary system is what all NPCs will use when you aren't nearby in a loaded cell.

I spent a great deal of time figuring out how this secondary system works and crafted a record that would eliminate pretty much every cause of long distance pathing problems. Each cell can basically have a maximum of two nodes in it for this system to calculate pathing with. It uses blue node data from the normal path grids, so in order to get something that can actually be used, one needs to create a .esp file that strips every path node from every cell in the game, then go over each major road and set the two blue nodes in each one. The path links between them should fit as closely to the road as possible, which obviously gets tricky in places where there are tight corners, like west of Fort Nikel heading into the hills etc. Once they're all in position, generating the record should result in a long series of small purple nodes linked by purple lines on the map. If it's been done right, this should follow the roads pretty close to exact.

In Skingrad, the vanilla setup for this had the nodes for this record shifted off of the bridge and hovering over the gorge. So when you're not in the city the NPCs going to and from the castle stood a pretty good chance of falling into the gorge. Obviously weaker ones would die from this and then you'd never see them again. A similar thing used to happen with Open Cities Reborn in the redone Leyawiin layout before I figured all of this out and corrected it so NPCs there no longer fall into the river below.

There were a few other vanilla area where this was an issue as well and the fixed record included with the UOP should have taken care of them all. Now, since it's a record that covers the entire worldspace, it's possible you may end up with other mods that have messed with this data inadvertently and thus block the fix. It's also why Roads of Cyrodiil and Open Cities Reborn have their own versions of this record, along with a 3rd patch between them that makes them both work properly together.

For Open Cities Classic, it works just fine from the UOP record so it won't have this issue as long as the UOP is installed and nothing else is interfering with it.

And for the record, a similar thing was done in the USIP to correct the long distance pathing in the Shivering Isles. It would also need to be done for any major worldspace mods that need NPCs to be able to navigate over long distances, but in my experience only myself and a very small handful of other people even knew about all of this so most of them are probably lacking the necessary data.

#708
CarlosS4444

CarlosS4444

    Faithful poster

  • Supporter
  • PipPipPipPip
  • 1,996 posts
Hi Tiawar!

I'd like to ask whether you're familiar with NVAC - New Vegas Anti Crash https://www.nexusmod...egas/mods/53635 as it's a plugin for Oblivion as well?
Is it recommended to use it alongside EBF?

#709
Xz0mb13killaX

Xz0mb13killaX

    Enthusiast

  • Members
  • PipPip
  • 237 posts
In response to post #71960983.


Spoiler

I don't use it and oblivion almost never crashes for me.

but then again everyone's setup is different.

Edited by Xz0mb13killaX, 09 August 2019 - 01:15 AM.


#710
TheRomans

TheRomans

    Curmudgeon Deluxe

  • Premium Member
  • 2,324 posts
In response to post #71960983. #72410838 is also a reply to the same post.


Spoiler

One problem you may have with a crash preventer, is that sometimes they avoid the crash by ignoring some corrupted data, and then that data corruption gets stored in your save-line.




Page loaded in: 0.960 seconds