exploiteddna

same here.. idk, ill update this thread if i figure something out

Several problems, all relating to the Load Order tab in Vortex Which version of Vortex are you on? 1.3.8 What game are you trying to mod with Vortex?Witcher 3 How many mods do you have installed?So far, only 5 ("Merged mod" from script merger, Community-Base patch, and 3 separate mods for HD-Reworked) What environment are you running Vortex on?Windows 10 Pro x64 (v2004; Build 19041.508) 2. Be precise and concise in your report Total of 5 "mods", all of them installed outside of Vortex because that's the recommended protocol for these mods. These include:"Merged mod" from script mergerCommunity-Base patchHD-Reworked-1HD-Reworked-2HD-Reworked-3 When I open Vortex and go to the "Load Order" tab, 1 and 2 are locked in their positions, like they should be. But the three HD-Reworked mods, part 1, 2 and 3 are in load order positions #4, #3 and #5, respectively. Two problems..problem 1: sometimes when you right-click a mod entry and input a priority value, wehn you apply/submit the change, nothing happens... the chosen index is not applied to the mod you're trying to change priority.problem 2: I'm trying to change the priority of HD-Reworked-2, so I right-click the mod >> "Set Manual Priority", but the dialogue that pops up says "Insert new numerical priority for HD-Reworked-1" even though I clicked on HD-Reworked-2. So there's no way to change the priority of #2 because I'm unable to get a dialogue box for #2.. doesn't matter if I r-click on #1 or #2.. the priority dialogue for #1 will pop up for both of them. Same thing happens with another external mod. So, I found a workaround by packaging each of the HD-Reworked mods into a non-compressed 7z archive and installed them through vortex so theyre no longer external mods, and now vortex seems to be playing nice with them, allowing me to change their priority appropriately... and im not going to reinstall them externally just for the sake of getting a screenshot.. just trust what i said in my description above, that should be sufficient As this is an ongoing effort, I no longer have only the 5 mods listed above. I have added a few more external mods. To demonstrate problem 2, I will use the current state of my modded game.(Rant/Unrelated to the topic of this thread: im in the process of trying to reinstall all of my mods because I reinstalled vortex earlier today just as a means of completely clearing the slate, starting fresh bc of other issues I was having ... deployment would fail every time, no matter what.. also could not purge mods.. so i said screw it and started over from scratch.. and thats what led me here.. to finding these other issues during my clean reinstall of mods) So anyways, the same problem #2 I had when only HD-Reworked/Patch/Merged were installed showed up again after I found the workaround for problem #1. So to demonstrate problem #2, I've got some screenshots for you, showing how I am unable to change priority because the UI is not registering the correct mod that I'm clicking on. See below 3. Provide helpful screenshots and/or log files Here are some screenshots demonstrating this problem: Right-Click modFirearms_ShopAddon Mouse cursor hover over "Set Manual Priority" before i select it After selecting "Set Manual Priority" the dialogue that appears is asking me to enter priority for different mod, modFirearms .. not modFirearms_ShopAddon (cant see my cursor in screenshots but you can trust I clicked on the correct mod based on where the dialogue/context menu popped up) Unfortunately i dont have screenshots of the first problem because Ive moved on from that (see workaround above) One last point, as a workaround, I have tried to manually edit mods.settings, changing the priority that is set in there. However, this does not work. As soon as you launch Vortex, it changes the mods.settings file and your changes are not implemented. I've even tried setting the file to "read-only" but Vortex was still able to modify the file and put the priority back to whatever random number it desires. Not sure if I'm forgetting any useful information but I'll update the thread if/when I do

Id donate in a heartbeat and im pretty sure many of us would. I think we'd be amazed at how much money we could raise in just a short period of time. Money talks, and with large sums of cash at stake, we humans tend to make time, find time, figure out a way, come hell or high water, to get things done. The caveat is, from what I've read, the 2 primary devs are unable to accept money because of their real-life jobs, which apparently restricts them from monetary gain for work done using company tools/assets/etc. At least, this is the way I understand it.

:wallbash:

le sigh.. i forgot all about SSE for the past 5 months.. intentionally... so i wouldn't drive myself crazy.. thought I would come check on the progress, but now I'm sorry I did. We'll just have to be more patient. Hopefully they find the time/motivation to complete the project..

