GrantSP

If run try to execute the PatchusMaximus.jar, or indeed any Proccer, from outside MO does it work? Also what are the permissions that are set on that L drive? Do you have full access rights on it?

You've set the correct arguments for the patcher as outlined in the wiki? Perhaps you could paste your settings so we can check? There could be something minor you've missed.

Okay. Made a bit of headway. You can get Wrye Bash (WB) to see the MO profile saves but it does involve a bit or symlinking which may not be the best alternative. That is of course unless there is an obvious way that is still eluding me. Simply put Wrye Bash's version of profiles is a folder in the documents folder: C:\Users\<username>\Documents\My Games\Skyrim\Saves\So, let's make a profile called Test. You can make a symlink of the saves folder in MO which will be something like: C:\Program Files (x86)\Mod Organizer\profiles\Test\saves\and point it to the documents folder and rename accordingly to look something like: C:\Users\<username>\Documents\My Games\Skyrim\Saves\Test\Anything that appears in the MO profile saves folder will appear in the documents folder and then Wrye Bash will see it and display it as though it is a new WB profile. You don't even have to refresh WB as it just appears in the Profile list. Using this method it now shows that my later saves are in fact fine, no missing plugins and the same condition is displayed in both MO & WB. Warning! This is not a two-way street. Changing profiles within WB DOES NOT sync the load order to that profile so any differences will be flagged. The load order of the MO profile will ALWAYS be active from within WB regardless of which profile save you are looking at. EDIT: Further changing WB profiles severlely messed up the mod order in MO resulting in the PMOP dialog indicating a needed 'Fix'.

Ahh... well... no. Sorry about that. My mistake. I went about trying to look into this a bit more and I have made a rookie mistake. After installing everything and getting into MO a bit more months ago, I decided to make a specific profile and moved 'some' saves into that profile's save folder. That meant the very first few saves and a couple of later ones exist in the default Skyrim saves folder where as in the profile folder the very first few saves and ALL subsequent saves are there. I wasn't checking the the save numbers correctly, just the character name when I was looking in Wrye Bash, so what I thought was the latest save was in fact a save from months ago. Doh! /*facepalm*/ I found this out by trying to load another profile and do some bad saves and see what Wrye Bash shows. To my horror I found out I have no idea how to get Wrye Bash to find my profile specific saves. Still don't know. I can't find it clearly explained anywhere. When I do I think MO Advanced wiki will be getting some new information added.

According to the file path in that screen shot you are trying to launch the Java executable that resides in the Program Files folder. Unless you have installed Java manually and have specifically placed it there, that version of Java will be the 64bit version, as 64bit programs usually get installed into the Program Files whereas 32bit programs are in the Program Files (x86) folder. Of course all of that is only the case if you have a 64bit version of Windows. The majority of users today do which is why I am making this assumption. Since MO can only run 32bit programs, you will need to install the 32bit version of Java (both 32bit and 64bit can be installed with no conflict) and use that to start the SkyProc patcher.

Just so we don't fall into the colour-blindness trap, as far as I'm concerned, purple is the bottom one. A master is missing. You should check to make sure that you have not inadvertently renamed or removed the plugin.

You know now that you mention it I too have noticed this. I am not using Wrye Bash as much as I did in my Oblivion days, but it is still installed and I use it to check on some things like these threads. I would reckon that the plugin checking with Wrye Bash must be more stringent than the MO version. When I started my default profile and playthrough I had a couple of plugins that after a while I realised they are not really needed and removed them. MO when looking at those early saves shows them as having those plugins missing, however all later saves don't say they are missing, rather there are no indicators that anything is missing. Wrye Bash however shows that all my saves are missing those plugins. My game suffers no problems. There are no CTDs, or anything that is the result of missing plugins. They were in fact extremely minor compatibility patches that shouldn't have been loaded in the first place. All my saves, according to Wrye Bash are purple and are need of urgent attention. However as I said, this profile has been running smoothly for months and shows no issues.

Amazing, us poor saps down here in Aus. have something that isn't available in the US. Who'd have thought it possible. The M525 looks like the next installment from my M510. Don't know if I would class it as a good gaming mouse. It does a fairly good job but lacks extra buttons and the like that you might want. There isn't any noticeable lag that I have seen so that's a plus. I would take the 3yr battery life with a pinch of salt. They would've had to made some fantastic adjustments from the 510 to get anywhere near that.

