TechAngel85

The custom sources sounds like it would work for me. We already have separate pages for them...i think. If not, we will! libbsa.dll is in the folder. I did not have the "start in" folder set in MO. I will set it to the ModAnalyzer folder and rerun. Moderators works for me. I don't mind updating the analysis for mods that we use on the guide. Just adding me for now is okay, unless someone else from the staff wants to jump in here. I'm basically evaluating the platform by just using it how we would need to use it for the STEP Guide. So far, so good as long as certain things are accessible from the API like, mods from a list, mod options set on the mods from a lists, etc. Those are the type of things we'd need to pull into the Guide. Are you guys planning on supporting LOOT Meta Rules for setting plugin priority and "Load After" rules, or are you guys rolling that stuff into your own sorting solutions?

Yep. That's basically the direction I was having you head. That user just skipped ahead in my troubleshooting (or got to that point himself). I had to be a mesh or record fix, but I agree that this is something which should be fixed by the author of the mod. You should take a moment to report your findings on their Nexus page.

On our Nexus page: https://www.nexusmods.com/skyrim/mods/11/? Listed under "Optional Files" there are two versions. Install one.

Now this: Analyzing STEP Optimized Vanilla Textures - Performance Version 1.2-11-1-2.7z... Calculating MD5 Hash. STEP Vanilla Optimized Textures - ReadMe.txt STEP Vanilla Optimized Textures - Performance.bsa STEP Vanilla Optimized Textures - Performance.esp Extracting BSA at STEP Vanilla Optimized Textures - Performance.bsa... STEP Vanilla Optimized Textures - Performance.bsa extracted, analyzing entries... Getting assets from bsas\STEP Vanilla Optimized Textures - Performance.bsa... Could not load file or assembly 'libbsa.dll' or one of its dependencies. The specified module could not be found. at ModAnalyzer.Domain.AssetArchiveAnalyzer.GetBSAAssets(String bsaPath) at ModAnalyzer.Domain.AssetArchiveAnalyzer.GetAssetPaths(IArchiveEntry assetArchive) at ModAnalyzer.Domain.ModAnalyzerService.AnalyzeEntries() at ModAnalyzer.Domain.ModAnalyzerService.BackgroundWork(Object sender, DoWorkEventArgs e) Analysis failed.I was also thinking, we are basically used to maintaining the mod pages for STEP, if you think it something you would be okay with, you could just add me as a curator to all the mods in the STEP Guide. Some are old and will likely never be update, but then again some authors are turning for updating in preparation of getting their mods to SSE. Instead of me adding "Incomplete Analysis" tag to every mod that I find is incomplete or needs an update, I could just do it as that has always been a part of our process. Also, we'll need to mod pages on Mod Picker updated fairly regularly whenever the authors update the mods. It'll be a lot easier and less work for your staff if one or two STEP staff were able to take care of all that ourselves for the mods in the Guide. ...just some food for thought.

Thanks! I'll be adding those tags. There are already several incomplete analysis where mod options where skipped just from the Fixes section of STEP alone. Sweet! I'll download it now. I have the mods all listed besides the STEP mods, which I'll be adding soon now that the Analyzer will work. There will be an issue; however, because we're simply using our STEP Nexus page as a file resource. We'll need to list the "STEP Mod" twice in our Mod List because currently two different files are installed at different points in our Guide, both from the same Nexus page. That is not possible since you only allow a single listing for each mod. The only what around this is to use a Custom Mod for one of the entries. I've started working on the Mod Options for the list and aligning up the Plugins a bit. I'll basically just be following a LOOT sorted list on those for now to speed things along.

