Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Shadowlord]

Dwarf Fortress File Depot Download links:
Uristmod for Windows (Includes source)
Uristmod for x86 Linux (Includes source)
SLTileset

Uristmod is a mod management program for Dwarf Fortress which provides additional capabilities for mod authors to allow them to write their mods to include changes files which are read and applied to the raws, insulating the mods against fixes and changes made to DF's raws as DF moves from version to version.

One idea behind Uristmod is that instead of having to check your modified raws against the DF raws every time DF updates, and try to find everything you may have changed, you instead can write out your changes and to what they apply, and Uristmod will apply them to DF's raws. They're likely to be applicable directly without being modified again. Another is that it can find things and change them en masse for you, such as setting impact fracture to make all stone unmineable, but not soil or sand, and you could even exclude specific individual stone types such as obsidian if you wanted to. (It can also install tilesets and graphics sets, if they're placed in a folder so it sees them as a mod, and can update saved games when you update raws)

Furthermore, it can update the raws inside your save game folders for you. It has a simple method for replacing characters in language files (for removing accents), can copy files without changing them if you desire (for new raw files, graphics files, fonts, the init file, etc), but its most sophisticated capabilities focus on finding existing blocks in raw files by matching [stuff] to regexes, removing [stuff] from them, adding [stuff] to them, or modifying [stuff] in them (you can also remove entire blocks).

Examples from .changes files:

Spoiler (click to show/hide)

Code: [Select]

=== Make all rock unmineable except obsidian - won't affect sand, soil, or gems ===
?[INORGANIC:.*?]
?[IS_STONE]
![STATE_NAME_ADJ:ALL_SOLID:obsidian]
[IMPACT_FRACTURE:5000000]

=== Make a bunch of changes to kobolds (from Kobold Camp) ===
?[CREATURE:KOBOLD]
= This will add CAN_SPEAK if it doesn't exist already
[CAN_SPEAK]
[INTELLIGENT]
= These - lines remove an existing line in the raws
-[BONECARN]
= Note that it probably isn't going to place the new body size line with the others, but will place it near the end of the creature:kobold block, along with other things that it is adding to it - like can_speak, intelligent, and the kobold_materials body detail plan.
-[BODY_SIZE:12:0:20000]
= This adds the line instead of replacing another BODY_SIZE line.
+[BODY_SIZE:4:0:20000]
[CHILD:4]
-[MULTIPLE_LITTER_RARE]
== Swap out the STANDARD_MATERIALS plan for our replacement one which has fur ==
-[BODY_DETAIL_PLAN:STANDARD_MATERIALS]
== We have to use a + here because there are other [BODY_DETAIL_PLAN:.*?] lines in the kobold definition ==
+[BODY_DETAIL_PLAN:KOBOLD_MATERIALS]

= Change all INORGANIC metal ore (EXCEPT iron!) to tile 154
?[INORGANIC:.*?]
?[METAL_ORE:.*?]
= This looks for iron, and makes this block not apply to it
![METAL_ORE:IRON:.*?]
[TILE:154]

= Change all magma-safe stone to tile 199. The melting point line is basically looking for any numbers between 12000 and 19999. If we wanted even higher temperatures (Raw adamantine is the only inorganic with a higher melting point) we could change the 1 to a range as well.
?[INORGANIC:.*?]
?[MELTING_POINT:1\[2-9\]\d\d\d]
[TILE:199]

?[INORGANIC:.*?]
?[IS_STONE]
== Look for ENVIRONMENT OR ENVIRONMENT_SPEC with CLUSTER_SMALL
?[ENVIRONMENT.*?:CLUSTER_SMALL:.*?]
[TILE:7]

= Feather trees (this changes or adds the tree_tag, sapling_tile, tree_color, and sapling_color tags, depending on whether they already exist or not)
?[PLANT:FEATHER]
[TREE_TILE:245]
[SAPLING_TILE:141]
[TREE_COLOR:2:6:1]
[SAPLING_COLOR:2:6:1]

= Quarry bushes. Should change the leaf art to 166, if it was still tile 6 before.
?[PLANT:BUSH_QUARRY]
[LEAVES:quarry bush leaf:quarry bush leaves:166:7:0:0:0:1:6:LOCAL_PLANT_MAT:LEAF]

= Cave wheat
?[PLANT:GRASS_WHEAT_CAVE]
[PICKED_TILE:159]
[PICKED_COLOR:7:0:1]


Your raws at the first time that Uristmod does anything to them are backed up to DF/originalRaws, and that folder is what Uristmod bases everything on when it installs mods. If you uninstall a mod, it'll reinstall all the others in case they overrode each other.

The manual explains the syntax of everything for modders, and how to make graphics sets into a mod (it's easy, you put the raw\graphics into a folder (ideally named SomethingG so it's clear it's a graphics set) and add an empty graphics_example.txt), how to install it, how to use it, and so on and so forth.

Uristmod is coded in Haskell, which made it easily portable to Linux. If I had a Mac with OS X, I'd make a Mac port too, but I don't. (I have a Mac with OS 6 or 7 or something with a broken keyboard sitting in a basement, but it's quite useless.)
It is open source, though, so if anyone with Mac OS X wants to use it, they can still compile it themselves if they want to.

Uristmod is actually also compatible with 40d, except you wouldn't want to use the "Update saved games' raws" feature. Of course, most mods for DF2010 won't be compatible with 40d and vice versa.

Features I am already considering adding include:

• The ability to have +[foobar] lines add the line after a specific other line instead of always at the end of a block

I'm open to other feature requests (or bug reports, if I missed any) as well.

Oh, and the menu that it shows when you run it? It's in text rather than a GUI, you just type in the number of your choice or the name of the mod to install (the name of its folder in the DF folder), as the case may be.

P.S. If it exits suddenly without pausing, then there was probably an unexpected error - It shouldn't do that unless there is an unexpected error, and by unexpected I do mean unexpected. It should not do that unless you find a crash bug in it. (I've been using and testing it with DF2010 since it came out, and tested it with 40d as well (but not as extensively), so hopefully I caught them all)

Edit: The init.txt included with the version of SLTileset which was in Uristmod 1.0 has TEXTURE_PARAM set to LINEAR (which is the default in DF's default init.txt), and it looks much better with NEAREST instead, which is what it is set to in the separate package linked to now.

Also, Uristmod 1.0 had several bugs which are fixed in 1.1 (none of which occured in really simple mods like SLTileset, but showed up in more complex ones - I did some more complicated things and  found and fixed them for 1.1).

[Phoebus]

Does it automatically updates savegames?

[Shadowlord]

It has a command to update all your saved games, but it won't do it without you telling it to, because you might have saved games with incompatible mods installed (or have incompatible mods installed in DF that aren't installed in one of your saved games). So yes, except it isn't *automatic*, because that would actually be dangerous.

[Rochndil]

Very interesting!

When I get that far, I may try to have Uristmod install my MMO mod. On a side note, what IS the worldgen crash fix? I've not seen anyone post about solving that particular bug yet.

Rochndil, playing a long game and collecting bug reports...

[Shadowlord]

The fix is to move all the DEFAULT lines in each block in the graphics set's txt files so that they're no longer the first line in each block. For one-line blocks, you have to make dummy lines (such as CHILD or the like) to go before the DEFAULT lines.

Of course, that triggers another bug: If you do a worldgen and then go to embark, various characters are missing or replaced by other characters, so stuff looks completely *wrong*. Restarting fixes it, though. (This doesn't happen if you don't have the fix, or maybe if graphics is off. I'm not sure which, since I haven't tried turning graphics on after worldgen but before embark, without the fix.)

I'm not sure which is better/worse, really, the temporary character corruption, or having to switch graphics to OFF during worldgen and then back ON again afterward. Either way you have to restart DF in between (though not edit a text file for the character corruption). I only applied the fix after worldgen, so I didn't see the problem right away myself, either.

In news: I've got the linux version working and will be uploading it later. I think I'll upload the windows version, the linux version, and my tileset to separate files on the DFFD, and that way people can download whichever they need and not have to redownload the tileset repeatedly if the program is updated (or download it at all if they don't want it, or don't need an example mod). The source code, README about it, GPL LICENSE file, and assorted tiny files compress to about 28 KB, so I'll probably throw the source in with both the linux and windows versions.

To make it linux-compatible I had to write one new function to handle the situation where it was seeing extra \ns or \rs at the beginning or ends of lines due to the operating system using a different line ending than windows. (I made it look for both \r and \n even though the only modern-ish OS to use \r as a line ending (thus leaving \n behind) is mac os 9, and it probably isn't possible to port it to that)

At the moment I'm not sure what would happen if you wrote the mod files on linux and then tried to load them on windows. I'll test that in a bit before releasing this and see if the windows version breaks when the line endings are just \n. Come to think of it, does DF work when the line endings in its files are \n instead of \r\n? (Though I expect the actual-linux version would work fine) I only tried running it in wine with raws that I hadn't edited in linux at all, so I wouldn't have noticed (In virtualbox, on a CPU that doesn't have virtualization, with probably less memory allocated to virtualbox than it needed, so DF was incredibly slow, took 10 minutes to load a saved game, and froze up when I alt-tabbed, but I confirmed what I needed to confirm ).

[Shadowlord]

Uploaded 1.1 for windows and linux with the source code included in both, and separated SLTileset into a separate package. (Links are at the beginning of the first post)

Did extensive testing with more complicated modding (actually, I went and compared Kobold Camp 2010 to the default raws, and... ported it to Uristmod, which I will probably do something with tomor...er...today, after I sleep.) and fixed all the bugs in Uristmod that I found as a result, and added a couple useful new features (which I tested and bugfixed while I was bugfixing the other bugs).

Changes:

• Released the linux port, included the source code in both the windows and linux port
  
• Can handle non-\r\n line endings.
  
• Added ! line prefix, which acts like a NOT ?.
  
• Improved - line prefix to let you use regexes instead of the simple-line mode.
  
• Fixed a bug which could cause the original raws to not get backed up until after a mod was installed D: (this happened as a result of my changing Uristmod to not always reinstall every mod prior to installing new mods, shortly before releasing the first version - I tested to make sure the change worked, but I already had the original raws backed up, so I missed the bug)
  
• Fixed a bug which caused - lines to not work properly (they were removing the line, but then the add-remaining-lines routine wasn't noticing that they were removal lines, and was adding them back to the block (without the -), hee hee)
  
• Fixed a bug which caused lines which started with a [ to be added without their initial [ if they weren't replacing something already in the block they were going into.
  
• Made + lines not get added in reverse order.
  
• Fixed a bug which was causing ?[CREATURE:] mod blocks to not work properly at all (and possibly others, who knows). Uristmod was seeing [CREATURE_TILE:'g'] in the raws and going "Oh a new CREATURE block!" because I had the regex for new blocks looking for "\\[ *" ++ (escapeRegex (L.unpack dataType)). So, it saw "[CREATURE_TILE" and searched it for "[CREATURE" and went "LOOKS GOOD TO ME!" I fixed it by adding ++ " *[:\\]]" onto the end of that, requiring the "[CREATURE" or what-have-you to be followed by a : or ], but allowing spaces between the tag name and the colon or right square bracket.
  

Note: The ! feature does not seem to be working properly yet, unfortunately.

[Shadowlord]

1.2 has been uploaded, which fixes ! so it works now. This makes things like this possible:

Code: [Select]

=== Make all rock unmineable, but not soil, and not obsidian ===
?[INORGANIC:.*?]
?[IS_STONE]
![STATE_NAME_ADJ:ALL_SOLID:obsidian]
[IMPACT_FRACTURE:5000000]


[Shadowlord]

1.3 is out now, which lets you put \ before [ and ] to do stuff like \[0-9\] in a ? line. It's the same as using [ and ] in a normal regex. Also, you can now use \d and other \stuff in ? ! ~ lines.

[Trouserman]

I think this is a great idea and a good design.

I'm a bit puzzled why you require the brackets to be escaped like that.  I assume it's to prevent mistaking the closing bracket for the closing bracket of the ? expression, or some such.  But surely the program can do a little more work to save humans the annoyance of escape characters which are not only unnecessary but behave oppositely to their conventional meaning in a regular expression.

[Shadowlord]

That's a good idea, I could do away with the \ requirement before []s by looking for nested []s. That hadn't actually occurred to me.

Here's what I've implemented for the next version now.
[ and ] inside a line will result in regex brackets except for the starting and closing []s. (If you ended up doing something like [foo][bar] it would split it into multiple lines anyways, but it's still counting how deep it recurses and counting its way back up as it goes through [s and ]s anyways)
\[ and \] are still converted to regex [ and ] for compatibility with 1.3.
To get a literal [ or ] other than the starting and ending ones you would have to write \\[ or \\] (This isn't a hardcoded character sequence, you're just escaping a backslash so you get a literal backslash in the regex).

I'd like to know if you think I should remove the compatibility with 1.3 in favor of making \[ and \] into literal brackets.

[Wyrm]

Yes, \[ and \] should be regex escaped [ and ]. Now is the time to break compatibility, before many mods get written using this utility.

[Trouserman]

I'd like to know if you think I should remove the compatibility with 1.3 in favor of making \[ and \] into literal brackets.

Yes, this seems like a good idea.

To get a literal [ or ] other than the starting and ending ones you would have to write \\[ or \\] (This isn't a hardcoded character sequence, you're just escaping a backslash so you get a literal backslash in the regex).

Is there a need for backslash escapes at all in the translation from an Uristmod tag to a regex?  The only thing I think you could need it for is brackets, since those are your tag delimiters.  But regex brackets nest, so you don't need to escape those.  \[ and \] for literal brackets could be passed as is to the regex, without requiring the additional backslash, but it's not clear to me that this is even useful, since brackets don't appear inside DF raw tags.

[Shadowlord]

DF allows (and correctly parses) [TILE:'['], for instance. I don't think there's actually anything in the raws that uses [ or ] by default, though, but if you WERE looking for things whose tile/symbol/etc was '[' or ']' you would need to escape it. Just putting an unescaped [ or ] inside []s (assuming that works in this regex engine) would probably confuse Uristmod since you'd have a mismatched number of [s and ]s.

[ManaUser]

First let me say this looks really powerful, and I hope it does become commonplace to distribute mods this way.

With that in mind, I have a few criticisms/suggestions:

1. I'm afraid some people (yes, even DF players) will be turned off by the interface. A GUI would be best, but even short of that it could be polished up some. In particular it would be nice if you could pick the mod name from a list instead of typing it. Also it should be fixed so lines don't wrap like t-
his anymore.

2. Reading the manual, it was unclear whether ~[block] and ![block] could be combined. Please clarify, or if you're still at the stage where the syntax can change, I suggest replacing

Code: [Select]

~[block]with

Code: [Select]

?[block]
~It seems clearer and more consistent to me.

3. It was also unclear how you could add new blocks to a file. (I know in general it's better not to, but sometimes it might make sense.) Perhaps a specific command for appending new blocks to a file would be good.

4. Finally, what would really make this take off IMHO is if it could generate a change file from a traditional mod. I realize that's kind of a tall order though.

Edit:
5. Another thought, as I sit down to actually try and make a mod using this... Since +[stuff] (add) and [stuff] (change) are different commands, does that mean I have to know whether a given tag already exists? What happens if I try to add a tag that is already present or change one that isn't? This is fairly important for mod compatibility.

[Intelligent Shade of Blue]

Just want to say that I am using this for my Gustatory Science mod and so far, it rocks! Thanks a ton for developing this