fireundubh

9. Jump off a cliff. Would you?

There's nothing special about bashed patches. They're just normal plugins named "Bashed Patch, #.esp." Wrye Bash generates "bashed patches" with direction from you, so in effect, Wrye Bash is merely an interface for creating a customizable plugin. If you want to merge potentially hundreds of leveled lists on your own, go right ahead.If you want to make the tweaks that Wrye Bash gives you easy access to on your own, go right ahead.If you want to figure out which plugins can be merged without problems and merge them on your own, go right ahead.There's nothing wrong with not using Wrye Bash to create a bashed patch, but if you're not creating some sort of patch to merge leveled lists, your load order is probably not going to work right. Like everything else, leveled lists (read: loot tables) are just records and each successive plugin that modifies those records overrides its predecessor. Without merging all of the leveled lists that should be merged, you'll see only the last overriding leveled lists take effect in the game. That said, Wrye Bash does take direction from you, so... If your bashed patch is overriding item names, that's your fault for checking "Import Names."If your bashed patch is overriding stats, that's also your fault for checking "Import Stats."Most people should have no use for importing names and stats. Leave those options unchecked. Why? There's no such thing as "importing" names and stats. Names and stats are parts of the records that hold them. When you tell Wrye Bash to import names and/or stats, you're telling Wrye Bash to copy entire records into the bashed patch and then modify their names and/or stats. How does Wrye Bash decide which records to copy? I could test and find out, but based on your experience and my own past experience, I'd guess that Wrye Bash decides which records to copy by either a) choosing the winning overrides (i.e., the last copy of the record in your load order that matters) or b) choosing the master records (i.e., the first copy of the record in your load order that should be overridden.) We don't want either of these things to happen. If we use only the winning overrides, then, for example, the bashed patch will copy stats from a mod that was designed for vanilla Skyrim, instead of copying the stats from Weapons & Armor Fixes Remade, because that mod is farther down your load order. If we use only master records, then, for example, the bashed patch will copy names from the first copy of each record in your load order into the last plugin in your load order, effectively reverting any name changes that happened in between. Wrye Bash isn't smart about the way names and stats are "imported." In fact, since a bashed patch is a plugin that loads last, when you import names and stats into that plugin, you're creating a plugin that overrides every single record that was copied. In effect, you're "resolving conflicts" by using brute force to eliminate them. Actual conflict resolution, however, isn't about eliminating conflicts; it's about making conflicts work the way you want them. Wrye Bash's "import" features don't do that.

It's depressing that this settings tweak has received more endorsements in 6 days than my most complex mod has received since October 2013. Maybe I should just release settings tweaks...

I looked at this earlier. There's considerable variation in the quality of the meshes and textures.

Try waiting 30 days.

Oh, I see. Report that to Azirok.

No, Azirok did resolve them by deferring to Requiem. Not all WAF Remade changes should be carried over. Many should be overridden with records that defer to Requiem to maintain Requiem's balance. The key thing is that WAF Remade's keywords are carried over. There's nothing left for you to do when Azirok makes a patch except ensure that his patch isn't itself overridden in a bad way.

It doesn't matter as long as Azirok's patch comes after WAF Remade and Requiem. Azirok has already done the work of resolving the conflicts for you, so I'm not sure why this is an issue.

You don't need to create a patch if Azirok's patches are sorted after Requiem. Also, you can edit LOOT's metadata. I didn't say "never edit the metadata." Just remember that you did. By the way, if you use TES5Edit to clean unnecessary masters, you're just removing one extra thing that LOOT uses to sort plugins. With my patches, I generally add masters that aren't necessary to make this easy for LOOT, but really, the right way is to edit the metadata when you absolutely need to force a certain order.

I'm going to tear out the current detection system, add a Thunderchild-like "energy bar," implement an MCM menu, and add an option to configure a disguise key. So, detection will work like this: While the disguised player is within a detecting NPC's cone of vision, the energy bar will drain at some rate.The rate at which the energy bar drains will be determined by the player's best skill level in Sneak or Illusion.When the energy bar is depleted, the player's disguise will be blown.The maximum amount of cover energy will be determined by all of the factors that we have now, so some disguises will have less maximum cover energy than others.Before the energy bar is depleted, the player can press the disguise key to replenish the energy bar.The amount of replenishment will be determined by the player's best skill level in Sneak or Illusion.Cover energy will regenerate over time while the player is disguised, unseen, and not in combat.The rate of energy regeneration will also be determined by the player's best skill level in Sneak or Illusion.Finally, the cone of vision for the purpose of detection will be narrowed to 45 degrees. There will be no grading of the cone of vision. Energy drain will always happen at the same rate. Distance and angle won't be factors anymore.edit: I thought you could create health bars now, but I guess Thunderchild coopts the stamina bar.

It is my understanding that changes made by WAF Remade and Clothing & Clutter Fixes are already integrated into the CCOR patch, but Azirok may have been saying that you still need the masters. If you want to be on the safe side, just install WAF Remade, Clothing & Clutter Fixes, CCOR, and Azirok's patches for each.

