TechAngel85

Reference to Zilv: https://www.afkmods.com/index.php?/topic/4110-manual-cleaning-skyrim-and-skyrim-se-master-files/&do=findComment&comment=164020 Several posts later is where this discussion started took to take off on AKF Mods: https://www.afkmods.com/index.php?/topic/4110-manual-cleaning-skyrim-and-skyrim-se-master-files/&do=findComment&comment=166166 I believe the comment from Arthmoor is on the post following where he states: "The most obvious benefit is that if someone is not using the unofficial patch, Dawnguard has dirty edits that break house upgrades for Hearthfire. Failing to run the ITM removal will result in people complaining they can't buy Breezehome upgrades and that the steward is stealing their money. So there's no truth to the claim that ITMs in official DLC are harmless."The important part here is: "...if someone is not using the unofficial patch...". Assuming this is fixed with the patch and not fixed without it, but cleaning will fix it. However, we never recommend running a modding game without the UPs installed. So does that point even matter?...maybe not for us, but for a broader scope?Mator follows up and the conversation can be read on your own. Try to ignore any tones of hostility or passion...both? Such a fine line...

See edits to post above.

Link to citation? Why only if using USSEP? Reference? Same...why if only using USSEP? https://wiki.step-project.com/Guide:STEP_Community_Citizenship#Terms_of_Service It is expected that any information added to The Wiki or The Forums is clearly cited, where applicable, as many users do not appreciate unverifiable speculation, unless it is plainly stated as such. That is to say, feel free to write what might or might not be factual, but qualify what is intended to be factual with verifiable information by posting a link where appropriate. However, we want to facilitate community contributions, so we encourage all users to get involved.When citing any user, please include a link to the citation. When citing from our forums, it's recommend to use the "Quote" button at the bottom of the post.​​ I accidently removed those points with my recent edits, but I put it back and up top since it applies to both wiki and forums. It's always been expected when discussing topics like this to post references to your citations, especially important when quoting users. I'm sure you can understand why. I also gave the bullet the same update I gave the rest of the Guide the other day. EDIT: One of Mator's posts. EDIT #2: Another point that should be noted is that console users are not likely to have "cleaned" vanilla files. This seems roll off one of the point Mator makes of authoring without cleaning the files. However, later on he does say, "The chance of that harm is extremely low and requires you to be a mod author creating plugin files." in reference to the only known harm that can come from cleaning the files. So basically what Mator is saying is that for 100% of users cleaning the masters is nothing but a placebo. However, there is a remote chance a mod author could cause a CTD within a specific set of circumstances. Is it possible to cause a problem? Yes.Is it likely? No.That seemed pointless...seems we're mainly back to the question of benefit vs risk. Mator (yet, another user to the count) says no benefit to cleaning.Mator's reference is the only one so far to any potential negative effects to cleaning.Still no references to actual issues as a result from not cleaning.

So I've had a separate discussion and it seems, at least some of this, stems from xEdit's mishandling and errors during the cleaning process that have been fixed since (fixes possibly still in beta versions). These are a few of the reports: https://github.com/TES5Edit/TES5Edit/issues/803https://github.com/TES5Edit/TES5Edit/issues/823https://github.com/TES5Edit/TES5Edit/issues/853https://github.com/TES5Edit/TES5Edit/issues/855Then there is also the argument that the vanilla files work whether they're cleaned or not. Personally, I'm not aware of any negative effects that would result if the vanilla masters are left uncleaned. I conferred with Arthmoor on this and he said the same of not being aware of any issues. He went on to say, "the game seems perfectly content to play with uncleaned masters" (note this is solely in regards to using uncleaned masters and not to mods). I haven't came up with any additional references, either for or against, but this is enough to start a proper discussion... In regards to xEdit's handling of the vanilla masters... One point to note is that, like any tool, there are bound to be bugs. The devs fix such bugs when reported, however, this brings up one "big question", which is the unknown. How many such bugs exist that are simply unknown? The reported bugs very clearly bring up the question of how well is the cleaning of the vanilla masters tested. A missing worldspace is a large thing to miss! However, I understand that testing is a HUGE task and there is no way to cover everything. With what information we have now, the real question is... Is the risk worth the benefits? Consider that we've already stated...several have stated this now...that we don't really know of any benefits nor negative effects to cleaning or not cleaning the masters. Note that this could apply to any game after Oblivion, however, since STEP only offers Skyrim-based Guides, all this is in regards to only Skyrim Special Edition and Skyrim Legendary Edition.

First I'm hearing of anyone claiming this too. If it's not made it into any of the tools (like xEdit and LOOT), then I would take it with a "grain of salt". Such a discussion needs references.

