Tannin

The Skyrim engine consists of several parts. The graphics engine and scripting engines are fairly new and at least the scripting engine is 64-bit ready, I doubt that stuff will be rewritten for Fallout 4. Which is bad for us because the scripting engine is what's causing most headaches with Skyrim. The data storage system (esp, esm, ess, bsa) is ancient since it's mostly the same since Morrowind. Again, there is no indication yet Fallout 4 will drop it since it is a tried system. This however is the part that enforces the 256 plugin limit and it's probably not 64-bit ready. The question is: Do we want the low-level stuff to be replaced? Who's to say a new engine would be moddable at all? And even if it is, we would loose all the knowledge and tools that have been built up since Morrowind. Script Extenders? Have to write from scratch. All the unique functionality from wrye bash? useless. TESxEdit? nope. It's very possibel that, if Fallout 4 uses a whole new engine, we wouldn't see complex mods (beyond texture replacers and quests) for the first 3-5 years after release. If at all.

This issue has been on my backlog for a while now. Sorry it took me so long to reply. I'm a bit at a loss on how to approach this problem, maybe some of you have good ideas: the initweaks.ini is created at time of game start by combining the individual ini fragments (aka tweaks) from mods so its temporary and used as an "overlay" whenever the game reads ini settings. Now the problem happens as the game writes ini settings (potentially with the same values read before). Now what's the right place to put these writes? a) the regular skyrim(prefs).ini file which is where the game intends to write. This is what currently happens. It is confusing and broken because read accesses will still go to the initweaks.ini. This means that settings made through ini tweaks become effectively read-only (which may be a good thing), though the vanilla inis still get changed. b) the initweaks.ini file. In this case the settings get modified for this session but thrown away on every restart which would still be confusing. c) the ini fragment which was integrated into initweaks. This would persist the setting while keeping those settings out of the vanilla files, but it means the ini fragments get modified which is probably a bad thing (*). Also it would be a ton of work for me. d) a whole new ini file (in the overwrite directory?). This would be consistent with how other file modifications end up in overwrite but it would be another layer of ini virtualisation so not exactly easier to comprehend. (*) Modifying the ini fragments is a bad thing because they are set for a reason. Usually ini tweaks are made because a mod requires a certain setting so bundling this setting with the mod is a cool feature (the whole point of the initweaks actually). If you could inadvertently change the setting from the game ui you might break a mod and never find out why.

I know about the limit of 256 active es* (esp, esm and ess). I doubt this can be fixed, it's enrooted way too deep in the engine (fixing that ini limit is already the darkest hack I've done in over 20 years of programming) I was wondering about the limit of 508 es* (no matter if active or inactive) nitpick claims to fix.

MO fixes the number of characters in the ini by similar means as nitpick (hence they collide). To be honest, I wasn't even aware of this 508 esp/esm limit. It's easy enough to fix manually in MO but could someone point me to a discussion of this issue?

Please remember that the correct way to report an issue in MO is the issue manager on https://issue.tannin.eu/tbg/modorganizer

It doesn't matter which browser you use. Start the browser you want, click on a download and if MO is associated with nxm links it will open. If it doesn't work for one browser, it shouldn't work for any other because its windows delegating such download links. If MO is not associated with nxm links then click the globe icon in MO to fix that.

Thanks for writing this down, it's a huge help. Please note that to a large part setting this up is automated. When you click the globe icon in Mod Organizer it will register this instance of MO as the handler for the currently managed game. Example: Say you have NMM installed. Then you install MO for Skyrim, click the globe icon then install MO for FNV, click the globe icon then the situation is as follows: You have nxmhandler.exe twice for each MO installation but only the first (the one in your Skyrim MO) is active and it should have a setup like this: Skyrim - Fallout NV - Skyrim, Fallout NV, Fallout 3, Oblivion, Others - The games will be picked top to bottom so even though NMM can handle NewVegas Links, MO gets called. Should you deinstall the NV MO, NMM will handle the links again. Others means "all games not on the list". The above setup means NMM gets to handle fallout3, oblivion and any other game. It's not a placeholder, it's a catch-all. And the games supported here are only games that have nexusmod pages. Nehrim isn't it's own game on nexus so there is no point setting it up here, there are no nehrim-nxm links. And Morrowind isn't officially supported by MO. EDIT: Oh, and one more thing: If MO is already running, all downloads go to the running instance no matter what has been set up in nxmhandler. I know this isn't intuitive but since multiple running instances of MO aren't possible atm I've found no proper way to work around this (except for stopping the running MO and starting the right one but that seems like a sub-optimal solution)

