kryptopyr

Mator, I hope I didn't come across as offended by your comments. Not only do I have a vast amount of respect for your thoughts on this matter, but I happen to agree with you, at least in theory, on nearly everything you've stated. It's just that my experience in trying to work with other mod authors leaves me with very little expectation of seeing something like this get implemented within the current mod community. Despite my pessimism about the situation, I still think the discussion is one that is certainly worth having (though maybe we should move it to a new thread?). So, that being said, here we go... There's a huge difference in Mod Configuration Menus and the quest interface you're proposing. MCMs provide a direct benefit to the mod and mod author. They're sleek, they're easy for users, and they're relatively simple to set up. There is no real reliance on or need to cooperate with other mods (beyond SkyUI). And SkyUI is one of the only mods massive enough to be able to set this sort of standard all on it's own. Setting up a quest interface for other mods to tie into provides a much more indirect benefit. If no other mods use the system, then the mod implementing it doesn't gain anything, even indirectly. The mod author still has to do the work, but any benefit they receive is dependent on other mods using the system and hooking into the their mod. Trying to convince the majority of mod authors to implement special features within their mods when they may not even directly benefit from that effort is likely to be a losing battle. I strongly believe that this is something the Unofficial patches should implement. If you could convince the UP team to use this method, then I think the weight of USKP could well drive others to follow their approach. There are few (if any) other mods that could carry enough weight to do this, so barring that you'd need to convince the authors of at least a dozen (imo) of the largest mods to cooperate. Honestly, I see think this is about as likely as throwing a dozen cats into a swimming pool and expecting them to cooperate with one another in order to get themselves out. Many modders are fairly cooperative, to a point, but they are also strongly opinionated and tend to prefer tried and true methods over new approaches...at least until someone else paves the way and proves the theory sound, and even then it can be a hard sell. I agree with you 100%, but I was talking about using Quest.GetQuest for current existing mods (not theoretical mods that include interface quests specifically designed for communicating with other mods). Using Quest.GetQuest for current mods would just be grabbing arbitrary information. If the quest isn't designed specifically for mod compatibility, then the author could decide to change the quest just as easily as randomly deciding to change the mod's name. And they would probably be even more likely do so, given that this isn't a standard way for existing mods to communicate with one another. I don't think there are many modders who would really think twice about altering the name of a quest within their mod or aliases within that quest, and it wouldn't occur to many that the change could possibly create compatibility headaches for a mod using the Quest.GetQuest function. I wasn't even aware of this function myself until very recently. I think we may be talking about two different things here. What I meant by 'breaking' a plugin patch is that if an author changes a record or formID then that will impact any esp patch that is referencing that record just as much as it would affect a mod using scripted compatibility via Game.GetFormFromFile. Changing the record or FormID would break either form of compatibility in this case. However, many users (and even modders) aren't generally in the habit of opening up the scripts within a mod and looking through them for this sort of potential conflict (and there's no way to easily cross-reference the scripts with the forms they're referencing to check for changes or conflicts). Compare that to the growing number that are at least marginally comfortable with looking for problems and conflicts in TES5Edit, and it becomes much easier to identify and fix problems in plugin patches than it is in mods that use scripted compatibility. I'm not arguing against the value of TES5Edit scripts for creating certain mods or improving compatibility among mods. Honestly, I think TES5Edit scripts are fantastic, and I wish I was more familiar with creating them (I'm slowly working on addressing that problem, thanks to you). However, even seeing what amazing things you're capable of doing with scripts, I still can't imagine creating most of my most using automated scripts. WAF and probably CCF could almost certain have been created much more efficiently using scripts, but the others? It just depends on what the mod is trying to accomplish. I definitely recognize that automated scripts are massively more efficient at what they do than manual edits could ever be. But the more exceptions you have to deal with, and the more complex those exceptions are, the more quickly you start to eat away at that gain in efficiency. I certainly did not intend it to be an insult, for you or anyone else. I was simply trying to point out that despite the less-than-ideal compatibility methods that many modders currently use, those methods still tend to mostly function as intended, because they are generally seen and treated as standards within the community, even if they do happen to be flawed, delicate, or otherwise imperfect. It isn't an ideal system, and I agree that the perceived standards are constantly changing. However, even the most widely used community standards can't be considered truly universal. Modders use the tools they're familiar with and the ones they feel work best for them within the setting of their own knowledge and their interaction with the broader community. The ideal system, as you pointed out, would be a truly concrete and explicit standard that nearly everyone would be familiar with and would use. Such a system would greatly benefit the entire community. But I believe the only realistic way to establish that sort of universal, unquestionable standard is to have it established by Bethesda. Even SkyUI and it's MCM are not universally used by all mod authors and mod users. That statement isn't at all intended to denigrate your work or lessen your accomplishments, and I'm definitely not suggesting that we should only be using "official" standards. My intention was quite the opposite. Yes. Yes. And yes. I agree with all of this. I'm not telling them what to do; I'm not even arguing with them about it or suggesting to them that they change it. I haven't made a single complaint to them concerning this; I only asked after their reasons. As you correctly point out, it's their choice to make. I have merely expressed my reasons for disagreeing with their decision, that doesn't mean that I don't fully respect their right to make that decision. I've also stated that I'm engaging in this discussion more for the sake of the debate then because I feel strongly about this. I also agree that filenames are not designed specifically with the intention of creating an interface, but both patch files and scripts use them in that way. This is fairly common practice, so regardless of whether it's a good standard for compatibility, the reality exists that file names are used in this way. I'm not disagreeing with you that we could design much better, more effective compatibility standards. But we can't simply ignore the widespread use of the current existing standards just because theoretically there are better options. Well, I'm already pretty happy. Honestly. I'm truly thrilled that they're moving to a unified patch, and there's not an ounce of sarcasm in that statement. But, yes, I think your two-click solution does sound nice. I don't think it's all that many. I think Arthmoor had some number that he gave last year(?) when they first proposed the idea of merging the unofficial patches. Of course, I suspect that number only takes into account mods that are directly dependent and not the ones that are using scripts for silent compatibility. But even if you include the scripted mods, it's a fairly small number. Good, me too. I'm enjoying the discussion, and I think the issue of compatibility standards is definitely a conversation worth having. I apologize if I'm coming across as overly pessimistic or aggressive in my arguments. To some degree, I feel a bit like I'm taking up the role of devil's advocate here, not because I don't agree with what I've stated, but because I do recognize that some of the counter arguments are equally strong and just as valid. And as I stated before, I'm arguing most of these points much more strongly than I truly feel, since I do think the debate is an interesting one. I'm a big proponent of better mod communication. In fact, it's something I feel rather strongly about, and it's an area where I feel the community as a whole would benefit greatly from even relatively small improvements in the current standards. But I've chased this rabbit before. Cross mod compatibility is something I've spent a lot of time on and have actually invested countless hours sending private messages to some of the major mod authors to try to establish a framework for a more efficient system of cross mod communication. With several notable exceptions, I've been met with either unshakable skepticism or simple disinterest. For some authors, I think they just don't see enough direct personal gain to be worth the effort. They are happy with their mods as things currently stand and feel that compatibility patches and Game.GetFormFromFile are perfectly sufficient to address any issues between mods. Other authors are skeptical about any new approach to compatibility, regardless of whether or not it could directly benefit them. This group would probably be willing to adapt if a new standard were established. The problem is convincing enough major authors to take the first step and implement the new approach in order to build up the recognition needed to convince the rest. So, yeah, if I seem somewhat pessimistic about this idea, it's because I feel I've been quietly fighting that battle for several years and making very little progress. I'm not against your idea of interface quests. Actually, I think it's brilliant. If you'll help me figure out the best way to implement an interface quest in some of my mods, then I'll be happy to do so. I just don't know how to get other modders to adopt it. I can contact the authors who have been receptive to my ideas of cooperation in the past and see if they'll consider using it as well, but I still believe that we'd need other major mod authors to sign on before this would get much notice. I believe it's a worthy goal though.