No problem! Here's the next: 1. This is true, but Wabbajack would basically do away with the entire Guide, according to my understanding...or the majority of it. If ever explored, it would be an option; never a replacement for the Guides. 2. Hmm...I feel we're reaching a bit. Lets narrow our focus on what the automation tools are providing, rather than looking at them so broadly. BethINI handles INIs. It still allows users full customization of these settings too. BethINI's scope ≠Wabbajack's scope. In fact, they're built for different purposes so not a 1:1 compare.DynDOLOD...yes, it's also automation. There is no other way of doing what this program does unless you built your own program. But again, DynDOLOD ≠Wabbajack. Not a 1:1 compare.Mod managers...same thing. Although, these two would be the closest to a fair comparison as they're both for mod installations.These tools may be automation to some extent but you're applying your concept far too broadly, imo. STEP would have to look at these tools far more narrowly when considering them. So it's only inconsistent when you're put everything under the very broad banner of "automation" without narrowing down to what these tools are actually doing and providing. 3 & 4 & 7. I decided not to address these because we're just going back and forth rather than having a forward discussion. It serves no benefit to the topic to discuss these points given the responses. As to my responses, they are formed from years of running STEP. 5. Your view is not wrong and I can see your point, but perhaps you can see my point? Loss of experience is loss of information. Let me put it this way... One can not gain wisdom without experience nor experience without doing. Automating takes away some of the "doing", therefore not has much experience is gained, which means less wisdom to narrow down issues when they arise. Not there yet? Real world...It's the same thing when your car breaks down. If you have the knowledge and experience, you can fix it yourself (and save a lot of money). Else, you have to take it to a shop and let someone else fix it for you. Now turn that into automation...If you have the knowledge and experience, you can fix whatever is wrong "under the hood" of that automation tool yourself, instead of running to a discord/forum to have someone give you your solution.I'm not against some automation, but someone has to know what's going on under the hood. 6. I don't think anyone would deny that time is gained from automation. However, information lost from experience isn't an acceptable trade-off...for me. For others, it would most definitely be the other way around. I'm the type of person that gets more from the journey than the destination. RE: Guide Support... It "could" be, but the drop in support isn't from the addition of these tools and that is a fact. Considering who you're discussing with, this statement implies that we don't know our own project. We've ran this site for years and released numerous Guides in that time. The only way for anyone not involved in STEP to know how we've reduced our support is to do an in-depth analysis of generated support related to Guide releases over the period of time which STEP has operated. I'll assume you haven't done this because doing so would be crazy...unless you're into that sort of thing. I will say your thought is not a bad one, it's simply not correct. We've refined the Guide little by little over time, and little by little support has reduced. DynDOLOD has been a part of the Guides for a good chunk of this time. BethINI was more recently introduced with the SE Guide, however, there was been no obvious change in support regarding INIs because there was little to none to begin with. Same thing with xLODGen, it was introduced with SE (with the last couple releases actually). Therefore, the evidence, in regards to STEP, doesn't support your thought of it being partly automation that has reduced our support. In fact, those tools created a hell of a lot of additional support requests when they were introduced vs when we didn't have them...though some of that is to be expected because of their newness to the users. So, did these tools cause a reduction in support? From my first-hand experience, no. They simply added another point of possible user error. Part of the reduce, I will freely admit is due to less users using the Guides. However, from where we used to be...we now have a really good workflow with the SE Guide, better instructions, and patches that are user-oriented. All these have attributed to reduced support and we're aiming to improve workflow even more with our updated wiki framework. With all that is said and done where does the "burden of proof" lie? I would say it's on the users wanting, supporting, and requesting automation. You would not? Burden of proofs always lies with the initiating party. So if you or someone want take the STEP Guide, produce a Wabbajack for it, and then present STEP with a "show and tell", go for it! Be prepared to answer plenty of questions. We'll specifically have to know: Do you, honestly, believe it would be simple to maintain within a structured released project? ...meaning it would have to updated for every single change and release to the Guides. Is this simple enough to not be a burden on maintenance? (Obviously, only STEP can answer these for STEP, but I want to hear your opinion.)What would be our ideal maintenance overhead for something automated like Wabbajack? Basically...let us get the mod list set up in MO because we're doing that anyway as part of the Guide releases. Once it's set and done, click a button and a file is exported that we can upload. That is simple and involves a process that we're doing already (aka doesn't really add any extra maintenance overhead).

I've gone through updating and organizing this Guide a bit. There is still a lot of work that needs to be done to make it a proper reference for users, but it's already much better organized.

