Tannin

compression adds work to the cpu but lessens the work on the disc. But CPU speed has increased much much faster in the last couple of years than disc speed. Therefore compression on an even remotely modern system, basically anything able to run skyrim, compressed BSAs are way more likely to reduce stuttering than increase it. The enb topic is completely unrelated. BSA data is compressed on disk and uncompressed very rarely (i.e. on startup, when switching zones). ENB data, if I understood the point of that setting correctly is about data compressed in memory and uncompressed every frame.

We are sooo going in circles here... There are no mixed messages in MO. There are mixed messages between posts on the internet that don't discuss MO at all and what MO does.You are confused because you desperately try to apply knowledge that is completely unrelated no matter how often I tell you "MO doesn't work like Lojack said when he wasn't talking about MO but MO works like MO tells you how it works!"MO has a conflicts view. There it tells you which files conflict in which mod. And it gives you a warning if something you configured makes the conflicts view display wrong information. One line. And this is the truth, this is the reality and NOTHING you have ever read outside of MO is relevant to how asset ordering works in MO. There is one single line of information you have to read and comprehend to know everything you need to know.In standard Skyrim asset priorization you have to know which types of asset-containers are applied in what order, you have to know your installation order and you have to know your plugin order, all of which lojack documented in a lengthy post and from that information you can deduce which assets get used.In MO you don't have to know this stuff, you just look at the conflicts view. And therefore, since there is no need to "know" technical details to understand what happens we don't need a lengthy documentation.All it could ever do is confuse the users, make them think there is something complicated to necessitate hundreds of lines of documentation, make them believe there is difficult stuff they need to know when there really isn't. When did ini tweaks become a part of this discussion? Forget ini tweaks, they have nothing to do with anything.MO virtualizes the ini file as well as FS. When you allow MO to manage a bsa that bsa will be loaded through the (virtual) ini file but this is a technical detail, you don't care about it!And please stop talking about "registered BSAs"! That is a term lojack used and is explained as "BSAs that have priority lower than plugin-loaded BSAs and loose files". This is not how BSAs work with MO. They are loaded in the same way but that is a technical detail, you don't care about it! Yes it is correct, no it's NOT a better info text because it explains how MO isn't supposed to work! Why would I document inside MO how MO doesn't work? What I'm saying is: that is a technical detail, you don't care about it! And why would they? IF the vanilla BSAs were exposed then every single asset that replaces something in the game would be in conflict! And, since you can't modify the "installation order" of the original data directory you couldn't do anything about it. While true, I do this in my spare time, I don't get paid for my work on MO. Satisfying the users, while important to me it is NOT my primary concern. And while user groups usually find reasons why they should be more important to the dev than others, they aren't right. If a feature is mildly useful for user A but a major annoyance for user B I'll remove/replace it, no matter how much user A thinks he is more important. "not working correctly" means "working different from how it was designed" not "working different from how someone expected it to work".Testers, like regular users primarily need to understand how MO is supposed to behave so they can recognize a deviation but they don't need to know how it is implemented.

