Mod Organizer

[bob11]

 

I need to edit and compile a script from an existing mod.  Running notepad++ through MO and trying to compile from within doesn't work, as the script is in mod organizer's directory.  As I don't want to bundle the game with extras, is there a way to compile through MO?

Just install mods you need to compile directly in the Skyrim folder like normal. As long as Mod Organizer doesn't have it's own version of the mod, it won't overwrite it when launching with MO.

 

I install all my mods through MO, but I do all the work on SexLab directly out of the data folder, haven't had any problems.

 

Yes, that's the issue I have, I wanted to compile a Sexlab script, but unless all scripts are in the data folder, trying to compile from within MO doesn't work.  I just made temporary copies in the data file, compiled, then deleted the temps and moved the script to sexlab's folder in MO.  That's a crude solution though.  I was hoping for something more elegant from inside MO.

[Ashal]

just leave all mod dependencies for the mod your working on in the data folder, so install sexlab and your own mod to data and work like normal. Don't load creation kit from MO either, load it directly as well.

 

Mod organizer shouldn't ever come into the equation except when starting skyrim in order to test something.

[AwfulArchdemon]

In Mod Organizer, you have a list of mods on the left column. Your .esp files will be on the right column. You'll see little +/- icons next to mods when you activate them, as previously stated. When you use MO, these overwrites have not actually happened yet. They are a "preview" of how the information will be read by your game when you run it. The files will never reach your data files, as they do in NMM. This means that the chance that files will be "left over" after installation is removed. Your game will run it's files, and your MO will "temporarily" (for lack of a better word) add the mod's information to the game using it's own path. It is referred to as a "virtual path", and it's the safest way to use a mod.

 

Programs like Creation Kit, NifSkope, Blender, Photoshop, etc are better left out of MO. MO can run all kinds of stuff, but not necessarily at their "full potential". Editing and compiling are an example of this limitation.

 

MO has a tab on the right called [ Downloads ], that keeps track of the mods you've downloaded from Nexus. If you ever accidentally "remove mod" from MO, this makes for an excellent back-up.

 

By right-clicking a mod, you will see a list of options appear. From here you can enable all mods at once. I wouldn't recommend doing that, if you just toss a ton of mods in MO, which is why it is good to remember to create more than one profile. I have many.

 

One of the options that appears is "Remove mod". If you click that, and confirm that you want to go through with it, your mod disappears from existence. Therefore, always download mods into a desktop folder, for backup purposes.

 

Another option is "reinstall mod".  If you downloaded the mod directly to MO from Nexus, you can reinstall, and rename your mods right there and then. You have the option to rename any mods anytime by doing 1 of 3 things:

1)clicking the mod in MO to highlight it, and clicking again to turn the mod's title blue, indicating that you're now in edit mode

2)right-clicking the mod and clicking "rename mod..."

3)opening the mod "in explorer" and right-clicking the mod from within MO's files.

[bob11]

just leave all mod dependencies for the mod your working on in the data folder, so install sexlab and your own mod to data and work like normal. Don't load creation kit from MO either, load it directly as well.

 

Mod organizer shouldn't ever come into the equation except when starting skyrim in order to test something.

The main point in using MO over anything else is keeping the skyrim installation as clean as possible.  Adding stuff into data, especially something as heavily scripted as sexlab, beats the purpose.  CK through MO is running pretty well, at least for the minor changes I make here and there.

[AwfulArchdemon]

MO is not designed to be the glue that holds Skyrim together. You want your mods installed safely? Use MO. You want to edit the mods you downloaded, do it manually.

 

MO is not a mod editing tool, it is a mod organizer. It can do absolutely anything if you know exactly how it works, but if you do, you'll realize that the option you're looking for would need to be added as a plugin. As far as I know, Tannin42 is not adding such a feature in the near future, though it may happen eventually. Who knows.

 