Yes, I've seen. I've just not sure it should stay in STEP as my elks have been very...bright, I noticed.

Actually, he's right. Most users will add more mods on top of the STEP Guides. Didn't read as imposing, but an opinion, as have all of your statements. I don't recall a single staff member reporting to actually using STEPupper. It was an idea and experiment by airbreather for an automated version of STEP that he maintained on his own with permission. I, personally, didn't see it as a viable option has it added a lot of maintenance overhead. He upkept it for a time, but didn't last long. I want to say it had some limitations. There has never been a good viable option for automation for STEP. Lets reign this topic in and keep it to an actual discussion. No personal attacks.No mistruding of posted contented.Post clearly so that your meaning/tone of your post is understood.If you're posting an opinion, keep in mind it's an opinion. Your opinion. Others may or not may agree. Discuss, don't argue.

I happen to agree with that. From my personally experience, automation tends to make many users lazier. When I say "lazier", I mean it in the context of "lost information". Everyone is all "automation, automation, automation". Yeah, it makes life easier but, in my experience, the moment the user encounters something the automation "chokes on", is the moment they are up utterly lost. Why? Because they lack the experience and knowledge gained from, what I will just call, "traditional modding". Nexus is already packed full of users that are too "green" to know these things. What are they going to turn to to learn? Automation is the easy path but teaches you little. However, diving into guides and learning the tools will equip those users to handle issues in the future. There is no replacement for this learning and it's for these reason I'm, personally, not a fan of automation. Lost knowledge and a dumbing of the people. That's automation from my perspective...9/10 are going to choose the easier route too...that's just human nature. It's also this "loss of knowledge" (or lack of willingness to learn) from automation that creates more support than it prevents. That's coming from the perspective of helping to run these forums for years and years. Our actual support for the Guides is quite low. Most of the support on these forums go toward other subjects or are outside the scope of the Guides.

True or not true depending on several developmental factors... However, the point is we're not exploring Wabbajack at this time. We're focused on bringing our platform up to date. A big part of that is just software updates to our current software. However, with that comes required updates to many other things like skins, SWM, extensions, etc. This is our fault for not keeping them more up to date so we're not covering a rather large jump in versions. All this to say, our time is booked until STEP 3.0 releases. In the meantime, the Wabbajack devs already have our permission to put up the Guides. They came to us seeking permission so if they're not already up, you should probably be asking them why. So...I can't make this any clearer: We are not exploring Wabbajack at this time, however, the future is the future. I don't mean to insult your contributions or support. I freely admitted that I took some offense to this section of your post any will not apologize for my feelings, as they are my own. Though, I will apologize for any misinterpretation. To understand my perspective...no one really knows just how much time we put into STEP (and in my case mod authoring too). For me, when I'm at full swing, I put 20-40 hrs a week into this project. Adding to that, I got the tone of your post as "insinuation", rather than "inquiry" or "suggestion". "What's missing here is consideration of what the community/STEP users want." This particularly sounded like insinuation that we don't listen to our community when, in fact, we know very well the community wants an automated STEP install. It's nothing new...just new tools. Users have wanted this for years and years and our stance has never changed due to some specific issues around author rights, endorsements, etc. As new tools become available, they may be explored, but will likely never take a priority over our own platform, whatever that may be. You can imagine we're not eager to steer away from it any time soon after the Mod Picker trial and error, which wasted nearly 2 years of potential growth for STEP. However, continued discussion on this will be of no benefit. It's clear you didn't mean the post to read as such. I apologize, again, for the misinterpretation. I'm sure it would have been much more productive in person, as you mentioned. You may have offered to help, nothing specifically that I can recall, but if you weren't responded to or turned down it would have been that the help offered didn't match the help needed, at that time. That would be the only reason I can think of not accepting help. It should be obvious that we'd love more staff by the recent announcement. With that said, I'll expand a bit on this. STEP roles are sort of like positions within a company... 90% of users that offer help have no knowledge of wiki development or are fairly new to the STEP Community. These types of offers for help are the "front line workers" and will always be sent one of two paths: Become a Mod Tester; which only requires you have STEP installed to a profile without any added mods for testing. This role's only responsibility is to test mods being suggested by the community within a STEP setup and against the STEP Mandate. Once staff gain some experience within this role, then they can be considered for higher roles with more involvement. However once users see the work involved, 99% of them that take up this role end up MIA. It's not glamorous work, but it's work that ALL of the staff has done at some point because ALL staff beyond this role are expected to know how to mod test and be involved in that process. It's the foundation of what we do and even with automation, such work is necessary. Users than can't cut it in this role, will not be of much use in higher involved roles of the Project. Therefore, it can be considered our "proving ground" for new staff. Become a Moderator. This role's responsibility is to help moderate the forums and answer support questions. Users considered for this role usually have spent some time within our forum community and haven't had any negative behaviors. Therefore, they are members of the community who have show themselves mature and trustworthy enough to handle moderation tasks. Users of this role are required to be familiar with our Community Citizenship Guidelines, else they wouldn't be very effective moderators as they are entrusted to handle all types of forum moderation, including passing out Warnings when appropriate.All level of staff are encouraged to create and update wiki content. Only once users have been around for a while, gained some experience, shown responsibility, and shown interest in diving deeper into the Project will staff be promoted into "leadership" roles; Uber Moderator, STEP Staff, and Admin. These positions have higher-level access to the site, tools, and sensitive Project stuff. Therefore, it's obvious the members of these roles would be well respected and trusted members of our community because someone could wreak some havoc, if they desired. This is the same path I took to Admin. I started at the bottom, stuck around, made myself useful because I believed in what the Project was doing, and eventually landed where I am today. Also, we provide plenty opportunity to move up in roles. All staff has to do is ask. If they're not ready, we'll be honest, tell them that, and let them know what they can do to prepare for the role they want. Else, as any of them can attest to, we nag the staff from time to time about their current positions within the Project, whether they want to move up or down, etc. All are within the roles they have chosen for themselves.

