Actually I'd fully expect this. If I ask Bash to import the face records from a mod that has ONLY new NPCs, what choice would it have but to include the mod as a master? Where else would the NPC records come from for the face patcher to use? If this is what you're getting at then such records need to be ignored entirely as there's nothing to change.



I don't use the COBL Races stuff to begin with so I'm not familiar with the setup, but if the ESP is referencing records found in the ESM, I'd expect to see that ESM get added as a master. If the plugin is only modifying face records on vanilla NPCs, I'd expect it should only pull the needed data and modify the vanilla NPCs accordingly. Without pulling in either the COBL ESM or the TNR ESP as masters. Unless of course there's hair and eye data that only the COBL ESM file can provide, in which case I'd hardly consider it out of the ordinary for that to be pulled in as a master to the patch.



If the faces contain data that can only be provided from the COBL ESM file, what choice would they have?



That would be nice, yes. The random hair/eye thing isn't something I particularly care about, and I've taken active measures in my own mods to avoid having them added to the patch for things like that.

I get it now. :facepalm: That is going to be even better than I thought it to be - the ability to eliminate error-prone selections in the bashed patch window for mods that are not supposed to be active.

Cant wait for the fixed up version! Thanks for taking the time to explain :icecream:

What about the case where the user has 255 mods active (not including Cobl Main.esm) and tries to import from Cobl Races TNR.esp? The patch now requires Cobl Main.esm, and the patch is now broken. The game crashes due to a missing master if the patch is active, and the missing master can't be activated because there's no room in the load order.

Maybe I'm missing something and need to see how that COBL plugin is set up, but if it needs records from the COBL master, why wouldn't it need to pull that data in as a patch master? And why would the ESM not already be active anyway?

Ok, well that was fast: http://img574.imageshack.us/img574/8305/coblraces.jpg

The circled eye reference exists only in Cobl Main.esm. I don't see any other way for this to work other than making Cobl Main.esm a master to the patch. The data for that eye record assignment doesn't exist anywhere else.

You know what (I think) would be cool? If you could associate a picture with a BAIN archive or project. Like OBMM. Would that be a simple request, or would that be a pain in the *** to accomplish?

Suggestions/bugs time:

(Based on 290, I'm not too fond of using unstable code.)

- Drag and dropping a package in the installers list doesn't work properly if you apply a sort such as "projects first". The mod gets dropped at an offset instead of where you wanted to place it. Proposed solution: package takes the place (number) of the one your cursor was hovering over.

- Hiding a package is buggy (described in detail in my previous post).

- Can you please make it so that the selected package(s) is always visible and bright, even when you click in another part of the UI or Wrye Bash doesn't have focus?

- A way to open the installed files would be immensely useful, for instance to edit an .ini file without having to hunt for it in Explorer.

- A question that always bothered me: when you modify an .ini file, Bash stops tracking it for deinstallation since it doesn't match the one included in the package, isn't it? I think we need a set of tools in that area, to: a) list orphaned files that don't belong to any mod b ) give you and option of removing such orphaned files when their name matches a file in a package that's being uninstalled c) copy some of the orphaned files to a project or package for backup purposes, very convenient to keep a copy of a cleaned esp or edited ini.

- BAIN overwrites original Oblivion files without asking questions, right? It can be annoying when testing out a terrain noise mod or one overwriting vanilla music. Since those files are well-know, could we make a quick list of them and set up things so that BAIN has a special "vanilla Oblivion files" project where it backs up any overwritten original? Using the package paradigm would be very useful to see at a glance which vanilla files have been overwritten and by which other packages, and would allow a quick restore. However since vanilla files can be huge (the .bsas) the package should probably be semi-fake and only contain a copy of files that have been overwritten.

- Markers (==last==, etc) in the installers list are very pale, and are hard to see especially when dispersed along a very large mod list. I suggest making them very bright and conspicuous instead. Some kind of non-intrusive quick jump from a list of these markers would also be useful.

- The workflow for moving a bunch of mods to the proper section in your installers list is not very good: 1/ Select mods 2/ Scroll up to spot the right number 3/ Scroll down to the selected mods 4/Move To... and input the number, if nothing distracted you on the way. This would be much easier if the Move To... dialog was non-modal but stayed on top, and you could scroll to find the right spot while having the dialog box open.

