Jump to content

Question

  • Answers 68
  • Created
  • Last Reply

Top Posters For This Question

Recommended Posts

  • 0
Posted

Hmm, I didn't actually have the priority bug with 1.2.3, but found some other strange behavior with external mods after switching the "Display mods installed outside MO" setting off and on again.

 

Wasn't finished repeating the series of steps to type a bug tracker report, so I'll try it again with the 1.2.4 beta, and if it's still happening, will post to bug tracker.

  • 0
Posted (edited)

Started testing with 1.2.4 today.

The new pseudo-mod handling seems to work very well and just as expected.  Not found any issues at all yet. Great job!

One thing I'm not so keen on - it seems like the mod installation "Extract BSA" dialogue option has been removed completely. It's no longer asking me if I want to extract BSA files when I install a mod. I reset my dialogues to be sure it wasn't a stuck "Always" option.

I'm guessing this is deliberate, because of all the kerfuffle with extracting BSAs?

 

EDIT:  Actually it's not been removed!  Well hopefully :)  See next posts from DoubleYou and myself;  the Exe installer is missing a couple of files compared to the 7z archive, one of which is the BSA extraction plugin that handles this.

 

Presumably that was unintended.  If it wasn't, then Tannin can confirm - and I'll ask that if he really doesn't want BSA Extraction to be obvious, that he includes the plugin but has it disabled in the Plugins menu by default.  But for the moment I'm assuming it was just a mistake.

 

 

 

Another issue - which may be a bug - the Conflicts tab is really slow to update with BSAs.  I actually nearly raised a bug just now, because I re-installed all the Unofficial Patches, such that they would change from Loose to BSAs.  After doing that, every one of them showed 0 Conflicts, and the "Unconflicted Files" section showed - for example for USKP - '5 files'.  Where it should be thousands.   Eventually, after I'd clicked around in the interface a few times, taken a couple of screenshots, and come here to write the top half of this post, I then noticed that it was correctly showing Conflicts.  It felt like it took several minutes until they were updated.

 

So maybe that's a bug.  Or maybe it's an inevitable result of the time it takes MO to process a 125MB BSA file to get a list of files to compare for Conflicts?   I'm concerned it might be the latter, and it's therefore another reason why someone might (I emphasise might!) want to continue extracting BSAs.

 

EDIT:  See later posts from DY and myself; it's definitely not a performance issue, and does seem like a bug.

 

 

 

I also have some other feature request changes I'm going to raise in this area - such as improving the Filetree/Conflicts so that, for extracted BSAs, it lists all files, including those that don't conflict - thus further mitigating one of the last benefits of extracting all BSAs.

 

But the great news is that 1.2.4 seems very stable to me; certainly it has been a drop-in replacement for 1.2.1 for me today.  Awesome work Tannin, thank you as always!

 

PS. Love the new AND/OR option in the filter, thank you!  I had been meaning to request that, and there it is anyway!  Makes filtering properly useful now.  Much appreciated!

Edited by TheBloke
  • 0
Posted

Started testing with 1.2.4 today.The new pseudo-mod handling seems to work very well and just as expected.  Not found any issues at all yet. Great job!One thing I'm not so keen on - it seems like the mod installation "Extract BSA" dialogue option has been removed completely. It's no longer asking me if I want to extract BSA files when I install a mod. I reset my dialogues to be sure it wasn't a stuck "Always" option.I'm guessing this is deliberate, because of all the kerfuffle with extracting BSAs?I have to say I'm not super keen. I can understand hiding the option away a bit more, maybe require enabling it in a menu. But I don't like removing it completely. I'm pretty sure I want to move to having mostly unextracted BSAs.  But I would still like the choice when I install mods.  I know I can go to the Archives tab, right click and choose Extract.  But that's not nearly as convenient - I have to manually browse for the right mod directory, then manually delete the BSA afterwards.

 

Although I know there are many clear benefits to not extracting BSAs, there are also some downsides.  A key one is that I can no longer browse to Mod Organizer/mods// and see all files, and easily open any file.  Nor can I seem them all through MO's internal Filetree.  

 

