Previous Topic:
http://www.gamesas.com/index.php?/topic/1120974-upcoming-mod-tool/

SmartMerger:
http://planetelderscrolls.gamespy.com/View.php?view=Utilities.Detail&id=78


I haven't seen any replies for a few days. That's either very good, or very bad.

And i think it's time to put a new topic that's much more obvious and accurate from the old one.

Anyways, last updated news. Version: 1.6 is out.

I'll also ask that those who have used/tried smartmerger, please vote on the polls, so i can get an idea of how people feel about it. Also post comments, suggestions, found bugs.

Hmmm... new to these polls...

Personally, I prefer tools with GUI's, not because smart merger, or other command line tools aren't powerful enough, or that they are too hard to use, but because gui's simplify and speed up the process and remove that intimidating feeling one gets when using the command line.

As a graveyard shift worker in RL, my free time is limited, so anything I can do to maximize that time is imperative for me personally.

That being said, what I have seen looks very promising, and I'm sure that there are plenty of modders out there that would be happy to have this tool available to them.

As a player who only really mods for my own personal use, with no self made mod releases to my name, merely tweaks to current mods with my own personal flair, I can say that I like the idea of being able to perhaps merge all of my game files into one esp to help speed up loading times, though I haven't fully tested the program, and have grown to fear anything that merges dialogue.

I do however wish you luck, and fully appreciate your continued support on the project, I have a bit of hope that one day it will become the defacto mod tool to use(and perhaps even have a gui made), because quite frankly, between tespcd, testool, MWedit, Enchanted Editor, wrye mash and various other tools, its sometimes hard to choose which tool is right for which job.

me too. :foodndrink:

Can you have a "won't use it if it has a GUI option"? I prefer working from a Bash shell where I can, even under Windows. Far more efficient than clicking stuff all over or trying to works with Emacs.

I prefer a GUI. I find working with command prompt frustrating, as I find instructions for them hard to read and people used to using command prompts often forget to mention vital information like "it's case, dash and space sensitive" or "two dashes together in my readme may look like a single long dash" which leads to lots of annoyed time spent trying to figure out wtf it's not working or wtf the directions actually meant by enter --B for blah blah function and -a- for blech blech. I like to spend my problem solving time in game or in the CS, not in a program that's supposedly making something easier :shrug:

For the Linux community this has always been that way. The reason is consistency and simplicity (or maybe something else.) Simply, a abbreviated option, like -v would be verbose, but if you wanted to use the whole word, you'd say --verbose. I'm avoiding abbreviations for the moment.

Added the new option, as i understand the GNU/Linux community, and command-line users like myself. We can get more efficiency from a command-line, especially since we can save exact options rather than starting from scratch and looking all over the place.

Added a second question, since it comes to mind. So far I've done everything with STDERR output. Likely a mistake after it has grown so much. Mostly it's all STDERR so it always flushes output, to a commend of tee would still give you quick meaningful information in case it stalls.

Somehow I'm not surprised a lot of users want a GUI which I'll add at some point. However it won't be integrated as part of the program, it would be a separate utility/entity/script, Not out of the need to keep it separate, but to keep me from getting into complex, confusing, and system/OS dependent code. I can do the GUI in AHK and get easier and faster results.

Actually the main reason i haven't made a GUI is i concentrate on getting options and raw speed. I tend to be a 'no bells and whistles' guy. Besides, the true power of programs isn't in the GUI, it's in the pipeline

Ok. I spent some time fiddling with Smartmerger. For the most part, Smartmerger is just a few iterations away from being a must have tool. The tool has come a long way in a short period of time. Here is what I see so far.

1. Merging-
I first used it to merge patches into the plugins they were patching (worked great). Very pleased!
Then I tried to merge an old "mod set" I had made years ago. The program stalled on a dialogue problem same as the one listed in your readme. I removed the mod in question and tried again. Got a little farther but it still stalled. No_dialogue_merge option didn't work.
I like the output to the command window but would like to see it more readable. Also, is there any way to output it to a file instead. I like to keep records and the command windows buffer doesn't hold much so if it's even a biggish small mod I can't see all the output.

For a wishlist on this feature (excluding the dialogue issue). I'd love an option to "approve" each item as its getting merged. I know that would take forever to merge anything but sometimes a mod contains things that don't need merging (or you just don't want). Even better would be an option to selectively pick which pieces are merged together (excluding things like dialogues which that'd be inpractical). Admittedly, that might be a little too crazy to program but a guy can wish

