Tannin

You probably don't want to read the source code. What you want is the headers in uibase starting with an I. Those are the interface classes and most have been exported in some way to python. The python class mobase.IPluginInstallerCustom corresponds to the C++ interface IPluginInstallerCustom found in iplugininstallercustom.h IPluginInstallerCustom derives from IPluginInstaller (in iplugininstaller.h) which derives from IPlugin (in - surprise! - iplugin.h) Your plugin has to implement the member functions declared "virtual" from each interface. Those functions will be called by Mod Organizer as needed. If your plugin needs to access information from MO, you go through the "organizer" object passed to the init function. The interface for that object is called IOrganizer and declared in imoinfo.h (woops) This lets you create empty mod, install mods, get information about the current profile and so on. You can also get access to further interfaces like the download manager, an interface to retrieve nexus information and so on. The "hello world" plugin would look like this: from PyQt4.QtGui import QIcon, QMessageBox class HelloWorld(mobase.IPluginTool): def init(self, organizer): return True def name(self): return "Hello World" def author(self): return "Tannin" def description(self): return "Gives a friendly greeting" def version(self): return mobase.VersionInfo(1, 0, 0, mobase.ReleaseType.final) def isActive(self): return True def settings(self): return [] def displayName(self): return "Hello World" def tooltip(self): return "Says "Hello World"" def icon(self): return QIcon(":/pyCfg/pycfgicon") def setParentWidget(self, widget): self.__parentWidget = widget def display(self): QMessageBox.information(self.__parentWidget, "Hello", "Hello World") def createPlugin(): return HelloWorld()

Of course, how would MO know that there is a blog? All versioning info and descriptions come from nexus. No, you don't have to configure each mod manually, usually you have to configure nothing, because MO usually (including the case you posted) correctly determines version numbers. If you install mods that are not hosted on nexus (or are not up-to-date on nexus) I'd suggest you remove the nexus id and version altogether. MO will then use the installation date for the version number, that should be good enough to determine if a version on the blog is newer than what you have installed.

Depends on the plugin. "tool"-plugins will appear in that dropdown. "installer"-plugins may add a new supported file type (that type will than appear in the downloads list and in the "install mod" dialog) and will then be invoked when such a file is opened. An installer-plugin may also use an already supported file type and can then "choose" if it supports a specific file (based on the name or content, but the latter is currently not supported in python plugin) There are more ways to have your plugin do something: You can also write plugins to add more checks to the warnings dialog (exclamation mark in the upper right) and you can set up a plugin to automatically be run when a binary is run. Further plugin types are added as necessary, so if you want to write a plugin to be notified every time after a mod was installed or after a download was completed or when the profile changes, ... then let me know.

MO comes bundled with python so that's not a requirement anymore. Shortcuts, no, there are quite a few things you can't do with shortcuts currently.

Many times when you go swimming during a thunder storm you will not get struck by lightning and die. That doesn't mean you should advice people to ignore all warnings against it! If you suggest to people they ignore the warning, how will they know when the ordering is actually important? If people continue to suggest the warnings I put in are ignored and I continue to receive bug reports and hate from affected mod authors because of it I will be forced to dumb down MO to the point where people don't have to read anymore. Also: If you know how to improve the warning detection, why not just tell me? Because I honestly don't. Unless mod authors start to properly document compatibility of their mods but we all know that's not going to happen.

Yes, you can install mods from a python plugin. In the mod organizer code repository there is code for a plugin that takes a list of mods from a csv file, downloads them from nexus and then installs them. I didn't release it because it has a lot of potential to piss off nexus admins but left it in the repository as a sample for installing mods from python plugins. You can see the code here: https://sourceforge.net/p/modorganizer/code/ci/default/tree/source/plugins/installerBatch/pyBatchInstaller.py It did work at some point, I don't promise it still does (due to changes in the interface). Should get you started though.

That's not the mod you mentioned before. This one does not use a major.minor.subminor version. I'm fairly certain MO is applying the correct versioning scheme here

Care to elaborate? I'm not aware of any issue in that functionality and I would ask that people (especially moderators and mod authors) not advice people to ignore warnings without at least a bug report on the MO issue tracker detailing why the warning is wrong.

64 bit support is actually in the works. Unfortunately progress is slower than I would have hoped because maintaining MO 1.x is a lot of work.

the "Write to file..." option is only there to write a list of all your data files to a text file. There is no option function to copy files from the data tab.