My suggestion:  if it's Tannin's desire to really "bury" the extracting BSAs option, then how about adding a new config option - in Workarounds if you like - saying "Ask to extract BSAs?"   Defaults to off.  If selected, it re-enables the previous behaviour whereby the user is prompted after each mod install to extract any contained BSAs.    Tooltip on that new config option warning that it's unsafe and not supported, can cause cancer and impotence, and if it's selected Arthmoor might come round to your house and take a dump on your porch.  Etcera.

You must have used the installer version. Grab the 7z. It has the BSA Extractor plugin in it (not sure why it's not in the installer). Go to plugins tab in Settings and set it to true to enable the dialog.

 

Another issue - which may be a bug - the Conflicts tab is really slow to update with BSAs.  I actually nearly raised a bug just now, because I re-installed all the Unofficial Patches, such that they would change from Loose to BSAs.  After doing that, every one of them showed 0 Conflicts, and the "Unconflicted Files" section showed - for example for USKP - '5 files'.  Where it should be thousands.   Eventually, after I'd clicked around in the interface a few times, taken a couple of screenshots, and come here to write the top half of this post, I then noticed that it was correctly showing Conflicts.  It felt like it took several minutes until they were updated.

 

So maybe that's a bug.  Or maybe it's an inevitable result of the time it takes MO to process a 125MB BSA file to get a list of files to compare for Conflicts?   I'm concerned it might be the latter, and it's therefore another reason why someone might (I emphasise might!) want to continue extracting BSAs.

Click refresh to immediately show conflicts (don't know why the auto-refresh seems slow, but this has been what I've been doing for some time now).

  • 0
Posted

Well I am a little late to the party due to a complete system reinstall, which gives me an opportunity to hopefully test out some things that I could not before.

So far I have Skyrim, Fallout NV and Fallout 3 installed along with NMM. NMM has been run and it is associated with all the default settings. All the games have been updated to the current releases with all of the DLCs available.

 

I have downloaded the beta v 1.2.4 and for now it is installed for Skyrim. Upon first run, MO wanted to set the association for the NXM download link, which I let it do.

 

MO had detected the DLC and Highres texture packs as expected. My installed pseudo mods are as follows:

 

HighResTexturePack03, priority 0.

HighResTexturePack02, priority 1.

HighResTexturePack01, priority 2.

HearthFires, priority 3.

Dragonborn, priority 4.

Dawnguard, priority 5.

 

The Plugins were as follows:

Skyrim.esm

Update.esm

Dawnguard.esm

Hearthfires.esm

Hihhres pack 1

Hihhres pack 2

Hihhres pack 3

 

Archives tab is as follows:

Data

Hihhres pack 3

Hihhres pack 2

Hihhres pack 1

Hearthfire

 

On to modding.

  • 0
Posted (edited)

You must have used the installer version. Grab the 7z. It has the BSA Extractor plugin in it (not sure why it's not in the installer). Go to plugins tab in Settings and set it to true to enable the dialog.

Ah ha! How strange!  Thanks.

 

OK so I have run a comparison of the Exe versus the 7z, and found a few more files that are missing. Specifically:

[*]dllsboss.dll

[*]NCCGamebryo Base.dll

[*]pluginsdatapyCfgDialog.pyo

[*]pluginsbsaExtractor.dll

[*]pluginshelloWorld.dll

[*]pluginstestnexus.py

The last two definitely look unimportant, but the others may be important; the bsaExtract.dll certainly is.

 

I've raised this for Tannin here: https://issue.tannin.eu/tbg/modorganizer/issues/659

 

In the meantime, for other beta testers - it appears that the Exe installer version is incomplete, and that the 7z should be used in preference for 1.2.4.  

 

Click refresh to immediately show conflicts (don't know why the auto-refresh seems slow, but this has been what I've been doing for some time now).

What Refresh button are you referring to?

 

I just tested it again. I installed a new mod with a 350mb BSA file. I confirmed that the Conflicts page just showed '2 files' (the ESP and the BSA), and this persisted for at least one minute. Then I went to the Data pane (right hand side), and clicked Refresh. No change in Conflicts. Then I clicked the Refresh at the top of the mod list (left hand pane). No change in conflicts. Then I tried clicking back and forth between all the tabs of the right pane (Plugins, Archives, etc). No change in Conflicts.

 

A further 2-3 mins later, the time it took me to come here and type that paragraph, and Conflicts is still not updated; still shows two files. I've tried clicking both Refresh buttons again, no difference.

 

After 8 minutes total, it still had not updated. At this point, I re-started MO. As soon as it re-opened, conflicts were showing for that mod.

 

So am I missing a Refresh button somewhere? Otherwise, I can't seem to get it to trigger a refresh like you described?

 

Either way, I'm raising this one as a bug - I think it should just automatically refresh the Conflicts as soon as it can, without manual intervention ever required.

 

Bug report here: https://issue.tannin.eu/tbg/modorganizer/issues/660

 

It only takes a few seconds to extract a 350mb BSA file on my system, so it shouldn't take more than a few seconds to get the file list (if anything, less.) Based on what you said, it seems like it's maybe on a delayed refresh cycle or something?  Perhaps that's for performance reasons, but I find it really annoying and confusing. If it's really needed for performance for some people, it should be an option.

 

So I hope this can be changed so it automatically updates conflicts for BSAs (or within a few seconds at least), like it does for loose files.

 

Update:  It's more complex even than the above.  Restarting MO causes a BSA mod to show conflicts.  But so does installing a new mod.  So if you install mod#1, and only that mod, then its conflicts will never update unless you restart MO.  But as soon as you install mod#2, mod#1's conflicts will update - but then mod#2's won't be updated!   It gets even stranger; if you restart MO to get mod#1's conflicts to show, then you untick & retick it in the mod list, it will again not show any conflicts.   However once you've installed another mod, mod#2, you can untick & retick mod#1 (or any pre-existing mods) as many times as you like, and their conflicts will always show.

 

So it seems like restarting MO causes some kind of refresh of conflicts, but it's not a permanently saved one - but installing a new mod seems to make all previous mods calculate, and store/cache their conflicts, so that they never disappear again.

 

Weird in operation, but hopefully some obvious/easy fix for Tannin :) 

Edited by TheBloke
  • 0
Posted (edited)

The Refresh button is found at the top of the Data tab of the right-hand pane.

 

It's a really wide button, can't miss it.

Yeah that's the first one I tried ;)

 

Then I went to the Data pane (right hand side), and clicked Refresh. No change in Conflicts. Then I clicked the Refresh at the top of the mod list (left hand pane). No change in conflicts. Then I tried clicking back and forth between all the tabs of the right pane (Plugins, Archives, etc). No change in Conflicts.

 

I've tried clicking both Refresh buttons again, no difference.

Edited by TheBloke
  • 0
Posted (edited)

Change request regarding formatting/highlighting of new "pseudo-mods":

 

 

Tracker link:

https://issue.tannin.eu/tbg/modorganizer/issues/661

 

Description:

I would like to request the following changes to the highlighting of the new "psuedo mods":

[*]Red Blue or Green text for all fields, to extra-highlight these special mods

[*]EDIT: DoubleYou pointed out in the Tracker comments that red is bad because it indicates 'problem'. I quite agree, so am suggesting blue or green instead now

[*]Add a new special category for pseudo-mods

[*]I would suggest that vanilla/DLC content is labelled with category "Vanilla/DLC"

[*]There could then be a separate, "Outside MO" (or similarly named) category for content which is not vanilla/official/DLC, but is still a pseudo-mod.

[*]Remove the conflict icon

[*]I can't double-click on these mods and view the Conflicts tab. Therefore I find the presence of a conflict icon distracting and misleading.

[*]Furthermore, removing this conflict icon also serves to better visually differentiate pseudo-mods from normal mods.

 

Screenshot mock-up of my requested changes:

Posted Image

 

(click image to view it properly!)

Edited by TheBloke
  • 0
Posted

Change request: provide enable/disable checkbox for pseudo-mods:

Tracker link:

https://issue.tannin.eu/tbg/modorganizer/issues/663

 
Description:


It's great to have the new pseudo-mods, allowing precise positional control of vanilla/DLC content.

But I was hoping that this could also provide the ability to enable and disable the pseudo mods.

At the moment, if I want to play a game without, say, Dawnguard - or create a no-Dawnguard profile, for example for testing compatibility of my own mod in various configurations - I have to first manually untick the ESP in the load order, and then manually untick the BSA in archives.

This isn't a vast amount of work, but it's a different process required than for all normal mods.

So what I would like:

  • Pseudo-mods display the normal enable/disable checkbox in the mod list (left pane)
  • Unchecking a pseudo-mod works the same as unchecking a normal mod; the ESP(s) and BSA(s) for that mod disappear from MO's view, no longer appearing in the Load Order and Archives tab.
     
  • 0
Posted

I've noticed some unexpected behavior "bugs" related to refreshing the mod priority / plugins / assets lists after either toggling the "Display mods installed outside MO" feature under the Workarounds tab in the Settings menu, or if mods in the real /Skyrim/data are moved out / deleted while MO is running.

 

The Tracker Link for my report to Tannin is here (#664).

  • 0
Posted (edited)

Bug: Mods with BSAs: Conflict tab shows Hide menu, but Hide fails on any BSA-contained file.

 

Tracker link:

https://issue.tannin.eu/tbg/modorganizer/issues/665

 

Description:

I don't think this is a new bug in the latest betas, and it's not related to the new features added by these betas.

 

I'm mentioning it in this thread regardless, because it is relevant to our recent discussions regarding BSA extraction and the pros and cons of doing so.

 

In brief: the Conflicts tab displays a right-click menu showing the option to Hide files. It displays this for all (conflicted) files, including those that are contained within BSA files.

 

However, the Hide operation fails when attempted on a file that is within a BSA. It displays a Windows error message, indicating that MO attempted to rename the file as if it were a loose file, stored discretely on disk.

 

My thoughts: At the bare minimum, the Hide option needs to be removed for files contained within BSAs. But I am planning to talk to Tannin to ask him whether it might be possible to extend per-file conflict resolution to files contained within BSAs. In other words, whether he can find a way to either a) rewrite the BSA header, renaming files or b) implement some kind of on-the-fly hiding of files within a BSA, at the time of creating the virtual file system.

 