2. Moving land-
I couldn't get this to work correctly. I will try somemore later. I tried moving a small island and while the land moved the objects didn't. In fact, they didn't show up in the game at all. They were still listed in the mod but didn't appear in the game. Maybe the object reference gets messed up (or maybe I screwed it up). I do tend to try unconventional things so I'll experiment with it some more and report back. I assume right now that it doesn't alter scripts, doors, and pathgrids right? Another thing that'll need to be included to replace TESfaith is an exlusion capability. Either command line option (i.e. --move_land --exclude 3,4/5,12 etc) or from a text file listing all cells to ignore.
I know this isn't a top priority (as it shouldn't be) but just pointing it out for things to think about. I remember you asking for help on the data...what exactly did you need to break down. I could try but I don't know what info you are looking for (not a programmer but I have spent an unhealthy chunk of time looking as the ESP data in a hex editor).

3. Hard limit-
I haven't had a chance to actually try this one. It's definately a good feature. Maybe expand it to all reasonable objects (misc items, armor, or anything with a price)

4. GUI-
I'm not a linux person but I definately spent quite some time working command line back in the DOS days. So I'm relatively comfortable using the command prompt. That being said, most people are not. Most will be using windows which makes using the command prompt even more tedious. On top of that, having always used programs with GUIs, they will shy away from command line tools. Look at TES3CMD for example, It's cleaning functions are much much better than TESTOOLS but everyone still predominately uses TESTOOL. I do agree with you though. Keep them seperate. I don't see why you need to merger the GUI and the program. A simple frontend would be enough for most people and the command line option is still there too.

5. Misc-
I really appreciate some of the misc features you have worked in. Ammo_damage, script fix, dup_id, header editing, etc. Thanks. These little things sometimes really make a program stand out.

6. Readme-
The readme still isn't very clear on what the functions do (their practical use) and need example for them. Some I'm not sure when I would use them or even if I should use them. An expanded readme with more clean explanations and examples would help alot. This is particularly important for the less computer savy and folks not as familiar with the inner workings of a Mod.

Hopefully most of that made sense. I tried to be as honest and complete as possible. I am very hopeful for this tool and would use it even if you stopped development today. Thanks for the hard work

Yes, the no_dialog_merge is rather broke. I'll put a higher priority on getting it working right.

I know dialog merging can still stall, although it shouldn't stall forever (but could seem that way due to the breakout value). The only reason i haven't tried converting it to my new idea/system, is because if you merge plugins that aren't related and aren't the finished product, it could have very weird results, or just not plug in right. I'll end up adding it still as a option, but that will likely be in 1.7 or 1.8.



Planned. Likely an option something like --choice and followed by a series of what kind of records you want to worry about. IE "SCPT,GLOB,ARMO" Ect. That way you can say which ones you want, leaving plenty of flexibility.



It should move the land, and all objects in the land. Doors from elsewhere that refer to the teleports on land within the plugin also are updated. My test shows you can move an entire island. Although it does still need work.

Basic usage is intended as --moveland x,y, where x is how many cells you want to move to the right, and y how many up. Negative reverses it. So if i take my island and say --move_land 1,-35 it will move from the upper-right corner to the lower right corner.

Scripts, interriors and pathgrids are not touched, I'm not sure how you would modify the scripts without needing recompile them. Maybe modify them anyway and make a manditory re-compile on your plugins and then re-merge the result. As for the pathgrids, I think i can fix in the next version. I had forgotten about them.

The help i needed, was mostly understanding the X,Y coords, however understanding cells were 8192 in length, i was able to update that.



Yes i asked about expending it, likely will. That will be oodles of fun.



Yes the younger generation aren't taught commandline or the workings at all, beyond Linux/Unix and Server admins it seems. I'll have a scripted GUI in the next version. Compiled EXE or just the script? (compiled adds 200k to the download)



Welcome. I added them because i wanted and needed them. Besides, it removes the need for making separate plugins to do the same thing, that are longer and more tedious, and can't compensate for every possible author out there who's mod doesn't try to make it with them.



Yes, more examples. I'll add an example or two for each command option.

This is the kind of feedback i needed Gives me a place to start.

Personally that doesn't disturb me at all.
It like if that is not added 20 Mo to the software.

Thought of another thing. If you could make a way to drop a plugins content to a file (in a semi-readable form). Tried it with query but that didn't work. That would be a boon to modders and moddites(?) alike.

Planned. I intended to do that a few versions ago, basic framework is done but had other priorities. Probably be in csv format, since that's easiest. so expect --csv output.txt to be used sometime in the future. Likely dumping the current state, and not each file individually. Could even have it dump what file it's getting it's state from, if that's wanted.

