780 replies to this topic
Posted 07 May 2019 - 11:32 AM
Posted 09 May 2019 - 01:45 PM
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.
Posted 12 May 2019 - 09:05 AM
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.
Posted 12 May 2019 - 09:08 AM
In response to post #69964193.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.
Posted 25 June 2019 - 08:36 PM
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:
You need to approach Chorrol from the east for this bug to happen. Oh, and here is my LO:
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.
Posted 08 July 2019 - 11:06 PM
In response to post #68476181. #68696906, #68697931, #68777601, #68783466, #68786891, #68803231, #68963391, #68975216, #68992201, #69188706 are all replies on the same post.
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.
The UOP says the problem was fixed by adding a road.
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.