Not sure what this error is about with the Analyzer: Analyzing The Ruffled Feather v4.4-11-4-4.7z... Calculating MD5 Hash. Parsing FOMOD Options Found FOMOD Config at Fomod/ModuleConfig.xml FOMOD Config Extracted Object reference not set to an instance of an object. at ModAnalyzer.Domain.FomodFile..ctor(XmlNode node) at ModAnalyzer.Domain.FomodFile.FromNodes(XmlNodeList nodes) at ModAnalyzer.Domain.FomodPattern..ctor(XmlNode node) at ModAnalyzer.Domain.FomodPattern.FromDocument(XmlDocument doc) at ModAnalyzer.Domain.FomodConfig..ctor(String xmlPath) at ModAnalyzer.Domain.ModAnalyzerService.AnalyzeFomodArchive(IArchive archive) at ModAnalyzer.Domain.ModAnalyzerService.AnalyzeArchive(IArchive archive, ModOption modOption) at ModAnalyzer.Domain.ModAnalyzerService.BackgroundWork(Object sender, DoWorkEventArgs e) Analysis failed.FOMOD is good and validates. Mod is found on our Nexus page: https://www.nexusmods.com/skyrim/mods/11/?

Are you using MO? Nvm, this is SE. The only possible answers are: 1) a plugin is changing the mesh and/or texture paths for guard's clothing or 2) a mod is providing that texture. Load your entire load order up in xEdit. You can find the armors under the Armor tree. Use Skyrim.esm and sort by Editor ID or Name to find what you're looking for more quickly. The EditorID is the armor's name in the CK. The Name is its name while in-game. Make sure nothing is changing the MOD2 - Model Filename. That's the mesh the armor will use. If it's different from Skyrim.esm, then that plugin is changing the mesh. Just look for the armors that are affected to make sure there aren't any changes on the MOD2 and MO2S records. I think what you're looking for is "ArmorGuardCuirass*". If you open up the armor tree in Skyrim.esm and sort by EditorID, scroll down until you see "ArmorGuardCuirass...". There are the 8 different guard armors. All of them use the same model, but a different texture. Make sure there isn't a plugin changing the texture used.

So tools can't be added in the Tools section and in the Mods section? Any reason why? Some are both, like DynDOLOD (DynDOLOD Resources file). Also the sections aren't "talking" to each other. If I have SKSE in the Mods section, the Tools section is complaining that it's a missing requirement. It's not missing...it's just listed in the Mod section as a mod instead. I think STEP can work around this, but getting the sections sharing this information might be something to look into. Sorry for the random reports. I'm just chiming in whenever I noticed something. You're actually getting off easy. Usually when someone give be a new toy to play with the first thing I do is try to break it. Ganda can attest to that.

Thanks! I'm going to finish setting up the dev Guide mod list on it. After completing half the list, I think if STEP did use Mod Picker, this is where the separation of Core and Extended should happen. With this, I'll be able to test the cloning feature to separate the two guides. One the Core Guide, and one the Extended Guide. This has been our plan for a very long time, and I think this move warrants making the change now. Mod Picker could also support our idea of "Packs" since users can "clone" the lists. This works perfect for getting the STEP:Core base mods to quickly start building a "Pack" on top of. This would mean STEP 3.0, folks! However, I still think the real solution is a mashup of both Mod Picker and STEP Wiki platforms, and the result be generated on a page on the STEP website; this being the "STEP Guide". Do you think something like that is possible and viable? Basically, we'd be maintaining two mod lists on Mod Picker and submitting our mod testing results to the mod pages there where and when appropriate. We would still maintain our own mod pages on the wiki to house information specific to our project. Then, perhaps feed information from both sources into a generated web page through a CMS? We will likely be using a CMS to make a web front for STEP. Z seems to like Drupal. I haven't used Drupal in years and only have real experience with WordPress, but I think for this project Drupal would be the best choice since it's more secure and already has a more robust dev environment. S4N might have another idea.

Nope, just an idea. Looks like Nexus could use an update to their API to include some extra information. Nevermind. It's a rep points thing again.

So I found the WATER mod page that I'm the co-author of and I see no way to edit the page. I am going to say that answer was, "no". It does not automatically add co-authors as curators or as co-authors to the mod pages on Mod Picker. That is not a bad idea. If a user just needs to get the mod up, they can do so without much fuss. This would still create some re-work from either staff, authors, or curators so that is the trade-off. Glad you shared that. I was looking for more information on what a "curator" was. The first time I encountered it was on the mod submission page so I was looking for information about it there. Didn't find it in text, nor in the videos (outdated?) I also tried to follow those instruction to become a curator to WATER, but the button to submit a request didn't do anything. Still an unfinished feature?