Sorry, hat a crappy day at work today.re 1: yes, if you check a bsa in the archives tab it is decoupled from its plugin. if it's not checked the bsa will work like it would with any other mod manager (or without). The MO conflict information will not be correct in this case.re 2: Why is this confusing? This is a list of archives -> check one to have it loaded in the expected/intuitive way.If the bsa is checked it will be loaded. the plugin does not matter then. it is loaded in the mod order (aka installation order aka asset order) -> no warningIf the bsa is unchecked and the plugin is unchecked then the bsa doesn't get loaded. It is to be assumed that is what the user wants (why would he uncheck everything?) -> no warningif the plugin is checked and the bsa is not then the bsa is loaded although it's not checked and its load order is different from the installation order -> THIS is the confusing case. This is the case that is counter-intuitive and thus the case that needs to be explained -> hence the mark. And this is exactly what the text says: "Contrary to what you might expect when you see an unchecked option this bsa is still active and may behave in an unexpected way"re 3: Yes, on the technical level checked files are loaded through the ini file but they don't behave like "registered bsa" as described by Lojack so don't call them that! They can override loose files.re 4: yes, except for the vanilla bsas (or better: all bsas in the data directory) The problem is: all of this, every single thing I posted here I have explained before.The following is documented directly inside MO: and and And in the wiki we also have it explained: Shall we make a poll how many people have actually read all that? How many more ways should I explain the same thing before it's documented enough? BSA extraction is already a subversion of the standard load ordering. The controversy is because (some) people use advanced features they don't need or understand and don't read warnings and don't read documentation and then bother the mod authors. The 10% of users that read documentation aren't the problem, they already have the information they need available. The problem are the users that don't and never will read documentation. These people can only be helped by taking control away from them.MO gives you a mod order suggestion. If you just follow it you don't have to know ANYTHING about BSAs and loose file. You just click on the warning icons, do what it says and the whole thing is done. finished. No need to read, no need to think. Which is why you get a warning that tells you exactly that. There is the documentation. It's one sentence. You even quoted it but you still didn't read it...

What I'm saying is:- If the mod with the bsa is higher in the installation order than the one with loose files then the bsa takes precedence- If the mod with the loose files is higher in the installation order than the one with bsa then the loose files take precedence Or, to phrase it more plainly (like I did before)- If a mod has higher installation order then it takes precedence. The format just does not matter I honestly don't understand how MO is complicated when it gets rid of a whole category of complexity... @z929669: If esp and bsa are unchecked then the bsa is not loaded and can thus not conflict WHAT do I document? That a certain problem people may have read on the internets does not actually affect them? I can hardly start documenting unusual things MO does not do. Also, sorry to say this: documentation is worthless. People don't read it (well, there may be a few but certainly the majority of my users don't, this very discussion is proof of that). @Garfink: I had such a button in the very first version that had the potential mod order warning but doubleyou convinced me to remove it. Don't know which thread that was in.

Regarding BSA extraction in MO: I've decided to move this functionality into a plugin that will by default be disabled. This means an advanced user who wants BSA extraction can enabled it and use it as he always has whereas someone who doesn't know about BSA extraction will not be confronted with the choice at all. Regarding BSA order vs Loose order in MO: MO totally "messes up" this concept, just throw out everything you've read about BSA vs. loose order, it doesn't apply to MO. In MO, (if you check all bsas in the archives tab) all BSAs are registered BUT if a BSA has higher installation order than a loose file that loose file doesn't appear in the VFS. This means assets are effectively loaded in installation order no matter which format they are in!This also means that no matter if you extract BSAs or not, the bsa order will never be automatically matched to your plugin order! Therefore you have to have to have to follow MOs suggested installation order in the warnings window (Potential mod order problems) to ensure a stable game.When I suggested I might remove BSA extraction I was also thinking of removing the behaviour in 1, because then we could drop mod order suggestions as well -> loose one feature, get rid of one issue, drop tons of complicated and confusing functionality. More BSA Pros: Better performance (a lot of files also slows down game startup, especially when using MO)Less disk usage (because BSAs can be compressed)Faster installation (you save yourself the extraction step)Removes user-control (yes, this is a good thing, at least for mod authors and myself ;) ) I always tried to be guided by reason... If the critic base has the better arguments then they're who I'll listen to.

@Wolverine: How would having the file inside the bsa simplify hashing? The files can be compressed or uncompressed. So to calculate the hash of a file inside a bsa I might have to extract it. MO usually "registers" all bsas, loading them through the ini file. Those are NOT synced with esps. If they were, asset load order would be different between loose files and bsas, making correct conflict detection a total mess. caching the hash results would require a ton of housekeeping and would break the moment someone changes stuff outside MO. @Kuldebar: I soo love people who ignore everything that has been said on the topic then tell others to RTFM. Do you even realize that people like you who sell BSA extraction as "best practice" are the prime reason I'm considering to remove it? Statements like this are the very reason beginners extract BSAs without understanding the consequences.

