Bay 12 Games Forum

Good morning!

This keeps getting better. I'll be taking it for a spin today if I can get the laptop running. Thanks for all your hard work!

Rochndil, who definitely looks forward to tinkering...

This question is actually both simple and complicated, because the answer is, "it depends."

In general, you will follow the mod maker's instructions (if they are kind enough to include them), run DF, and generate a new world (almost always necessary). This usually works just fine, until you decide you want to try to run two mods at the same time.

To properly understand how this can be a problem, you need to have a basic understanding about how DF works, and how mods affect it.

Much (not all, but a good deal) of the raw data DF uses to generate and play the game world is stored in various plain text files in the game directory. By changing existing files or adding new ones, you can alter the way the game works. Many mods work in exactly this way. They alter the existing game files, OR add new files, or sometimes both.

As long as you're only running one mod, this usually is not a problem. But if you try to run two mods, and they both alter the same file, the simple process breaks down. Since the basic replace-the-file operation is an all-or-nothing process, you can have the file from ONE mod, or the OTHER, but not both. In addition, if you replace a file changed by one mod with a file changed by another, and the first mod uses/alters other files that require the changes in the replaced file, the whole first mod may become completely broken (and even break the whole game).

What a mess! So, what can you do about it?

Learn at least a little about how these things work. Ask questions on the forum. Support mod-makers who make sincere efforts to make their mods comprehensible and easy to use. Contribute your own ideas, and help make the experience better for everyone.

Take a quick look at your installed DF directory. There are a bunch of files and directories in there, but most mods will actually only affect a few.

Simple stuff first. Tilesets (character sets, not critter/race graphics) go in the /data/art folder. If you peek in there, you'll see a bunch already there. To install a new tileset, just drop the BMP/PNG file into the art folder. THEN, you'll need to tell the game to actually use that new file. This is done in the /data/init/init.txt file. You've probably been in this file before to set up your game. To change the tileset used, just alter the FONT: references to the new tileset name, save the file, and you're off. A simple change like this doesn't even require a world regen, yay! Except, if you're using a tile set that requires altered "RAWs," see below.

Graphics are usually very easy to install. All graphics get dropped into /raw/graphics, and are usually preformatted by the maker to store their files correctly (as long as you preserve the directory structure when you install them). Again, a change like this won't require a regen, but it will require you to re-start the game to see the new images. If you haven't already, to USE graphics you'll need to set [GRAPHICS: to YES] in the /data/init/init.txt file in order to get them working.

OK, now for the messy stuff. Almost every other thing you can change about DF, from changing races, to adding creatures, minerals, or items, is controlled by the files in /raw/objects. In your base installation there are about 65 files there. Mods may, as mentioned above, add to or modify these files to make the modder's intended changes happen in the game world. Since almost all changes are to the files in this one directory, the possibilities for change collisions are the greatest here as well.

In the current version of the game, the process of making changes has also become more complicated, and while it does provide significant benefits, it also greatly increases the possibility of a file-replacement catastrophe for the new mod user. The biggest issue is with the entity definitions, located in entity_default.txt. Since a significant number of all other changes must also be referenced in this file for them to actually be used by the game, virtually every mod out there makes essential changes to this one file!

At this point in time, unless the mod creators actually indicate the specific changes they made, merging two mods together can be difficult or impossible without messing something up. Unless, of course, you can yourself figure out exactly what they changed, and merge those changes together into one new file. This can be easy if the modders kept, and provided, good notes, or a royal pain if they did not. And, if the two mods both make changes to one individual item, they may be permanently incompatible, at least as far as that item is concerned.

As mentioned above, some character set/tileset changes require RAWs changes as well, since part of the information in the RAW files is what tile is used to represent in-game stuff, like minerals, barrels, and workshops. In order for some tilesets to work properly, the relevant raw files must be updated with the proper tile information, and, if so, the appropriate files will usually be included with the download package. This is one major reason why some graphical overhaul files actually include the entire game, since their changes can be extensive enough that it's just easier to pack the whole thing up as a unit than to install each bit individually.

That's the bad news. Inter-mod compatibility is, at this time, very limited or only reached through significant individual user efforts. Unlike some other games (the Elder Scrolls games, for example), there is not a really good community standard for mods (although this is improving), and there has not emerged one universally-accepted program to allow automated mod merging. The good news is that we have numerous skilled and dedicated programmers in the community right now. New programs are being written all the time, and several amazing and useful utilities already exist. It is only a matter of time before someone writes that "must-use" app for mod merging, and then the game experience of all mod-users will become radically simpler.