They could still release the legendary patch on a new page. Just because it's given a flashy new page with big bold letters about the requirements, doesn't mean it would have to have a new file name.

Well, I have updates planned for a number of mods, but I haven't had time lately to work on them. I'll probably prioritize updates for the mods that won't be affected by USLP and wait for the others until after USLP comes out.

One could argue that any updated file is a new file. I see this as more of an update to the USKP to include support for the DLCs than as a completely new file. If the edits themselves or the FormIDs were changing, then I definitely agree and would feel that it should be treated as a new file with a new name. But given that the majority of the thousands of edits and non-DLC records shared between USLEEP and USKP will be identical, I think it should be treated as an update rather than a brand new file. I'm just don't see where the confusion would come from. A quick glance at the metadata or the file's masters would determine which version you were dealing with. Almost every mod that I know of that has started out as individual files then gone on to release legendary version, has kept its original name. The ones that don't are generally more of a pain to deal with because anyone who is creating compatibility patches has to decides whether to update and/or support two different versions. In many cases, existing compatibility patches remain valid and functional if the mod doesn't change it's name. Though, again, if there is a huge restructuring or change to the record edits or FormIDs within the file, then it should probably change names since that restructuring will likely invalidate any patches regardless. But it isn't necessarily a different beast with regards to a specific mod. Take a house mod that alters Proudspire and has been forced to use USKP as a master only because of the single cookpot record that it adds. Chances are that one record will remain identical between USLEEP and USKP. If the file name wasn't changed, then that house mod would still function perfectly regardless of whether a player is using the older USKP or the newer legendary version. However, by changing the name, the author of that house mod now has the following options: 1) do nothing and allow their mod to become outdated and unusable for the growing majority of players 2) change the mod to support the new file name and drop support for the non-legendary version 3) update the mod for the legendary version and then continue supporting two versions of their file instead of one Obviously if that mod author is no longer around, then #1 is going to happen by default. Some mod authors will choose #2 for simplicity and to ease their own work load. Others will try to support both versions because there are still people who don't have all DLCs and, quite frankly, because there is nothing about their house mod that requires the DLCs other than the Unofficial patch. I think that forcing mod authors to update their mods and to indirectly make their mods dependent on all three DLC, when the mod wouldn't otherwise need to be dependent on any of the DLCs is simply the wrong choice. Referring back to the comments on community standards and unspoken contracts, I feel like this decision could be seen as a breach of that assumed contract. ----------------------- Also, just to be clear, I don't think for a second that this is going to be a devastating compatibility disaster for the community. As a mod author, I see it as a minor annoyance more than anything. There will be a handful of mods that this have some issues due to this since their authors aren't around anymore, and a probably several dozen others that will be affected and will simply adapt to the new file. The convenience of having a unified unofficial patch more than makes up for any small headaches created by it's implementation. If I seem to be arguing the point more strongly than seems warranted, it's mainly because I'm finding this discussion of compatibility and community standards to be rather interesting and enjoyable.