Maybe you do but far too many don't. I wasn't making a statement about your person.I think this topic has been derailed a bit, it was actually about the mod order suggestions made by MO? BSA extraction is part of the reason this feature is necessary and even if I hide BSA extraction so only advanced users use it, those advanced users will still need to fix their mod ordering => this feature will still be necessary.Thereforce, if we're keeping BSA extraction in whatever form we will need to fix the suggestion algorithm.And I still don't have a bug report in the issue tracker actually explaining what's wrong with it.Btw. @wolverine: You were asking if MO does a hash check on the scripts. No it doesn't because, apart from making things more complicated, checking the hash of files inside a bsa would probably be very costy performance wise.

If you mix/delete/not install files from the mod then you're modifying the mod (heh) and you have to take full responsibility of the problems that result from that.And people don't do that. They mess around and then contact me or the mod author that their game is broken. There already IS a dialog saying "Extract BSAs only if you know what you're doing." That doesn't stop anyone. Every user who has been using his computer for more than five minutes thinks he's an expert. I've been thinking about requiring users to solve a quiz before they can activate BSA extraction. > There are A LOT of people out there that they know exactly what they are doing and have so much enjoyed this powerful feature of MO (among other features ofc). I doubt it. There are very few people who actually know what they're doing in regards to BSAs. And those people don't extract BSAs... Btw.: In MO you don't need to extract BSAs to see conflicts. MO shows conflicts for files in bsas (except for the vanilla bsas because that would be silly). Which goes to show that you yourself don't know as much about MO and BSAs as you think. Just saying.

It makes sense to you because you already know what the lists do but "overrides" doesn't explain anything. The labels as they are now are explanatory texts. They tell the user what's going on, they aren't merely "headers" to the lists.

no

How is this better than before?

@z: I mentioned the Videos in one of my "Message of the day"'s, yes. :) The videos have my full endorsement

In the same way BSA extraction allows you to resolve conflicts it allows you to cause new ones by loading scripts in different order than the esp which is 50% of the reason the feature discussed here exists. If this feature doesn't work, BSA extraction doesn't work, they are dependent! The fact that MO makes BSA extraction easy is part of the reason Arthmoor and other mod authors have been raging against MO and at times refuse to give support to MO user for the simple fact that - to the community as a whole - BSA extraction causes a lot more problems than it solves. I don't want to piss off MO users but I want to piss off Mod Authors even less.

I didn't post the last comment because I was bothered by this thread, only to inform you that you shouldn't be expecting me to participate. To clarify my point: I do not consider bsa extraction a good feature. I implemented it on request and had nothing but trouble with it. To this day I couldn't figure out the reason people extract bsas except for "someone claimed 8 years ago when Oblivion was current that it's a good idea." That's not really a question, right? ;) What do you want to know? If this can be done? sure, why not? Would it be a good idea? I really don't know. I develop a windows application, I don't know more about Skyrim modding itself than the next guy. Could it be a problem that you'll be loading scripts from mod x which may refer to asset files from mod z? Prolly? I honestly don't know. My advice would be: Don't start applying workarounds in your "productive" MO installation because you want to use the current Beta but can't wait for a bugfix.In fact: Don't use Beta software if you can't live with bugs

Guys, just to let you know: this is far too much text. I'll not continue to read this thread, I just don't have the time. If you think something requires my attention boil the problems down for me to minimal test case that allows me to reproduce the issue. On the issue tracker! bullet points is fine, entire novels are not. If we don't get this feature working I will just remove bsa extraction and separate bsa ordering from MO altogether and be done with it.