Mod Organizer is already top-notch. I just hope I can help with all issues quickly. I'd hate to see negative posts regarding my best friend.   I'll try my best!

[bob11]

MO is not designed to be the glue that holds Skyrim together. You want your mods installed safely? Use MO. You want to edit the mods you downloaded, do it manually.

 

MO is not a mod editing tool, it is a mod organizer. It can do absolutely anything if you know exactly how it works, but if you do, you'll realize that the option you're looking for would need to be added as a plugin. As far as I know, Tannin42 is not adding such a feature in the near future, though it may happen eventually. Who knows.

 

Mod Organizer is already top-notch. I just hope I can help with all issues quickly. I'd hate to see negative posts regarding my best friend.   I'll try my best!

Well, the edits work though xP Sure they're basic but who cares

[AwfulArchdemon]

@bob11, if anything goes wrong with MO's primary functions, please inform me, and I will do my very best to resolve your problems.

 

Anything else, anything I haven't posted here yet (your problem, for example), I will eventually figure out, and post here. I am ever diligent, and further developments are being made (secret), so please be patient, while I solve them. I don't know EVERYTHING about MO, because I did not create it, but rest assured, all questions will certainly be answered, to the best of my ability.

 

Thank you.

AwfulArchdemon 

[bob11]

@bob11, if anything goes wrong with MO's primary functions, please inform me, and I will do my very best to resolve your problems.

 

Anything else, anything I haven't posted here yet (your problem, for example), I will eventually figure out, and post here. I am ever diligent, and further developments are being made (secret), so please be patient, while I solve them. I don't know EVERYTHING about MO, because I did not create it, but rest assured, all questions will certainly be answered, to the best of my ability.

 

Thank you.

AwfulArchdemon 

BTW, is it better to use the 0.12.9 stable, or go for the .99 beta?  Is the beta stable enough and does it have important features I'm missing?

[AwfulArchdemon]

I've heard no complaints about the Beta, however I use the 12_6 w/ 12_9 update.

 

Feel free to test (I endorse Tannin42's work) and report bugs. I could likely still give you excellent feedback, considering my source. I'd be surprised of things didn't work even better for you!  Also, I see myself using it soon.

[AwfulArchdemon]

About the Beta version of MO, it's quite likely that I'll be making my LL/MO plugin for that version. I need to check to see if that's a good idea, but it makes sense, because the Beta will evolve into his new version soon enough I'm sure, and I wouldn't mind releasing it on the newest possible version right away.

 

In case you didn't know, I'll be creating a plugin for MO, and the topic thread for it can be found here.

[Dorryn]

Hello there.

 

This is my first post here so sorry to kind of barge in like this but as a fervent user of MO I cringed when I saw this :

 

[...] be sure to say "NO" if it asks if you'd like to unpack the .bsa (if it has 1 or 2).

 

Now why would you not unpack your BSAs when using MO? The purpose of a BSA is to keep files confined within an archive so the data folder doesn't become a mess. It's useful with NMM but MO already confines every mod into their own folders so there's no point in not unpacking a bsa (unless they have another use I don't know about).

[AwfulArchdemon]

A bsa can be removed ever-so-easily. I said to say 'NO' because the mods I was using recently have all been updated (of course), and many of them like to use bsa's, instead of their previous esp's, etc, and I was noticing that some things weren't working properly. I then reinstalled real quick, and said no to unpacking, and sure enough, everything worked. Remember, even not unpacking .bsa files puts them in a "virtual path".

[AwfulArchdemon]

Mod Organizer! by Tannin42

 

 

 

MO is righteous. MO loves you. MO will guide you.

 

 

 

 

 

 

[Dorryn]

A bsa can be removed ever-so-easily.

 

So can a folder, which is why I don't see the point. But if keeping the bsa makes things work better for you then that's a good reason.

 

[AwfulArchdemon]

Why wouldn't I keep the bsa, if that's the feature in the mod that was added? If what I need is the bsa, I would 'unpack' it...why??

