#SKYRIM LE BASHED PATCH CODE IS BROKEN#
#SKYRIM LE BASHED PATCH PATCH SHOULD BE#

Skyrim Le Bashed Patch Patch Should Be

When I do this i get errors (Exception in unit xxx line xxx: xxxxxxxx Error: Could not be resolved ) while running DynDOLOD.exe. The Bashed Patch should be last in your load order, unless you have plugins that explicitly state that they must load last. The configuration dialog consists of a list of major sections to the left, and the contents of the selected section to the right, with the build and save buttons at the bottom.The Unofficial Skyrim Patch mods are bugfixing mods, with the goal of eventually fixing every bug within Skyrim and the DLCs.

If you set them up correctly, and aren't dying for plugin space there's no reason not to. I'll give you some links on how they're done. As for when.you do them after you're sure of your modlist and after you run LOOT and make any post LOOT positioning adjustments.Make sure both of these are the last things, merge then bash one after the other, in your order unless you have a CONCRETE reason for them not to be. That typically does not include phrases on a mod page like 'this should be at the bottom of your load order' even those go above the merge/bash. Unless the author -specifically- says as part of that phrase or another one that it needs to be under the Bashed Patch, like DynDOLOD.esp, then it doesn't and goes above.EDIT: Also, as Chef mentioned, there are apparently guides on steam if those videos are too slow. I suggest to put this mod under your bashed patch and manually patch yourself.

Do you have an array for loadorder.txt and separate array for plugins.txt for classic Skyrim? Do you use the same two separate arrays for Skyrim SE and the Star Load order?Just to reiterate this is not for Skyrim SE. When it can't do that then bad things will happen ( as shown here) as the FormID table isn't being properly managed.I can't provide Git bisect info because this only happens with the Star Load order system.I am wondering. When that happens Wrye bash or Skyrim SE can properly renumber the FormIDs based on the plugin's position in the load order. Which causes an unresolved reference in the Bashed Patch.When the FormID prefix is assigned properly then it matches the Master in the file.

If I load a Bashed Patch into SSEEdit it is assigned the wrong master index. When I open the Bashed Patch in TES5Edit it properly aligns with the record in Dawnguard.esm.When I make a Bashed Patch for Skyrim SE the records for Dawnguard are not assigned to the master. The Master index will be as follows.Obviously the Bashed Patch, 0.esp is not part of the header but the 02 indicates all the records native the the Bashed Patch only.You would have a layout like this if you have 15 plugins.So when it builds the Bashed Patch for Skyrim I can use a hex editor and I see that Wrye Bash added the FormID with a master index of 01.

Skyrim Le Bashed Patch Code Is Broken

Did you get that far yet? Because if you didn't just do that and stop asking me to explain it. Not sure.I'm trying to get you to just download the No Vampire Attacks In Towns.zip and use it with classic Skyrim. The procedure I am trying to get you to do so simple the explanation is probably what's holding you up. Well I was going to tell you but the code is broken.You mean the procedure you describe but the bug is in SE right ?Correct. If I open the Bashed Patch in a hex editor the number is.

Just uncheck all the patchers in classic Skyrim but Merge Patches like I show in the screen shot.I can't think of a more minimal reproducer then that.Then parse through it and when you come across places where it is adding the record to the Bash patch you will see that the FormIDs will end up as follows and it should be exact.For EDID: DLC1VQ00VampireAttackNodePM and the entry DLC1VQMinLevelVampireAttacks the FormID will be exactly 01019942 which is a GLOB record. It's one file with two records. And look at what happens rather then ask me.

Like how I try to show, but do a crappy job of it, in this screen shot.When I do this for Skyrim SE the FormID gets assigned a 02 from the entire load and doesn't seem to be assigned 01 from the Master Index of the Bashed Patch. When you finalize the Bashed Patch all the FormIDs have to convert from ('Dawnguard.esm', 0145E9) to 0145E9 where is the Master Index of the Bashed Patch, not all the loaded plugins. Those FormIDs are relative to the Bashed Patch.When using your Star Load order variables, somehow the FormID assigned is from what you are calling the entire load order or all the files loaded at that time which makes the FormID end up starting with 02 since Dawnguard.esm is at position 02 relative to all the loaded plugins.What it should be assigned is Dawnguard.esm relative to the Bashed Patch which since at the time the Bashed Patch adds the master is after 00 Skyrim.esm so Dawnguard becomes 01 Dawnguard.esm.If you add other masters, all the other masters get the next number like 02 Hearthfires.esm. For DLC1EclipseAttackNextChanceNight 010145E9 which is also a GLOB record. Those FormIDs are relative to the Bashed Patch.For EDID: DLC1VQ00VampireAttackNodeAM and the entry DLC1VQMinLevelVampireAttacks the FormID will be exactly 01019942 which is a GLOB record.

You were able to use the Long Fid conversion that already existed for Oblivion. ( Shown Here)Because I'm thinking the disconnection is that for Skyrim you properly assign the right FormID to the header of the Bashed Patch and the records because you see it in your mind and then made the code work for the load order much more clearly. The active mods are only the ones with the star as the first char just strip out the '*' again. ( Shown Here)Well for Skyrim SE and Fallout 4 do you use the same two variables? All the time? The entire load order is all of plugins.txt just strip out the star '*'. Use the same variables you use for Oblivion and/or classic Skyrim.For Oblivion/clasic Skyrim the loadorder.txt is the entire data folder and plugins.txt are the active mods.

The reason you shouldn't look into CTDA right now is because this works for classic Skyrim with the exact same file. There are no union deciders anywhere in all of the Python code, maybe one or two I might have had Valda add for me. You don't want to do anything stupid like (xNumber -1) or anything like that.CTDA may be broken may not. Then when you go through the code and ('Dawnguard.esm', 0145E9) comes up for Skyrim SE, the FormID gets a number higher then it should. By using the wrong array or by skipping something you feel you can skip since Fallout 4, you are not using the same array that you were using for classic Skyrim and loadorder.txt. Or at least that's what I am thinking.

Again maybe something I had Valda add and maybe in the FO3 or FNV code.This is done done everywhere in xEdit all the time. Nothing like that is ever done anywhere. If it's a FACT record then you need to set another variable to 0 and if the signature is NPC_ then it's an integer and set it to 5. When record.signature = 'GLOB' then the add that to the FormID table, if not then what type is it. Is there a FormID here, okay then take the FormID ('Dawnguard.esm', 0145E9) and get the type.

What has been assumed is it should never matter.Well it's just not a good idea to add an integer as a FormID or overlook a FormID when it's a float assuming it will be one or the other the majority of the time.The following mods had load errors and were skipped while building the patch. That can potentially assign as a FormID because the integer is set to 0 in the plugin. Even when it might be an integer in most cases.

Dragonborn.esm: Dragonborn.esm: Could not locate Strings File 'Dragonborn_ENGLISH.ILSTRINGS' Update.esm: Update.esm: Could not locate Strings File 'Update_ENGLISH.DLSTRINGS' Skyrim.esm: Skyrim.esm: Could not locate Strings File 'Skyrim_ENGLISH.DLSTRINGS' For more info, see Bashed Patch: Error Messages.