He may had been planning on putting it all into one installer. Nexus users tend to be naggy when you do that because they have to download a bigger file. Hmm... Does it recognize users listed as co-authors? I'm no longer an "author" of a single mod on Skyrim Nexus (am on SSE Nexus) due to my mod being absorbed into the original mod. I am, however, listed as the co-author of several mods on Nexus (8 to be exact), one of which I'm actually the only active author of. Mod Picker Mod Submission After only submitting a couple mods to Mod Picker I would have to say that, overall, proper mod submission on Mod Picker is easy and mostly effortless but in some circumstances can take significantly longer vs the STEP Wiki. This is mainly due to the mod analysis. When you get a mod like Farmhouse Chimneys which has options for mods users do not use (in this case 9 additional mods), a proper mod submission to Mod Picker requires users to download all additional mods. In this case with Farmhouse Chimneys, I had to download and install 12 :O_o: additional mods just to get a proper mod analysis and the analyzer not to fail. Keep in mind, a few of these mods were not small files, and Wyrmstooth can only be safely downloaded from an obscure Reddit post. If there is anything that I can tell you from my experience with STEP, it's that users are lazy. They will do the least amount of work possible to get it done. In cases like Farmhouse Chimneys, users will likely just skip the options for the other mods during the analysis; however, in Farmhouse Chimney's case, it couldn't skip them due to the mod packing everything into a FOMOD...which is common practice...so... users will be going through this process a lot when submitting mods. Else, skipping options would leave incomplete mod pages and a lot of maintenance to be done by staff. Which ties into my next question... How are the mod pages updated when the authors update the mods? I'm assuming if the update added new resources, the mod would have to be rescanned with the analyzer. How is this aspect being maintained? By staff?...there's no way that's maintainable for the future... I don't see any place to resubmit new analysis results from the user side. If it's author/staff only, it would be beneficial if list authors were allowed to resubmit these results since, in most likelihood, it's the list author that submitted the mod in the first place. Of course, that might not be a good idea either. I can see this mod analysis thing being a handful to deal with and being messy if too many hands were allowed to mess with it. This is one of the downsides to submitting mods, imo. A lot of mods are packaged into FOMOD so going through a bit of a process of getting the mod analyzed will likely be a common thing, and likely a more tedious process than most users will want to go through. Just my 2 cents. Lastly, you should somehow pull the first image from Nexus to use as the thumbnail when submitting mods with no thumbnail chosen. I don't think most user submitted mods will go through the hassle of downloading an image to use for the thumbnail...specially after having to add an additional 10+ mods just to get it submitted...nope, nope, nope.

Okay. Got ya. I just finished watching your "advanced mod submission" video. I analyzed Deathbell HD incorrectly as I didn't get all the options for the mod. Just letting you know. You should consider having something for authors to get around these rep point thresholds. I can image it would become a point of frustration for authors when you're wanting well established authors to join your platform, but are asking that they "reprove" themselves when they're already well "proved" elsewhere. Authors automatically get elevated privileges at STEP and Nexus. Just some food for thought. :: Sweet! That works.

How long does it take for a submitted mod to show up for addition to the lists? I submitted a mod, BethINI, a while ago and it's still not showing up in the search so I can add it. I'm asking because adding mod pages on the wiki shows up across the board for use pretty much instantly in our current setup. The only thing that is delayed is the refreshing of the actual Guide once information has been changed. The Guide itself will re-cache a couple times a day, I think. This was done to limit that page's affect on system resources.

Okay, so something that you HAVE to implement is some sort of auto-save feature on the lists. I am entirely frustrated right now because I've lost work and have had to redo several things multiple times. If I accidentally clicked on the mod name while editing, it takes me to the page and when I hit the back button on my mouse, all work is lost. I don't feel like I should have to hit the save button religiously or fear losing my work. Also, disabling the links on the mods when in "editing mode" would be of help to prevent accidental clicks.

