GrantSP

Archive Invalidation will be handled in MO so no issues there. The "Unmanaged Bashed Patch 0" is from the Wrye Bash installation and will always be there, just ensure your edited copy comes after it, as you have done.

You haven't actually stated in what way CASM NOT working. Apart from the F4 thing, which you now have fixed, what isn't working? Can you enter the MCM menu?Can you call it properly by holding down the hotkey?Can you make changes to the timing settings?

Comparisons such as these are going to be very difficult for users to decide which course of action to take because the variables are far too large. Even if the comparison shots were short video snippets, the decision to go MSAA, FXAA, ENB or none of the above are not based purely on what you see, but as others have said on what you 'experience'. Placing all these data in a table along with the minimum GPU, FPS-loss/gain, blurriness, etc. would come close to being an aid but even then it is still too subjective. Really these sort of things fall into more of a 'marketing' discussion rather than a 'technical' discussion. It's a case of "do you LIKE this or not?", not "does this IMPROVE the game?" My 2 cents worth.

Just now compiled those changes and it works beautifully.

Whilst trying to track down an issue with another user from LL, (don't ask me what the mods are, you really don't want to know.) we noticed an odd behaviour regarding animations and how they are saved in MO after you run the FNIS tool. Normally when you run ANY tool in MO the files that exist already in the VFS are updated and any NEW files that are created are sent to 'Overwrite', where you can decide if they need to made into a mod or discarded. This is how everyday FNIS use is when we add mods that have animations that affect the actor or the player's character or NPCs. Now when you add a mod that has creature animations, such as the ones in the initial situation, (considering the site they came from you can imagine what they contain :O_o: ) FNIS somehow handles these differently and the resultant *.hkx files are actually saved into the MAIN FNIS mod and are now active in EVERY profile that you have FNIS active. This is completely different to PC & NPC animations where you can have the FNIS output from 'Overwrite' made into a profile specific mod that can be de/activated at will. What this means is the MAIN FNIS mod is now changed to contain animations specific to those mods and if those plugins necessary for those animations are not active, such as in another profile or if you remove those mods, you will have frozen or T-posed creatures in your game. How to fix this situation? The first thing you might consider is to run the "De-install creatures" function from inside the FNIS tool. This will in fact remove these newly created animations from inside the MAIN FNIS mod but it also removes the *_TEMPLATES specific to each creature from inside the FNIS -- Creature Pack, necessary for the functionality of these mods. This means if you want to install another mod that also has creature animations FNIS will complain that Creature Pack is missing, despite the fact the mod is still installed. MO is unaware that the TEMPLATES inside it have been removed. So, after running the "De-install creatures" function you MUST re-install the FNIS -- Creature Pack. (Now after bringing this to @fore's attention he has agreed to change the functionality of that button to leave behnd the TEMPLATES, but this won't be in place until the new version of FNIS is released.) Here is my MO log from running FNIS with a creature animation mod installed. Here is the Bug Genie report that is now closed because @tannin can't see how it is related to how MO's code works. What we need to do is see if it is in fact an error caused by the code in FNIS or MO and then bring it to the attention of either author. We also should consider re-evaluating the install instructions of FNIS inside MO to avoid this issue. There are possibly a few ways this can be avoided. The biggest problem is the MAIN FNIS mod contains the tools needed to update the animations. The original soultion posed by this user was to have multiple installs of FNIS, specific to each profile. Whilst I originally criticised this idea it does now look to be a good option, except for the need to update multiple copies of the mod with each new FNIS version and then ensure the shortcuts to those tools are correct each time. Very problematic. Splitting the FNIS install into two: tools and scripts in one mod and the basic meshes in another unfortunately doesn't work since running the tool still places the new *.hkx files into the mod that contains the FNIS tool, not the one with the meshes, thus defeating the purpose of splitting them. What anyone that uses FNIS, to provide creature animations needs to do, is re-install the Creature Pack each time after choosing "De-install creatures", at least until the new FNIS version is released. If anyone can think of a clean and easy way to maintain profile specific versions of the FNIS mod, please post here as I am currently devising a "simple" method for all MO users to run this tool. Or if you can pinpoint the error as from either FNIS or MO let me know and we can get either author to change it. EDIT: 1) I just now tried to make an already existing mod that contains the various creature animations and have that active alongside the FNIS -- Creature Pack. No change, although the established MO behaviour would dictate these already existing files would be UPDATED, new files are again place inside the MAIN FNIS mod. Very weird. I've PMd @fore to get some input into how he has his code working, ie. does NPC & PC animations have to be treated differently to creature ones, and whether his code specifically treats them as different and if so why. Further both @Greg and myself are examining the VB code for it, to see if there is some trick to this odd behaviour. EDIT: 2) Looking at the MO logs seems to show that the FNIS code uses variables for the paths used by actor animations but it uses commandline functions to go back through the directory tree twice before saving the files in the meshes folder when dealing with creature animations. It is shown thus: DEBUG (09:35:56.0227): create process (w) null - ".\hkxcmd.exe" convert -v:WIN32 "temporary_logs\atronachstormcharacter.xml" "..\..\meshes\actors\atronachstorm\characters\atronachstormcharacter.hkx" (in C:\Program Files (x86)\Steam\steamapps\common\Skyrim\data\tools\GenerateFNIS_for_Users) - hooking compared to this: DEBUG (09:35:51.0557): create process (w) null - ".\hkxcmd.exe" convert -v:WIN32 "temporary_logs\defaultmale.xml" "defaultmale.hkx" (in C:\Program Files (x86)\Steam\steamapps\common\Skyrim\data\tools\GenerateFNIS_for_Users) - hooking I still can't see why MO would follow that and place them in that folder and not the 'Overwrite' since none of these files exist beforehand in the VFS.

