See there @cmorgan ;-) You answered that stuff better than I ever could. I am all for this idea if it can be made to work and not break any mods. We just need to keep talking so everything potentially bad is fully understood enough to keep it from getting ugly at the players end.
Regarding the wild override folders, I predict a lot of shot feet. And frankly, I don't see what the gain is. Maybe that was elaborated upon in the reddit thing, I don't know.
Most mods cannot be organised into discreet subfolders, nor would it make sense to do so. You have everything from bit-precision patching of shared files, install-time conditionals to the matter of global files, like the string table or the WeiDU log. @cmorgan already expounded on this. But, for instance, this example by @Boaster:
Then, inside the mods folder (D:\games\Black Isle\BG1EE\override\mods\) I would then create a folder for each mod I would install to keep things separate.
One of the problems here is that the list does not have to be very long before two or more mods start overlapping by affecting some of the same files. In fact, it is not that unlikely that these hypothetical proficiency and kit mods would already be conflicting (say, by both needing to alter weapprof.2da). To solve this you could patch files incrementally, but then, where is the use in having these separate folders? Very few mods can be independent of each other, in the sense that they can cleanly coexist as separate entities. This is a simple consequence of how the game files are structured.
WeiDU already offers a good solution to the problem of organising and managing mods.
Then you have things like biffing, or interactions with WeiDU and its mod-stack operations and the nigh-universal recommendation will be to not use this feature.
I find it totaly confusing to work or play with more then one override folder. Maybe it´s just because of my nwn background where we just use haks for specific purposes and overrides for testing (I at least only) so forgive me my lack in knowledge.... So here my question, is it possible to create something like a modpakage? This is a handy feature when working a bit more organized on projects. The pakages certainly need a priority setting.
Various override folders is clearly not adequate when thinking about using many different mods for a unique game configuration for all the obvious reason cited already in this thread.
However additional optional override folders, can be used to switch very quickly and efficiently between various game configurations, or say other wise play different mods or settings independently but not all together.
It's also nice for testing purpose, example:
If you have your Override already containing lot of modded files, and you want to test various changes to some of the files. You can just create additional override folders TEST1, TEST2, etc... that only contains the modified files required for the test. Then you can quickly perform tests just by enabling them in the Ini. So you don't have to duplicate the whole "main" override folder for each different various tests you want to perform.
But it's not only good for tests only, but also for playing. If a player has slight variations of its finalized installed mod configuration, that he switches from and to depending of the character he plans to play. He can then use additional overrides folders to comfortably switch between various configurations, without the need to each time run "weidu disable/enable" on all the concerned files, or the need to duplicate his whole override folder for each little variations, or without the need to manage files (renaming, moving or whatnot).
Brief I clearly think optional override folders are certainly not a method to install and use many mods at the same time. Weidu works fine for that. However what can do more, can do less. You can still mod the game the way it used to be, using only one override folder. And obviously I just don't expect such additional override folders to be managed automatically by mod installation. But I like having the possibility to use more if I need.
Maybe @CameronTofer could chime in and comment in light of the modders' considerations. It is my understanding that this feature has already been implemented, but if it's actually an inconvenience for modders it may be possible to eliminate it?
It is my understanding that this feature has already been implemented, but if it's actually an inconvenience for modders it may be possible to eliminate it?
It is not inconvenient, just not terribly useful for adding mods to the game.
An update on the subject, Trent Oster just recently tweeted:
"We'll be doing free feature improvements and existing content improvements as we go, but we are also planning some paid DLC."
and
"Scott was fighting with multiple TLK files earlier in the day. This will open ease of modification a fair bit and reduce content collisions"
In such context, additional override (or DLC) folders makes sens to organize mods (similar to what Dragon Age uses), furthermore if more than TLK file types will be handled concerning collision.
In such context, additional override (or DLC) folders makes sens to organize mods (similar to what Dragon Age uses), furthermore if more than TLK file types will be handled concerning collision.
But multiple overrides, with precedence rules and directory-separation of files, does not actually solve much. It does not even give each mod its own namespace, since the overrides are merged in memory, with the content of higher precedence shadowing any overlapping content of lower precedence. You still have to use prefixes to establish namespaces, both for mods and DLC, (Bioware used prefixes back in the day too) and incrementally patch if you want two different modifications to the same file. As for why multiple TLKs is a bad idea, I posted my thoughts on the subject here.
@Wisp: All is always merged in memory. Mod, DLC, Overrides are all loaded by the game in a certain order (even when the order is not explicitly chosen.)
A DLC, not only for BG, is just an override folder with a different name. The engine loads vanilla game data, then DLC data. If DLC contains colliding data with the vanilla resources, it acts like an override folder.
The new [override] section in BGEE ini could have been as well named [DLC] or [Mod]. It's just an additional way to load additional resources.
You can organize mod in different DLC or Override folders. It makes very quick abd easy to enable/disable any DLC/Mod when it's organized that way. A simple launcher with a checkbox to turn the mod folder on/off in the ini. It's also very simple to install/un-install mod that way since you just have to copy or delete the folder.
Of course while it's very clean and comfortable, it's not as flexible if you need to modify lot of the original files with Weidu scripts. It could always been done in the Override folder as usual. But Weidu installation would have to take the other folders into consideration when seeking for files. And the Weidu installations would need to be refreshed if the user install a non-weidu mod, or an official DLC afterward.
Of course that means the community will need to work on updating the tools and the mods in such hypothetical setup.
@Wisp: All is always merged in memory. Mod, DLC, Overrides are all loaded by the game in a certain order (even when the order is not explicitly chosen.)
A DLC, not only for BG, is just an override folder with a different name. The engine loads vanilla game data, then DLC data. If DLC contains colliding data with the vanilla resources, it acts like an override folder.
The new [override] section in BGEE ini could have been as well named [DLC] or [Mod]. It's just an additional way to load additional resources.
But it is not an additional way of concurrently running additions to the base game, be they mod or DLC. When there is overlap the content of lower priority will effectively vanish. This is a HUGE step back from existing modding practices. In fact, it would be straight back to the bad old days of circa year 2000.
You can organize mod in different DLC or Override folders. It makes very quick abd easy to enable/disable any DLC/Mod when it's organized that way. A simple launcher with a checkbox to turn the mod folder on/off in the ini. It's also very simple to install/un-install mod that way since you just have to copy or delete the folder.
But it wouldn't. This is not TES we are talking about here. IE modding does not work that way. Due to the file formats and the way the engine works, it cannot work that way. If you installed the G3 Fixpack with this system, you would either have to choose between installing no other mods, live with the incompatibilities of using more mods, or impose the burden of the resulting combinatorial explosion upon the modders. None of these choices are acceptable.
@wisp: It does not work that way so far . But that's more a subject of the discussion we have in the other thread ^^
And I know it does not work that way. I've seen all the same files being modified by various mod when using weidu, as well as when I modded stuff in.
I'm gonna give a concrete example:
Let' say I create a small standalone adventure (so independent of the official campaign). Obviously I will modify original files for it to work. But my standalone mod is obviously not supposed to work with official campaign mods. By having my mod in its own folder, i can just switch anytime from the official campaign (modded or not), to the my mod and eventually other similar standalone mods. Just by disabling or enabling the mod folder.
That makes sens to have separate folders for such mod.
Even just for the Official Campaign mods it make sens to have various folders, when you want to have more than one type installation.
For example you could have one weidu managed override folder containing BG+Mod A+Mod B+ settings X, and another weidu managed override folder containing BG+Mod B+ Mod C + Settings Y). And you can switch anytime between various installation just by modifying an INI setting, or using Bgee.exe launch parameters.
It can be useful if you have two or more mods that are not compatible with each others. For example one mod modify an area to have a big castle, while another mod adds a lake at the same place. You certainly want to keep these mod separated as they cannot run together. Currently with BG-Weidu you have to make a choice, or take the hassle to weidu install/uninstall each time you want to switch from one config to another, or to juggle with moving/renaming override folders. That's not the case when you can easily turn on/off various override folders as needed.
And last as I was saying few days ago, it can be useful even for slight variations of a main installation that you like to switch around. You just need to have your big modded override folder, and additional override folder that you turn or and off as needed. Of course that's only for a finalized installation, not supposed to be modded again, else you will need to recreate each of your slight override variation each time you make modification to your big mod override. That's something I often use, and the reason why I created HyperOverride for my own usage in the first place, so I will be happy to have the feature natively supported First time I needed an additional override folder, was because I wanted to have a unique BGTutu installation that could run either, and immediatly switch between BG1 or BG2 campaigns, just by setting a parameter in bgmain.exe shortcut. (There is only few different files between BG1 and BG2 when using a BGTutu installation, so that was convenient.)
Currently Near infinity, DLTCEP & Weidu can't check subfolders in override.
Moreover, with several folders you can have the same file in several places and the same file can have several descriptions in tlk... If you want to make the life of the modder a hell, it's a good idea... Otherwise it's a very bad idea.
I'm willing to change DLTCEP. Not a big deal. Weidu is the big deal, but only if this would break backward compatibility.
I thought WeiDU could potentially be adapted to support pretty much anything (then again, I know nothing of how WeiDU works; it was just an impression).
The problem with WeiDU is that somebody might have been smart enough to use the override folder to store modding resources inside (to not fill the main folder with suspiciously looking folders).
I know of no such case, however at least I have considered doing so at one point.
I also fail to see how subfolders would enhance modding possibilities.
override folder crowded --> slow game performance. With subfolders, you can separate mod stuff from original game data. I think this is a very good feature, it just needs support. But, all new feature needs changes in the editors, it is just a question of backwards compatibility.
I support the idea of subfolders, allows better configurability with mods. I don't have doubt that mods and modding tools will need some tweaking to work with BG:EE.
On a slightly aside note, if the game cached the entire override folder on startup, and when instances get modified sub-cache certain files like it currently does, then game performance wouldn't be as badly affected... at the expense of some increased memory requirements and some increased startup time; two things that modern day computers should be able to handle pretty easily.
If the amount of tweaking required to make existing mods and tools work with BG:EE is relatively small, and the increase in flexibility / moddability / performance is great, I would say it is pretty good deal :-)
The way existing mods work wouldn't change if you just merely add the option for sub-folders to point to, that would allow organizing of files or mods.
For example, if you wanted to add a sub-folder for files and not necessarily a mod, in the INI you would need to point to that file folder as if it were a mod.
This is at least the way I interpret the addition of sub-folders.
An option added is not an option taken away in this instance.
Right now we use this feature to point to work in progress files that we don't want to distribute to the rest of the developers. When we finish something, the file ends up in the existing override directory.
Comments
Regarding the wild override folders, I predict a lot of shot feet. And frankly, I don't see what the gain is. Maybe that was elaborated upon in the reddit thing, I don't know.
Most mods cannot be organised into discreet subfolders, nor would it make sense to do so. You have everything from bit-precision patching of shared files, install-time conditionals to the matter of global files, like the string table or the WeiDU log. @cmorgan already expounded on this.
But, for instance, this example by @Boaster: One of the problems here is that the list does not have to be very long before two or more mods start overlapping by affecting some of the same files. In fact, it is not that unlikely that these hypothetical proficiency and kit mods would already be conflicting (say, by both needing to alter weapprof.2da). To solve this you could patch files incrementally, but then, where is the use in having these separate folders? Very few mods can be independent of each other, in the sense that they can cleanly coexist as separate entities. This is a simple consequence of how the game files are structured.
WeiDU already offers a good solution to the problem of organising and managing mods.
Then you have things like biffing, or interactions with WeiDU and its mod-stack operations and the nigh-universal recommendation will be to not use this feature.
However additional optional override folders, can be used to switch very quickly and efficiently between various game configurations, or say other wise play different mods or settings independently but not all together.
It's also nice for testing purpose, example:
If you have your Override already containing lot of modded files, and you want to test various changes to some of the files. You can just create additional override folders TEST1, TEST2, etc... that only contains the modified files required for the test. Then you can quickly perform tests just by enabling them in the Ini. So you don't have to duplicate the whole "main" override folder for each different various tests you want to perform.
But it's not only good for tests only, but also for playing. If a player has slight variations of its finalized installed mod configuration, that he switches from and to depending of the character he plans to play. He can then use additional overrides folders to comfortably switch between various configurations, without the need to each time run "weidu disable/enable" on all the concerned files, or the need to duplicate his whole override folder for each little variations, or without the need to manage files (renaming, moving or whatnot).
Brief I clearly think optional override folders are certainly not a method to install and use many mods at the same time. Weidu works fine for that.
However what can do more, can do less. You can still mod the game the way it used to be, using only one override folder.
And obviously I just don't expect such additional override folders to be managed automatically by mod installation. But I like having the possibility to use more if I need.
"We'll be doing free feature improvements and existing content improvements as we go, but we are also planning some paid DLC."
and
"Scott was fighting with multiple TLK files earlier in the day. This will open ease of modification a fair bit and reduce content collisions"
In such context, additional override (or DLC) folders makes sens to organize mods (similar to what Dragon Age uses), furthermore if more than TLK file types will be handled concerning collision.
A DLC, not only for BG, is just an override folder with a different name. The engine loads vanilla game data, then DLC data. If DLC contains colliding data with the vanilla resources, it acts like an override folder.
The new [override] section in BGEE ini could have been as well named [DLC] or [Mod]. It's just an additional way to load additional resources.
You can organize mod in different DLC or Override folders. It makes very quick abd easy to enable/disable any DLC/Mod when it's organized that way. A simple launcher with a checkbox to turn the mod folder on/off in the ini.
It's also very simple to install/un-install mod that way since you just have to copy or delete the folder.
Of course while it's very clean and comfortable, it's not as flexible if you need to modify lot of the original files with Weidu scripts.
It could always been done in the Override folder as usual. But Weidu installation would have to take the other folders into consideration when seeking for files. And the Weidu installations would need to be refreshed if the user install a non-weidu mod, or an official DLC afterward.
Of course that means the community will need to work on updating the tools and the mods in such hypothetical setup.
As for the TLK, I've replied there already
And I know it does not work that way. I've seen all the same files being modified by various mod when using weidu, as well as when I modded stuff in.
I'm gonna give a concrete example:
Let' say I create a small standalone adventure (so independent of the official campaign). Obviously I will modify original files for it to work. But my standalone mod is obviously not supposed to work with official campaign mods. By having my mod in its own folder, i can just switch anytime from the official campaign (modded or not), to the my mod and eventually other similar standalone mods. Just by disabling or enabling the mod folder.
That makes sens to have separate folders for such mod.
Even just for the Official Campaign mods it make sens to have various folders, when you want to have more than one type installation.
For example you could have one weidu managed override folder containing BG+Mod A+Mod B+ settings X, and another weidu managed override folder containing BG+Mod B+ Mod C + Settings Y). And you can switch anytime between various installation just by modifying an INI setting, or using Bgee.exe launch parameters.
It can be useful if you have two or more mods that are not compatible with each others. For example one mod modify an area to have a big castle, while another mod adds a lake at the same place. You certainly want to keep these mod separated as they cannot run together.
Currently with BG-Weidu you have to make a choice, or take the hassle to weidu install/uninstall each time you want to switch from one config to another, or to juggle with moving/renaming override folders.
That's not the case when you can easily turn on/off various override folders as needed.
And last as I was saying few days ago, it can be useful even for slight variations of a main installation that you like to switch around. You just need to have your big modded override folder, and additional override folder that you turn or and off as needed. Of course that's only for a finalized installation, not supposed to be modded again, else you will need to recreate each of your slight override variation each time you make modification to your big mod override.
That's something I often use, and the reason why I created HyperOverride for my own usage in the first place, so I will be happy to have the feature natively supported
First time I needed an additional override folder, was because I wanted to have a unique BGTutu installation that could run either, and immediatly switch between BG1 or BG2 campaigns, just by setting a parameter in bgmain.exe shortcut. (There is only few different files between BG1 and BG2 when using a BGTutu installation, so that was convenient.)
I think I have addressed this concern in the TLK thread. You can to this today (but the details vary). No one uses it.
I know of no such case, however at least I have considered doing so at one point.
I also fail to see how subfolders would enhance modding possibilities.
With subfolders, you can separate mod stuff from original game data.
I think this is a very good feature, it just needs support.
But, all new feature needs changes in the editors, it is just a question of backwards compatibility.
On a slightly aside note, if the game cached the entire override folder on startup, and when instances get modified sub-cache certain files like it currently does, then game performance wouldn't be as badly affected... at the expense of some increased memory requirements and some increased startup time; two things that modern day computers should be able to handle pretty easily.
For example, if you wanted to add a sub-folder for files and not necessarily a mod, in the INI you would need to point to that file folder as if it were a mod.
This is at least the way I interpret the addition of sub-folders.
An option added is not an option taken away in this instance.