- Displaying from which package a mod/ini tweak comes from is immensely useful, thanks a lot for adding that feature. Now all that's missing is the ability to jump directly to that package in the installers list.

- Oh, and probably not trivial to implement, but would be so, so useful: a search-as-you type filter for every bash tab: mods, installers, saves, ini tweaks...

As usual thanks for all your hard work, and a Happy New Year!

There's nothing special about Cobl Main.esm & Cobl Races TNR.esp. They're just examples that I had handy. Cobl Races TNR.esp simply uses hairs and eyes defined in Cobl Main.esm.

Let's start over. You're getting too caught up in the particulars and aren't looking at it in a general sense.

The basic question is simple. When the patch is being made, should non-active masters be unconditionally added to the patch if an imported formID requires it?

Right now, this means the face patcher, but it doesn't only apply to the face patcher. In the future, other import patchers may be written that need to work with imported formIDs. One example would be extending the graphics patcher to import magic effect shaders, enchantment effects, and lights. Any proposed answer should be generic enough to work with any potential future patcher.

Pros:
1) Any formID can be imported.
2) Simpler code.

Cons:
1) The patch can become dependent on a master that isn't present.
2) The patch can become dependent on a master that the user didn't actually want active.
3) If the load order is already full and a non-active master is added, the patch is unusable.

This is a subjective call, but I don't believe in general that the advantage outweighs the disadvantages. The patch should not be trying to activate masters that the user didn't select. The user should be in charge, not Bash. That said, the disadvantages can be worked around if the user is savvy enough to realize what importers are pulling in the unwanted masters. They just have to deselect the problematic imports. In my experience though, there are many users who can't figure this out very easily.

If we work from the premise that the patch shouldn't add non-active masters (or at least should be able to decide it on a case-by-case basis), we come to the conclusion that formIDs referring to non-active masters have to be handled in some manner. Either filtering them out, or marking them so that Bash can decide what to do.

Pros:
1) The patch won't depend on missing or unwanted masters.
2) The patch won't accidentally try to make more than 255 mods active.
3) Patchers can make more complicated decisions when importing formIDs.

Cons:
1) Slightly more complicated code.
2) The patch might not add any non-active masters even if that's what the user actually wanted.

There are several possible implementations:
1) Just don't import formIDs. This is the simplest, most fool-proof, yet most restrictive method. As long as the master is active (which is most of the time), formIDs are perfectly safe to import, but this method still prevents it. The underlying issue still exists, but it never comes to light.
2) Have CBash somehow mark formIDs that reference a non-active master. For example, when CBash loads a record, set any formID that references a non-active master to a special value (such as 0xFFFFFFFF). When Bash tries to import the formID, it can check for this special value to decide what to do (skip the entire record, just skip that formID as appropriate, add the missing master, etc).
3) When CBash loads a record, discard the entire record if any formID in it references a non-active master. Any records left over are safe to use, but a lot of information is lost. Additionally, this may break other records in the mod that refer to the discarded record. A decision would have to be made whether to also remove any records that reference the discarded record, and much of the mod may unravel. Otherwise, any formIDs would have to be tested to see if they're still valid.
4) Rather than change CBash, just have Bash look for and handle any formIDs that aren't safe on its own.

For both Bash and CBash, all import patchers except faces follow #1. It works, but it limits what the patchers are allowed to do.

#3 is much simpler to implement than #2 or #4. It also guarantees that any record that survives the pruning process is completely safe to work with in any manner, so no special attention has to be given when writing new patchers or maintaining old ones. It provides consistency in behavior at the expense of flexibility. A patcher may only be interested in the non-formID fields of a record, but loses access to the entire record with this method. Csv files and filter mods are already filtered like this.

#2 and #4 are almost identical, #2 just offloads some of the work to CBash where it can be done more quickly. Both of them require the coder of each patcher to determine the "best" way to handle any potentially unsafe formIDs, and this would be handled on a patcher by patcher case. Over time, this could become confusingly inconsistent as some patchers drop only the formID, other patchers drop the entire record, and other patchers go ahead and add the missing master to the patch. It makes maintaining patchers more work, but it gives the most flexibility too.

