[Dean Ashcroft]

Alright got it and it is in the root of the traceback in the same post. Bash is confused if the fomod folder is placed on a simple/complex package.



But to fix this I need what I asked for in back to BAIN issue: https://github.com/wrye-bash/wrye-bash/issues/219



That is a complete specification of the package format. I need to understand edge cases like that.



Do we agree for starters that those are the accepted formats ?

Simple package:
Installer.7z or project folder/
   some.esp
   Textures/

Simple package II:
Installer.7z or project folder/
  Some other folder/
     some.esp
     Textures/

Complex/simple package:
Installer.7z or project folder/
some files <---------------- EDIT: must have files here otherwise it is considered simple
  Some other folder/
     some.esp
     Textures/

Complex package:
Installer.7z or project folder/
maybe files
  Some other folder/
     some.esp
     Textures/
  Yet some other folder/
     some.esp
     Textures/

In the place of textures could be any other game folder and in the place of some.esp an ini or esm or bsa - actually I have went into pains specifying this in the

BAIN-Compatible installer layout

section in the wip readme (that comes with my betas I post here)



But I need further info - for instance where should be legal to expect a fomod folder ?



EDIT: the wizard txt should be placed in the top level of a package, not in the fomod folder. What is a top level for a complex simple package - uh oh





EDIT: at Sharlikran - this is the project : http://i.imgur.com/p6kkT1V.jpgthat lists the missing files below :



> Then I looked at the missing tab and it said info.xml and ModuleConfig.xml from the fomod folder were the missing files.



?

[Ally Chimienti]

In reference to the missing files and the info.xml and ModuleConfig.xml. I will be happy to answer that in, well... a more acceptable way tomorrow in a video. Low res though video though.

My take on that isn't that it's what BAIN should do it's what mod authors of NMM mods do. Wrye is not being developed to be compatable with NMM installers. However, it should not complain when it encounters something like I am reporting. I guess we should just be aware of it, allow it, Wrye should not complain about it, just not support the NMM installer format.

> That is a complete specification of the package format. I need to understand edge cases like that.

That though I leave to the experts as I am not a BAIN expert. Sorry.

[Mason Nevitt]

I notice there is a new version so before I do any testing, in case issues have been addressed, I'm going to update things first.

While I am doing that, with the http://i.imgur.com/lZh8DJn.jpg will Wrye Bash collect Bash tags from all five places as it has done in the past? Will it merge that into one aggregate collection of Bash Tags as it has done in the past?

1. taglist.yaml

2. masterlist.yaml

3. userlist.yaml

4. Header of ESP or ESM file

5. Manual Bash tags set by user

[Brandon Bernardi]

Don't just yet - wait for another version - takes a bit

Re: tags there is no change introduced in this code whatsoever (is it ? ) - I have dreamed someone would come along to review my commits (since Lojack disappeared, who reviewed some, often to declare as mystified as me) but I have to make do

Thanks for trying though

[Matt Bee]

307.201605101954