That's a good point @phazer11 makes, of course that is only applicable if you are using Mod Organizer. Are you? I haven't seen it mentioned yet. If you are, are you using correctly? ie. not in conjunction with another mod manager or with mods installed into the Skyrim data folder. LOOT will be confused if your MO setup doesn't have those mods enabled but they are installed directly into the data folder. Then LOOT will see them and tell you so. Since LOOT is telling you need a specific plugin and you say you don't have it that's a pretty good indication as to your CTD, Missing master plugin.

Without wanting to stay off-topic too long. The best option with Steam Workshop installed mods is: Subscribe to themCreate an archive of that modUnsubscribe, so Steam doesn't stuff up your clean data folderInstall the mod in MO and let MO maintain it.

As for MO there will be no problem with you just making backups of those folders and copying them back to your new MO installation. You should also make copies of your 'profiles' folder. I think I am understanding this correctly, you are reinstalling Windows onto a new disk? That being the case there will be no settings in the registry for the Skyrim installation and there need to be. Just copying the files to the correct location will not be enough for the game to run or for MO to recognize that Skyrim is installed. You will need to install Steam and Skyrim as per usual. Afterwards you can make a backup of the Skyrim folder and restore it to the same location if anything drastic happens to your setup, so long as the registry settings are the same. ie. Windows hasn't been reinstalled. So to reiterate. MO and all of its settings can safely be copied to a new location and your mods and profiles, etc. will be there for you. If your Windows system is a fresh install, Skyrim and Steam will need to be installed so the correct registry settings are in place.

The 'FNIS Overwrite' mod you created resides in a folder with the same name in the Mod Organizer\mods\ folder. Deleting that folder from the Windows explorer is the same thing as deleting the mod from within MO. It should have been deleted if you did so from MO. The 'meta.ini' exists only within that folder so it can safely be deleted also, if that mod is no longer needed. If you no longer have either FNIS or the 'FNIS Overwrite' mod installed then most likely it is a leftover message in your logs. The logs in the Mod Organizer\logs\ folder can be deleted also, a new set will be created upon the next startup. If that message no longer appears there is no issue and you can continue as normal.

Where you have the Wrye Bash executable installed you will find an ini called 'bash_default.ini'. Make a copy of that file in the same folder and name it 'bash.ini'. The Wrye team do it this way so that the correct default settings will never be lost. Open the 'bash.ini' in your editor of choice and search for the line: ;bEnableSplashScreen=trueDelete the semi-colon from the front and change 'true' to 'false' and save it. The splash screen is now disabled.

*GrantSP* is now in sneak mode. I should make it clear, trying to convey a sense of humour or mild sarcasm is so hard on a forum. I was not having a shot at @Aiyen, just the comment. Sometimes if I don't have my breakfast before I post I sometimes go off the deep end.

I'm a little confused, the title of your thread says it is a CTD during the Helgen scripted scene but you refer to a bandit camp causing the issue. So I will assume you have mashed together two issues into the one thread. Seem to be a lot of references to missing files and "Unable to bind script <scriptname and ID> because their base types do not match" entries. These are mostly because of mods not being where they are supposed to be. You say you have been changing a lot of mods lately. I think that may be your problem. Your saves are still looking for stuff that no longer exist. But, if you are getting this on a new game, ie. during the character creation, then there surely are conflicts with your mod order. What does LOOT indicate? Are you still using a bashed patch from a time before you removed mods?

Sorry, I don't wont to come across all 'high and mighty' but this goes against everything MO is designed for and could also be construed as against S.T.E.P. ethos. One of MO's greatest designs is the fact everything has its own place and nothing is just clumped in with everything else. And really saying "if you do not know what is going on" comes across as though this feature is just for newbs. It isn't. This practice is the same sort of thing that users get messed up with when they install a whole batch of new mods in one go and then they are unsure which one has then crashed their game. Good practice is to be methodical and do things in, dare I say it, STEPs. How hard is it to run a tool and then either create the new mod from the overwrite folder or move those files into their correct place? It should be commonplace for anyone that follows these S.T.E.P. guides. Here endeth the rant.

This folder ALWAYS has the highest priority, and that may not be the best position for those mods. It's just laziness to not move those files to their correct mods. Leaving this folder full is asking for trouble. Bite the bullet and move them out.