I lean towards #2 even though it means more work. I think the flexibility is worth more than the consistency that #3 gives.

For the face patcher specifically, #1 means that all the face data except the hair and eyes are imported even if the hair and eyes happen to be safe. #3 means that none of the face data will be imported if the hair and/or eyes require a non-active master, but all of the face data will be imported otherwise. #2 & #4 mean that the decision still has to be made, but it can be made more intelligently. For example, if the hair and eyes are in an active mod, all face data including hair and eyes can be imported. If the hair and/or eyes are from non-active mods they can be skipped (or be randomly replaced from existing hair / eye records, or be set to a predetermined default, etc) while still importing the rest of the face data. Or, if there's room in the load order, masters can be added if needed.

My 2 cents: I think the current behavior i.e. the bashed patch becoming dependent on the master is correct.
This needs to be solved UI-side:
- in the bashed patch-building interface, mark with a special color and a "will add inactive master to bashed patch" tooltip the entries that present that problem.
- if adding that inactive master would push the number of mods above 255, refuse to activate the checkbox and present a warning dialog box.

At least with this approach the underlying mechanics are clear for the end-user.

One problem with that is that it isn't known whether the inactive master needs to be added until the patch is already running. The patch process could be altered to abort if it tries to push the number of mods above 255, but I'd prefer it to behave more gracefully than that.

Well this issue of hidden masters for the bashed patch not being present or deactivated has caused me hours of combing over my load order and the bashing process. I like Gabba's suggestions. Even if just in the form of just more information and no action is taken.

By hidden I mean that the bashed patch is still green, but you still get the crash on start up. I recall quest delayers left merged can do this.

Ok, if I understand well my idea would need a kind of pre-scan of the mods before selecting the options of the bashed patch. Then we'd know exactly which records a specific option will add, and what will be the impact on adding masters, etc.
I guess said pre-scan would be almost as long as building the patch itself, but maybe with CBash's speed it would be possible?

Edit: Oh, and no matter what you do, definitely abort the Bashed Patch building if the masters go above 255... this is just a smart error condition to check, so the user never ends up with a bashed patch that crashes without the user knowing why.

Yeah, a pre-scan would amount to building the patch. In other words, it wouldn't exactly be a pre-scan.

Coding in the check to abort the patch would be about the same amount of work as coding #2 above and eliminating the possibility altogether, and #2 would give more control when building the patch.

Sorry if I appear to be glossing things over here but I just don't get the argument. If you're importing NPC face records, which for practical purposes includes eyes and hair, then I don't see any way out of it other than to include the inactive master that contains the data for the hair and eye records. Unless Bash is going to copy clones of those records into the patch or something. I could see that working for stuff like the hair/eye example from COBL.

Of course, if the user has the ESM in there without being active, is there any way to know that the meshes and/or textures being asked for exist either? And really, isn't is just a bad install if a required master for something like that isn't active to begin with? How far do you want to go with Bash to protect against user errors that have nothing to do with Bash?

There isn't an argument. I'm honestly shocked that it has provoked this much of a reaction from people. It's been blown way out of proportions.

All this started because CBash has a minor bug in how it copies formIDs from imported mods. I mentioned that hairs and eyes on the face patcher were disabled for now because of it, and that I'd have to fix it. I also mentioned that I hadn't already fixed it because I was still deciding on the best way to do that.

I provided some additional information since people seemed interested, but that's really all there is to it. I certainly didn't intend to start any kind of debate.

For face importing specifically, yes, it makes sense to add a missing/non-active master as needed if there's room. As you said, the hair and eyes are a fairly important part of the face.

In general though, it also makes sense not to force mods to become active when the user hasn't explicitly added them to the load order.

Which of these two choices is the best? I don't know yet.

Does it make sense for any importer in the future to require adding a missing/non-active master? I don't know, but probably not.

Should I design a middle ground so that it can be decided case-by-case? I don't know yet.

Is there another option that I'm overlooking? I don't know yet.

Sensing a trend? :blink:

Whatever I implement now will guide how any future importer patchers are designed when using CBash...which is why I'm giving it some thought now rather than coding a quick 5 minute hacked fix and regretting it later.

Understood, just keep in mind the reason it generated the response it did is because it's such an important part of what Bash is used for now. I think it's just that we don't really want to lose any functionality vs what we currently have.