So if you're not suggesting we completely move to Mod Picker, what you are suggesting is maintaining both what we have now and a list on Mod Picker. This basically doubles our work which doesn't sound appealing, but I could see a mix happening if the right information could be provided. Basically a mix in my mind would be maintaining both mod pages (Mod Picker and our wiki pages). Then, using APIs, we would pull information from both sources to build the Guide on the STEP website. I could see that working, if everything played nicely together. Simple and sweet...can you provide a list of what you are suggesting gets moved to Mod Picker and what stays a part of STEP. Draw a clear line for me to view, if you can. I see no way of adding custom install instructions per mod on the Mods tab as we have it in our mod tables. If the description has to be used for that, then that's the separation of streamlined information I was referring to (having users constantly clicking back and forth between tabs to get all the information they need. If making a "mod notes" area isn't planned, I think it should be. Dreadflopp has already asked for this, in the other thread. If you're going to make successful "Guides" on Mod Picker, then you are going to need to take a page from the most successful modding guides in the community: STEP, SRLE, FLNV, etc., and get all your information about a mod needed for a mod list installation all in one place. This means allowing the list authors to provide things like install notes. The mod list is the best place for this, imo, because it'll be all together. A small arrow that users can click to show and hide these things under each mod would be efficient. Don't forget that STEP is foremost a Guide, not just a list of mods. We need to be able to provide details on what to install, when to install, how to install...all specific to our Guide. Generalized install instructions on mod pages aren't going to cut it for our needs. Your answers to dreadflopp in the other thread has me concerned as well. From what you said both there and here, I'm interpreting that you're expecting some features (like FOMOD instructions) to be behind your paywall because users will have to use your Mod List Setup Utility which you are providing at a cost. That doesn't work for us because STEP is free and will always be free. Other things, like which mod options to download, you mention that the plugin list is provided. Non-paying users would be out of luck here, if the mod options will also be provided by the Utility. So I'm interpreting that as you're expecting non-paying users to do some work on their own or have the list authors provide this information in the descriptions. As for the flags, only the STEP Flags are the ones that are of real interest. They are the flags used to display information within the mod tables for users, along with input from other fields. The Document Flags aren't really necessary, and the Content Flags are mainly covered by Mod Picker already. All of the content of the STEP Flags are tailored to us. Core Mod marks the mod as a Core mod on the mod tables. FPS, VRAM, Performance, Quality, all display information within the mod tables of the Guide so users can know this information at a glance. And of course our mod notes is the, "what to install, how to install it for STEP" bit. This would work if we're using both solutions and mashing it all together via APIs. I have to disagree. I've used Mod Picker just enough to know that it's no quicker or easier to set up the list than what we're doing now. The STEP process of getting mods and information added to the Guide, overall, is nearly equivalent in terms of time. Hence why I said adding Mod Picker to our process would nearly double the maintenance for us. If we merged things with APIs, though, I believe the time and maintenance would be equivalent enough to what we have now to consider Mod Picker an option. This is because we'd be adding Mod Picker which adds several things to the mix, but we'd also be doing away with having to maintain a couple things on the wiki. It would mostly balance out in terms of time and level of maintenance. Custom mods still aren't ideal, but I agree that you've probably done the best you can with an unfortunate situation. As for control, we're still losing some of it. Anytime one moves to a third-party platform, one must relinquish some degree of control over aspects of the situation. If Mod Picker fails, we're set way back in what we do vs is if we retained the information we needed on our own resources. If we want to expand to X-Com 2 next week and we have everything in place to do so, we loose the ability to do this if Mod Picker doesn't support the game (or we have to come up with yet another solution) Plans are just plans until they take fruit. STEP has existed in the community for years and we want to continue growing, so we have to weigh the options extremely carefully. If we decided to use Mod Pick and Mod Picker falls away, where is STEP left standing? For these reasons and more, I'm very caution about using any third-party solution that isn't well established yet. You're asking us to take a risk and we're going to have to weigh out those risks. Anything added to a process without taking something of equal or greater value away will not be saving anyone time, but rather would be adding to the time and maintenance of the process. I can interpret this no other way unless you can provide examples of saved timed. That I completely understand. Hence my explaining of what we do and need in this reply and others. Honestly, if we could use APIs to mash this all together into a nicely laid out Guide on the STEP website, I think it would be a win-win. You get the benefits of all our mod testing being put into Mod Picker, and we get a better solution than what we have in place now with (hopefully) a lighter load on our servers...which is the entirety of where this discussion stemmed. I will likely await S4N's thoughts before replying again.

