Have a question about the changes from version 3.2.3 to 3.2.4, that I don't see in the readme. Or I missed in the thread.
3.2.4 includes 50+ NPC's that have the 'No Low Level Processing' flag added. Just want to make sure they were intended, before editing the custom UOP I use.

I'll look into it. The chest is probably set to respawn without regard to what was in it.



Yes, those are intentional. Forgot to make a notation about it in the readme. Those NPCs are all in places they never leave and so they don't need to be tracked unless you're there with them. It should help with AI related performance issues. Some of them were even dead NPCs that had packages.

Ah! Might that explain why I'm now seeing groups of NPCs standing in straight lines, unmoving, in various unnatural places, especially in the Market District, until I get near them?

If so, can we get a version that doesn't include that particular fix? (Or at least a list of the names so I can undo that change myself?)

Great work, BTW! I don't think we thank you nearly enough for picking up where Quarn and Kivan left off!

:tops:

That problem you describe has nothing to do with changing the AI flags on these NPCs. You probably just have too many mods in general affecting the AI system. None of the ones in the Market District should have been affected anyway since they tend to have packages taking them in and out of buildings and other districts. What I did would be for NPCs you literally never see anywhere but their house, or some guy in the jail. That sort of thing.

Okay, but drat - I thought I'd found the answer...

Thanks anyway!

I think this horse rider is tied to the 'Break the Siege of Kvatch' quest though.

Nope. The Gottshaw rider is not referenced at all by the vanilla game. He's simply disabled for some unknown reason. He has no scripts or AI that take him into Kvatch. Just a patrol route assigned, complete with markers. All he was missing was the AI pack to meet back up with his horse if he dismounted for some reason.

So if I were to use the UOP http://www.tesnexus.com/downloads/file.php?id=17621 and also the latest UOP Hotfix, can I replace the UOP.esp from the Hotfix with the UOP Non-MOBS version for FCOM and still get the latest change from the Hotfix?

I believe the latest hotfix is Non-MOBS already, so installing the hotfix should be what you need.

With the current hotfix, in order to get a MOBS setup I think you have to use Corepc's standalone MOBS files and import stats in Wrye Bash.

From the mobs thread on Frans UOP versus Hotfix UOP..Use Hotfix and Standalone Version import with bash..


Read above or read the mobs thread

So what your saying is, the only thing that frans edited other than the mobs stats in it's UOP version was leveledlists? Good to know, I only use frans and nothing else so this would be a problem for me but it is easily fixable with tes4edit

And perhaps a few creatures so check those has well..easiliy fixable with tes4edit once again..

Where can I find more detailed information regarding the (3,3) bug? I wanted to find out what the effects are and if it affects new worldspaces as well.

I see I'm late to the discussion, but care to elaborate on which scripts will be "imposed" by the UOP 3.2.4 if the Scripts tag is active? I've done a check in TESEdit with more than 260 mods (including merged ones) and I expected the UOP to override at least a few scripts; I was surprised to see it doesn't override anything.

For instance since I have the UOP tagged with Scripts, I thought it would override the chest script from your Arthmoors' http://www.tesnexus.com/downloads/file.php?id=21234, but even though it's only activated and not merged, mg19obsefix.esp wins the conflict and that script doesn't end up in the based patch. I'm officially confused.

BTW, I have Wrye Bash 277.

Do we need to define the Scripts tag on any well-known mod to avoid its scripts being overriden?

There aren't a great deal of scripts to be "imposed" into the bashed patch as it is anyway. With current Bash behavior it's more likely the lack of scrips on many things will cause that to override other mods that add scripts. that's why for now the advice is to tag OOO with Scripts as well, otherwise the UOP imposes a blank record over something OOO needs altered. PacificMorrowind is working on correcting this for 278 so tags will behave in a more logical manner.

I have no idea what this mg19obsefix.esp is you're talking about. So I'm officially more confused than you

Lol, sorry for being officially lazy and not posting a link. mg19obsefix.esp is the esp from http://www.tesnexus.com/downloads/file.php?id=21234. The UOP contains the same script and is tagged with Scripts, so shouldn't it win the conflict? If not, I'd like to be englightened as to why.

Ok. I got it now. The scripts tag is not what you think it is.

When an NPC or object has a script (the UOP ghost anim fix, OOO's harvest containers, etc) those are assigned on the relevant record. This assignment is what is being carried forward. The scripts themselves are not affected.

What you're looking at here with this mg19 fix is an actual script that has been modified. I'd have to double check, but this is something that would be covered under the Scriptcontents tag which the UOP does NOT have and won't be getting.

Scriptcontents should be used only in very specific circumstances or what you describe will end up happening. Scripts in early loading mods overriding those in late loading mods. Since tags are not selective, ANY edited vanilla scripts will be brought forward, not just a specific one. If you're only looking to pull one specific script forward out of several in a mod, you need to make a patch for it.

Also for anyone looking at this MG19 fix, it won't be added to the UOP since it requires OBSE.

So to recap, assuming the UOP is the only one with the Scripts tag and there is a mod XYZ that loads later: if the UOP assigns uberScript to apples, and mod XYZ assigns powerScript to apples, apples will end up with uberScript. However if they both assign uberScript to apples, apples will end up with XYZ's version of uberScript, i.e. the Scripts tag won't have done anything.

Did I get it now ?

Thanks for clearing up the confusion. BTW I think the Wrye Bash docs would benefit from an edited copy-paste of what you explained.

Not quite. apples would still get UOP's version of uberScript, because the tag only cares about the assignment in the UOP. You need to tag XYZ as well in order to guarantee it's versions of the assignments get pulled forward.

Not being familiar with the items this user reported in the UOP entry at Nexus, does anyone have a comment? Would this be something that should be reverted in a future update? Personally I'm all for having opportunities to steal stuff as a thief, especially if it's meant to give me a free house upgrade.

It also explains why that poor guy is rotting in jail for no apparent reason

The distinction between assignment and modification is who gives it first? For instance, in the two apples examples I gave above, whether Oblivion.esm assigns the same script or assigns nothing to apples would make a difference?

Ok. Let me see if I can explain this more clearly.

Mod A makes a new script.
Mod A assigns this script to an NPC.

Mod B makes a new script.
Mod B assigns it's script to the same NPC used in Mod A.

Now you have a conflict.

Without Bash, the assignment made by Mod B wins and you lose whatever Mod A wanted done. But you want the script assignment from Mod A to win.

The solution then is to tag Mod A with "Scripts". This will tell Bash to pick up the script assignment from Mod A and use it instead of the one Mod B wants. ONLY the script assignment will be carried forward though. Any other changes made to this NPC by Mod A are still lost and get overridden by Mod B. But other tags exist to take care of other cases.

The source code of either script is entirely irrelevant. It's also not important who actually defines the two scripts. All this tag is concerned with is what the NPC has assigned to it (or the object). This is best illustrated if you're using Frans and you tag the "Francesco's Optional New Creatures Add-On.esm" file with "Scripts".

This particular tag is only really important when the NPC or object comes out of Oblivion.esm and more than one mod wants to make changes. You're less likely to need tags if Mod A and B are working on their own NPCs they created.

I agree those items sound like something that should be reverted. Thanks!

:tops:

Nobody else has any thoughts on the receipts?

UOP History of fixes for them..



I think they where removed just for that reason..free house upgrades..

I personally do not mind free house upgrade is nice after all, has you get frostcrag for free,

but you have to upgrade it furnishing has well that cost money. So vanilla should cost has well ..if you did not have to play for house upgrade then where else would you spend you hard earned money once again..

Corepc