I'll disagree with you on one point: There aren't gods & half-gods, there are people that use their brains and then there are stupid/lazy people that just want to click and be done with it. Judging by the concise questions you pose on all manner of subjects you firmly belong in the former category, not the latter.

No. But you can send them to @Mator! Only kidding. What he means, from what I have seen him say on various occasions is, humans should be able to decide what mods need to go together and whether A goes before B or not. Tools are only as good as the algorithms used and they will never be as good as a human's brain. Really, once you get your game modded, you should be only adding mods one at a time and making these choices at installation time, this makes it easy to do. It's only when you are making large installs, like you are now with STEP, that it seems like a large task. If I may be so bold, from the questions I have seen you ask in various forums, you are well on your way to understanding the intricacies of mod order and soon these sort of things will be second nature to you.

I'll get in first before @Mator and preempt what he'll say: "The human brain"

I've noticed quite a few users comments, in various threads in Nexus, expressing a fear of the new 0.60 version breaking their system. Many other users are saying how glad they are that they switched to MO months ago and now are confident their games are safe, when managed by MO. I'm just imagining the next steps. MO now looks to be easier to use than NMM and new users flock to it. I could of course be completely wrong, known to happen every now and again.

I think we should prepare ourselves for a mass exodus of users of NMM. Already the rumblings of the stampede of disaffected users can be felt.

You say you have: "downloaded and activated the mod". Do you actually mean you have "downloaded and installed the mod"? NMM users may be expecting that to be one and the same thing, you will have to activate or enable it in the 'left-hand' pane.

Nice summation.

Where are these BCF recommendations in the STEP guide? Why are we still using them?

Never used it so I can't speak from personal experience but apart from the 'dirty edits', that you can clean, there is still the "issue" of the FXBirdFleeSCRIPT.psc errors. How that actually manifests itself, I'm assuming a massive slowdown in the game engine when you enter the script trigger zone, may be different to different mod setups and systems. Some may see a problem and some may miss it. Since it has been in STEP a while I can only assume most STEP users don't see any issue.

Welcome to STEP. If, as you say, this problem applies to new profiles also you should examine the mods that are being used in these new profiles. Best method is to start with the few basic essentials and add in more mods until you see the problems return. Since MO makes no changes to your actual Skyrim installation there is no chance you have irrevocably broken it. As @Greg the most likely culprits will be shared 'user-created' mods such as the FNIS output mod. You did mention changes applied in one profile being made in another, this should not happen in any circumstance and it would be good to examine those profiles to be 100% certain.