Custom player homes aren't a part of the Guide, thus, are outside the scope of the Guide. One of the issues in the past is that we noted all this stuff that had nothing to do with the Guide, itself, but rather with users installing mods beyond those the Guide contains...and us putting this info into the guides/mod pages for those "just-in-case-you-do-this" scenarios. This is, by definition, "scope creep" and is something to avoid going forward. With the Beta Guides and v3.0 and beyond, the Guides are meant to be installed in their entirety and that's it. We'll not be covering anything that isn't within the Guide itself to keep the project scope maintained.

Mod Picker? You're a bit outdated in your information. I suggest a look through the more recent announcements. Meaning we're already maintaining and distributing the Guide via our wiki and doing so via Wabbajack would be redundant. This is borderline entitlement and rude...now I'm going to try to remember this isn't Nexus in my reply, but note that I have taken some offense to this. People do value their time...your own words, however, are you being considerate of our time? Are you missing the consideration that your asking a team of two to give up what little free time they have? We already spend most of that time on the site/Guide and what you're asking is that we now take more time, time away from our families or doing something other than modding, to maintain a second iteration of the Guide that we already give for free? Why? Seamingly for no other reason than it's easier and faster...translation...lazier. Huh? Yeah. It is...so? "Guide" is defined as: Something, such as a pamphlet, that offers basic information or instruction.Something that serves to direct or indicate.something that provides a person with guiding information.I didn't find any definition saying that a Guide is anything other than what we're already providing. What you're asking for is not a "guide". It's a handout. I don't think you know much about what STEP is, our philosophies, our methods, our history...our passion. That is very apparent with your statements here. Now that I addressed that, you missed something vital in your reading... There are no "we" or "us" in my that reply. Taking the post that I was replying to into context, it should be obvious that... Translation....we (STEP) aren't doing anything. The wabbajack devs will be putting it up...if and when they desire. They have permission.

Updated OP All the various notification templates have been replaced across the entire wiki with the new alert and alert small templates. Please use these going forward as the old ones have been removed. During this process, all of the broken templates were fixed; however, any problematic pages were simply removed...they obviously weren't being maintained. If anyone comes across this content and would like it restored, PM me with: a link to the pageyour reasoning for the restoration requestyour intentions regarding the content's maintenanceregardless of intent, the content could be restored and then archived, however, it's important to note that archived content could be moved in the future to a namespace that restricts editing.

I've updated this template slightly. After seeing its use on several pages it seems a lot of users (including myself) end up starting the content with a line break. Therefore, I've put this into the template itself. I think it looks nicer and now the content always sets away from the visual elements of the alert. I've also ensured the margins behave correctly; thus, users shouldn't require any line breaks before or after the template anymore...as it has nice 2em top and bottom margins. Several other small tweaks to get it to display more visually appealing, like slightly brighter font. MO Note template was also merged into this one. It's not the same style as the old MO Note template, but it's inclusion here allows it to be consistent with the other alert styles.

Discussion topic: Template:Alert Template:AlertSmall

Discussion topic: Icon Template

Updated OP.