True, but keeping the download at a mere 60k is a interesting feat based on what it does. I've seen large more annoying programs not come anywhere close to this little utility. But that's the same logic why i don't compile and release it as a Cygwin build, since it's a 1.5Mb download for the dll. And making someone download a separate file just doesn't stand well in my book. Although i could link it externally i suppose...

The whole system is really simple once you get the hang of it, it's just a weird jump for people spoiled by the Windows GUI since they first used a computer. Knowing how to use a terminal is a good skill for anyone of any age (my first comp was Win98, but I still learned it just cause).


And scripting. I've been batch processing some data files lately, along the lines of 4000 of them, and having to click through a GUI every time is pretty much impossible.


Throwing a GUI in front of a commandline program can be pretty simple, especially if the output data is sent to stdout or stderr and well formed. The only downfall I can think of is process startup cost, but you could get around that pretty simply by turning the core of your tool into a dynamic library and providing two front-ends (one commandline, one GUI). Something to consider maybe, since it would give you some added flexibility, allow others to integrate your tool into their pipeline, and let you leave off the GUI till later with no consequences.

Edit: Also, doesn't the GPL, in one of its many little clauses designed to frustrate and undermine developers, have a requirement to print the notice to the console if your program is licensed under it? I know there's a requirement to make the notice available from within the program.

I think so, but adding a note to the header is easy enough. Other programs like VirtualDub, require you to see and acknowledge the license it's under, but won't bug you on every run. On command-line, it's pretty easy to ignore.

http://www.gnu.org/licenses/gpl.html


It also recommends adding the license header to each file of your sourcecode. I've done this before. The interesting thing about copyright, if you post sourcecode on the internet, no one can legally compile it and distribute it, nor can by incorporate it in any project. You need permission (which the license is for) before you can do that safely. It also protects the programmer and the users in not so obvious ways.

Some have called the GPL the 'Greedy Programmer's License', and a few called it a 'viral' license. (Anyone that modifies the code and releases it, it's required to be under GPL as well). Doing the GPL in this way, keeps companies like Microsoft from being able to change one or two tiny things, and then taking control and ownership of the program and becoming proprietary. The true spirit of GPL, is so everyone can download, modify, and even upgrade the code and re-distribute it, like a big friendly community and family, to see it improve and not let money, greed, or any other reason stop or prevent the use and growth of the software.

Enough on licenses though. I'm not an expert, but i'm pretty sure what's here is pretty accurate.

Asking to recompile is common practice (Mash export/import scripts, TESFaith) and not really a problem, after all it is just a matter of clicking recompile all in TESCS, and a modder is supposed to be able to do it.
I think TESfaith http://projectmanager.f2s.com/morrowind/downloads/TESfaith-0.96beta.zip/http://projectmanager.f2s.com/morrowind/TESfaith-Readme.html could help you a lot figuring what would be of use. Also, an interesting http://forumplanet.gamespy.com/morrowind_cs_general/b49689/7290130/r7290132/ by a TESFaith user here.
I'd love having something with http://timeslip.users.sourceforge.net/morrow.html handy cell view interface and TESfaith 0.96beta or better capabilities

I need a GUI. Command lines scare me. :cold:

ALSO: reduced visibility if you put the mod in the Utilities section. ES Search doesn't search Utilities, and additions/updates to anything in Utilities don't make it to the PES "New" and "Updated" pages. Consider adding it to TESNexus so that your mod will appear in search results.

I think SmartMerger is already a fantastic utility, and as you fix and add things it will probably become a must-have utility. Currently, I think two or three things stand in your path if you want widespread adoption:

1. GUI. I think SmartMerger is pretty darn easy to use on the command line, and with more examples in the readme it would be even easier. But the people fear command lines, and want GUIs. (You're planning this, so no big deal.)

2. A working feature to not merge dialog. The Morrowind mod community has had nearly a decade of "Don't use Merge Dialogs!" ingrained into its head. It will take some time for you to work out dialog merging quirks and for people to trust dialog merging, and so if you want people to use SmartMerger dialog merging really has to be optional. (I don't think this option has worked since it was first introduced. My opinion is that it should be a higher priority.)

3. A clear concise description of how to use SmartMerger to replace TESTool's Merged Objects and Wrye Mash's Mashed_Lists would be fabulous. Not everyone needs to merge all their mods together (although that is pretty dang awesome), but just about everyone needs to merge the common changes. If I understand correctly, this should be pretty easy with --reference, but guidance from you would be appreciated.

EDIT: I voted that the output shouldn't show the header/GPL, but what I actually meant was "I like all the output so I know what's going on, feel free to leave everything."

Is there some reason that the GUI talk feels like an Apple, Windows, Linux debate :facepalm:



Look, I cut my teeth on an Apple Macintosh (yeah, I am that old) not a Windows machine and I've also had a Linux build - right now I'm on Windows, mostly because I like it. I have no desire to ever go back to command line if I don't have to. It's great for more control, programmers and people that know what they're doing. Keep in mind there's a lot more people who don't know what they're doing than do and there's absolutely nothing wrong with offering them an alternative that they're comfortable with.

Also once the GUI is available SmartMerger will get more feedback from the masses that have held back because they're uncomfortable with command line or completely clueless on how to use it. Much better for finding any final hiccups. Unless the intention was for Smartmerger to be more of a developers tool than a tool for mod users a GUI simply makes sense going forward.

As much as I generally enjoy being mistaken for a spoiled tween, think of my support for a GUI more like sound marketing advice instead of fear or ignorance.

Except that, without some care, recompile all can be a game-breaker. I think drawing from the MWEdit code, particular the compiler module there (I think MWEdit is under the GPL or a similar license) and just recompiling the scripts then and there would be easier. Depending on how the MWEdit compiler works, it might not be horribly difficult, not sure.

I am the n. 1 fan of MWEdit strict syntax checking, it can detect many more syntax glitches than TESCS, I use TESCS compile all only after having passed MWEdit strict syntax test.
But MWEdit compiler does not digest well some things (set objectid.variable... ) you often find in some mods, and MWEdit may screw/discard other things when saving complex mods, so I never use it for compiling scripts/saving mods if they do not require extended syntax.
The problem with TESCS compile all (the possibility of dirty game settings/scripts generation) can be easily avoided or solved.
- if your mod depends on both Tribunal.esm and Bloodmoon.esm, no GMST are generated.
- if your mod depends on Morrowind only or on just one of the Tribunal/Bloodmoon, you can prevent GMST generation just loading http://planetelderscrolls.gamespy.com/View.php?view=Utilities.Detail&id=74
- if you can't/won't/forget to prevent GMST generation, you can easily* clean the mod using TESCS ignore, TESTool, tes3cmd clean, or any other proper tool.
[EDIT]typos
[EDIT2]* to be more precise, if you happen to generate the 5 dirty scripts, you probably need TESCS ignore or Enchanted Editor to clean them.

1. I personally can use a command line but GUIs never hurt.

2. Either have merged dialog working or have a working option to not merge dialog.

3. This is the reason I'm most interested in this program but --reference still seems to output files on par with merging whole mods.

Interesting. i could include a plugin that includes the default GMST' as well, and then you don't have to load the full esm's for cleaning. But it won't find redundant or unchanged objects/data...




But it is a utility, that does a few modding features. And generally it's a modder's resource. Being in the 'Morrowind Mods' section is since i don't see anywhere for utility discussions.


The dialog merging is by far the most annoying thing to work on, as I've said in previous posts and on the other fourm. However, there are a few simpler solutions. In one of my original releases, i did what i called 'forced linking' which made all the warnings and errors and issues with dialog & stalling go away; However the specific order of the dialog could be wrong, making quests and choice dialogs impossible to complete and had to use the console to quit out.

I can add an option back in for forced linking, however if i did it has to fit certain criteria. Mainly you would have to have to be merging everything (dependent mods/masters), or at least reference them (likely all dialogs would be written as changes due to re-ordering). Since it would force everything to be reordered, which I'm reluctant to do for everyone (merging only unrelated plugins won't connect properly.


I've added a new question and options, just for curiosity what you would use it for.

I'm not sure what "Merge plugins to Masters" means. Is that a TESTool-Merged-Objects-like function? Such an option would certainly be welcome in the poll.

It's just how, or where the destination of your plugins are. Example. (won't make the complete command)

Plugins - unrelated: These plugins have no relation to eachother, and should not interfere at all.
Fair Magic Regen.esp
Improved_Health_v1.esp

Plugins - Related: Plugins that may either go to a similar object, or be an offshoot of a plugin.
SOPBeta1.4.esp
SOP1.4Patch1.34.esp

Plugins to Masters: Think of it as patching, adding plugins/masters together to make a (semi?) complete product. My preferred method
Morrowind.esm
Tribunal.esm
Bloodmoon.esm
Morrowind Patch v1.6.4.esm

If you use any master(s), you are merging to a master. Exception is when all masters are referenced.