Read here: https://requiem.atlassian.net/wiki/pages/viewpage.action?pageId=61472833 Bug Fixes corrects this issue: https://www.nexusmods.com/skyrim/mods/76747/?

Several issues from reading that... @STEP Mod Pages The use of our mod pages is specific to our needs. The information these contain is also specific to our needs and most of it should remain static. STEP needs mod pages to contain the information we need (mainly install instructions and flags), and sections of these pages should only be editable by the Staff. We likely wouldn't need the analyzer for our own purposes, but it seems to be fairly integrated. @Mod List This is the equivalent to our mod tables, but again, we display custom/tailored information per mod that is different and streamlined to our purposes. The list would be very different on Mod Picker in terms of how all the information is displayed and set up for the user. We try to keep all information as streamlined as possible. Within the last few releases, much of the Guide has been altered in favor of streamlining. I feel if we moved to Mod Picker for all our needs, this would be a step in the wrong direction because the information would be broken up again. @The STEP Process Step 1: Mostly right. Whether a mod is accepted or not is based on several criteria as you mentioned, but isn't not all discussion. Each mod must be tested against the current set of mods in-game. All mods must first fit the STEP Mandate before anything can be done. @Opt Out. Right out of the gate this will be causing issues for creating and maintaining a STEP list on Mod Picker. Arthmoor and Shurah have no issues with STEP (I personally have author access to ICAIO and have gotten help from Arthmoor on many occasions. Great, smart, and easy going guy). This alone is a very good reason to stay away from third-party solutions which you don't control. In my opinion it trumps all the good. Having authors opt out due to the platform and not anything to do with STEP is a deal breaker, imo. Not only do we lose the control over the mods that can and can't be in the Guide (in the detail we need), but we also lose the flexibility to expand in the directions we want....say into other games that Mod Picker doesn't support and has no plans to. Finally, if STEP decides to go Non-profit one day, then the water is going to get muddy in how we're merging onto and using the platform. For our plans for the future, I just don't see many wins for STEP in merging onto Mod Picker. If anything, it sounds like more work (we're already limited on time), would be more restrictive than our current solution, and would restrict us from flowing in the direction the winds take us in the future. With all that said, I see no harm in maintaining a STEP Guide (to the best of our ability) on Mod Picker. I do agree that Mod Picker could offer some insights into the load order of STEP. I also agree that Mod Picker's custom solution is very similar to what we're doing now, but not exactly the same. Honestly, Mod Picker's platform would likely work for STEP with a few tweaks, but we'd want to have the freedom to customize for to our needs as we have with the forum/wiki software. If you consider selling a software license or issue a usage agreement, we just might be game! ...unless you want to do it for free or work out a deal, of course. ::

Antivirus or antimalware program blocking it, perhaps?

No idea about that.

Disable the "Thalmor Boots" mod and see if they show up in-game.

Added.

We're going to need more detail than that, but have you verified your local cache in Steam?

This is true, but I'd imagine most only open the program when necessary so without tracking they may miss bug fixes which should be corrected by updating and rerunning. I know this is the case for me.

Yes. BethINI works for SSE too. It'll straighten out your INIs. Be sure the track BethINI on Nexus so when it updates you'll be able update, as well, keeping your INIs is pristine condition.