@z: We aren't talking about physics or mathematics here where one thing is definitively truth and one is definitively wrong. As I said: In the virtual directory files get overwritten as the mods are read into it. There is no difference between this overwrite and an overwrite on disk except that one happens in fleeting memory and one happens in persistent memory. Thus the term "overwrite" is not wrong, it may merely be misunderstood by users. And no: The overwrite directory does not represent files that get overwritten on disk! MO doesn't overwrite stuff in the target directory (Skyrim/data) at all. skse plugins and tools started from MO moved or created files into the target folder and since MO is supposed to keep that clean it redirected the files to the overwrite folder. But for the purpose of reading "Overwrite" is treated like any other mod with guaranteed highest priority and thus gets to (virtually) overwrite the content of all other mods. It is always if it conflicts. That's why it's called "Overwrite". To rephrase: For the purpose of reading "overwrite" is a simple mod with priority infinite. For writing "overwrite" is priority and catches all write accesses that haven't been assigned to another mod. And there ends the specialness of "overwrite". Tbh I do NOT think we should start talking about "override" to make a distinction from "overwrite" and we shouldn't talk about virtual overwrite. When we explain to users how MO works, what we should say is: "It works as if the mods got installed on-the-fly in the order they are arranged on the left pane whenever you start the game. In practice nothing changes on disk and the process is almost instantaneous but it works just like that. After the start, any files that would be created inside the skyrim/data directory or moved there are instead created in/moved to overwrite". I think this is all the user needs to know about the workings of the virtual fs. Everything else is technical detail he may read up on if he cares but is not essential to use MO.

As I said: If this is 1.2.1 I'm not surprised if there are new bugs. This is a beta after all. In this case please create an issue report. one for each thing you noticed. If it's an older version I don't really care because, as I said the algorithm changed and I won't fix the old one.

Last things first: There have been a lot of contributions to MO in some form or the other. There's the help people provide on forums, on the wiki in videos. There's the translations, graphics (splash screen and icon are user contributed), bug reports and improvement requests, ... And in fact there have been a few code contributions. But the reality is still that most of the programming work is done by me and I have to weighted regarding use vs. cost by me and very often the cost may be surprising to users. And all that I have to weigh against my free time which, to me, also has value. Now regarding priority vs. x - no offence - but I whole-heartedly disagree with you Uhuru. For one thing "Load order" for the plugins would be wrong because what I currently call "priority" puts all plugins, enabled and disabled into an order. Not all of them get loaded! "Mod Order" would also be confusing because differentiation between "mod" and "plugin" is hard. After all, the index of a plugin which corresponds to its load order is called "mod index" in almost all documentation. So, how am I gonna explain to users that the "Mod Order" is an attribute of the "mod package" whereas the "mod index" is an attribute of the plugin? Its madness. Secondly "Load Order" is a technical term: Order in which things get loaded. It has been largely established in the community but it's not a very good term because it doesn't say what that order means for the user. You have to know how the engine loads plugins to understand that a plugin loaded later will override stuff from plugins loaded before. Or if you don't know you may assume and there is a 50% chance you assume exactly the opposite of what is happening. "Mod Order" on the other hand is not technical it doesn't communicate anything. It's an order of mods. So is "alphabetic". So is "by size". But what does the mod order mean to the user? Thirdly: I consider priority on mods and priority on plugins the same thing, they both say: "The contents of this thing (mod or plugin) is more important to me than that with the lower number. So in case of conflict, I'll take the stuff from this thing, thanks.". It's a more abstract concept. Regarding override vs. overwrite: I'll have to trust you guys if you say "override" is more appropriate. I'm not a native english speaker, the word override in this context never occured to me. In programming "override" means something very different. I considered "overwrite" an appropriate term because for all intents and purposes the files from one mod overwrite those of the other mod virtually. Either way, I'd like to point out that the word "overwrite" appears in many places. "mod a overwrites mod b". the overwrite "mod" overwrites all other mods. the overwrite mod corresponds to the overwrite directory on disc. Where are we going to make the cut? Do we still call the overwrite mod "overwrite"? isn't that more confusing than anything if we then have to explain two terms "override" and "overwrite" instead of just saying "overwrite is virtual. It doesn't affect the files on disc it just says which file becomes visible in the virtual directory." Or are we going to rename the overwrite mod too? In this case I'd have to migrate existing MO installations. And what do I do if a user already has a directory (or file) called "override" in his MO directory? And what about users that have set up scripts to move files from the overwrite directory to separate directories? In both cases we would have to update the wiki, update the tutorial update the videos because if we don't we will be causing more confusion by changing terminology than we're going to clear up by using a better name. And what about tutorials/explanations/... outside our control? There are MO discussion threads on other boards in foreign languages (and a more xxx oriented community ;) ). We'll be outdating a lot of information about one of the more complex topics on MO. This is sooo much work and so much potential for breakage. I'm not saying changing the term is a bad idea but is it really worth it?

