Aller au contenu

Addons & Mods: Organizing the Override


23 réponses à ce sujet

#1
Guest_Lunarionsilver_*

Guest_Lunarionsilver_*
  • Guests
I had made this post in a comment over at DA:O Nexus and was asked if I had made a post here about it. I decided it would probably be best to share what I learnt about the override folder to the main DA:O community. Some of you may already know this. Others of you may not.

The DA:O override accepts a single sub-group of folders. The best way to
organize your mods would be to go into your override folder and create a
folder for each mod you have. So long as those mod specific folders
don't contain any other folders your mods will work fine and remain
organized for easy uninstall. The only thing you need to be wary of is
when you're dealing with mods that may have similar 2DA files.

My override looks like this and works perfectly. Something to keep in mind.


I hope this helps the community when dealing with addons and mods to the game which are not absed on the *.DAZIP. Personally I prefer the use of the override folder when dealing with modding a game. This way of organizing your addons and mods is great when updateing, uninstalling, reinstalling, or backing up.

I hope this helps. Feel free to add whatever other knowledge you have in helping people organize their addons and mods, or just general information. The more we know the better!

- Lunarion Silver

Modifié par Lunarionsilver, 18 novembre 2009 - 02:12 .


#2
Toom316

Toom316
  • Members
  • 64 messages
The Dragon Age Mod Management Tool installs all of its listed mods in this format. I take the time to go through and change every mod we have listed to fit this format.



Not only does it keep the override folder cleaner and easier on the eyes. It makes uninstalling mods a breeze.



Now if only every Mod Author followed this simple rule everything would be golden.

#3
Ambaryerno

Ambaryerno
  • Members
  • 532 messages
The biggest problem with the upcoming releases of mods is going to be what happens as more mods start to fight over the same IDs in the 2DA files, or make different changes to the same models and game mechanics.

#4
Toom316

Toom316
  • Members
  • 64 messages

Ambaryerno wrote...

The biggest problem with the upcoming releases of mods is going to be what happens as more mods start to fight over the same IDs in the 2DA files, or make different changes to the same models and game mechanics.


That will be a problem. Here is to hoping that someone comes up with a Mod Authors Guidelines or something similar that can help keep people on track and such.

There isn't too much that can be done on same IDs other then to educate authors and attempt to get them to use different sets of IDs.  Or maybe give a listing of IDs used in there readme file. Atleast that would help with finding compatability issues with other mods.

#5
Guest_Lunarionsilver_*

Guest_Lunarionsilver_*
  • Guests
I have a feeling that once more mods are released the authors of the most popular ones, or perhaps even the fans, will start merging 2DA files for compatability purposes. This was done in other games such as NWN2 and KotOR, so I don't see it as a problem. I would think the most we may have to worry about is simply waiting for such compatibility issues to be fixed.



We'll have to wait and see how these things work out I suppose.



Also Toom316. I was looking at the DAMMT your working on. It's an interesting concept and I think a lot of people will find it quite useful. I've personally always been a fan of manually managing my addons and mods for games. Even such extensive ones as WoW. Of course that is jsut my preference. I do quite like your project.



- Lunarion Silver

#6
Toom316

Toom316
  • Members
  • 64 messages

Lunarionsilver wrote...

I have a feeling that once more mods are released the authors of the most popular ones, or perhaps even the fans, will start merging 2DA files for compatability purposes. This was done in other games such as NWN2 and KotOR, so I don't see it as a problem. I would think the most we may have to worry about is simply waiting for such compatibility issues to be fixed.

We'll have to wait and see how these things work out I suppose.

Also Toom316. I was looking at the DAMMT your working on. It's an interesting concept and I think a lot of people will find it quite useful. I've personally always been a fan of manually managing my addons and mods for games. Even such extensive ones as WoW. Of course that is jsut my preference. I do quite like your project.

- Lunarion Silver


Thank you for the kind words. It's still in the early stages of development right now. But now that I have found a Web Designer to help out with the interface design and the layout of the Tool. It's now going to get some much needed graphical love / makeover done on it.

#7
Riuthamus

Riuthamus
  • Members
  • 12 messages
I roughly skimmed this post but modifying 2das in the past for nwn made me question creating a "register" link. Each month moders would go there and register their mod additions and that group of people would modify the 2da's and give out ID's accordingly. This would allow the serious moders to ensure their models were not impeding upon another mod and would allow for it to be centralized. God help the people who do this since 2da work is like pulling teeth, but might be something to look into.

#8
ladydesire

ladydesire
  • Members
  • 1 928 messages

Lunarionsilver wrote...

I have a feeling that once more mods are released the authors of the most popular ones, or perhaps even the fans, will start merging 2DA files for compatability purposes. This was done in other games such as NWN2 and KotOR, so I don't see it as a problem. I would think the most we may have to worry about is simply waiting for such compatibility issues to be fixed.

 

I'm not sure how it was done in KotOR, but NWN2 modders have a section on the NWN2 wiki for 2da reservations, the majority of us that are aware of this use it; it's the ones that don't know about it that create headache for the rest. I should know; I'm one of the NWN2 modders that uses it quite often.