In the meantime, you may be forced to choose carefully what mods you want to use, until you become knowledgeable enough to mash them together on your own. And, by then, you may be well on your way to making some mods of your own!

Rochndil, who has high hopes for Valdermar's DFMM...

Good morning!

Question: Are you planning on making the tiles for the minerals iconic, like Phoebus?

In a word, no. Each type of mineral resource (NOT each specific one!) will have a unique un-mined display tile. All ores, for example, will use the same tile (with some SPECIAL exceptions), but with a different color set. All flux stones will also share one unique tile, but with a different color selection for each. There will also be different tiles used for certain types of MINED resources. All this is for consistency and usability.

For example, when you look at the map, you can quickly tell if your stone is sedimentary, since all sedimentary stones will use the same tile. Fuel resources will be easy to identify, as will flux, ore, soil, sand, etc.

I'll throw up an image of the tileset once I'm done with it. As of last night, I'm working on row 16 (of 16), and then I need to go back and move a few things around to account for changes necessitated by updates in the latest builds of '10. Note that the tileset PRESUMES the use of a graphical replacer for the dwarves, etc, as well as accent removal in the language files, AND custom raw assignments (or you'll have walls full of lizards and equally odd stuff).

Rochndil, who will have everything together eventually...

Precisely, you can now define a separate character for the wall-end column. So the letter "O" can actually look like an O now.

Rochndil, who is a little fuzzy on that alpha thing, and what the deal is with TrueType...

Good afternoon.

As I'm sure is common knowledge, the latest build of DF is rather...lacking...in the metals department. I've generated a dozen or more maps, and it's rare to find an embark site that has ANY metal at all, or if so, may only have ONE type. However, I've not yet played with modding in some additional metals. I'm suspecting/hoping that the code limiting vanilla ores won't be able to affect stuff I mod in, but I thought I'd ask if anybody else has checked on this.

"All stone and no ore makes Urist a dull boy."

Rochndil, hoping he remembered the line properly...

Good afternoon.

As some of the more enduring board members may recall, I worked extensively on a mod I called the MMO (Metals and Minerals Overhaul). This project built upon work done by other modders, most notably Sean Mirrsen and Deon, and all imported (stolen) work is credited in detail. It got as far as a .9 beta release (old thread: http://www.bay12forums.com/smf/index.php?topic=33340.0)before the DF10 version overturned the raws mushroom-cart, and I had to start again.

I'm already working on an update/replacement compatible with the new system, though of course work is slow due to constraints on my free time. I won't have to completely throw out everything I did before, but there will be pretty extensive changes necessary to adapt the original work to the new system.

I'm not going to detail all the changes again, since it'll be substantially the same this go-around. There are a few elements I'm not going to bother with (like sand), since some of Toady's improvements rendered a few of my changes irrelevant, and there's no reason to complicate things with unnecessary tinkering.

Basically, the MMO does the following:

 - Clean up the metals processing reactions, bringing them a bit closer to real-world functionality (with an exception or two)
 - Add a double-handful (not a wagon-load) of new metals, ores, and gems to the world
 - Add a waste-production system to the ore refining process
 - Alter the display of soil/rock layers, ores, and harvested minerals to a more consistent and useful system
 - Use a custom tileset to perform the above, and extend some of the organizational improvements to other display elements
 - Document ALL changes to original system in detail, and include in download package

Right now I'm tinkering with the tileset. I did a LOT of cleanup on the tiles I used, created a few, and adjusted quite a few more. With some of the changes in recent builds (still waiting for the .20 bugfix!) I think I can squeeze in a few more useful tiles. Most of what I had before is salvageable, I think, so that work's not wasted.

Then, I need to do a couple of things, some of which will require some research;

 - Try to figure out some of the materials engineering behind the new metals defs, codify that into a calculating spreadsheet, and then use that to generate new numbers to approximate the values used in the old MMO
 - Update all the necessary changes to the new system, making sure to take advantage of the latest features and capabilities
 - Think about a custom workshop or two for some of the reactions
 - Investigate compiling the raws changes into a auto-update program (uristmod?)
 - Get the whole mess done and tested, and hopefully finish it this time around

There are a number of new tools available that should make this a lot easier for me than it was before, so hopefully I won't run out of time before I run out of steam.

Rochndil, who always seems to be doing DF-modding at tax-time...

Good evening.

I finally got all my DF files put away, and gave DMM a spin. So far, no real problems, but one comment. It doesn't seem to be able to handle stuff in the /graphics folder (or subfolders). Since a lot of the larger mods include graphics, this is definitely something to give some thought to for the future. As anything else comes up, I'll be sure to let you know.

Rochndil, who has taxes to work on...bleh.