GrantSP

Ha ha, yeah that part I got. What's involved in voicing a character? I'd give it a crack if you think I can mask my accent well enough. I can put on a high-brow silver-spooned voice but whether it is 'good' enough is a subjective matter.

What are the permissions on the MO installation folder? Since MO makes no use of the registry to store those settings it has to be something related to your settings not being saved in that folder. After you run MO for the first time make a copy of the ModOrgnizer.ini and compare it to the original in the MO folder on subsequent runs. If they are significantly different then you may have permissions issues. Possibly that file is being set to RO for some reason.

LOOT version 0.7 has finally reached a release status. Woohoo!! If any have stayed with 0.6 because of fears of the 'beta' status, please make the change now. As with previous instructions follow good upgrading practices. Lastly it works with MO just fine and any issues are not due to code conflict, just user error.

I'm going to sound heretical here but why not just drop the internal sort function and just link the button to the full LOOT application, or drop the function altogether? Unless I've got it all wrong, there is no way to edit metadata that goes into the userlist.yaml without using the full LOOT program so doesn't it just add another level of error if we use LOOT to do some things and then overlook it for others? When I use the 'Sort' function all I can do is... sort the plugins. Only by using LOOT can I edit the metadata and apply 'my' fixes to plugin sorting. Also there is no LOOT report to show the 'dirty/clean' status of plugins with the 'Sort' function. I would say that is a needed tool.

I'd advise you check my exchange with @fireundubh on the mod page. The Civil War scripts are a fairly important aspect of the game and enabling this may or may not impact on your playstyle. I think he has done an amazing job but the reason I wanted to use it can't be done because of those script issues.

Nice to have you here @jvr2400. What do you classify as a 'good' male High Elf?

The way @Brumbek has been pumping out updates lately, that new version will no doubt be up to 1.8 before the month's end.

Welcome to STEP iShoZza. I'd go along with @AyleidRuin's point and examine your INI files. There seem to be a lot of 'tweaks' that are said to be for improving graphics and such, but I would question their worth. Just revert to default and add little by little if you must 'tweak'.

Right now I have a couple of Pink Floyd albums on rotation, Animals, Wish You Were Here and Dark Side of the Moon. I tend to go in phases but usually end up coming back to my favourites like these. And yes, I am on old fogey.

What do you mean "still didn't fix the shortcuts."? If you are talking about the desktop shortcuts made from MO, then I see no issue with whatsoever, in fact 1.3.5 fixed the profile specific bug from the previous version. If you are seeing issues then by all means report them all, how are any to fixed if no-one mentions them.

All the settings to the 'downloads', 'mods' and 'cache' folders can be set via the 'Settings' in MO's UI. Just make sure they are pointing to the actual location that is where those assets are. I'm not sure what settings are different for your FO3 game compared to Skyrim or FNV but the same principles apply. If one game works, ie. it sees all the saves and mods, etc. then the other MO installs need to look at the paths to those things. Since the same code is used for all MO installs, it clearly isn't an issue of MO not working in Windows 10, just a case of user settings. MO 1.3.5, BTW is working pretty soundly. One or two very minor issues but all in all a good choice.

Yeah, my bad. Looking at one mod that has a C# script and installed another in MO thinking it was the one I was looking at. All C# go through the external installer and only one or two XML scripts have issues with the internal. At any rate regarding the OP the external installer is where it has always been and hasn't 'gone' anywhere.

Can you upgrade to 1.3.5 and see if you get the same result as me? ie. nothing in the Data folder and ONLY in the 'overwrite'.

It appears to be only the BSAs used by the original game, not the DLCs. With no BSAs extracted I can see conflicts with files inside them but only the BSAs used by the DLCs. It's just one of those things that I took for granted and never really examined closely. Apologies to @HalkHogan for completely derailing his thread.

Yep, I meant only MO versions.

