Previous Topic(s):
http://www.gamesas.com/topic/1120974-upcoming-mod-tool/
http://www.gamesas.com/topic/1140559-smartmerger/
http://www.gamesas.com/topic/1146795-smartmerger-2/

Downloads:
http://planetelderscrolls.gamespy.com/View.php?view=Utilities.Detail&id=78
http://rtcvb32.herobo.com/SmartMerger/MW_SmartMerger_v26D.zip

Online Documentation:
http://rtcvb32.herobo.com/MW_SmartMerger_Docs/

Since the previous topic has been locked, here is the new one.
Current version: 2.6D

In regards to http://www.gamesas.com/topic/1146795-smartmerger-2/page__view__findpost__p__20631201, I fixed the issue by reverting back to the version available on planetelderscrolls.

EDIT: And it still crashes when generating a merged_objects

Not sure how helpful I can be, or if you still need the help; Recently re-installed my OS taking care of stability issues. I hate it when my system keeps crashing for no good reason. Anyways, recent news.

SmartMerger D: (Or rename to SmartMergeD?)

Seems I lost some of my sources, but on track once more. So far I can read esm/esp files, write them, and output all information from subrecords, including flags and related. First priority is to try and get nearly all the current functionality in the new sources, although with certain aspects greatly simplified and using inheritance it's cleaner, although not sure if it's faster yet. Contemplating putting sources on http://sourceforge.net/. _{(what type of license to go for?)}

Depending on how much it takes for my head to explode, hopefully I'll get the D version to have all current/previous features inside of 3 months (Guess I'm back in my programming mindframe). I'm trying for 95% code coverage and full unittests (the last 5% being tests where it throws due to a failed test )

Beta testers welcome once I have a version that can do something useful. I'm sure spiffyman will be one of them.

So, how does dialogue merging look for the future?

I would say expect a big improvement.. I'm just not sure if I should use an array/tree for each entry that keeps track of what's left and right (Which is a lot of overhead, but better in the long run?) or go with with keeping track as it steps through the list what's to the left and right. Both seem to cancel eachother out a bit. I was thinking of having a second list of info records it keeps track of when it can't confirm a record is to the left or right, in which case it tries again later.

I was thinking of having it deferring files to merge if all of it's requirements weren't loaded, but there are cases when you don't have those loaded so file order may be more important than deferring. Not sure yet. So many things to try and keep track of. So many things to decide on. Some things just to try and see how they do.

edit:


Mmmm I've come up with how to handle them, so there's only 2 arrays, a tree and an associative array. Now that I think about it it's quite simple and genius.

Hmmm Guess I'll make a note of this...

Added feature to deal with finding land textures easier (at least listing them all)

http://rtcvb32.herobo.com/SmartMerger/MW_SmartMerger_v26D.zip

http://www.gamesas.com/topic/1369632-tes-construction-set-how-to-figure-out-what-texture-is-used/

Wouldn't it be cool to merger http://www.mwmythicmods.com/MAPoMODSUpdated01.jpg into one mod compilation? I suppose all but "Morroland" and "Blacklight + Silgrad Tower".

I think the same argument goes around for merging the three main masters, plus a couple.

• Savegame data. The new merged module won't recognize most of the old items, especially if any FRMR's change.
  
• Mods likely done by different authors, and may not want works combined.
  
• other mods may be dependent on said mods (Expansions or fixes) and may not work (or refuse to work) when merged.

Probably the biggest is that since they are already separate, mods relying on them have to be tweaked. If someone cares to begin a project for that perhaps it would be great. But honestly I don't think I'll have the time fairly soon. Nor would I have the Patience.

I was actually thinking of exactly that when I was typing my post, why not just assign something completely new(even if only temporary) while sorting things, instead of using whats there because of the problems it causes. I wasnt sure of how you had handled anything so far.(assuming I got what you are saying right)

Current C implementation uses double linked lists for the info records. That's my choke point in the code; I could add the additional code now to deal with that, but without inheritance and other details helping in normal C I'm not so sure; plus add a feature and all other records need to carry the extra weight too.

Actually I don't think it will help in C. For it to help in C I need to implement a AVL tree (which I have one converted) or something that's self-sorting; Otherwise it will be resorting after each insert and could be as slow as it is now if not worse. Well that's the price I paid for using C. I tried working on v2.7 to add the tree support to managing all the records already (And remove the 'sorting:' block after loading each file ), but I've decided unless it's really important I'll just leave it be while I try to get my D version done. I want to say the code re-write for basic merging (plus referencing) is over 50% done, and additional features afterwards would be simple to add.

Edit: I've also been wondering what if I use double instead of an int/long and just increment by one instead? That actually sounds like it would be better due to how floating point works...