I was really disappointed to find that per-file hiding of conflicted files is not possible for BSA-contained files. I was nearly sold on the growing consensus that extracting all BSAs may not be the best idea. I was sold on it because I thought I could still handle per-file conflicts - mislead because I saw the right-click -> Hide option, even for files in a BSA. Sadly I didn't actually try it until today, and have now found there's no special implementation of file hiding for BSA-contained files.

 

I'm now thinking that I will go back to extracting everything, which should be safe as of the latest MO which can interleave the Unofficial patches. Nonetheless, it would be awesome to have the ability to keep BSAs (e.g. for the performance benefits, particularly on non-SSD storage), and maybe that could be possible if Tannin can find a way to extend file Hiding/renaming to files contained within BSAs as well.

Edited by TheBloke
  • 0
Posted (edited)

Mentioned it elsewhere, but just for the record: I have no more bodyslide issues with 1.24 and everything looks good. My thanks to Tannin for all the hard work.

 

[edit]

 

Didn't get around to attempting to compile scripts under the CK however. I'll try that tonight.

Edited by DocClox
  • 0
Posted (edited)

Can someone explain to me what the DG and DB patches that appear at the bottom of my mod list are. What are they for? Where shoould they go? What should I do with them?

 

EDIT: It also puts Hearthfires, HR3, HRT2, and HRT1 at the top in that order, which I'm pretty sure is wrong. Then it puts DG an DB pseudo mods at the bottom along with the the DG and DB patches, which I'm also pretty sure is wrong. Even if I change it manually it reverts back if I hit refresh. Is this just me?

 

I installed like I normally do by extracting the files from the archive into my existing MO folder.

 

It was also nice to have be able to refresh by right clicking.

Edited by Vulgar1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.