All the other baskets are *.nifs, so they just replace the original and have his textures loaded by the paths in them. Just found out a curious, and off-topic, thing when looking at this. In MO you can get conflict resolution with textures by examining the Data tab and seeing if a file is overwriting the vanilla assets but it doesn't appear to work with *.nifs. No meshes are shown to be conflicted either on this tab or with the Information window of the mod in question. Has that always been the case and I've just not noticed it? Just noticed you do get conflict resolution with the DLCs but not the original assets.

If your opening question, based on the title of your thread, is actually: What happened to the Internal fomod installer?, then the answer is far easier to arrive at. If the fomods you are trying to install are C# script based, then ONLY the external installer is called regardless of the setting you apply. On the otherhand XML based scripted fomods can use the internal code inside MO and the external installer if that is the setting you have. So if you are changing the settings and still see the one type of installer, that is probably because the mod in question is a C# based one and therefore the internal installer is NEVER used. However, as the small dialog that appears shows, this is the 'external' installer and it hasn't gone anywhere. Anything other than that is a fault and needs to have some supporting background to go with it such as your installation settings etc. Merely asserting something is wrong without evidence will not have very much traction in bugfixing. EDIT: No, not even that is correct. Some C# fomods call the internal installer and others don't. Still alot of work to do with the fomod installers.

I'm not insulting your intelligence. I have no idea of your settings but I do know that for everyone else there is no problem, I am only trying to get some information about what is different with your install to everyone else. Your opinion of what is and isn't working with the fomod installer is based solely on your experince whereas I am basing my questions and opinion on that of the userbase as a whole. So I will ask again, how did you install the latest upgrade? Is one on top of a 1.2.x series install?

Something is wrong with your install if you're not getting the installer working. How did you upgrade/install the 1.3.5 version?

Are you happy with the current version you have? Does it do everything you need to do? Can't be bothered to send in bug reports for 'new' functions? If you answer 'Yes' to these questions then stick with your current install. There isn't anything wrong with the 1.3.x series but you will want to do a bit more with it. When the 1.3.x series has all the bugs ironed out @Tannin will no doubt change it as the default download and the 1.2.x series will be retired, until then either series is a working install and does everything needed to mod/manage your games.

I'm not 100% sure but I think Qt5 may need to have sizes defined by pixels (px) whereas this stylesheet (dracula.qss) has them defined in 'em' units. Just making some changes to that seems to fix it.

hmm... I think something has changed with the way MO/xEdit is handling these files. I just verified my files with Steam, to restore them to 'dirty' and then using MO 1.3.5 and xEdit 3.1.0 I cleaned the 'Update.esm' and my cleaned file and a TES5Edit Backups folder with datestamped original Update.esm are both in my 'Overwrite' folder and nothing in my Data folder. Retried it with Dawnguard and exactly the same result. This is going to be tricky to figure out if different versions are placing the files in different locations.

I can't figure out why your checksums are so different to ours. I just uninstalled the GOTY version I had and installed an old original version and then ran the 1.7 Update on the exe and applied the LAA patch, still got the same checksums as I have now. All I can think of is the Steam client is checking for a specific file and, for whatever reason, your files don't meet that criteria and it errors out. Like I mentioned earlier, this isn't really an error caused by MO, but by Steam and unfortunately I can't see a way to fix it without some intervention by Valve with regards to their Steam client. Sorry to say it but I'm out of ideas.

I wouldn't bother tbh it isn't going to affect functionality Just a minor thing

Ahh... re-reading your OP I see that is exactly what you said. My bad. So, can you provide your MO settings for how you have xEdit set up to run? I'd be interested to see if you have anything significantly different that might cause it do that. Might also like to provide the versions of MO and xEdit you're running. As to whether it will causes issues. No, if you have the cleaned plugin in a mod, the way GamerPoet suggests, then so long as that is active and lower than the 'Unmanaged - dirty' version in the left-hand pane, all should be fine.