[Dorryn]

Why wouldn't I keep the bsa, if that's the feature in the mod that was added? If what I need is the bsa, I would 'unpack' it...why??

 

If you unpack the bsa the files in it will still be there, just not archived. That's what the bsa is : an archive same as a .rar or .zip.

 

Like I said it's usefull when you install your mods directly in skyrim's data folder, like you said it's a lot easier to remove one archive than loose files. However since MO keeps all mods separated in their own folder even loose files are easy to find and remove.

 

Also, if your bsa contains texture files, you'll have the possibility to safely optimize them with tools like DDSOpt or texture optimizer. (Although both have the ability to optimize files inside a bsa every tutorial I've read advises against it).

[chaoswings]

Why wouldn't I keep the bsa, if that's the feature in the mod that was added? If what I need is the bsa, I would 'unpack' it...why??

 

Because :

First Mod organiser has a conflict resolving option, unpacking the BSA permits MO to actually see all the files (textures, meshes and scripts), which permit you to determines the load order of your mod (independantly of the ESP) for (for an example) having the priority higher on a set of textures or script than on another, and that, you cannot do with a BSA, for that you must unpack, of course you can manage priority with a BSA but it does not serve any purpose if you don't know what's actually inside.

 

Second, Unpacking BSA permits you to check the "quality" of included textures, it is not a secret that a lot of textures are not optimized at all, the difference in size can vary from Simple to quintuple, if a texture does not have transparency the DDS file should in the vast majority of the case not be compressed in DXT 3 or 5, and instead in DXT1, because in the end if you have to load 10 times a texture because 10 NPC or anything else uses that texture it is preferable for your V Ram use that this texture is optimized (should you you reach the V ram threshold your game can CTD because of it), and if don't unpack you can't know if the texture is optimized or not, and if it is not, you can optimize it yourself.

 

OK sure, it is slightly better for loading the game that you have BSA, but unkpaking all my BSA to be able to resolve conflicts and optimize textures has proven to render my game (209 Esm/Esp, and even more if you count textures mods) more stable than using BSA and relying on a blind faith in what modders do.

[remois]

I don't usually unpack a bsa unless the mod is giving me problems... I'm an adept of the if it works don't mess with it...

[AwfulArchdemon]

 

Why wouldn't I keep the bsa, if that's the feature in the mod that was added? If what I need is the bsa, I would 'unpack' it...why??

 

If you unpack the bsa the files in it will still be there, just not archived. That's what the bsa is : an archive same as a .rar or .zip.

 

Like I said it's usefull when you install your mods directly in skyrim's data folder, like you said it's a lot easier to remove one archive than loose files. However since MO keeps all mods separated in their own folder even loose files are easy to find and remove.

 

Also, if your bsa contains texture files, you'll have the possibility to safely optimize them with tools like DDSOpt or texture optimizer. (Although both have the ability to optimize files inside a bsa every tutorial I've read advises against it).

 

True. This suggestion of mine suggests that those things will not be happening. My suggestion is mostly for people who will not be messing with their bsa's.

 

 

Why wouldn't I keep the bsa, if that's the feature in the mod that was added? If what I need is the bsa, I would 'unpack' it...why??

 

Because :

First Mod organiser has a conflict resolving option, unpacking the BSA permits MO to actually see all the files (textures, meshes and scripts), which permit you to determines the load order of your mod (independantly of the ESP) for (for an example) having the priority higher on a set of textures or script than on another, and that, you cannot do with a BSA, for that you must unpack, of course you can manage priority with a BSA but it does not serve any purpose if you don't know what's actually inside.

 