We'll have to wait and see how these things work out I suppose.


I think I will create a page on the wiki here for this information so that modders of this game know about it; I will also create a thread linking to it in this forum and request that it be made a sticky topic so it's always in view so those that use this site have a way to get to it. I'm really not caring whether modders that refuse to use this site know about it or not.

#9
ladydesire

ladydesire
  • Members
  • 1 928 messages

Riuthamus wrote...

I roughly skimmed this post but modifying 2das in the past for nwn made me question creating a "register" link. Each month moders would go there and register their mod additions and that group of people would modify the 2da's and give out ID's accordingly. This would allow the serious moders to ensure their models were not impeding upon another mod and would allow for it to be centralized. God help the people who do this since 2da work is like pulling teeth, but might be something to look into.


For NWN, we had this Reservered 2da Ranges. I use it quite often. I don't think there ever was one for NWN.

#10
BryanDerksen

BryanDerksen
  • BioWare Employees
  • 273 messages

I have a feeling that once more mods are released the authors of the most popular ones, or perhaps even the fans, will start merging 2DA files for compatability purposes. This was done in other games such as NWN2 and KotOR, so I don't see it as a problem.


This shouldn't be needed (and isn't really advisable) for DA's 2DA files. DA uses M2DAs ("multi-2DAs") that auto-merge with each other when the game loads them up. To ensure compatibility all you should have to do is change the line IDs so that they don't overlap with each other, they can remain in their separate files.

Addins can also be enabled and disabled with a checkbox in the "downloaded content" pane, so incompatible addins could coexist in relative comfort on the same system as long as the user only enables one of them at a time.

#11
Talian Kross

Talian Kross
  • Members
  • 239 messages
I just wish modder's would get out of the nasty, lazy habit of throwing everything into the global core/override folder and instead create a proper AddIn and use its core/override folder.

:?

I love this new layered, modular approach introduced in DA:O.  (For once, I actually don't resent greed inspired DLC stuff since I'm sure that was what inspired this new system.)  The only thing I haven't figured out yet is how to denote an AddIn's priority other than manually editing the manifest file and changing the load order.

Modifié par Talian Kross, 19 novembre 2009 - 11:38 .


#12
Ambaryerno

Ambaryerno
  • Members
  • 532 messages
Bryan,

I think what people are getting at, is some way to organize what ID ranges are being used by different modders to minimize ID conflict.

Say, in Arms and Armor's BITM file I set Falchions as ID 301. But someone wants to run another mod that ALSO uses ID 301 for a staff in the BITM file. Now the solution would be for one of us to adjust our IDs in BITM to accommodate the changes made by the other mod. What they're suggesting is a central database where modders can go to see what IDs are being used by other mods so they can plan around them and PREVENT having to go back and change them when a conflict is discovered later on.

Talian,

If I understand the situation that won't make a difference in the case of the example above if both mods use the same IDs. Even if you put your information in your add-in's own override folder, it will STILL come into conflict if someone else's mod--also with its own override folder--changes those same IDs.

Modifié par Ambaryerno, 19 novembre 2009 - 11:42 .


#13
Talian Kross

Talian Kross
  • Members
  • 239 messages

Ambaryerno wrote...

If I understand the situation that won't make a difference in the case of the example above if both mods use the same IDs. Even if you put your information in your add-in's own override folder, it will STILL come into conflict if someone else's mod--also with its own override folder--changes those same IDs.


Oh, I know.  My post was just an off-topic (but still kind of related) mini-rant. :whistle:

(Actually, it is not that off-topic because it was Bryan's mention of enabling/disabling custom content via the Installed Content tab that made me think of it.)

#14
ladydesire

ladydesire
  • Members
  • 1 928 messages

Ambaryerno wrote...

Bryan,

I think what people are getting at, is some way to organize what ID ranges are being used by different modders to minimize ID conflict.


This is exactly what I was getting at.

#15
BryanDerksen

BryanDerksen
  • BioWare Employees
  • 273 messages
Oh, certainly, something like that will likely be needed for the popular mods. I was just reacting to the suggestion that this would involve "merging 2DA files". It really shouldn't, since merging stuff into one big lump like that makes it really hard to change parts later on.



Actually, stuff in the addin's override directory doesn't get loaded into memory by the game at all unless that addin is explicitly part of the currently active module hierarchy. For example if you had two stand-alone campaigns, they could in theory have overlapping 2DA IDs without fuss since only one of them would be loaded into memory at a time. So coordinating IDs may not be quite as pressing a need as it first seems. Still a good idea, though, since there are potential gotchas (stuff in an addin's _core_ override directory gets loaded into memory regardless of whether the addin is in the heirarchy or not, for example. These various override directories make my head hurt sometimes).



A few 2DAs have limits on their row IDs but for most 2DAs it might be handy to pick some big random number to start with and you'll be less likely to collide that way. Start your sword pack's 2DAs at row ID 2937487, for example, and you're less likely to step on anyone else's toes. Not a perfect solution but something to consider until a perfect solution comes along.

#16
BryanDerksen

BryanDerksen
  • BioWare Employees
  • 273 messages
In the very next thread I read after replying to this one, I came across a great bug found by elys: http://social.biowar.../index/218226/2



It looks like the ExcelProcessor.exe we included with the toolset will produce incorrect binary versions of the 2DA for row IDs larger than around 8 million. So when picking random numbers keep that in mind for now, until we can get a bugfix out for that. :)

#17
Tikkidew

Tikkidew
  • Members
  • 33 messages
Hey thanks for the link Lunarionsilver .. had no idea there was already a DA:O Nexus .. that's awesome! I was really hoping for one. Sorry to change the subject ..

#18
Talian Kross

Talian Kross
  • Members
  • 239 messages

BryanDerksen wrote...

Actually, stuff in the addin's override directory doesn't get loaded into memory by the game at all unless that addin is explicitly part of the currently active module hierarchy...

I guess that's true.  My mods have all been geared toward extending the "Single Player" campaign, and their hierarchy has been set as such.

Of course, I have yet to see or download a mod (yet, this early) that wasn't intended for official campaign, so my slightly off-topic mini-rant still stands. :P

#19
ladydesire

ladydesire
  • Members
  • 1 928 messages

BryanDerksen wrote...

A few 2DAs have limits on their row IDs but for most 2DAs it might be handy to pick some big random number to start with and you'll be less likely to collide that way. Start your sword pack's 2DAs at row ID 2937487, for example, and you're less likely to step on anyone else's toes. Not a perfect solution but something to consider until a perfect solution comes along.


Which 2DA files are they? I realize that it's early in the cycle, but knowing which ones would help us out greatly.

#20
Nodrak

Nodrak
  • Members
  • 144 messages
It seems like you can have a structure that is more then one folder deep. My current override looks like:

\\override\\toolsetexport\\Mod\\files

Yea, I can confirm it.  I moved files that worked ingame from "\\Override\\toolsetexport\\" to "\\Override\\toolsetexport\\testmod\\testdir\\" and it worked the same.

Modifié par Nodrak, 20 novembre 2009 - 03:51 .


#21
Rishavs

Rishavs
  • Members
  • 149 messages
Fantastic tool. If it gets to be as good as the Oblivion mod manager then we can standardize the mods released by others. you have my support. and my axe.

#22
Qutayba

Qutayba
  • Members
  • 1 295 messages
A slew of questions, and since they fit here I won't start another thread:



For builders, is there a mechanism that lets you set where resources created in the toolset will be exported, or is organizing the multifarious override folders something that must be done manually?



For the moment, I'm keeping my module files in the Documents/BioWare/Dragon Age/AddIns/<ModuleName>. When I get to the point of creating a DAZIP (or DAModder file), do the module files get sent to the user's local Documents folder with the same organization I have set up while I'm building (i.e., if I keep them all in a <Module Name> folder, they won't end up scattered all over the place for the user)?



I occasionally see posts about certain kind of resources only working if they are in specific override folders. Has this been confirmed, or would I be safe picking one of the many override folders (such as AddIns/<ModuleName>/core/override/<Subfolders>) and sticking everything in there (and organizing them there)?



Do resources have to stay in a /toolsetexport subfolder or can they be reorganized, too? Are the Assets, Core, and Module substructure in an AddIns/<ModuleName> directory required, or can I create my own structure and still have it work?

#23
Proleric

Proleric
  • Members
  • 2 352 messages

Qutayba wrote...

A slew of questions, and since they fit here I won't start another thread:

For builders, is there a mechanism that lets you set where resources created in the toolset will be exported, or is organizing the multifarious override folders something that must be done manually?

The toolset does it for you - and conveniently makes a set of folders named after your mod or module, as long as you make it as an add-in. As general guidance, manual changes to folders are bad news as they can cause incompatibility between modules, though there are exceptions (such as deleting stuff that the toolset still erroneously places in the packages folder).

For the moment, I'm keeping my module files in the Documents/BioWare/Dragon Age/AddIns/. When I get to the point of creating a DAZIP (or DAModder file), do the module files get sent to the user's local Documents folder with the same organization I have set up while I'm building (i.e., if I keep them all in a folder, they won't end up scattered all over the place for the user)?

Yes

I occasionally see posts about certain kind of resources only working if they are in specific override folders. Has this been confirmed, or would I be safe picking one of the many override folders (such as AddIns//core/override/) and sticking everything in there (and organizing them there)?

I suspect this is true and would like to see more information in the wiki. If you're just making the standard art and design objects described in the wiki, you shouldn't go too far wrong, but there might be issues with custom models, textures and icons.

Do resources have to stay in a /toolsetexport subfolder or can they be reorganized, too? Are the Assets, Core, and Module substructure in an AddIns/ directory required, or can I create my own structure and still have it work?

If the wiki is to be believed, you can't just assign any folder name you like, but other people may know more about this.

#24
elys

elys
  • Members
  • 458 messages

Toom316 wrote...
......

There isn't too much that can be done on same IDs other then to educate authors and attempt to get them to use different sets of IDs.  Or maybe give a listing of IDs used in there readme file. Atleast that would help with finding compatability issues with other mods.



2DA ranges in use. 

But if nobody uses it... It does not help Image IPB