The only way I can imagine that happening is if you didn't tick the "Tweak Settings" checkbox. Or some weird Python error that isn't presenting itself. In any case: You can create records in TES5Edit by right-clicking the file, selecting Add, and choosing the appropriate record group type. In this case, choose GMST. Then, right-click the newly created Game Setting group, select Add, and choose GMST again. Click OK when prompted for a New Form ID. Right-click the EDID cell and select Edit. Input the name of the game setting you want to configure. Right-click the Int cell and select Edit. Input the integer value that you want assigned to the game setting. You can also single click, or slowly double click, cells to use inline editing. Repeat steps 2 through 5 for each game setting you want to add.

I don't really understand your setup (or your post, honestly), so I'll suggest some general things to try: If you're using MO, search your mods folder for any bashed patches and delete them. Also, delete the bashed patch from the overwrite folder.If you're not using MO, delete the bashed patch wherever that may be.Download and install the latest Wrye Bash.Re-create the bashed patch.Verify that Tweak Settings is checked.Verify that "AI: Max Active Actors" and "Combat: Max Actors" are checked.Verify that you've customized the settings for both tweaks. I have them set to 100 and 40, respectively. They shouldn't be equal and combat should be less than max active.If you're loading a save, ensure that you reset the cells you've already loaded. Find a cell you haven't entered and then wait for 10 days or 30 days or whatever you've set the cell respawn time to in Requiem. Wait an extra day to be certain. Then leave the cell and go test.

Per the wiki, "Use All causes the list to always return all of its contents." In English, that means that when the game looks at the leveled list to add an item, the game will add all of the items on the list to the game world. This flag is exclusive, so the calculate flags will be ignored if Use All is checked.

As for how leveled lists work, well, there are three kinds of leveled list: LVLI (Items), LVLN (Actors), and LVLS (Spells). They all work the same way. A leveled list is a table. LVLI is a loot table, for example. The game makes a dice roll and one or all of the items in that table are added to the game world. In TES5Edit, you can see that their structure looks like this: LVLD - Chance NoneLVLF - FlagsLVLG - GlobalLLCT - CountLeveled List Entries Leveled List Entry LVLO - Base Data Level Reference CountHere's what these elements mean: [*]LVLD is the chance that none of the references will be selected when the game looks at the leveled list to add an item to the game world. 0 = 100% chance that an item will be selected. [*]LVLF are flags that determine how the game uses the list. The wiki links define the available flags. [*]LVLG is an alternative to LVLD. You can use a Global (GLOB) record to set the chance. You can manipulate globals with scripts. [*]LLCT is just the number of leveled list entries. You can ignore this. [*]Leveled List Entries is the parent group of entries. [*]Leveled List Entry is the child item. [*]LVLO describes the entry. [*]Level is the player's level and it is treated differently depending on the list's flags. [*]Reference is the item, actor, or spell that will be added to the game world when the entry is selected. [*]Count is the number of items, actors, or spells that will be added to the game world when the entry is selected. Leveled Lists don't exist in a vacuum, however. They have to be assigned to something, like an actor. The following screenshot is of part of a warlock record. The "Items" group defines the items that will be added to the warlock when the warlock spawns in the game world. When the warlock spawns, the game will: look at the LItemWarlockDagger list and add one (or all, if the list is flagged so) of the daggers on that list to the warlock; look at the LItemStaffChainLightning50 list and add one or all of the staves to the warlock; and then look at the LootWarlockRandom list and add one or all of those items to the warlock.That's how leveled lists distribute items, or actors, or spells in the game world.

The easiest thing you can do is to create a bashed patch with merged leveled lists, use my script in TES5Edit to delevel the lists, and install Mfg Console. In the game, when you come across an item that doesn't belong, use the Mfg Console to identify the Form ID of that item. Then quit the game and load your entire load order in TES5Edit (you can hold the Shift key when you click the OK button to not load strings and speed up the load.) Go to that Form ID in TES5Edit to identify the mod whose un-Requiem-ified item is being distributed by the merged leveled list. If the Form ID links you to a plugin early in your load order, check if there's a "Referenced By" tab at the bottom of TES5Edit. If there is one, go to that tab to see all of the overrides. Check each overriding record in each plugin for the matching stats. If there isn't a "Referenced By" tab, you've already identified the right plugin. Once you identify the offending plugin, consider uninstalling that mod. Or, find the offending record in TES5Edit and single click (or twice slowly) the Record Flags cell in the appropriate column. Check NotPlayable and InitiallyDisabled. That will disable the item from appearing in the game, despite being included in the merged leveled list. This is the simplest option. Or, remove that item from all of the merged leveled lists in which that item appears. Without a script to automate this process, this option sucks. Or, create a Requiem patch for that mod. This option requires some knowledge of how to balance items for Requiem.