Good to know. I haven't looked at this mod, but I like to keep track of mods that use injected records. Do you know if these are records are all intentional? @Mator I don't really disagree with anything you said, and I like some of the ideas you propose. However, I think that an ideal framework for modding is not going to be achievable. It'd be great if the entire community could be convinced to follow a specific format and use your idea of Interface quests or something similar, but I can't see it ever happening unless Bethesda actually builds in some system for inter-mod communication so that there is a concrete, indisputable standard. Anything else is always going to rely on the same sort of "unspoken, unagreed contract between mods that could be broken at any time" that currently exists. Using Quest.GetQuest() as things currently stand would involve just as many assumptions as Game.GetFormFromFile. And in fact most modding practices are based on similar assumed standards, not just scripted compatibility. Equipment slots are one example. There's simply an expectation that mod authors will follow the community standard when assigning equipment slots. Likewise, it's standard for mods to use aliases when possible instead of directly editing the player actor, change vendor leveled lists instead of directly adding items to a merchant container, include any relevant bash tags, etc. I've designed a communication framework based on injected records, which when used correctly can be a wonderful way for mods to communicate. But it has it's downsides as well, and also relies on a vague agreement between mod authors to use the records as intended and for other mod authors to avoid using identical FormIDs. All of these modding practices are nothing more than unofficial standards used by mod authors. And sometimes what seem to be fairly concrete conventions end up getting broken or overturned. Before the UP team chose to defy it, there was an assumed standard that all mods should be loaded after the official DLCs, and mod managers were designed based on that standard. And before MO came along, the assumption was that loose files would always take priority over those packaged in a bsa. At one time, many modders would have said those were fairly explicit practices, but they turned out to be no more than assumptions based around old standards. Plugin patches that directly edit mod records are just as easy to 'break' as scripted compatibility (the breaks are just easier to identify and correct in TES5Edit). Automated scripts aren't going to solve compatibility because they're still based off of assumptions. True, they allow modders to extend their intentions to other mods, which can be an awesome tool, but the script still has to make assumptions on the way the various mod authors have set up their mods. If a mod doesn't use vanilla keywords in the standard fashion or replaces certain vanilla perks with new ones, then somehow the script needs to recognize that mod as an exception and adjust accordingly. And as soon as a user has to start making exceptions for specific mods, then your compatibility process isn't nearly as automated as you'd like it to be. Many mod authors do follow the unspoken contracts as they currently exist, because it does help the community as a whole deal with compatibility issues, but there are plenty of mods that break with these conventions either because their authors weren't aware of the standard, because they didn't care, or because they thought that their way was better. There is very little in modding that is truly concrete or explicit, other than what is made necessary by the structure of the official files. The modding community being what it is, I just don't see any way to realistically strengthen this system without some officially-defined structure for mod communication and compatibility.

