3 réponses à ce sujet

[BryanDerksen]

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.

[BryanDerksen]

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.

[BryanDerksen]

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.