I'm telling you that the Wrye Bash tweaks are NOT the problem. A bashed patch is indistinguishable from every other plugin. It is just an ESP named "Bashed Patch, #" that is ordered last. That is all. It doesn't behave any differently from any other plugin. The exact GMST records added by Wrye Bash to the bashed patch plugin function identically to the GMST records in that mod you linked. It is IMPOSSIBLE for those GMST tweaks to do anything else.

I like helping with TES5Edit, but I only see TES5Edit questions when I happen to read a thread in which those discussions are taking place (e.g., Requiem Pack.) Can we get a "TES5Edit Support" forum and direct everyone with TES5Edit questions to post threads there?

1. None of the options available to you when generating a bashed patch can modify item stats. 2. More likely, you have mods installed whose items are distributed via leveled lists and those items are not patched for Requiem, so when you merge leveled lists, you finally get to see those items. When you delevel the merged leveled lists in the bashed patch, you just see them earlier. 3. If you don't want to see those items, uninstall those mods. After all, other leveled lists are taking precedence. There's no point in keeping mods whose content you don't want and will never see. 4. That mod you linked does the exact same tweak that Wrye Bash does, so your problem is #2, not the tweak in Wrye Bash. You can get rid of that plugin. If you just want to change one cell, you can click and drag the cell with the value you want to the cell with the value you want to change. What you did was copy the entire record with the name you wanted and now that record takes precedence. Sometimes you want to do that. Others times you just want to carry specific changes over.

If you put out a BSA filled with optimized textures from Dawnguard, someone else can put out a mod that uses those optimized Dawnguard textures. That mod wouldn't, or shouldn't, be banned if your mod wasn't banned. Therefore, your mods would work without the DLC because you're actually distributing DLC content that doesn't require any plugins. You'd be effectively distributing DLC content as "modder resources" disguised as optimized textures. First of all, redoing a EULA is easy to do when you have an army of lawyers already on your payroll. Not that I agree with your reading of the EULA. Second, your definitions don't matter. Bethesda's definitions are the only definitions that matter here.

If Bethesda doesn't officially care about sharing unmodified DLC content sans plugins, there's no reason for Nexus or other sites to care. And to what extent is modified content truly modified? Texture optimization aims to reduce file sizes without sacrificing fidelity. But what if you remove one byte from the file? Does that mean the texture is "modified" and therefore distributable? What if you change the file date? That changes the file header. Does that count as "modified"? If the end result is the same texture, and not original content, then distributing that texture infringes on Bethesda's copyright unless Bethesda provides modders with a license (i.e., explicit permission) to do so. That Nexus doesn't really apply its rules in any sort of consistent way is unsurprising, but Bethesda still needs to lay their rules out in more detail. It would be great if Gstaff came back and said that all of the content in the BSAs was distributable.

Which is not true. You don't need the DLC plugins for DLC content to work in the game as long as you have that content and a mod that adds that content to the game.

He doesn't say anything about giving away DLC content for free, which is what was being discussed. If Bethesda allows DLC textures to be passed around freely, what's stopping anyone from uploading the DLC BSAs unmodified? If we could do that, a lot of mods would need only DLC assets and not have to require DLC plugins as masters. I asked Gstaff, the global community manager at Bethesda, for the official word on whether modders can distribute optimized textures, higher-poly meshes, or even complete BSAs from the DLC.

I was a very competent QA engineer in the game industry on console and handheld titles. Everyone I knew who discovered a problem could identify that problem, trace their steps, figure out what went wrong, and make recommendations to the developers about how to fix that problem. They understood how software works, how a game was put together, and why you get certain feedback from a program when the user performs certain actions. They weren't all amazing, but even when they couldn't reproduce an issue that only I could, they knew to not make any leaps of logic and keep trying. I'd hate to be technical support because you're not just dealing with people who make bad assumptions, you're dealing with people who don't make basic assumptions, like maybe electronics that are plugged into power outlets need power to operate and perhaps you shouldn't call technical support during a blackout... My expectations of most people who use mods or make them are too high. I know that but I can't bring them down. All I can do then is either let all of that negative energy from frustration consume me or look away. I'm choosing to look away now, especially where the Nexus is concerned. I'll still help around this forum where I can though.

Ugh... "Polling causes save bloat. Don't use polling.""Dynamically attaching scripts causes CTDs. Tell modders to rewrite their scripts.""Bashed patches do bad things that bashed patches cannot possibly do. Avoid bashed patches.""Mods that have scripts degrade the game's performance. Don't download mods that have scripts.""TES5Edit corrupts plugins. Avoid cleaning your mods.""I upgraded to a new version of some mod and now the mod doesn't work. What? Troubleshoot? Nobody else had to troubleshoot! Don't even try identifying the problem.""Papyrus errors are harmless. Ignore any errors you see in the log.""LOOT sorts my mods in a way that I'm not used to seeing. Don't use LOOT."I just... I don't even... I'm going to focus on my mods from now on.