This is my intended solution, at least where I already have USKP support in my mods. Since the FormIDs will remain the same, it should be fairly simple to copy the existing script and change the name it's looking for (then add and adjust for any forms from the DLC patches). From what I just read, I think GetQuest() would work in place of Game.GetFormFromFile or Game.GetModByName, so that's certainly something worth keeping in mind. Thank you for making me aware of it. Of course not all mods include new quests, but many do, even if it's just to add an MCM. It's important for users to know the mods they're using, which can be rather difficult since scripts aren't the easiest thing to check. There are a lot of mods using Game.GetFormFromFile or Game.GetModByName to identify other mods and add compatibility features. This is why if using Frostfall or Wet & Cold, you never wanted to merge Cloaks and Winter is Coming. Sure, you'd save yourself 2 plugin slots, but at the same time it broke compatibility with two other major mods. Generally, any scripted mod that I download, I usually look for scripts named something like "maintenance," "player" or "playeralias," or "compatibility" and specifically look for mod detection/interaction within those scripts. But there is certainly no guarantee that the mod author will follow this sort of naming convention or that they won't be checking for external FormIds elsewhere in their mod. I think, even with Mator's amazing script, that users should not be attempting to merge every mod in their load order. Mator's script may well be a game-changer, but merging large complex mods, particularly those that are still in active development, just doesn't sound like a wise idea to me. It will be wonderful if the Merge Plugins script can merge the mods' scripts as necessary to allow this sort of merge, but I still think I'd reserve that sort of merge to specific situations and not try to simply blanket merge all scripted mods together.

What method do you suggest?

I believe that error message was there even with the previous version of SkyUI, so this is not anything new.

Arthmoor's response: This confirms that the formIDs will remain the same for the records from USKP, so that should make the process of converting the scripts from mods like mine fairly simple. Unfortunately, his response is rather vague about what type of problems they're concerned about in making the decision to rename the file, which is the point I was most curious about. If I had to guess, I'd say this re-designation is being done to simplify support and reduce the number of dumb user errors, which is certainly understandable from the perspective of the USKP team. However, I still would have preferred to see compatibility for older mods and increased flexibility for mod authors take priority over idiot users who can't be bothered to read the mod requirements. Regardless of the form it takes, I'm still happy that they're finally moving to a unified patch.

I posted on Arthmoor's original announcement page asking about this decision and pointing out the compatibility problems it would create. My comment has received no response.

Well that only works if the plugin is using USKP as a direct master. What about mods like many of mine that check for USKP using scripts, then adjust things accordingly? Determining which mods are checking for USKP in scripts is going to be a lot trickier and a bit difficult to fix. And this is assuming the FormIds are still the same between USKP and USLP, which isn't a guarantee.

I'm very happy to hear this, but I wonder why they chose to rename the file. There are mods that use the Unofficial Patch as a master, sometimes just to carry over one or two edits. These mods will all need to be updated now, and if the authors aren't still around to do that, this decision will kill those mods. Keeping the name of the main file (and the FormIDs) the same would have allowed those mods to remain functional, and it would provide at least some potential for users to pick between using the legendary and separate versions (depending on the mod in question and what it's changing obviously). I check for the presence of USKP in several of my mods via scripts. Many of these mods would not have needed to be updated if they had instead merged the DLC patches into the main USKP file instead of renaming the file.

If you do try those fix mods and one of them seems to work, please report back. It would be nice to know whether there really is a decent fix available for this problem.

You can safely ignore this conflict, or you can drag the EDID record from Complete Crafting Overhaul to the STEP Patch in order to make it consistent with the other files. There won't be any effect on your game either way.

It's been reported and confirmed: https://www.afkmods.com/index.php?/tracdown/issue/11971-quick-reflexes-slow-time-effect-becomes-permanent/ I guess maybe it's a tricky one to fix.

It was actually reported on the USKP page, and it was marked as 'couldn't reproduce.' However, the problem seemed pretty apparent to me when I tested it. Maybe Navida1 could be persuaded to edit the Orc, Khajiit, and Argonian helmets so they would also fit a bit better. Well, at least let me know if anyone foresees any problems that might be created by including this in WAF.

Agreed. A quick way to set up a NavCut collision marker is to just copy one from a vanilla cell, then place it where needed and resize. Hearthfire uses a ton of these markers (which is where I first discovered them). The starting chests/workbenches located at the HF building sites make for an easy reference.

Do the esp changes from Glass Helmet Fix work okay with skysan4298's meshes? I would expect the meshes & textures from that mod to simply overwrite the Glass Helmet Fix meshes, but I'm curious whether the plugin fixes cause any issues. I contacted Bugsbugme and have received permission to include his changes in Weapons & Armor Fixes. Ideally, I think I'd like to have the improved meshes set up as an option in the installer, but the changes to the armor addon records would be part of the main file. The ear clipping fix is something that applies to both the vanilla and the improved meshes, so it seems like a valid change to include in WAF, but I'd like to be aware of any potential conflicts this might create.

Yep, I realized a few minutes after posting that I'm not using the original mod, but actually using Glass Helmet Fix (then, of course, my internet connection died and I couldn't get my post updated right away). :P I created a new thread for discussing Glass Helmet Fix here: https://forum.step-project.com/topic/8460-glass-helmet-fix-by-bugsbugme/