Second, Unpacking BSA permits you to check the "quality" of included textures, it is not a secret that a lot of textures are not optimized at all, the difference in size can vary from Simple to quintuple, if a texture does not have transparency the DDS file should in the vast majority of the case not be compressed in DXT 3 or 5, and instead in DXT1, because in the end if you have to load 10 times a texture because 10 NPC or anything else uses that texture it is preferable for your V Ram use that this texture is optimized (should you you reach the V ram threshold your game can CTD because of it), and if don't unpack you can't know if the texture is optimized or not, and if it is not, you can optimize it yourself.

 

OK sure, it is slightly better for loading the game that you have BSA, but unkpaking all my BSA to be able to resolve conflicts and optimize textures has proven to render my game (209 Esm/Esp, and even more if you count textures mods) more stable than using BSA and relying on a blind faith in what modders do.

 

Not bad for a 1st post.  However, I am not making this complicated. I am using a really simple formula here:

My mod's not working right, so a change must be made. I'll try saying "no" to unpacking bsa's. Oh good! My mod's working now.

 

If that had not worked so well, so easily, I wouldn't have done it. There really is no downside to my suggestion, if you aren't interested in checking your mods 'qualities', or messing with it's files at all (not that I've run into any problems at all using my simple method).

 

If people are running into any problems at all not unpacking their bsa's, just let me know, and I may edit my thread. Until there are any actual issues, this way works well for me.

 

I don't usually unpack a bsa unless the mod is giving me problems... I'm an adept of the if it works don't mess with it...

Exactly! Couldn't have said it better myself. I posted what I said because I was getting a few issues, and this solved it. Rather than have people post problems about why there mod isn't working right on their mod's authors' threads, I've considered this to be a 'shortcut to success'.

 

 

 

Nobody is wrong here! I'm not disputing any of it. My way removes some possible problems, and creates no problems of it's own, unless you need to change orders, based on files in the bsa. For those of you who want to optimize texture qualities, and change bsa load orders, and stuff like that, I'm sure you already know that unpacking is how that's done. This is a more basic guide than all that, and I doubt people who don't do that stuff are going to start unpacking their bsa's just because others, who DO do that stuff, are unpacking theirs to alter stuff.

 

I know this, it solved my problems (4 of them, actually), so I posted it that way, as "say NO to unpacking bsa's". If you plan on getting into more advanced things with your mods, then you already know when to, and when not to unpack your .bsa's. I'll just stick with saying no.

 

I sometimes forget how advanced most of our members are here on LoversLab, so if you want me to get into the far more advanced aspects of mod installation, then you will have to let ME get more advanced 1st. I'm no genius! I've been using a computer for 11 months now, and never even e-mailed someone before that. I knew nothing whatsoever about a computer.

 

All I know is, nobody made a thread about MO on LL yet. And, while I don't know EVERYTHING about mod installation, and MO, I DO know an awful lot about both. Therefore, I started a thread about MO.

 

I fully expect people to post their thoughts, and any helpful suggestions they may have here, on:

Mod Organizer

Started By AwfulArchdemon, Aug 19 2013 11:50 PM

 

Thank you all for your posts. I will be adding more info soon. My newest info will be based on the currently Beta version. So, any info posted after August 27th will be based on the Beta (0_99_2)

[Dorryn]

I'm curious : What mods were not working well when you unpacked their bsa ?

[AwfulArchdemon]

I'm curious : What mods were not working well when you unpacked their bsa ?

Hmm, I forget exactly which one's were the troublemakers, since I've changed a couple mods. I'll just post my current bsa list:

[Dorryn]

I don't see FNIS anywhere. Did you put it in your data folder?

[AwfulArchdemon]

[WizzyD]

FNIS.jpgFNIS2.jpg

 

can you list all those lines here in plain text?

 

so ppl can just copy and paste them into the editor

 

especially the argument line

 

trying to get fnis 4.0 beta added

 

 

 

edit:

so well then

 

spent 2 hours searching on how to add fnis to MO

this seems much easier than manual

 

 

 

[AwfulArchdemon]

Specific FNIS installation insructions.txt

I added mine in manually, then I made it run using MO.