See, that's just it. Face importing is the only importer that is affected by this, and the only functionality that might change is when a user imports faces from a mod, and the face being imported requires a master that is missing or simply non-active. This is a very specific set of circumstances that most users don't (or shouldn't) come across. I fail to see how this is an important part of Bash...you didn't realize this was possible, and you've been using Bash since importing was first added.

Bash adding a missing master is a bug. The master isn't there, the bashed patch can't be used.

Bash adding a non-active master is a bug. It shares the same mechanics as adding a missing master. If you don't care for the word "bug" since it happens to be desirable in some cases, call it undefined behavior. Relying on undefined behavior is bad. Bash happens to force the non-active master to become active, but it doesn't give the user any feedback about what just happened. CBash happens to break the patch.

I'm not talking about removing the ability to import from mods. I'm not talking about restricting the ability to import faces including hair and eyes. I've been talking about expanding the functionality of importers by defining the proper behavior when importing a formID that requires a missing or non-active master. It may be as simple as saying that Bash's current undefined behavior IS the proper behavior. In which case it needs to be made explicit in the code, and the case of missing masters needs to be handled.

I get exactly what mean heres another example if someone is using cobl races and wants the tnr changes from bg's tnr merge mod for rbp then with option 2 u would get the rounder faces that bg's tnr has w/out having to use rbp core mod so essentially u would get far greater compatibility and people would be able to use optional addons without having to use that core mod which u dont want to use. this is another example hopefully clears up for some.

Small question, I looked everywhere...

I'm back to Oblivion after 18 months and this time I'm doing everything in BAIN. But I'm running out of disk space. I noticed I can change the "Oblivion Mods" location in the bash_default.ini, but I'm worried that I might break something. I did an entire FCOM install with lots of other things... twice, this week. I'm afraid I might lose my work.

Can I simply move the entire Oblivion Mods folder to an external harddrive and change the line in the .ini and everything will be ok?
Or is there a difference between "copy" and "move" and will I run into problems if that HD is formatted to only take files up to 4GB?

I think I read something like that somewhere but now I can't find it anymore.
Anyway, Bash is awesome

Request - Could we have a list appended within the Wrye Bash html, somewhere in the installers section.

Detailing - All folders and files recognised within a Bain?.

Occasionally its noted in these threads, but I'm damned if I can find it just now, and I am sure a couple have been added since last listed.

Is CBash on by default in v291? I don't think it is, but I can't tell. I don't know how to turn on the CBash functionality anyway.

Shouldn't be, you have to Rename "RenameCBash" to CBash...

Thanks for the reply, Brozly. This import spells thing is killing me. Geez...

really a lot better now... but even the initial didn't actually install deactivated installer's obse plugins - it just asked if the user wanted to :headbang:.


well now that error is odd... for some reason it's memory of the oblivion.esm path got removed... odd error.. really can't think of how it got that happening... but it is easy to avoid from ever erroring like that again... fixed, thanks
(and in regards to pidfile.tmp 291 doesn't have that problem so not going deeply into faqs or anything)


loooong since done - within 24hours of the change in fact


er they are... near the top... Wrye Python 03a linked and then individual components
Pacific Morrowind

Don't know about the 4 Gb thing but yes - close Bash, update the ini, move your folder, open Bash, let it refresh

sorry but you have a problem ith your testing... there is no earthly way that Bash can run on 3.1 unless you make a lot of changes and even harder get a 3x Python version of wxPython (which doesn't AFAIK) exist yet... I think your shortcut/however you're launching it might not be properly giving you the right python version.


that is some very very weird error... never even seen that type of error - that is wxPython's underlying wxwidgets (C++) code not liking the data being sent to it (looks potentially to me like it is receiving -1 (instead of a number in the range of 0 to very big number) or something :shrug:)... unless you can replicate it again/randomly receive it a few more times I won't investigate further... ah between the time I wrote that and was about to click submit it was percolating through my grey matter and I will put a check for a -1 index and not run that function (SetString) in that case... good chance just that little check will fix it permanently , so don't worry about it unless you keep getting it after SVN 792/next release of 291+)


doubled it... can ofcourse increase it more if needed.