Thanks! Good to know. Seems to be unused by the game, then...from what I can tell. In vanilla, it's only applied to some clothes, jewelry, and shields, and is referenced by the quest for Serana's curing. From what I can tell, it's been redacted in the script, and Greg's reported of her race changing to nord and not DLC1NordRace confirms that. It's not back-ported to any of the non-Dawnguard items in the base game. However, USSEP expands it by adding it to more Dawnguard items and...oddly...the wenches outfit. Most of kryptopyr's mods adds it to both non-Dawnguard and custom armors, clothing, jewelry, items, etc. If this is the case and it's really not used in the game, then the plugin is truly not needed as adding the race to items would serve no benefit/purpose. This finding really needs to be confirmed by more that me, though. It would be good to contact kryptopyr to get the reasoning for its addition in her mods, as well as, contacting Arthmoor or the USSEP team to get their feedback (and if confirmed, report that it should be removed from their mods). These are contacts I would have done, myself, as a project lead and a member of the STEP Staff role, however, I'm still trying to step back more from those roles. Anyone care to make these contacts and report back?

Haha! I'm the opposite. I never believe LOOT. Really, just check it in xEdit. The plugin adds DLC1NordRace to the vampire amulet, which USSEP does not. This allows any NPC using that race to wear the amulet (mod or vanilla NPC). In vanilla, research seems to reveal that this is the race used for Serena after... Plot Spoiler I did look into it a bit more in the CK, I can't tell if the race change actually happens or not. The script has the line commented out with a following comment that says "oops, can't do this on an NPC" . They may be switching the race another way, but that was the extent of my investigation. I can't get her race as I've not gotten to that point on any of my saves and forcing it may not have the same results.

Before we upgrade the wiki, we'll be performing some periodic cleaning and updating of pages, templates, etc. This includes several actions: Users may notice some changes to content, formatting of content, template styling, etc.Anything that is deemed no longer desired/needed will be deleted without notice.All "Pack" content will be removed.As such, users may notice things missing from their pages or old templates being converted to newer ones. Any of this is done due to the cleanup.Any missing user content will be the result of it being too much maintenance to fix things such as broken links, which fill out our maintenance reports. Such content obviously isn't being maintained and will simply be removed.Anything that is questionable will be added to the Candidates for deletion category.Users can check this category for any pages that we're considering removing.Please see the individual page's talk page for discussion regarding the content removal.Anything that is considered outdated, but is neither being considered for deletion or updating, will be added to the Archives category. Not all updates will be recorded below, but periodic updates will be posted from time to time. Updated STEP Content Anthology BoilerplateUpdated Templates ArchivedDeletealert (new)alert small (new)icon (new)Updated General Content All content has been assigned a category. All content on the wiki should receive a category when being created as this help maintain the content structure.Many missing links across the wiki have been removed or restored.Icon template has replaced the old "Ask", "No", and "Yes" templates across the wiki.Alert and alert small templates have replaced the old "Bug", "Construction", "MCM Note", "MO Note", "Notice", and "Warning" templates, as well as, their smaller counterparts. Alert small also has the "FO3 Note", "FNV Note", and "Loot Rule" templates merged into it. Removed Content Most of the the unused files have been removed. Users should remember when updating images on pages to upload a new version of the existing image rather than simply uploading a new image. Doing the latter creates a lot of abandoned files. Doing the former also retains a version history for the file.All of the active galleries from the Mod pages have been removed. The gallery option will be removed from the Mod Form for the platform update as it's been deemed redundant and unnecessary.

1. The Guide has system requirements that aren't much different from the game's recommended system requirements...so if a dust texture is slowing your system down, sorry, but you shouldn't be running the Guide. So no, this mod doesn't break the Mandate. 2. How the mod is packaged has no bearing whether or not it should be included in the Guide, unless it's packaged incorrectly, which it is not. If you have an alternative you'd like STEP to look into, feel free to suggest and post compares.

That's because the name of the mod was updated, thus, I updated it here. Check Nexus, it's "Cathedral Landscapes". Well, I'm not fixing things I've already fixed so if something has been undone, Z, you'll need to redo it...

Modding NMS is completely different than Bethesda games. Most your edits are to global files that are just glorified XML files. Conflicts are resolved by the last file that wins, so unless you're merging changes from conflicting files, you are not going to end up with the result you desire. Also, NMS updates fairly often so keeping mods up-to-date is a bit of a chore...as such, mods become obsolete fairly quickly unless their authors keep them updated. The other issue is the global file parameters are not 100% understood and what is understood of them isn't documented well (or at all). ...not to mention some major game update can have made some parameters obsolete without being cleaned up by the devs. It's a bit of a "wild west" in terms of modding NMS.

Your system is similar to mine and I have no issue running the SSE. You should be able to run an ENB, but I'd recommend sticking to a lightweight one.