always make sure you use the 'Sort Masters' function when you start adding new masters to the plugin header.. you want to try to keep them in the order of the accepted load order. This becomes an issue when, for example, you make a patch that requires dragonborn as a master. So your header only has Skyrim.esm and DB.esm in the header. Then next week you go back and add another override that requires dawnguard. you then add DG to the master list, but it is out of order.. the header would read: 1. skyrim.esm 2. dragonborn.esm 3. dawnguard.esm you should then right click and select 'sort masters' from the context menu. This function can go a long ways to preventing these types of issues.. not always, but much of the time. Good luck

In response to post #42645035. ive been able to uncook parts of it, but not the whole thing.. the uncook process always fails in the middle of the process

I agree with what Reneer said, you don't really want to edit the vanilla scripts.. especially as a beginner. In fact, I'd say editing vanilla scripts should be strictly off limits unless you are very seasoned at both scripting and modding, you have a really good reason, and you're unable to accomplish your goal by using a separate script (or doing so would be overly complicated).

i agree with the point youre making here

yeah I had this exact thought. I know theyre trying to be helpful or whatever, but, to a certain degree, we dont need their help. I don't need or want the 'convenience' of installing a mod from within the game. Modding has always been about control for me. Sure, for those who want to click it and forget it, thats fine I guess. But I want to look at the package, I want to inspect the plugin(s), I want to know what all is included and what's being installed. These are things you have to know if you want to effectively manage mod/record conflicts, optional features, etc. This reminds me of steam workshop, which I loathe. Hope this new platform remains optional and does not interfere with those of us who dont need or want their integrated platform and/or help managing mods

the most comprehensive guide out there, in my opinion, is the FNVEdit training manual (google it, i think u can DL from FNV nexus) that was released for the fallout new vega version of xEdit. It's important to learn what plugins are (*.esm and *.esp files), how they are generally structured, they types of records, subrecords, values, variables, etc. that can be found and where. It's important to learn how plugins interact with each other, why does load order matter, what happens when two plugins modify the same record (how does the game see this information at run time, etc), learn the various types of conflicts, learn about conflict resolution, what is a bashed patch, what is a merged patch.. the list goes on. All of this stuff stays the same for every bethesda game. There are some differences in the *types* of certain things, but the main ingredients are all there and the underlying themes and concepts are unchanged. With respect to checking for bad mods, there a re a lot of things to look for, much of which is sorta intangible.. the 'youll know it when you see it' type of stuff. record conflicts are not inherently bad. many times a conflict is nothing more than a preference; you just have to choose which change you want. If two separate mods edit the same thing, you cant use both. If two mods edit different parts (think subrecords) of the same thing (records), you can often patch them together by keeping the edited part from each one. Other times it isn't that simple. Common errors are UDR and ITM; 'undelete and disable reference' is about object references that were deleted from the game. You can run a check using xEdit that will scan for this type of 'error' and will undelete the records, instead 'disabling' them (essentially removing a 'deleted' flag and replacing it with a 'initially disabled' flag -- why and how arent important right now). The other one, ITM, is 'identical to master'. this means that a record in your plugin contains an exact copy of a record in the vanilla plugin, and thus redundantly carrying vanilla data lower into the load order, which can cause problems in multiple ways depending on the situation. Anyways, a check can be run for both of these common "errors". Other common mistakes are bad record references (i.e. a record with references that point to formids that no longer exist -- basically the plugin is looking for some information that used to be present but was altered or removed and is not able to be found) All of these are just examples, and may not make a lot of sense to you at this point. After doing your homework and reading up on all of it, it should start to all make sense. when it does, you're on your way to having a level of plugin understanding that is required to be able to find problems. you have to know how everything is supposed to work normally before you can try to find what it looks like when its broken. the more time you spend looking at plugins, spending hours upon hours staring at records and making patches and writing your own mods, etc., the more natural it will become and the better you will be at finding errors, mistakes, or even just opportunities to improve the efficiency of the plugin. The creation kit wiki (which i believe was originally written for skyrim ck, but dont quote me on that) is also a decent source of info, iirc. you may look into that. Either way, the simple answer is that there is no simple answer. The more you undertsand, the better you are at reading through a plugin and understanding its structure, the better youll be able to find the erroneous things youre looking for. The way that modding currently stands now, I personally would be initially hesitant of any mod that adds new items into the gameworld (placed objects). These records will be found under the CELL and WORLDSPACE branches. It can be done, but imo its not something I am comfortable with doing. Any mod that is very complex, adds new systems, overhauls, etc. I would be cautious of. For now, until you get a better understanding of plugins, just open up the plugin of iterest, and take a look. expand the branches, compare its records to the vanilla version (mod version of the record will be in the right hand column, the default FO4 version of the record will be in the left column.. side by side comparison). This will allow you to see what going on. You may not understand all you are looking at. But some of it is self explanatory. If youre in the branch titles 'WEAPONS", youre probably looking at the part that specifies information about the weapons. Look at each record, see what was changed. Read it. You may see something and be like "oh wow why did this value get changed??? what does that have to do with this mod?? this mod is to increase settler limit, so why is there edits to the hunting rifle damage???" stuff like that is very common sense. And believe me, you will see stuff like this. I cant tell you how many times ive come across something and had those exact thoughts, like "wth is this and why on earth was this even changed??" Read, do homework, learn as much as you can about mod plugins (FNVEdit training manual and CK wiki), investigate the mods you use, and use your common sense. Thats the best I can give you. Good luck