I checked this yesterday: The Nexus interface for programs does not return anything on the new URLs and a redirect to the regular html site for the old URL. So either they have broken that component or they have chosen to lock out non-NMM tools completely or they have changed the interface. But the current NMM version seems to be the same story, at least I wasn't able to retrieve information about any mod. MO will need to be updated since the urls are hard coded but right now Nexus needs to be fixed first because I can't even test if stuff works with the updated urls.

a little off topic but ive searched for any mention/documentation on configurator plugin and this is the only thing i can find. "Plugin to allow easier customization of game settings" is the GUI description. 1. Aside from the brief description in the GUI, can you tell me what the configurator does? 2. Which game settings is this referring to, there are many settings in many different locations. 3. Is this a plugin that can be called by the user? If so, how do you use it? 4. Is python 2.7.6 sufficient or do we need 3.3.3 ? Configurator presents all the settings from skyrim.ini and skyrimprefs.ini in a somewhat usable way (i.e. number fields don't allow entry of text, floating number fields that have known limits have a slider for configuration) but it's still rather complicated since it displays all possible settings (grouped by category and "basic" vs "advanced" settings). The plugin appears in tools-button on the toolbar together with the old ini editor and the nmm importer. Python 2.7.x is required, python 3.x will not work (3.x is not backwards compatible and I chose to stick with 2.7 because it's api won't change any more and it's probably going to stay around for many years)

Do you use a wacom tablet and/or mouse? Those are not properly supported by Qt (version 4.x) and since both TS3 and MO are based on Qt 4, this is a likely candidate.

It's not just looking for a script folder but it's considering all mods that contain conflicted scripts and advices to sort those in the same way the esps are. The warning message does state that these sorting issues MAY lead to bugs not that they DO. It's an advice, not a definitive guide on what to do. I do not currently intend to make this feature more sophisticated as it serves its purpose in my opinion. But if anyone deems this important enough: This is an open source project. If you know better, feel free to fix it!

Then you're out of luck, the information is simply not available to MO. Regarding your other question: In this case you can still enter the name yourself. If I'm not mistaken MO lists all names that can be identified automatically and in practice it makes little sense to provide every permutation of those names. Why can't this be fixed? Can you just ask the user for Mod ID?Because usually MO doesn't know it interpreted the wrong component as the Nexus ID. In cases where it does know it already asks for user input.

That's the wrong log. If this is related to MO the relevant log would be the ModOrganizer_.log from the time you ran skse.

Some of the things you posted can't be fixed. For example MO can't know about the dependency between "SkyUI" and "EzE's Colored Map Markers" so how could the automatism keep those ordered when MO thinks the mods are unrelated? Therefore the automatic fix will probably remain disabled, this can't be fixed completely without user interaction.

If you unpack the BSA the assets are always active so you don't need the esp either. HOWEVER, this feature being new and all, I'd really appreciate feedback if disabling an esp causes problems. What it currently does is point out the esps that have no records at all, so to my knowledge the esp itself can't have an impact on the game. If you find an esp where this is untrue, please let me know (including the mod name and preferrably a link). Please note that Skyrim will still give the warning that a plugin has been disabled when you load the game, that warning goes by loaded filenames, it doesn't test if the plugin actually did anything. @GITech: I'm afraid that's not something MO can do. The new feature only points out esps that didn't do anything (apart from enabling assets) anyway.

There are a few things that can go wrong with Query Info: 1. the file list could be too long (this is NOT something I can fix, Nexus doesn't send more than 30 files) 2. the file you have on disc could have been removed 3. the formatting of the file name could be unparsable so MO can't determine the nexus id (or, more likely: It misinterprets another component of the file name as the nexus id) 4. the file information on Nexus is incomplete. For example MO might have been able to retrieve the mod name but not the file version. In this case (if I'm not mistaken) the warning sign remains active. The problems 1-3 can't be fixed by me, not sure if it makes sense to change the behaviour in 4. Query Info is really just a workaround, users should really prefer to download through MO so they don't usually need it.

This may not be the best approach actually. In newer versions of Windows (I believe since vista) HKEY_CLASSES_ROOT is a virtual registry path that is a mix of "HKEY_CURRENT_USER\Software\Classes" and "HKEY_LOCAL_MACHINE\Software\Classes" (the former "overwriting" the latter) To my knowledge NMM installs itself to HKLM, so it applies the nxm connection to all users. MO installs itself to HKCU, so it applies only to the current user, thus doesn't replace NMM in HKLM. Now if my information about NMM is correct, it would be best to uninstall MO as a nxm handler by removing "HKCU\Software\Classes\nxm\shell\open\command" because then the setting for all users takes over again. If you modify HKEY_CLASSES_ROOT to use NMM that change goes to HKCU so you have actually set up NMM as the nxm handler twice (in HKCU AND HKLM). I'm not yet sure how but sooner or later this will probably bite someone in the a**.

Yes. If you really need another level of minor updates, why on earth would you do anything other than appending another number? What insanity leads people to think "well, now I have three levels of numbers, it's really time to do something different: lets use letters. And on the next level we could use latin characters! We can have fun version numbers like "1.2.1b-IV+red^washington##foxtrot". It makes no sense...

Sorry but conention says a stands for alpha, b for beta. Google: software versioning. If you want to do a small update to 1.7 you call it 1.7.1, that is unambiguous.

Sorry about missing the pyqt files, this HAD to happen with a new installer... *sigh*. The Qt DLLs are optional because it's possible to install them system wide (either to c:\windows\system32 or the 64bit equivalent) or adding the installation path to the path environment variable (happens automatically if you install the qt sdk). In this case you don't have to have another set of dlls in the MO directory. Regarding the lack of an error message: This is expected because the python-proxy-plugin does work (the plugin that allows other plugins to be written in python), it's the configurator plugin that has further dependencies and can't be loaded. Now I could write a second code path for each python plugin individually (right, only one currently) that tests if the all dependencies (direct or indirect) are fulfilled and provide appropriate guidance but the effort required would be disproportionate. Finally, regarding the NMM import: the issue "not all assets are imported" can't be fully fixed. The same problems I mentioned on ASI apply: There is no reliable way to know which files on disk refer to which file in the archive. The installlog does not contain hashes so I can not restore the overwritten files for the other mods. Fortunately the whole problem goes away with NMM 0.5. As it stands now, the imported mods will work as expected as long as they all remain active. The importer now says so explicitly and advises to reinstall the partially-imported mods. the other issues you had I can't reproduce: - the nexus id is expected in "nmm mod folder/cache/.zip/fomod/info.xml" -> fomod/Id - the category is expected in the same file -> fomod/CategoryId. It will be mapped to MO categories based on your custom category setup if you have one. - endorsement state is expected in the same file -> fomod/IsEndorsed If these information are not transferred in your system then the only explanation I have is that they are stored differently, maybe the way things are stored has changed between NMM versions?

Guess I bent the rules a bit and put more into the 1.0.8 release than would be appropriate for a release candidate so it'd be great if some of you could take a look before I upload to the nexus. Primary changes: - This version provides a proper installer with optional features and an uninstaller - package now contains a (minimal) python installation - Added two more warnings: One will warn if more than 255 esp/esms are active, one will warn if esps are loaded in a different order than corresponding scripts (this should make USKP admins and users happy). The latter has an automated fix. - esp pane will now highlight dummy esps (which aren't actually needed if the bsa is registered) - some improvements to the nmm importer. in particular there is initial support for the 0.5 alpha, though I'm not sure it will be compatible to the final version Plus a couple of bug fixes of course. Full changelog once I upload to nexus (ideally next week) Link: https://sourceforge.net/projects/modorganizer/files/latest/download?source=files

Benefits of Linux over Windows: Hard to explain without background. Basically there are only 2 base-types of OSes around: Unix and Windows. Unix is old and has been designed as a secure server-system from the start. Windows has been designed as a end-user OS and has received concepts like password protection, user separation, access control, networking and especially network security as an afterthought. The unix family of OSes has withstood the test of time A LOT better than Windows: It's core concepts, i.e. regarding security deviced in 1970 or so are still robust today whereas Windows concepts were broken and had to be rewritten repeatedly. Or, worse, the broken concepts are still around. Admittedly, users usually don't notice how broken Windows really is but its pretty much patchwork. This shows for example in that several Windows tools (i.e. windows explorer) use interfaces that Microsoft itself has labeled obsolete 15 years ago. This is the reason earlier versions of ModOrganizer could (accidentally) create files that the windows explorer couldn't delete: The filesystem of Windows supports a lot more features than explorer can handle: the FS can support file names up to 32768 characters long (and could do that since Windows NT in 1993) but 99% of the windows programs (including shipped MS software) will crap out faced with file names longer than 260 characters. Have you ever wondered why your HD, which is probably the first drive in your system is C: instead of A:? Because in the 1980s PCs often had two floppy drives (3.5" and 5.25"), microsoft reserved A: and B: for those and there is still so much crappy software working under the assumption that A: and B: are floppies (again, this includes Microsofts own software) that even 30 years later they can't get rid of the ballast. Ok, enough with the rant, you asked what Linux is, not what Windows is... Almost all OSes in use today that aren't windows are some form of unix-based: Mac OS X, iOS, Android, FreeBSD, Linux Linux is (depending on context) either a free, open-source unix-based OS or only the kernel thereof. Anyone who wants to can create his own Linux "distribution" to create a customized OS. Popular distributions are Ubuntu, Debian, Fedora Core, Red Hat, CentOS, Suse, Gentoo, ... They usually have different goals (i.e. stable server systems, up-to-date desktop, gaming, ...) but they are all Linux. Linux does have bugs and occasionally there is a virus, but they can usually do a lot less damage. While there are maybe a few hundred viruses and other malware for Linux there are several million for Windows.

This is probably the same as this bug: https://issue.tannin.eu/tbg/modorganizer/issues/379 Here is the workaround I posted there: The directory listing only shows the contents of one mod and you have little control over which one. If you work on a single mod you can create a new, empty profile. Enable only that one mod and start the CK. You should be able to access all files from the mod ok. Also: You can still open files/directories even if they are invisible in the filebrowser of the CK. I.e. say you are in data/meshes/actors and the directory seems to be empty but you're sure there should be a "character" subdirectory -> Enter "character" in the name field and press enter -> the file browser should now show a partial listing of that directory.

What version of MO are you using?

Endorsements have 4 states: unknown, never, endorsed, not endorsed. Only in state "not endorsed" is the icon displayed. Immediately after installation the state is "unknown" and it's only updated when nexus is queried for that mods state. Said requests can be batched for less traffic. Since Nexus has been struggling with traffic for months and DarkOne has already indicated he may lock out alternative mod managers (only MO atm) if they cause too much traffic (as in: more than NMM)Â I chose not to automatically query the endorsement state immediately after installation. Instead the correct state will be determined once a "check all for update" is made. For the same reason several nexus-related ops don't happen automatically (i.e. "query info" on downloads). I may be overly careful here but I'd rather not bite the hand that feeds us. ;)