I added an enhancement request about this very thing a few months ago.

Welcome to STEP. You have inadvertently changed the sorting method of the 'left-hand' pane from "No groups" to "Categories". The large drop-down menu at the centre bottom of the 'left-hand' pane is the way that is changed. If I may encourage you to acquaint yourself with the wiki and the video tutorials that describe all of MO's features. Ninja'd yet again! :O_o:

You can merge if you wish but you don't actually gain anything in doing so. In fact it could be argued that you lose the ability to disable a feature, such as the 'forge addon', by merging. The only thing you need to keep in mind is when a different module has the exact same named files in it with different attributes, then merging isn't a good idea. Best bet, follow the guides to the letter and if they say merge, then merge, if they say keep separate, then keep them separate. If they advise nothing, then the choice is yours.

The only reason you shouldn't have the option to 'Create mod...' is if the "Overwrite" folder is empty. Or if you are trying to invoke that context menu from within the 'Information Window' that opens when you examine the "Overwrite" folder. In either case ensure you are looking at the left-hand pane with the mods listed, including "Overwrite", and right-click on that heading. If there are files in it you will have that option. It should go without saying that a command found within MO means examining these things from within MO itself, not via explorer.

If your AV package is viewing the MO executable as 'suspicious' it might not be allowing it to call any other executable, such as SKSE. You may need to set an exception for MO in the settings of your AV. I would like to see your root folder of Skyrim and the INI set for SKSE as described in the guides. Of all the games managed by MO, Skyrim has proven to be the least problematic and no-one else is reporting such a major error as this. At the very least you should see these files in the root folder: \skyrim\skse_1_9_32.dll \skyrim\skse_docs.txt \skyrim\skse_loader.exe \skyrim\skse_papyrus_docs.txt \skyrim\skse_readme.txt \skyrim\skse_steam_loader.dll

Woohoo! This is going to be a must have, I can feel it in me bones.

Sorry about that, I sometimes go overboard in my negative assessments of things. It's just I was so dismayed by the notion that someone who is running, arguably the most used and trusted mod site there is, still thinks installing a bunch of mods is the same as modding a game! What has he, and his software development team, been doing all these years? Do they actually mod games?

As mentioned already, Python is not needed to run MO. The only plugin that uses it is the 'INI Configurator' and since MO provides a simple Python install for it when you install MO itself, nothing extra is needed. Your best bet is to redo your MO install afresh to remove any errors that may have happened before. Grab the latest archive version of MO and extract the contents to a location of your choosing. Run the MO executable once to generate any INI files and folders needed and then move your previous 'mods', 'downloads' & 'profiles' folders into this new install, or simply edit the 'Settings' to point to those locations if you like.

Since the entire structure of NMM's and MO's "profiles" are based on different methods I think it will be a very difficult task to get MO's profiles to install an identical copy onto someone else's computer. We can make tweaks and edits to files in the mod after it is "installed" and then use those files in the modded game because MO stores the extracted mods away from the 'data' folder. This means the actual 'mods' are different to those provided by the mod authors. When they are downloaded from Nexus and installed by others, based on our profiles, there is no way to make those same changes to that set of mods. Add to that the few necessary mods that don't come from Nexus, such as DarnUI and its variants, and the troubles start to emerge. Further, every modder worth their salt knows the importance of making patches based on their specific set of mods. How exactly is any mod manager going to automate that process? Then you add to the mix the other patching tools that we use regularly: DynDoLOD, FNIS, DSR, etc. Not only do these tools need to be added externally, some of them rely on assets that have nothing to do with the actual game e.g. the merge scripts in the xEdit 'Scripts' folder. This is yet another attempt to remove the "process" from the modding process. Can't be done! I'll state it now: if this thing actually works ie. it reliably provides a working copy of someone's profile on a completely separate computer, I will sell all my worldly assets and take to living with the penguins in Antarctica!

In the edit window you can either use the 3rd button from the left, marked "Special BBCode" and select 'Spoiler' from the dropdown menu or place these tags before and after the text: [spoiler]text[/spoiler]