View Full Version : Modding Methods

07-14-2008, 08:02 AM
There are about 5 ways or methods of modding DoP. What follows is a brief description of how, and when to use them or not use them.
This is mostly my opinion. If I've got something factually wrong please step in and correct me.

Do not post in this thread with 'my mod isn't working' questions. Make a new thread, I don't want this one getting cluttered up with troubleshooting questions. By all means reference which modding method you used in your new thread.

This also isn't intended to be a how-to, I'm not going to put step by step directions here. This is a comparison of methods, not an instructional video.

Without further ado:
General mod formats: There are two. There's the 'loose files' method and the override method. I'll do loose files first.

Loose file methods:
General description: You take a file in the assets and use the whole file as a mod.
Cons: You cannont combine loose file mods with each other. They conflict with official patches, requiring you to merge your modded files with the patch files. They make it difficult to see what is actually being modded just by looking at the file.
Pros: It's easy to get started, and requires a minimal understanding of software technology.

The absolute worst thing you can do is edit files in the original asset zips. In addition to the common drawbacks you'll have to devote a significant chunk of drive space to keeping a current backup of the the original asset files for when you mess them up. Because you will mess them up. And you'll most likely need to reference the originals to fix it.

Option number 2 in here is to unzip the files you're going to mod and place it in a directory structure identical to what existed in the asset file you got it from. The only benefit this method has over method 1 is that you won't have to keep backups of your assets (because you're not changing them). This is fine for very quick and dirty testing of something you plan to mod, but not convenient for mods you actually intend to play the game with.

Lastly, you can take a mod using method 2 and zip up the whole directory structure so that it's all contained in a single zip file. The only benefit you get from this is... it's all in one zip file. If you want to take the mod out you only have to juggle a single simple file. I don't see any value in this, as it's an extra step for almost zero benefit.

Override methods:
General description: You use the override functionality addes in version 1.010 to alter just the parts of the game that you want to without disturbing the rest
Cons: It takes a little work to grok the concept. How much work depends on your aptitude towards these sorts of things.
Pros: They're simple to make, require almost 0 upkeep, can be made completely modular and interchangable, and don't indirectly interfere with patches or each other (obviously if two mods are touching the same part of the game they'll still conflict with each other).

4. You create an override file in a directory structure identical to the structure of the asset file you're modding. It's simple and straightforward, and is ideal for testing.

5. Take the mod from method 4 and zip it up into a single file, maintaining the directory structure. This is the most ideal way (that I know of) to package a mod. It's great for distribution, as well as easily adding and removing the mod from your personal game. Since it's an overrride mod it's less likely to interfere with anyone else's mods if you publish it, and less likely to interfere with official patches in any scenario.

My personal modding process works like this. I start with a method 2 mod to identify all the properties that I plan to fiddle with. Then I pare down the file and convert it to a method 4 mod. Once I'm happy with the outcome I package it up into a method 5 mod. Then I publish it, if I feel like it.