Modification Installation, Configuration and Development Augmentation Application("micadaa" - I like that better)Currently available mods:- Martial Arts+: included
- Minerals+: included
- TYE:Things You Eat (by Deon): forum thread
- Dwarmin's Hat Mod (remake by Deon): download
- Luggage's Instruments (remake by Deon): download
- Uncutter and Deblocker (remake by Deon): download
- Compound mod (by Deon): download
- Mega Toy Mod (remake by Deon): download
- Botany/Angler/Zoo mods (remake by Deon): download
- Dr.More-Oh mod (by me, experimental): included
- Clockwork Race mod (remade by Deon): download
- Umiman's 10sec mods (prefstring and engraving) (remake by Fleari): download
Modbase Cumulative Modpack NOTICE: Modbase no longer comes bundled with the mods!MCM allows you to get all existing mods in one easy to setup package.
It contains all currently available mods for Modbase.
The last version is 1.02 as of 31.07.2008
DFFD download page"Mod Base"Functional release 0.95yy as of 24.08.2008
DFFD download page.
NOTICE: You have to download the Cumulative Modpack, because the main archive no longer contains any mods!Also, the source is a separate archive. Link at the bottom of the post.
I would like to encourage readers and users to express any ideas you might have on how to improve the program's operations, or what functions to add.Author: Sean Mirrsen
====================
Description: ModBase is, ultimately, a program to aid DF mod makers and DF mod users alike.
Its functionality is frustratingly simple in principle. It takes the original set of DF raws, and superimposes any mods you feed it onto them. You can download a mod package, unzip it, then run the program and effortlessly install and configure the mod to work with any others you might have.
====================
Installation: Extract the contents of the archive so that ModBase.exe ends up in your main DF directory. If you had any previous version of ModBase, it would be prudent to delete the "original", "martmod" and "minmod" folders from the "raw" folder beforehand.
====================
Use - User side On starting ModBase, you will see a panel with two selectable tabs labelled "Mods" and "Settings".
Before you begin, verify that you have started the program from the directory of the DF copy that you wish to set up. Use the Change Directory button if the path displayed at the bottom of the Mods tab does not match the one you want.
From here, there are several things you can do.
If you want to install or configure mods, click the "Load Mods" button on the Mods tab. After a brief loading sequence, the mods you have present will be displayed in the Mods list. If any of the mods were previously used and configured, their order and active state will match those that were saved last.
When you select a mod in the mod list, its description, if any was provided, will be displayed in the greyed-out panel under the lists.
You can change the order of the mods in the list (this influences mods that change the same things), and you can disable them entirely, or disable their individual parts from the Components list.
After you have done this, you can press "!!!ACTIVATE!!!" to compile all the mods into a single set that will be readable by DF. The program will warn you if any mods cannot find any other mods they require, or if any such mods are present, but disabled.
If you want to configure DF settings, or change tilesets, click the Settings tab. You will see two lists, a set of buttons, and a panel on the right.
Click the "Load Init Settings" button. The upper list will display the current settings of DF, as lines from the current "init.txt" file.
Double-clicking any item on the upper list will bring up a dialog box that allows to edit the selected parameter, with any optional values selectable from a drop-down list, and any numeric values manually entered into a separate field. The bottom line of the dialog will provide guidelines for editing non-evident tags.
The dialog box will prevent manual editing of settings pertaining to tilesets, as those are handled by a separate part of the program. On the right side of the window, you can see a drop-down list, a button, two radio buttons, and a panel. When the init settings are loaded, clicking either radio button will display the current tileset set for windowed or fullscreen mode. You can select another present tileset from the drop-down and click the "apply tileset" button to append relevant lines to the list of pending init settings changes.
Once you are happy with your changes, you can click the small "S" button to the right of the lower list, which will save the init settings changes to a separate file. Clicking the "L" button will load a saved set, if one exists, and clicking "X" will clear the current list. After you save your changes, click "Apply Init Settings" to save the changes to the main init file.
NOTE: It is advised to save a backup copy of init.txt if you plan to ever edit it manually later, because the program will not save any comments that were present in the original file.
If you select a module in the Component List, the Edit Mod button will light up. It currently has no function other than showcasing the mod editor interface and letting you see everything that comprises the selected module.
Important note: The program will now save your init configuration to the DF main folder, as "init.cfg", and you can now place tilesets in the "raw\tilesets" folder to easier carry them over to a new DF version.Once you switch to the new DF version, just copy the init.cfg and your tilesets dir, then run Modbase, click Load Init, click the little "L" button, and then Save Init.
Yet another note: Modbase will now contain most of its data in the "modbase" directory, instead of "raw". When you switch to a new DF version, copy that directory, Modbase.exe, modbase.cfg, and init.cfg to the new version's directory, then go to the modbase directory and delete the "original" directory there. When you run modbase, you will be prompted to copy the contents of the new version's raws to the original mod directory.And yet another note: You can now place .PNG files straight off the wiki into the Tilesets folder, and modbase will convert them to DF-usable BMPs.====================
Use - Modder side The files provided with the program should be clear enough.
To add a mod to ModBase, you need to add a folder, and a text file to the DF\raw folder. The folder should have a reasonably unique name that represents your mod. In that folder should be the files that make up your mod. The descriptor text file you place in the DF\raw folder should have its name beginning with "dfmod_". As with normal DF raws, the first line of the file should be its name without extension, and following that, an [OBJECT:MOD] entry.
Each mod has a set of individual tags that describe it, and a set of tag arrays that point to the files used by the mod. Here they all are:
[MOD:<id>] - the standard ID of the mod. The ID must be unique.
[NAME:<string variable>] - the name of the mod as it will be displayed in the selector list in ModBase.
[DIRECTORY:<string variable>] - the name of the directory you placed in the DF\raw folder, that contains the mod's files.
[REQUIRES:<string variable>] - used to specify mods that this mod will not function without. The variable is the exact NAME: string of the required mod. Any number of these tags can be included.
[DESCRIPTION:<string variable>] - is used to display a description of the mod's functions. The string will include any linefeeds, so format the text as you wish here. Note, however, that you must use semicolons instead of colons - otherwise the parser will freak out. The semicolons will be automatically replaced with colons.
[VERSION:<string variable>] - version of the mod. No particular meaning at the moment, but may later be used to determine compatibility.
[MSECT:<string variable>:<optional flag>] - the mod component separator tag. The variable is the name of the component displayed in the component list.
If you include no optional flag, do not include the separating colon also.
The optional variables are:
MAIN - if a module marked with this is turned off, the mod itself is turned off. Module has "(required)" added to it in the component display.
OPT - if you enable a module marked with this, any other modules with this mark will be turned off. In the component list it will be preceded by a "(o)".
OFF - the module with this parameter will be inactive by default.[FILE:<string variable>] - the name of the file. Each [MSECT] tag can be followed by any number of [FILE] tags, but no [FILE] will take effect before any [MSECT] tags, and a [MSECT] tags with no following [FILE]s might crash the prog.
Additional tags have been introduced to MSECT entries:
[SPEECH:<string variable>] - the name of the file containing strings to be added to the DF speech files. The file can have any name, and the first line of it must be the name of the file in DF's data\speech folder that the other lines are added to.
[TILESET:<string variable>] - the name of the file contained in the mod's folder, that will be copied and set as the default windowed tileset. The file may be missing from the folder, in which case it must already be installed by other means.
The file name must be supplied with an extension!!![TILEMOD:<string variable>] - the name of the file that contains a modification to an existing tileset.
The file name must be supplied with an extension!!! The tileset must be already installed - the modder may use the previous function to accomplish that. The tilemod itself must contain a field of true blue, 0.0.255 color, in which individual tiles must be wholely painted in accordance with DF standards. The name of the tilemod file must be the same as the file being edited, but the original tileset is not overwritten - instead, a modded version is saved as a new file.
[INIT:<string variable>] - the name of the .txt file that contains any changes you want to do to the game's init settings, like color schemes. You can use any file name, thus, for example, providing several optional schemes. The raws syntax for ModBase-compliant mods is not different from original DF. However, there are certain features many major modders will find useful. The original DF rules for file names and contents still apply:
All files must begin with their name without extension, followed by an [OBJECT:<type>] reference tag, that describes the type of entries present in the file. Entries of nonmatching type might not crash the program, but they sure will mess up DF.
Including an entry with a type and name matching an already existing one (either from original DF or introduced by a mod) will add its content to that entry. Tags that are supposed to be singular will be overwritten, like NAME tags, while multiple tags like ATTACK will be added.
Including an entry with a unique type and name will create a new file if it doesn't exist, and write that entry to it. The name of that file matches the name of the source file the entry is in.
A [!DEL!] tag directly following the entry declaration marks the entry for deletion. Adding a new entry with the same type and name afterwards is one way of completely overwriting an existing entry.
A normal tag with an extra "!" parameter (like [WEAPON:ITEM_WEAPON_SWORD_SHORT:!]) will mark the tag for removal. The system is flexible enough to support multiple removals of similar tags that match on all arguments preceding the "!". So, an [ATTACK:!] tag will remove all attacks from a creature, while [ATTACK:MAIN:!] will only remove the main attacks.
Tag flags, like those used by ATTACK and BP tags, cannot be modified separately, as they are saved and deleted with the tag they belong to. To modify a tag like that, you have to delete it (you only need to specify the tag itself, without flags) and put it back the way you want to.
Be advised that language modding is a complicated task in itself. I don't think anything severely awful may come of it, but don't try deleting tags from words in the language_words file. Use full entry deletion instead.
New feature! - entry referencing. By adding a [!REF:<entryname>] tag as the firstmost tag of an entry (immediatly following the [type:ID] tag), you will force the current entry's contents to be copied from another tag, before any following tags are added. This is useful for setting up multiple similar creatures with minimum effort, or make creatures based on others.
New feature! - tag referencing. Using a special syntax, you can specify parameters relative to other entries of the same type.
Example: [ATTACK@:MAIN:BYTYPE:$HUMAN:$HUMAN:$HUMAN:%HUMAN*2:%HUMAN*2:$HUMAN] will copy the contents of the last attack tag in the HUMAN creature entry, and multiply the damage values by two. The syntax is: first tag argument must have a "@" at the end to indicate the tag uses referencing. Any further argument in the tag can have "$" or "%" at the start, indicating copying a string (or a number without changing), or a number, with optional "+","-","*" and "/" modifiers to alter the value. Optionally, adding a number after the "@" in the tag name, like this: "[ATTACK@2:" will load the tag arguments from a specific instance of the tag in the target creature. If the number is omitted, or exceeds the number of such tags in the target creature, the last tag in the target creature will be used as the source.
NOTE: Numeric parameter designation changed from "#" to "%"
New feature! - optional entry appending. By adding a [!REPLACE] as the first tag of an entry, you will ensure that ModBase will not try to create a new entry with this name, so the contents will not be applied anywhere unless it already exists.
This is useful for making alterations to modular mods, or general alterations for many mods.
New feature! - Overwrite tag. Adding [!OVER] as the first tag in an entry clears all tags from the original entry (if it existed anymays), so that all following tags will be written anew.
Both tags can be used at once, like this: [!REPLACE:!OVER], but not as separate tags.
Also, reference or delete tags cannot be used with these. Not that there's a reason to, anyway.
New feature! - conditional entry overwriting/adding. The syntax is fairly incomprehensible, but to append a change to all entries of a certain type, you make an entry called [CREATURE:#] or some other type like ENTITY, etc. To specify which entries to use, [COND:] tags are used. Use [COND:<tagname>] to check for tag presence, [COND:<tagname>!] to check for absence. Use [COND:<tagname>@<argnumber>#<argvalue>] to check for a specific argument's value in a specific tag, or add an exclamation to the end to check for anything but that value in that tag.
Some other functions don't work with this, namely entry and possibly tag referencing. Value modification via arithmetics works.
=======================================
CAUTION
=======================================
As a precautionary measure, I will clarify.
This is a functional test release. Which means that while the functions of the program are proven to be working, but the details of its operation may royally screw up the game. I want this program to get a very thorough crash-test.
Known bug: going overboard with modding will crash the app when compiling with an overflow error. Don't make my variables exceed integer limits. Specifically, be careful with conditional entries.I'm now looking for ideas to further improve the program.
Have fun!
Bugs fixed:
Fixed a stupid issue with init modding. It'll now actually revert to the saved copy before applying any mods. I think I should check if it does it with speech...
Modbase Source CodeIf you need it, it's here:
DFFD download page