[RELZ] Wrye Bash -- Thread #38
» Sat Apr 30, 2011 8:06 am
-
Haley Merkley - Posts: 3356
- Joined: Sat Jan 13, 2007 12:53 pm
» Sat Apr 30, 2011 5:10 am
I mean, is it safe to install shader replacers now? Excuse me, if that is what you just said. I am just unsure of what you mean by "managing."
It means we have code that can read and edit shader packages, but Bash cannot use it because there is not UI for it. One of us will have to whip up some UI stuff before anyone can actually use it. AKA hopefully soon, but I don't think it's on anyone else's plate right now (my time is a little limited right now).
-
Kat Ives - Posts: 3408
- Joined: Tue Aug 28, 2007 2:11 pm
» Fri Apr 29, 2011 6:54 pm
Okay, thank you for clearing that up for me. I am in the process of revamping my site, and I want all of the information to be current and valid.
-
Paul Rice - Posts: 3430
- Joined: Thu Jun 14, 2007 11:51 am
» Sat Apr 30, 2011 1:48 am
I have two mods, which seem to have races with eyes, which are not compatible with wrye bashs eye/race tags (version 279, I didn't test 280).
I get the following message, if I add the eye/race tags and check the mod in the bashed patch race section:
If I add a new condition in the bosh.py, I can rebuild the bashed patch with these mods.
I changed this (line 19006 in version 279):
to this:
This might not be a suitable fix, as I do not oversee the whole code. But at least, it seems to work.
In line 19080, there is a similar check for certain races, which does not seem to have rightEye/leftEye set in race.
I uploaded a test esp:
http://www.megaupload.com/?d=CT3NMOPV
Edit: ok, I took a look into 280 and saw, that this part of code has been changed. I didn't look at it, as the changelog didn't mentioned changes here. So you might forget my post
Best regards,
ThreeD
I get the following message, if I add the eye/race tags and check the mod in the bashed patch race section:
Traceback (most recent call last): File "c:\games\Oblivion\Mopy\basher.py", line 4514, in Execute raise File "c:\games\Oblivion\Mopy\basher.py", line 4476, in Execute patchFile.buildPatch(log,SubProgress(progress,0.8,0.9)) File "c:\games\Oblivion\Mopy\bosh.py", line 13871, in buildPatch patcher.buildPatch(log,SubProgress(subProgress,index)) File "c:\games\Oblivion\Mopy\bosh.py", line 19006, in buildPatch race.rightEye.modPath != raceData['rightEye'].modPath orAttributeError: 'NoneType' object has no attribute 'modPath'
If I add a new condition in the bosh.py, I can rebuild the bashed patch with these mods.
I changed this (line 19006 in version 279):
if 'eyes' in raceData and ( race.rightEye.modPath != raceData['rightEye'].modPath or race.leftEye.modPath != raceData['leftEye'].modPath or
to this:
if 'eyes' in raceData and ( (race.rightEye and race.rightEye.modPath != raceData['rightEye'].modPath) or (race.leftEye and race.leftEye.modPath != raceData['leftEye'].modPath) or set(race.eyes) != set(raceData['eyes']) ):
This might not be a suitable fix, as I do not oversee the whole code. But at least, it seems to work.
In line 19080, there is a similar check for certain races, which does not seem to have rightEye/leftEye set in race.
I uploaded a test esp:
http://www.megaupload.com/?d=CT3NMOPV
Edit: ok, I took a look into 280 and saw, that this part of code has been changed. I didn't look at it, as the changelog didn't mentioned changes here. So you might forget my post
Best regards,
ThreeD
-
Bad News Rogers - Posts: 3356
- Joined: Fri Sep 08, 2006 8:37 am
» Sat Apr 30, 2011 8:40 am
I asked about extra files being installed with OOO 1.33 and the problem turned out to be partly that the archive wasn't BAIN-ready and partly a limitation of the file skipping feature. I think this aspect of BAIN could be improved without much work.
- Skip Docs only seems to apply when searching for installed files. Docs will be installed Bash will report that they're missing. Please fix this.
- It seems like file skipping is only used for BAIN-ready archives. Obvious stuff like executables and omod conversion data should be skipped for non-BAIN-ready archives as well.
- File type skipping needs to be more strict. If it's not esp, esm, dds, ini, etc. it should either be skipped by default or swept to Docs. Ideally there shouldn't be a single file outside of Docs that isn't read by the game.
- For archives that are not BAIN-ready, all folders that are determined to be under Data but are not known folders like Textures or Meshes should be displayed as packages. I think this would cover a lot of archives that otherwise need to be converted for BAIN.
Other changes I'd like to see in Bash:
- More flexible values for Tweak Settings, preferably an option to manually enter a value. In other words I'd like an option to set the death timer to zero seconds, whereas right now the minimum is 15.
- Some way to relocate the files Bash places in Data to Mopy\Data.
- Tweak Names for spells takes the spell school from the first spell effect rather than the most expensive spell effect as it should.
- Bash.ini field for the directory used for hidden installer archives.
- Right-click -> Move to Top/Bottom for plugins.
- Right-click header -> Check/Uncheck all for plugins.
- Right-click -> Rename for installers.
- Right-click header -> Add Separator in the plugin and installer tabs, to place a ==Separator== for organization.
- Dummy separator plugins that start with == should be gray like ==Last== in installers
That's it for now. Thanks for all of your work on this.
- Skip Docs only seems to apply when searching for installed files. Docs will be installed Bash will report that they're missing. Please fix this.
- It seems like file skipping is only used for BAIN-ready archives. Obvious stuff like executables and omod conversion data should be skipped for non-BAIN-ready archives as well.
- File type skipping needs to be more strict. If it's not esp, esm, dds, ini, etc. it should either be skipped by default or swept to Docs. Ideally there shouldn't be a single file outside of Docs that isn't read by the game.
- For archives that are not BAIN-ready, all folders that are determined to be under Data but are not known folders like Textures or Meshes should be displayed as packages. I think this would cover a lot of archives that otherwise need to be converted for BAIN.
Other changes I'd like to see in Bash:
- More flexible values for Tweak Settings, preferably an option to manually enter a value. In other words I'd like an option to set the death timer to zero seconds, whereas right now the minimum is 15.
- Some way to relocate the files Bash places in Data to Mopy\Data.
- Tweak Names for spells takes the spell school from the first spell effect rather than the most expensive spell effect as it should.
- Bash.ini field for the directory used for hidden installer archives.
- Right-click -> Move to Top/Bottom for plugins.
- Right-click header -> Check/Uncheck all for plugins.
- Right-click -> Rename for installers.
- Right-click header -> Add Separator in the plugin and installer tabs, to place a ==Separator== for organization.
- Dummy separator plugins that start with == should be gray like ==Last== in installers
That's it for now.
Thanks for all of your work on this. -
Mr. Allen - Posts: 3327
- Joined: Fri Oct 05, 2007 8:36 am
» Sat Apr 30, 2011 6:39 am
I asked about extra files being installed with OOO 1.33 and the problem turned out to be partly that the archive wasn't BAIN-ready and partly a limitation of the file skipping feature. I think this aspect of BAIN could be improved without much work.
- Skip Docs only seems to apply when searching for installed files. Docs will be installed Bash will report that they're missing. Please fix this.
- It seems like file skipping is only used for BAIN-ready archives. Obvious stuff like executables and omod conversion data should be skipped for non-BAIN-ready archives as well.
- File type skipping needs to be more strict. If it's not esp, esm, dds, ini, etc. it should either be skipped by default or swept to Docs. Ideally there shouldn't be a single file outside of Docs that isn't read by the game.
- For archives that are not BAIN-ready, all folders that are determined to be under Data but are not known folders like Textures or Meshes should be displayed as packages. I think this would cover a lot of archives that otherwise need to be converted for BAIN.
Other changes I'd like to see in Bash:
- More flexible values for Tweak Settings, preferably an option to manually enter a value. In other words I'd like an option to set the death timer to zero seconds, whereas right now the minimum is 15.
- Some way to relocate the files Bash places in Data to Mopy\Data.
- Tweak Names for spells takes the spell school from the first spell effect rather than the most expensive spell effect as it should.
- Bash.ini field for the directory used for hidden installer archives.
- Right-click -> Move to Top/Bottom for plugins.
- Right-click header -> Check/Uncheck all for plugins.
- Right-click -> Rename for installers.
- Right-click header -> Add Separator in the plugin and installer tabs, to place a ==Separator== for organization.
- Dummy separator plugins that start with == should be gray like ==Last== in installers
That's it for now. Thanks for all of your work on this.
- Skip Docs only seems to apply when searching for installed files. Docs will be installed Bash will report that they're missing. Please fix this.
- It seems like file skipping is only used for BAIN-ready archives. Obvious stuff like executables and omod conversion data should be skipped for non-BAIN-ready archives as well.
- File type skipping needs to be more strict. If it's not esp, esm, dds, ini, etc. it should either be skipped by default or swept to Docs. Ideally there shouldn't be a single file outside of Docs that isn't read by the game.
- For archives that are not BAIN-ready, all folders that are determined to be under Data but are not known folders like Textures or Meshes should be displayed as packages. I think this would cover a lot of archives that otherwise need to be converted for BAIN.
Other changes I'd like to see in Bash:
- More flexible values for Tweak Settings, preferably an option to manually enter a value. In other words I'd like an option to set the death timer to zero seconds, whereas right now the minimum is 15.
- Some way to relocate the files Bash places in Data to Mopy\Data.
- Tweak Names for spells takes the spell school from the first spell effect rather than the most expensive spell effect as it should.
- Bash.ini field for the directory used for hidden installer archives.
- Right-click -> Move to Top/Bottom for plugins.
- Right-click header -> Check/Uncheck all for plugins.
- Right-click -> Rename for installers.
- Right-click header -> Add Separator in the plugin and installer tabs, to place a ==Separator== for organization.
- Dummy separator plugins that start with == should be gray like ==Last== in installers
That's it for now.
Thanks for all of your work on this.I like many of these suggestions, but the doc sweeping is still too general now that Pluggy allows mods to use .txt files. Could certain packages be flagged to be skipped in the Docs sweep maybe? I think that might be getting a little too complicated maybe...could the option just be available for BAIN packages or subpackages or something?
-
Chloe Yarnall - Posts: 3461
- Joined: Sun Oct 08, 2006 3:26 am
» Fri Apr 29, 2011 7:14 pm
I realize that I'm skipping through parts of your post, but I'm just commenting on what I know. The rest will need to be addressed by someone else.
This (and similar ideas) has come up before, and Wrye was against it. The main point that he brought up is that an archive should either be BAIN friendly or not. If BAIN recognizes the format, it will install. If it will install, it will work. BAIN shouldn't try and guess how to install a package. If it does, then it might install, but not work. Or, it might work. The problem is that there are then no guarantees. There's simply too much room for error.
The current specifications for a BAIN friendly archive are pretty broad, and allow a wide range of possible installations. I'd be extremely hesitant to change it at this point.
Agreed. This would be nice, but also require a UI change. Not sure how much work would be involved since I mostly worked on the back-end.
Should be doable with an ini setting. Most of the directories are customizable now, so it'd just be an extension of what's done.
I've no opinion one way or the other, but it'd be easy to implement.
Can be done. Should it? I don't know. With most of the other directories customizable now, I suppose it makes sense. But, it might have some unintended consequences.
Use the Redate function. No sense in duplicating functionality.
You can check/uncheck all selected mods by pressing the space bar. For now, you can select them all by clicking the first mod, scrolling to the last mod, hold shift and select the last mod. Then you can use the space bar to check/uncheck all of them.
It'd make sense to have ctrl+a select all mods (I'm surprised it doesn't already), and then you could press ctrl+a, then the space bar for the same functionality.
Isn't that already supported? It's right below "Hide..." on the context menu.
Agreed. This would need a bit more work than most of your ideas, but it's mostly implemented on the back-end. One potential issue is that there might be a few places that assume the ==Last== separator is unique, so some testing would be needed.
On the whole, as far as I'm concerned, they're pretty good suggestions. If the maintainers agree is another story
Until I get developer access to the Bash svn, I don't plan to make any substantive improvements to the Bash code. I'll fix bugs, but it isn't fair to Lojack to have to do all my commits for me (which I do appreciate, btw). I do have access to Bash's TESNexus page, but then any changes I made wouldn't be reflected in the svn and just make more work for the others.
- For archives that are not BAIN-ready, all folders that are determined to be under Data but are not known folders like Textures or Meshes should be displayed as packages. I think this would cover a lot of archives that otherwise need to be converted for BAIN.
This (and similar ideas) has come up before, and Wrye was against it. The main point that he brought up is that an archive should either be BAIN friendly or not. If BAIN recognizes the format, it will install. If it will install, it will work. BAIN shouldn't try and guess how to install a package. If it does, then it might install, but not work. Or, it might work. The problem is that there are then no guarantees. There's simply too much room for error.
The current specifications for a BAIN friendly archive are pretty broad, and allow a wide range of possible installations. I'd be extremely hesitant to change it at this point.
Other changes I'd like to see in Bash:
- More flexible values for Tweak Settings, preferably an option to manually enter a value. In other words I'd like an option to set the death timer to zero seconds, whereas right now the minimum is 15.
- More flexible values for Tweak Settings, preferably an option to manually enter a value. In other words I'd like an option to set the death timer to zero seconds, whereas right now the minimum is 15.
Agreed. This would be nice, but also require a UI change. Not sure how much work would be involved since I mostly worked on the back-end.
- Some way to relocate the files Bash places in Data to Mopy\Data.
Should be doable with an ini setting. Most of the directories are customizable now, so it'd just be an extension of what's done.
- Tweak Names for spells takes the spell school from the first spell effect rather than the most expensive spell effect as it should.
I've no opinion one way or the other, but it'd be easy to implement.
- Bash.ini field for the directory used for hidden installer archives.
Can be done. Should it? I don't know. With most of the other directories customizable now, I suppose it makes sense. But, it might have some unintended consequences.
- Right-click -> Move to Top/Bottom for plugins.
Use the Redate function. No sense in duplicating functionality.
- Right-click header -> Check/Uncheck all for plugins.
You can check/uncheck all selected mods by pressing the space bar. For now, you can select them all by clicking the first mod, scrolling to the last mod, hold shift and select the last mod. Then you can use the space bar to check/uncheck all of them.
It'd make sense to have ctrl+a select all mods (I'm surprised it doesn't already), and then you could press ctrl+a, then the space bar for the same functionality.
- Right-click -> Rename for installers.
Isn't that already supported? It's right below "Hide..." on the context menu.
- Right-click header -> Add Separator in the plugin and installer tabs, to place a ==Separator== for organization.
- Dummy separator plugins that start with == should be gray like ==Last== in installers
- Dummy separator plugins that start with == should be gray like ==Last== in installers
Agreed. This would need a bit more work than most of your ideas, but it's mostly implemented on the back-end. One potential issue is that there might be a few places that assume the ==Last== separator is unique, so some testing would be needed.
On the whole, as far as I'm concerned, they're pretty good suggestions. If the maintainers agree is another story
Until I get developer access to the Bash svn, I don't plan to make any substantive improvements to the Bash code. I'll fix bugs, but it isn't fair to Lojack to have to do all my commits for me (which I do appreciate, btw). I do have access to Bash's TESNexus page, but then any changes I made wouldn't be reflected in the svn and just make more work for the others.
-
Steve Smith - Posts: 3540
- Joined: Sat Jun 30, 2007 10:47 am
» Fri Apr 29, 2011 10:52 pm
Hey!
I was wondering why doe Wrye Bash only accept certain *.ini files coming from BAIN archives. For example, having the ini inside a "ini" folder isn't accepted but having it simply in Data is fine. Having it in _tejon is fine, having it in Streamline\Ini Files is fine.
Secondly - are there plans to allows *.esp-less packages to be recognised?
Third - and this might not be the best place to ask - but how can I get the folder structure of a package into the clipboard?
That's all for now!
Cheers!
cc
I was wondering why doe Wrye Bash only accept certain *.ini files coming from BAIN archives. For example, having the ini inside a "ini" folder isn't accepted but having it simply in Data is fine. Having it in _tejon is fine, having it in Streamline\Ini Files is fine.
Secondly - are there plans to allows *.esp-less packages to be recognised?
Third - and this might not be the best place to ask - but how can I get the folder structure of a package into the clipboard?
That's all for now!
Cheers!
cc
-
Travis - Posts: 3456
- Joined: Wed Oct 24, 2007 1:57 am
» Sat Apr 30, 2011 12:25 am
1) That question has been asked a lot recently, just wait some more...
2) Lots of texture replacers are .esp-less, and I have about 40 of them installed.
3) Copy and paste the list from the "General" or "Missing Files" section. There is not an automated way to do some tree format thing that I know of, but it is being worked on I believe.
2) Lots of texture replacers are .esp-less, and I have about 40 of them installed.
3) Copy and paste the list from the "General" or "Missing Files" section. There is not an automated way to do some tree format thing that I know of, but it is being worked on I believe.
-
Scotties Hottie - Posts: 3406
- Joined: Thu Jun 08, 2006 1:40 am
» Sat Apr 30, 2011 7:38 am
1) That question has been asked a lot recently, just wait some more...
2) Lots of texture replacers are .esp-less, and I have about 40 of them installed.
3) Copy and paste the list from the "General" or "Missing Files" section. There is not an automated way to do some tree format thing that I know of, but it is being worked on I believe.
2) Lots of texture replacers are .esp-less, and I have about 40 of them installed.
3) Copy and paste the list from the "General" or "Missing Files" section. There is not an automated way to do some tree format thing that I know of, but it is being worked on I believe.
Thanks!
For 2) I meant sub-packages. I have mods where a subpackage is just another ini configuration or another xml file and those get skipped.
cc
-
DAVId MArtInez - Posts: 3410
- Joined: Fri Aug 10, 2007 1:16 am
» Sat Apr 30, 2011 3:21 am
2) is still the INI file problem, esp-less subpackages can be installed to (seen Psymon's thread?)
-
maria Dwyer - Posts: 3422
- Joined: Sat Jan 27, 2007 11:24 am
» Fri Apr 29, 2011 7:25 pm
1) That question has been asked a lot recently, just wait some more...
2) Lots of texture replacers are .esp-less, and I have about 40 of them installed.
3) Copy and paste the list from the "General" or "Missing Files" section. There is not an automated way to do some tree format thing that I know of, but it is being worked on I believe.
2) Lots of texture replacers are .esp-less, and I have about 40 of them installed.
3) Copy and paste the list from the "General" or "Missing Files" section. There is not an automated way to do some tree format thing that I know of, but it is being worked on I believe.
1) Mainly it's an artificial limitation because Wrye was trying to standardize ini and script files being placed in a scripts directory. He was fairly adamant about it, and there were some heated discussions at the time. He made allowances for a couple mods that existed before BAIN (streamline, _tejon), but wanted to pressure future mods into using the scripts directory. The following directories will work atm:
- screenshots
- bash patches
- distantlod
- docs
- facegen
- fonts
- menus
- meshes
- music
- shaders
- sound
- textures
- trees
- video
- streamline
- _tejon
- ini tweaks
- scripts
Other places could technically be allowed, but it does make the code cleaner if people would use the scripts directory. In any case, it's a design decision that is fairly set. Nobody working on Bash really wants to deviate from Wrye's policies. It might be changed, but it would need some serious discussion first (i.e. I doubt it will change any time soon).
2) Ditto. If it doesn't work, it's a bug, and you need to give us an example.
3) It is implemented for 281, and it is auto-copied to the clipboard as well as displayed. If you want it now, you'll have to follow these http://www.gamesas.com/index.php?/topic/1083993-in-depth-guide-for-installing-fcom-and-non-fcom-setups-with-bain/page__view__findpost__p__15802947.
-
des lynam - Posts: 3444
- Joined: Thu Jul 19, 2007 4:07 pm
» Fri Apr 29, 2011 11:51 pm
Why isn't the OBSE folder allowed?...just curious. Also, I think that "scripts" is misleading for some users, but coders and users think differently, I know. INI does not translate to script for everyone...
-
Stryke Force - Posts: 3393
- Joined: Fri Oct 05, 2007 6:20 am
» Sat Apr 30, 2011 7:55 am
1) Mainly it's an artificial limitation because Wrye was trying to standardize ini and script files being placed in a scripts directory. He was fairly adamant about it, and there were some heated discussions at the time. He made allowances for a couple mods that existed before BAIN (streamline, _tejon), but wanted to pressure future mods into using the scripts directory. The following directories will work atm:
Other places could technically be allowed, but it does make the code cleaner if people would use the scripts directory. In any case, it's a design decision that is fairly set. Nobody working on Bash really wants to deviate from Wrye's policies. It might be changed, but it would need some serious discussion first (i.e. I doubt it will change any time soon).
- screenshots
- bash patches
- distantlod
- docs
- facegen
- fonts
- menus
- meshes
- music
- shaders
- sound
- textures
- trees
- video
- streamline
- _tejon
- ini tweaks
- scripts
Other places could technically be allowed, but it does make the code cleaner if people would use the scripts directory. In any case, it's a design decision that is fairly set. Nobody working on Bash really wants to deviate from Wrye's policies. It might be changed, but it would need some serious discussion first (i.e. I doubt it will change any time soon).
Fair enough.
I apologise for the above actually. I used the "Has Extra Directories" option and now they're visible.
2) Ditto. If it doesn't work, it's a bug, and you need to give us an example.
There is one I can't get to work - http://www.tesnexus.com/downloads/file.php?id=12074. The folder structure is like this:
00 Core
- SM Enc&Fatigue.ini
- SM Encumbrance and Fatigue.esp
01 Fallout
- SM Enc&Fatigue.ini
01 Revised
- SM Enc&Fatigue.ini
I ticked "Has Extra Directories" but for this one it doesn't do it. Might be the "&" character - my guess.
3) It is implemented for 281, and it is auto-copied to the clipboard as well as displayed. If you want it now, you'll have to follow these http://www.gamesas.com/index.php?/topic/1083993-in-depth-guide-for-installing-fcom-and-non-fcom-setups-with-bain/page__view__findpost__p__15802947.
Good to know!
I've got another suggestion/request - an option to view the readme a package has within Wrye Bash, prior to installation would come really handy!
Cheers guys and I thank you for all the work you've put into this!
cc
-
Alkira rose Nankivell - Posts: 3417
- Joined: Tue Feb 27, 2007 10:56 pm
» Sat Apr 30, 2011 2:25 am
I cannot get projects only containg INIs and .txt files to install either. Again, same old issue...
-
No Name - Posts: 3456
- Joined: Mon Dec 03, 2007 2:30 am
» Sat Apr 30, 2011 7:49 am
Why isn't the OBSE folder allowed?...just curious. Also, I think that "scripts" is misleading for some users, but coders and users think differently, I know. INI does not translate to script for everyone...
It is explicitly disallowed in the code because that is where obse has it's plugin dll files installed. Bash doesn't install dll files since they're a potential security risk, so Wrye wanted users to have to go through a little more hassle to hopefully think about what they're doing. Wrye went ahead and disallowed the entire directory for good measure.
I agree that "scripts" is misleading to users, and I might have chosen a different name myself, but that's really what most OBSE *.ini files are. Just scripts that are run through the console to set variables.
It's too late to change the folder name since there are (admittedly, few) mods that used that standard. Personally, considering the lack of adoption, I think the time for standardizing on that directory has come and gone and it wouldn't hurt to allow other directories in addition to "scripts". With that said, I (and probably the others, though I don't speak for them) would need both a convincing argument and very widespread support before touching that part of the code.
-
JAY - Posts: 3433
- Joined: Fri Sep 14, 2007 6:17 am
» Sat Apr 30, 2011 6:56 am
Fair enough.
I apologise for the above actually. I used the "Has Extra Directories" option and now they're visible.
I apologise for the above actually. I used the "Has Extra Directories" option and now they're visible.
Glad it's working :goodjob:
There is one I can't get to work - http://www.tesnexus.com/downloads/file.php?id=12074. The folder structure is like this:
00 Core
01 Fallout
01 Revised
I ticked "Has Extra Directories" but for this one it doesn't do it. Might be the "&" character - my guess.
00 Core
- SM Enc&Fatigue.ini
- SM Encumbrance and Fatigue.esp
01 Fallout
- SM Enc&Fatigue.ini
01 Revised
- SM Enc&Fatigue.ini
I ticked "Has Extra Directories" but for this one it doesn't do it. Might be the "&" character - my guess.
Could easily be the ampersand, but it sounds like the issue Tomlong mentions below. I'll look into this sometime later this week if nobody gets to it first.
I've got another suggestion/request - an option to view the readme a package has within Wrye Bash, prior to installation would come really handy!
A document browser for installers has been requested before. Ideally (in my opinion at least), BAIN packages should have documentation as a separate sub-package so that it can be installed first and read as desired (and then uninstalled when no longer needed to reduce clutter):
00 Documentation01 Resources02 Plugins...
A document browser like the mods tab has is technically feasible. It shouldn't be hard to set up, especially since BAIN already tries to detect readme's for document sweeping. When I add CBash support to Bash in a month or so, I'll take a look into this if nobody else gets to it first.
I cannot get projects only containg INIs and .txt files to install either. Again, same old issue...
That sounds very much like a bug, and not a design decision. As I mentioned above, I'll look at it sometime this week.
-
meghan lock - Posts: 3451
- Joined: Thu Jan 11, 2007 10:26 pm
» Sat Apr 30, 2011 7:35 am
I am fine with the not installing OBSE plugins part. I install those early, before adding mods. There is not reason for me to have a manager for them. Thanks.
Honestly, I would prefer that all INIs were installed to the Data folder. I do not know what the best option is for those mods that add lots of template INIs for the users convenience, however.
Honestly, I would prefer that all INIs were installed to the Data folder. I do not know what the best option is for those mods that add lots of template INIs for the users convenience, however.
-
Angelina Mayo - Posts: 3427
- Joined: Wed Jan 24, 2007 4:58 am
» Sat Apr 30, 2011 9:16 am
1) Mainly it's an artificial limitation because Wrye was trying to standardize ini and script files being placed in a scripts directory. He was fairly adamant about it, and there were some heated discussions at the time. He made allowances for a couple mods that existed before BAIN (streamline, _tejon), but wanted to pressure future mods into using the scripts directory. The following directories will work atm:
Thanks for the continued work on this tool by the way, guys. It's greatly appreciated by myself and I am sure the whole community.
Vac
-
Imy Davies - Posts: 3479
- Joined: Fri Jul 14, 2006 6:42 pm
» Sat Apr 30, 2011 3:06 am
Yep, that was the way of it :banghead:
-
Destinyscharm - Posts: 3404
- Joined: Sun Jul 23, 2006 6:06 pm
» Sat Apr 30, 2011 5:17 am
@Tomlong (and Psymon),
You two are the only ones I'm aware of writing guides for creating BAIN archives. If both your guides taught that ini files should be placed in a 'scripts' folder, people would not be confused. They would just believe you (at least as much as they believe the rest of your guide).
Many mods are not trying to be BAIN-ready, so their ini files might be anywhere: Data folder, Ini folder, whatever. Trying to pressure mod creators to change their directory preferences hasn't been so successful, but, then again, not too many of them are trying very hard to create BAIN-style directories.
Am I ignorant of the existence of otherwise BAIN-structured mod archives that are not installable because they have the ini file in a folder which gets skipped? I ask because I have never had this problem. If there are such mods, they certainly deserve to be mentioned in your guides. If there aren't, then I don't see the great need for changing Wrye Bash's directory structure.
gothemasticator
You two are the only ones I'm aware of writing guides for creating BAIN archives. If both your guides taught that ini files should be placed in a 'scripts' folder, people would not be confused. They would just believe you (at least as much as they believe the rest of your guide).
Many mods are not trying to be BAIN-ready, so their ini files might be anywhere: Data folder, Ini folder, whatever. Trying to pressure mod creators to change their directory preferences hasn't been so successful, but, then again, not too many of them are trying very hard to create BAIN-style directories.
Am I ignorant of the existence of otherwise BAIN-structured mod archives that are not installable because they have the ini file in a folder which gets skipped? I ask because I have never had this problem. If there are such mods, they certainly deserve to be mentioned in your guides. If there aren't, then I don't see the great need for changing Wrye Bash's directory structure.
gothemasticator
-
Conor Byrne - Posts: 3411
- Joined: Wed Jul 11, 2007 3:37 pm
» Sat Apr 30, 2011 6:51 am
I do not know how INI files work exactly, but I do not think that you can just put them in the INI folder. Doesn't the plugin have to have the write file path? If you move the plugins to "scripts" then you would have to change file paths in the utiilties, right? Also, I also think that mods with INIs in random folders are few in number. Most mods are BAIN-ready by virtue of being simple packages. The most common package format that stops that "most" from being the vast majority is only authors putting the ReadMe files at the same level as the "Data" folder. That is very irksome, and I overlooked that a number of time in my guide.
-
Mason Nevitt - Posts: 3346
- Joined: Fri May 11, 2007 8:49 pm
» Sat Apr 30, 2011 7:25 am
I think what I'm trying to ask is:
What would it solve to change Wrye Bash's supported directory structure?
(I'm following the discussion here and just getting a tad lost since I haven't run into any ini-related problems, and I install everything via BAIN.)
gtm
What would it solve to change Wrye Bash's supported directory structure?
(I'm following the discussion here and just getting a tad lost since I haven't run into any ini-related problems, and I install everything via BAIN.)
gtm
-
Melis Hristina - Posts: 3509
- Joined: Sat Jun 17, 2006 10:36 pm
» Fri Apr 29, 2011 9:59 pm
silly question, how do add a bash tag to my mod?
-
Danny Warner - Posts: 3400
- Joined: Fri Jun 01, 2007 3:26 am
» Sat Apr 30, 2011 11:25 am
silly question, how do add a bash tag to my mod?
I got almost a few minutes free tonight... I'll try and answer everyone questions soon I promise.
but yours is easy so: either add the text {{BASH:*tags*}} (replacing *tags* with the desired tag names or right click the grey box under the mods masters when selected in the mods tab and select the desired tags.
Pacific Morrowind
-
des lynam - Posts: 3444
- Joined: Thu Jul 19, 2007 4:07 pm