Nissa_Red wrote...
There is a workaround, but it's not something trivial, neither in matter of knowing how the toolset resources operate (achieving compatible 2DA files is only the tip of the iceberg/difficulties ahead, if you want to do it properly), nor in matter of time required to proceed to such an endeavor. No one has done it so far, or at least officially released anything, to my knowledge.
Honestly, unless you really had a huge amount of time ahead, you'd be better off with just picking one package, and building/adding on top of it, accordingly to your needs.
EDIT: Also let's not forget that whenever either team releases a new version of their package, the "merge" will have to be updated if it's to be an "official" one. All this really doesn't make it look... uh, very reasonable to be expected to happen anytime soon.
I plan on doing a test case with this with my merging tool, sounds like it's complex enough to stress test what I am doing, and it's only 2 packages so it won't be too confusing. Imagine what you describing beyond compatible 2da files involves migrating 2da rows, adjusting blueprints to match the moved 2da rows, and the dialog.tlk merging. I'd basically be downloading multiple projects based on a manifest, and merging like files such as 2da's and tlks automatically initially. The migration of conflicts for the same rows, or the same file which require migration is the second stage after that, the hardest part of that being where should the new rows be, so it's semi reserved so it minimizes the impact on modules and bics reliant on those rows.
Do you know of other areas of the iceberg which need to be dealt with? ( I am sure I will encounter them soon enough, but it helps to know what the mess is going to be ahead of time )
( I am not sure if there are similar issues like NWN2 has with mdb files, where you have to rename the file and have resources inside the file have matching names. )