You generally never let your 'Overwrite' folder get to a stage that looks like this. After EVERY operation of a tool, or during regular gaming, there will be a warning in the toolbar indicating attention is needed. DO NOT IGNORE THIS WARNING. The Mod Organizer wiki tells you what type of files are found in this folder, and how they got there. It basically boils down to this: If there is already a mod active in the Left-hand pane, any files that are created or edited will replace those files. If there is an active mod but lacks these new files, they will need to be moved to this mod. If there is no active mod then the files created or edited will be placed in the 'Overwrite' folder.With option 1 there will be NO warning and there is no action needed by you. With options 2 or 3 the user needs to decide which mod generated them and then manually move them to that mod. This is why the 'Overwrite' folder should be cleared after each action. Logs or txt files could safely be deleted but plugins and ini files need to go into their respective mods. Those files in the 'meshes' folder are probably from FNIS, or something similar, but you need to be sure and then move them into the correct mod.

Which version are you trying to install? Offline or online? Exe or archive? I don't know if you came across this page , but I found it informative. While I don't endorse their breakfast suggestion (see the video at the bottom of the page), I do agree that since a 1603 error is so generic, you may have to resort to some brutal steps to overcome the many possible causes for it's occurrence.

Well if that is the case we still need to find out what the differences are that make Chrome on Windows 8.1 bugout where Chrome on Windows 7 is fine. Since I don't have 8.1 I can't check this so I wonder if anyone with that version could test this for me. Click the 'Start'button, type "protocol" and choose 'Set your default programs'.On Windows 7 there is a dialog with programs with associations listed in the left-hand pane, choose ChromeAt the bottom right is two options, select: "Choose defaults for this program"The dialog changes to show extensions and protocols that can be used by ChromeLook for NXM and see if the correct program is setOn a Windows 7 system this doesn't show up but 8.1 may have taken control of more protocols and this may be circumventing any changes in the 'Local State' file. Maybe! As i said I can't check it but the amount of posts on the net about 8.1 taking control of certain protocols leads me to think it might help. Of course it goes without saying that the 'Local State' edit MUST be done when Chrome is NOT ACTIVE. So if any have been trying to edit that file with Chrome open, shut it down and try again.

As the wiki explains, it is not possible to use Windows explorer to view the VFS. There are however other file managers, such as FreeCommander XE, that can be set up to do this. The reason why is explorer is intrinsically linked to the Windows file system and it is not possible to have the VFS viewed in that manner. Whichever file manager is used needs to be 'tricked' into thinking it is viewing the actual file system. Just about any tool can be utilised in this way, as long as it is 32bit. 64bit programs simply cannot be used in the MO VFS.

It doesn't have to be a case of the GPU not handling the scenes for the game to slow. There could other factors at play. If the scene playing is a particularly script heavy one there might be a hit on your FPS. It could also be a case of the hard drive(s) constantly trying to read/write. I would though focus firstly on the GPU. Start up its configuration panel and see if it is using the correct settings for TESV.exe. Did NVidia install their GeForce Experience tool on your system? That shows some good info and can also be used to tweak any games to use the card more effectively.

Did you not try and open the 'Local State' file as described in the wiki? Regardless of whether you are trying to use MO or not, that file exists as it is an installation file from Google. The "nxm": false line is just another line in the section called: "protocol_handler": If you are unsure how to change the encoding in Notepad++, just open it with Windows' Notepad. It might possibly, though unlikely, be the case if you have a non-English Windows setup and the default is set to something other than Western language. I haven't used Notepad++ for many years now and I can't recall the options.

It appears that the functionality is a little quirky, but nonetheless understandable. Doing a couple of quick tests seems to indicate that if your previous Bashed Patch is enabled/activated before you run Wrye Bash and rebuild it then the resultant patch is placed into the previously created mod overwriting the bashed patch,0.esp. If you have disabled/deactivated the Bashed Patch before rebuilding it then a new patch is placed inside the Overwrite folder and you will need to move it to the previously created mod, overwriting the current patch. Mostly likely this is because only enabled/activated mods exist inside the VFS that MO employs and therefore Wrye Bash, which is being run inside that VFS will not be able to replace that file if it isn't there. MO will therefore place it in the Overwrite folder. I've added some text to the wiki to hopefully make this more clear. Oh, welcome to STEP.

@Smile44 Can you run the *.jar files from outside of MO? Theoretically all MO is doing is setting up the same commands as would be entered at the console, so if it they won't run from MO, maybe they won't run anywhere! For me I can just double-click on any *.jar and Java takes control and executes. If that doesn't happen then those filetypes are not registered in Windows correctly. Some archive programs, or tools that use an archive plugin, sometimes wrongly takeover that filetype. If that is the case then at least one variable has been eliminated from the problem. It's just curious that you, and others, with the exact setup I have are experiencing this when I have never seen it. My system is always updated so anything from Windows you got, I would have gotten too.