Its great that its not difficult for you. But you are not everyone. Some people, the average users, have no idea. The average user does not load their plugins into xedit and check for errors, itms, and udrs. Hell, even experienced modders may not know exactly how the fo4 records are structured yet. These things take time (never mind the fact that some of the records, subrecords, properties have yet to be decoded). For example, I myself havent spent a whole lot of time piecing together the new record types..Looking at the weapons record, see what type of seubrecords it is supposed to contain, how are the weapon mods assigned, where are their records located, what keywords are used to specify x, y, or z .. so on and so forth. For me, knowing the TES plugins like the back of my hand helps of course, but there are still quite a few differences in the mechanics and composition and it takes time to learn the structure and interconnectedness of the fallout4 master. But my response above is not about what I can or can't do ... it is about what the average user should be aware of when using current plugin mods. Asking the average user to do things that require the skillset of advanced users and experienced authors is unrealistic. They arent going to open the plugins, and even if they did, would have no idea what they are looking for.

the problem with xEdit at this point is not (for the most part) xEdit itself.. it's the fact that modders are having to manually piece together their mods. Adding new objects into the game, making sense of a lot of new records, subrecords, how each of them interconnect and reference one another, ... a lot of this is made soooo much easier when you have the CK in front of you. So, the primary concern should focus on whether or not the mod author has done their homework, dotted their i's and crossed their t's to make sure that they have considered every implication of the records they have tweaked/created, or taken on a project that is generally considered to be too complex for xEdit. Yes, CK is not needed for many most (some would argue it's not needed at all, beyond providing reference to decode the master plugin -- and from a simplistic view I would agree).. BUT, there are many mods that *should* be made, at least in part, using the CK, because doing it with xEdit is entirely too cumbersome and complex. Then add in the fact that we still are learning all the different components of this new game, new records types, etc.. that makes it *even more* complex. So it's not xEdit that i am necessarily concerned about (even though there is a *very* slight inherent risk in using the program).. it's the authors and the projects they decide to undertake that should be scrutinized. You can classify mods into two main groups: Certain types of mods are well-suited for the CK, whereas other mod types simply don't require CK; you wouldn't use CK even if it was available right now because it is much simpler to do it in xEdit. At this point in the game, it is the former that users should be concerned about. Those mods, more than the others, are at a greater risk of human error.

nowhere

there is no need to recompress into a new ba2 archive. that would be pointless and sort of reckless in my opinion. In my opinion, you should always keep your vanilla archives untouched. The only reason you extract the contents is to see what is in there, the data folders structure, and/or use some of the files as a base for what you are trying to do. Once you have tweaked files or new files that are the same name and structure, you need to place them into your game's data folder, in the correct structure. The correct structure is determined based on the archive. You can think of your Data folder as being the root for each of the archives. So, if you have an archive that contains only one folder, Textures (which contains more subfolders), then that means the Textures folder (and all that is contained within) will reside directly in the Data folder. If you don't quite understand this, then I would google for the answer, there are plenty of tutorials that explain this; it is the same for essentailly all of the bethesda games (elder scrolls, fallout series) As a final example, you you edit a file that is packaged in the ba2 like this: Sound\FX\WPN\Baton\WPN_Baton_EquipDown_01.wav then you edit that sound file and want to use it in the game, you need to place all of that path, including the top Sound folder and all of the directories contained in it, into your game Data folder (located at <PATH>\Steam\steamapps\common\Fallout 4\Data