This version contains all fixes for BAIN and load order (including fallout 4 star system + dlcs etc) - forget the rest for now. All previous versions were buggy due to new and old bugs - especially one I just fixed essentially broke duplicating an installer, which could break BAIN in the most mysterious ways (such as leading to infinite refreshes alt3rn1ty had reported a few threads back and one of our more elusive bugs https://github.com/wrye-bash/wrye-bash/issues/93(possibly resolved)).

Please hit this hard - especially load order I believe is finalized. The fixed I introduced for the fomod issue (not the installer copy) however, is very experimental so (ab)use BAIN. @Sharlikran you hit a vein there (lead amongst others to the duplicate installer fix) - since you are curious for the code here is the fomod fix: https://github.com/wrye-bash/wrye-bash/commit/90abeb9210c49b1bf3553d75e4042f9baf3a9fb4

It's highly technical (the experimental part) but I try to explain in the commit message what was going on - took some effort

I also highlight mods that load before their masters orange - test that too. I am not sure however how the runtime handles the situation (for the different games) - is it really something we should warn about ?

Finally I threw in some BP stuff - now the mergeable scan before building the patch will only look at mods that load before the bashed patch - was there a reason it did not do that before ?

[Aaron Clark]

I wouldn't know but I try to come up with respectful ways to ask. I just don't speak Python

[MR.BIGG]

What worries me now is that apparently my links in the second post were banned - any alternatives you'd suggest ?

[james kite]

Each time you say that it makes me think of the Onyxia Wipe WOW video. You have to come up with a different way to put that.

Yeah I'll rebase and check it.

I trust what Arthmoor and Alt3rn1ty said when I asked in a previous post. They said the game may not crash but won't override values correctly. Since how values are overridden is important, then yes I feel the warning is important. Also Wrye doesn't need to cater to other programs but when FO4Edit/TES5Edit runs it will stop and disable editing of plugins that are out of order. Having the warning just follows suit, I guess.

I don't know about it's functionality however there is also a chance that in the past, with people that really knew their stuff, they could have disabled some mods and made two bash patches. So having only merge mods before the bash patch might be a good idea as long as if I disable bash patch 0 and the mods it uses, I can make a second one with other files. This ties into the many times you have seen users say 292.x-ish is the only working version for Oblivion. Mess with how things have been done Wrye is considered broken.

[Elizabeth Davis]

Contact a moderator to look at them. I had to do that for my long TES5Edit posts. The security features for the forum are being a bit too strict is all.

[Talitha Kukk]

Banned by dropbox - my account has too much traffic - which is ridiculous basically so some other power is at work...

[.X chantelle .x Smith]

When I was putting together my "ultimate" playthrough, I had multiple bashed patches. I would have one that was "good", and when I experimented with adding new mods, I would rename the first one, deactivate it, and create a new bashed patch, so that if it bombed I wouldn't have to recreate the previous one.


I got the idea because the bashed patch is labeled bashed patch 0, which implies that there could be more than one bashed patch. With lots of mods, I could see someone possibly using a similar technique where each bashed patch serves a specific function or group of merged data.

However, last I checked, BOSS only recognizes the bashed patch 0.esp. So eventually when everything is solid and working, I usually just end up with one bashed patch.

[Laura Samson]

Thanks @sabel - multiple bashed patches (that take time to be scanned for mergeability0 is the reason I dropped the "scan mergeable" check for files that load after the Patch - I do not think that bashed patch would patch (or merge) any mod that loads after it so this would not make a difference. No ?

[Liv Staff]

Just got back from work so gimme a while to catch up - First I thought we only have 3 types of BAIN

( Reference your "uh oh" - I always refer to the Top Level of a zip package as being the root of the archive, in my examples below I will label all root items )

Your example of a Simple Package is fine :

Simple - Installer has .esp, .esm and/or .bsa files, and/or any of the standard game subdirectories at the top level of the package/project.

Installer.7z or project folder/

readme.txt maybe - root

some.esp .esm - root

some.bsa - root

textures/ - root

path/files

meshes/ - root

path/files

Your example of a Complex Package is fine

Complex - Installer has top-level subdirectories that each have a simple structure (as defined above). The top level subdirectories (known as subpackages) must not have the same name as any of the regular game subdirectories for this game. Each top-level subdirectory will be treated as a sub-package, and can be independently activated or deactivated as desired.

Installer.7z or project folder/

readme.txt maybe - root

wizard.txt maybe - root

subpackageonefolder/ - root

readme.txt

some.esp .esm

sounds/files

meshes/files

subpackagetwofolder/ - root

readme.txt

some.esp

meshes/files

Your example of a Complex/Simple package does not need files in the root ( they can be .. maybe )

Complex/Simple - A complex installer with only one top-level subdirectory. It is treated as a simple installer, starting at this top level subdirectory. Examples include mods packaged with a top-level Data directory.

Installer.7z or project folder/

readme.txt maybe - root

data/ - root

some.esp

scripts/files

Your example of a Simple Package II - Is actually a Complex / Simple package

FOMod/ folder should be where the mod managers that need them know where to look for them - root - Or, not root ( xxMM can dig down in an archive to find FOMod/ and it uses the level at which it finds FOMod/ as the anchor root basis for its pathing in the modconfig script ), personally I always make a point of keeping it root ( remember my bug reference wizards getting confused as to where root is if a BAIN is packaged one or two folders too deep ?, and so cannot find its images because the root to the path to them is at the wrong level .. What was done was acceptance that everyone naturally packs an archive one folder too deep ( by zipping just the folder they put all of their sub-packages into ), so Wrye Bash was allowed to also look at such archives but did not account for image paths in wizards )

Installer.7z or project folder/

readme.txt maybe - root

wizard.txt maybe - root

FOMod/ - root

images.jpg maybe

info.xml

modconfig.xml

subpackageonefolder/ - root

readme.txt

some.esp .esm

sounds/files

meshes/files

subpackagetwofolder/ - root

readme.txt

some.esp

meshes/files

But you cant say thats how all mod authors will do it, FOMod could be anywhere - If it causes problems for Wrye Bash either the author or users need to rearrange the content of the mod archive to be BAIN friendly .. I try to encourage a format that works for all.

Any other weird stuff / folders / files inside the FOMod/ folder an xxMM programmer may have in here is usually best sorted into subpackages and the scripting for those files ( modconfig.xml ) repathed accordingly to bring it in line with being Wrye Bash / BAIN friendly

You need to spend a few years on nexus to realise the latter case was the norm for a long time, Oblivion users of Wrye Bash have always made a habit of just rolling their own instead of what would be a pain trying to necro' an author who has not a clue or care for Wrye Bash friendliness and thinks Wrye Bash is weird

As far as xxMM programmers are concerned the following for them is entirely valid as an installer package ..

Installer.7z or project folder/

readme.txt maybe - root

An-Extra-Folder-Here-Because-Its-Easy-To-Right-Click-And-Zip-With-The-Readme/ - root

Stuff-The-Author-Wanted-To-Store-Separate-From-the-Main-Installation-Folders/

TheManyFilesIMayOrMayNotUse.*

Another-Folder-Because-We-Can/

FOMod/

images.jpg maybe

images2.jpg maybe

info.xml

modconfig.xml

some-folder-name-with-strange-subfolders-illogically-dumped-together-like-a-teenagers-bedroom1/ much.files esp bsa meshes etc etc

some-folder-name-with-strange-subfolders-illogically-dumped-together-like-a-teenagers-bedroom2/ much.files.part.deux

And the scripting can pick and choose MANY configurations out of the mess which only the authors brain ( or another determined modder trying to make it BAIN friendly ) can figure out and make sense of it all with a lot of experience and a good idea of the objectives of the mod and its files.

So there is not really a standard for xxMM scripting and folder organisation within an installer, they make it up as they go along because the scripting affords them the luxury to do that. They can for example have a folder filled with textures ( no paths, just all textures in one folder ) .. The author knows the unique paths of the original textures to make these all into replacers .. So he scripts in the paths at installation time ( saves having to make thousands of path sub folders like Textures/actors/character/etc/etc/ )

Whereas BAINs were designed to be not only reliable at ensuring what you think is installed out of thousands of installers files .. actually is .. but also to be speedy in execution and annealing the installation

Importantly : Sticking with what we know should be allowed ( the three BAIN types and ignoring FOMod wherever it is found but allowing the wizard script to use resources in there <-- This was not my idea, I have copied it from some older BAINs out there starting years ago .. and due to my enthusiasm helping over the years following, many other authors have adopted similar practices )

Because to alter that would break a massive amount of mods, wizards and patches

As Sharlikran says, its something that really should not be a concern for Wrye Bash, but the way Wrye Bash has always allowed it by ignoring it as a not-sub-package ( and I would add allowing Wizards to use resources in FOMod ) .. ought to be maintained.

If you ever need it for a reference - Guide for FOMOD Scripting http://www.nexusmods.com/newvegas/mods/44914/?

( You have probably noticed but also see the Wrye Bash Technical Readme - Wizards vs OBMM Scripts - Compares the two sets of commands side by side similarities )

Surazal may well nitpick me here .. Or Metallicow .. Both of whom can make wizards do math to compete with Magrathea and produce the answer 42 to The Question Life The Universe and Everything, in about two seconds ( dont blink )

Hell, its going to take me half hour to figure out if I am happy with the content of this post .. >.< click

[Emily abigail Villarreal]

Oh yes, thats something else I was going to mention ..

No need to concern with putting a wizard in a Simple / Complex BAIN, I think pretty much everyone realises there would be no point in making a wizard which would take longer to click through for the one choice, than a simple right click install would do.

If its not a Complex BAIN, no point in doing a wizard. Edit : Although again, someone may have just to have a fancy presentation to install the one option.

[Becky Palmer]

> Complex/Simple - A complex installer with only one top-level subdirectory. It is treated as a simple installer, starting at this top level subdirectory. Examples include mods packaged with a top-level Data directory.

I wrote that - but I need to correct it I think - because:

> Your example of a Simple Package II - Is actually a Complex / Simple package

Hmm - Bash will report it as simple (General tab)

Re: fomods - I am going to allow them at top level (must see for complex/simple etc) - Bash ignores them anyway silently (read the skips section in the readme there is a wealth of info. In general I wrote some sections there diocumenting waht the code does - here is the commit: - the situation is 80% clear but still details are pending)

> so Wrye Bash was allowed to also look at such archives but did not account for image paths in wizards

I will attempt a fix for that based on my work later on - I believe you left me a reproducer for that (wizard with images) - the problem is that Bash for such archives chops off the first part of the path up to the length of the root and keeps this length around - while the code needs the name of the root - or something in those lines

But for now load order and testing BAIN are the priorities - 307.201605101954 fixes couple serious bugs and I believe we will have no more surprises from BAIN

Metallic we did not manage to cooperate - I appreciate his skills but put a lot of pressure on me raising issues while I was trying to focus the development process to what I finally achieved - a (much) faster a bug free(er) Bash

I do not intend to change the package format, I just need to clarify it down to last detail cause hey that is the only way to fixup and extend BAIN

[Chris Jones]

Spoiler

O_o ( @ amazing amount of resolved issues ) Now you are getting too cool for school, to the last question - No, not that I know of anyway

Never realised there is no need for that really

Edit : Oh actually .. Sharlikran and Saebel have a good point ref multiple bashed patches. I have never used many myself either, but do recall advanced use conversations where merges could be skipped for an earlier loading Bashed Patch, 0.esp, and then included in a later loading Bashed Patch, 1.esp

The whys and wherefores as to what use all of that had are probably lost in the mists of time ( until you fix it and the grumpy silent majority emerge from the depths with pitch forks )

This is one hell of a project

[latrina]

Never seen that happen on DropBox, but I would imagine there are a lot of silent followers of your developments

Sheson uses Mega NZ https://mega.nz/#about- I have not used them myself yet so do not know if there is any veiled jumping through hoops to experience, but downloading from there frequently recently and had no problems

[Alisha Clarke]

Well, that depends. Are you scanning to see if they *can* be merged, and thus flagging them with the green text? Or are you talking about when someone tries to create/update the bashed patch.

If it's the former, then all files should get scanned to see if they are mergeable. When I install a new version of SDR, the file dates will usually place the files out of order, and often after the bashed patched, so the one file I have that is mergeable doesn't get flagged with green text right away. I usually have to run Boss so that it has the proper load order. Then if I exit wrye bash and come back to it, it's flagged as green. Sometimes it does it if I switch to the installer and back (I think, not sure, it's been awhile since I've had anything new to mess with).


If you are talking about the latter, when creating the bashed patch. Yes, all files after the bashed patch being created should be ignored. Absolutely.

[kristy dunn]

> Never seen that happen on DropBox, but I would imagine there are a lot of silent followers of your developments

Bah - something else it would take 1000s of downloads- emailed them, thanks for link.

> When I install a new version of SDR, the file dates will usually place the files out of order, and often after the bashed patched, so the one file I have that is mergeable doesn't get flagged with green text right away.

Does this happen with my latest https://github.com/wrye-bash/wrye-bash/archive/utumno-lo.zip? Whenever you switch to the mods tab after an install new files should be scanned.

> If you are talking about the latter, when creating the bashed patch. Yes, all files after the bashed patch being created should be ignored. Absolutely.

Thanks for confirming that, I was talking for the former - why scan mods for mergeability just before building the patch if they should not be used (see the latter) ?