https://www.nexusmods.com/skyrim/mods/37169/? I feel that this mod vastly improves the appearance of the glass helmet, particularly on male characters. On males you can actually see through the helmet on either side of the characters head. The fit for the female helmets isn't nearly as bad, and from what I can tell, this mod only slightly narrows the top of the female helmet. This mod is actually a combination of the meshes from Better Fitting Glass Helmet by Abakus and some esp changes that fix an issue with elven ears clipping through the side of the helmet. The ear clipping issue is present with both the vanilla meshes and the "better fitting" meshes, so this mod's fixes are valid even if the altered meshes aren't used. Here are some comparisons. The files are named in a way which should hopefully make it clear which are vanilla and which are from this mod. https://drive.google...aEE&usp=sharing

Thanks; I guess I'll have to check out Copy.

I was doing some unrelated testing and was looking at what mods I had that altered armor meshes. This is one of the mods I've had installed for a long time. I'm not sure if it's been forgotten, but I figured I'd give it a bump and include a few screenshots I took for comparison. I feel that this mod vastly improves the appearance of the glass helmet, particularly on male characters. On males you can actually see through the helmet on either side of the characters head. The fit for the female helmets isn't nearly as bad, and from what I can tell, this mod only slightly narrows the top of the female helmet. To address torminater's concern about the beast races, they use different meshes which (unfortunately) aren't altered by this mod. Here are my comparisons. I apologize for just linking to the folder, but for some reason when I tried to insert individual image links, they were showing up as broken. The files are named in a way which should hopefully make it clear which are vanilla and which are from this mod. https://drive.google.com/folderview?id=0B1P5VcgL895-fnFTS1dfSGRabk5YYmhxR0F5Qnc3VW5BN0lBdGJlLS1yX2JsSi0yd3RNaEE&usp=sharing Edit: Just realized that I'm not using the original mod, but instead using Glass Helmet Fix: https://www.nexusmods.com/skyrim/mods/37169/? I created a new thread for discussing Glass Helmet Fix here: https://forum.step-project.com/topic/8460-glass-helmet-fix-by-bugsbugme/ I think the only difference between them is that Glass Helmet Fix includes an esp that changes the armor addon record so that the elven ears don't clip (an issue present in the vanilla meshes as well as the "better fitting" meshes). The screenshots I took are still valid for Better Fitting Glass Helmet, with the exception of the side shots. These would show the tip of the ear clipping through the helmet (similar to the vanilla shot) if it weren't for the addition of the Glass Helmet Fix edits.

Just a heads up... WAF and CCO will have some minor inconsistencies when used with SkyUI 5. These are inconsistencies more than conflicts and won't have much, if any, impact on functionality, but I figured it's worth mentioning. Basically, SkyUI's "material" column doesn't directly correspond to the vanilla crafting categories, so the changes made in WAF/CCO to help better categorize items within the vanilla menu will result in some items appearing as "Other" or "Misc" instead of what you'd normally expect their material type or crafting category to be. I don't think there's a good way to fix this from my end, so I'd just recommend leaving the Material column disabled (which is the default setting). Everything else that I've tested works just fine.

Thanks for the run-down on these. I'll try to get an update made soon after the next unofficial patches are released.

The "Elven" version seems much more neutral to me, and without any specific ties to the Dwemer, that would be my choice for STEP. Also, while it's only an interpretation of lore and not something directly stated (as far as I know), I feel that given Meridia's hatred for "false life," she probably would not have approved of the Dwarven automatons or the use of captured souls to animate them.