please post the meta.ini here or send it by email to sherb at gmx.net

Probably because people have been pestering me for a year to support a versioning scheme that interprets dots in version numbers as decimal separators and for reasons I can't deduce now MO thinks that the mod uses such a versioning scheme (maybe they did once). If that dot is a decimal separator, obviously there can't be a second. Close MO and open the meta.ini file for that mod, it probably has saved the version as "f0.8". Remove the f and the versioning for that mod should return to "normal".

@dreadflopp: Software can create a file association (web protocols is the same thing) either for the current user or the whole machine. The latter can only be done by the administrator. Guess this is what 7zip does, same for NMM. MO only registers for the current user.

You try to stay polite when people offer "run it as administrator" as a solution when that is the top cause people have issues with your software in the first place. My post is compact because I was short on time, not because I intended to be rude. Imho it's also informative. But let me rephrase what I said to make it potentially more useful: Depending on how your windows is set up you either have - one account that is your regular user account AND an administrator - two accounts where one is only a regular account and the other is administrator In both cases you can "run as administrator" but the effect is different: If the first is true then all actions that affect "current user" will affect that one user, no matter if you started an application as "run as administrator" or not. In this case the problem you described shouldn't have occured, at least I wouldn't know why. In the second case, actions that affect "current user" when running with "run as administrator" will only affect other applications running as administrator. Example: if you run MO as administrator and register the nxm handler then nxm links will only work if you (always) start your browser as administrator as well. Considering you have MO installed in "Program Files" you probably have to run it as administrator. You probably wouldn't run your browser as administrator because most people don't. Therefore I concluded that that was exactly your problem.

"I did this both as a user and admin." If your current user account is an administrator account then you did the same thing twice. "One of these fixed the issue." is then wrong because each operation is equivalent. BOTH fix the issue. It doesn't matter if you do it as user or admin because both are the same. UAC doesn't matter, the registration happens in a region of the registry that doesn't require elevation to change anyway. If your current user account is not and administrator account then you registered MO to handle nxm links for two separate users. Yes, one of these fixed the issue, in the same way a shotgun can "fix" a buzzing fly...

MO registers as nxm handler only for the current user because its not supposed to be run as administrator.

Should I assume people use unusual versioning schemes? How do I pick which non-standardized versioning scheme people use?

And what is the rationale in doing this WilliamImm? Why would you have n-1 levels of numeric versions and then suddenly switch to letters on the n-th? How would you mark a beta in your versioning scheme? 1.2.7bbeta? I'd advice you read up a bit on established versioning schemes, at least the wikipedia entry: https://en.wikipedia.org/wiki/Software_versioning MO supports multiple versioning schemes, including mixed-numbers-and-letters, but by default it assumes the most reasonable (in terms of flexibility and usability) convention.

@1: please create a report on the issue tracker. @2: then ask the mod author why he calls it an alpha if its not? 1.2.7a is by convention the id for an alpha version. If that's not what he wanted to say, then he shouldn't have said it... To re-phrase: Yes it's on purpose; no, it's not gonna change.

Shoot! There I was, spending dozens of hours of coding to implement BAIN support and then I forgot to actually try it. Glad that after 2 years you came along to let me know... /sarcasm mate, If a BAIN package contains a wizard, that says that it's NOT a simple bain installer because a simple bain installer doesn't need a wizard. Since MO doesn't support wizards, it can't possibly know if the installation would be correct. If you want better BAIN support, I'd suggest you fetch the MO source code and get to it. You certainly don't have to be a specialist programmer, the whole point of the plugin system was to allow improvements to MO without the need to understand the low-level stuff (including the plugin system itself). Heck, you could even create a new python plugin for bain support and use the original wrye bash code for bain support.

How would it be a MO problem if one profile works? Tourist is absolutely right in assuming there is something different between the two profiles and that difference causes the ctd. @Tourist: You can use a tool like beyond compare from https://www.scootersoftware.com/ to diff the two profile directories. That will tell you all differences between the profiles, help you narrow down the problem.

Thank you for checking. And there was indeed a mis-configuration in the issue tracker. It should now allow guests to read comments again.

Please read my comments there and help if you can because the problem will not be resolved unless someone does.

I started working on this. If you're affected, please follow the issue here: https://issue.tannin.eu/tbg/modorganizer/issues/555

The message means that FNIS signaled to MO that it failed to run. FNIS itself should have displayed an error message with details 'cause MO really doesn't no more than "there was an error"...