Yes, you have to use the versioninfo class like this: mod_interface.setVersion(mobase.VersionInfo(1, 1, 1, mobase.ReleaseType.final))The following may also work, I'm not sure: mod_interface.setVersion(mobase.VersionInfo(1, 1, 1))Parsing the filename into mod name/id/version is not reliably possible unless you plan to write an AI ;) The way nexus mangles these file names makes correct parsing impossible, you can only guess and computers are notoriously bad at that. That being said, the regular expression I currently use in MO is fairly successful, you are of course welcome to use it: ^([a-zA-Z0-9_- ]*?)([-_ ][VvRr]?[0-9_]+)?-([1-9][0-9]+)-([0-9-]*).*mod name will be in match group 1, mod id in group 3, version (with - instead of .) in group 4 Getting information about a mod from nexus is currently not possible but I'll see if I can add this for the next release.

The first message only tells you that MO doesn't have a Danish translation. I assume that's your system language hence MO tries to load it. No problem here, it uses English as a fallback. The second message probably has the same cause as the download problem, neither is the reason for the other.Both error messages tell you that MO can not open the directory C:/Users//Desktop/ModOrganizer/downloadsThat directory doesn't exist or MO isn't allowed to access it. Please double check that there isn't a typo in that path like a wrong letter in the user name or maybe your MO path on disk has a space between "Mod" and "Organizer"? One more thing, though I doubt it would cause a problem: Does your username by any chance contain any funny letters not found in the english alphabet, like an Ø ?

MO can't open the file it's trying to write to. This is most likely because the output directory doesn't exist or because MO has no write permission to the directory. If MO was simply missing the "downloads" directory it would have created it, more likely something is wrong with the path "C:/Users//Desktop/ModOrganizer" (btw. / or doesn't matter)

Yeah, sorry, it turned out that interface wasn't exposed to python yet. This is fixed in 1.2.1. Also, the installMod function now returns the newly created mod. this means you don't have to call self._mo.getMod anymore because if the user renames the mod that call would fail.

Correct.

The algorithm is very simple: If scripts from two mods conflict the scripts should be loaded in the same order as the corresponding esps. There is no potential for cirular dependencies here. The order is very very likely the safest because If the scripts were bundled in a bsa (which is what Bethesda intended) and you were not using MO then scripts would be loaded in this order anyway (with no way to customize). To my knowledge the algorithm (at least up to 1.2.0) is perfect in that it never suggests an order that differs from the esp order. The only margin for error is if a mod contains multiple esps and they aren't loaded in one block. It does suggest moves that aren't necessary but won't hurt either (false positives). In 1.2.1 the algorithm hopefully doesn't report false positives anymore but since that is the newest version it may contain new bugs.

You're using the MO 1.2.0 beta version, which includes a broken version of ncc. ece didn't install correctly and so wrye bash was correct in reporting an error. Please apply the ncc downgrade from the MO page on nexus or wait for the update to 1.2.1.