Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - RantingRodent

Pages: 1 2 [3] 4 5 ... 30
31
DF Modding / Re: RantingRodent's Dwarf Fortress Raw Patcher
« on: November 04, 2010, 07:43:08 pm »
I forgot about that. I still need to figure out a good approach for tags which occur multiple times. At the very least, I can force it to search for the best match when it's replacing. That much is easy enough. An explicit ADD_TAG should cover other cases. I haven't got the time tonight, but I'll try to get a version out this weekend with ADD_TAG and REMOVE_TAG, as well as the object marker mappings for the raws where it doesn't match.

32
Five more. Almost finished.

Spoiler (click to show/hide)

33
DF Modding / Re: RantingRodent's Dwarf Fortress Raw Patcher
« on: November 03, 2010, 10:34:28 pm »
Great. Let me know how it turns out. I'm on a PC, so I haven't been able to actually test it on a Mac. I'd like to know for sure that it works properly.

34
DF Modding / Re: RantingRodent's Dwarf Fortress Raw Patcher
« on: November 03, 2010, 09:20:01 pm »
Yeah, that covers it.

35
DF Modding / Re: RantingRodent's Dwarf Fortress Raw Patcher
« on: November 03, 2010, 07:52:39 pm »
In programming, there is a cycle known as "edit, compile, test". Right now, without this tool, DF modding follows something similar: edit raws, start up DF, test changes. Because this tool has you edit deltas for raws, you've added an additional loop in that cycle: (edit compile test) compile test. Essentially, edit raw deltas, compile to raw, check raw, good?break:continue, start DF, test.

Ah, forgot to comment on this. This isn't a tool for initial development. It's a tool for applying your mod once it's developed. At this point, the "edit" step should be done with for good. When a new version of DF comes out, it's very unlikely that you should actually have cause to edit the raws again to bring your mod up to the new version. Instead your cycle starts with testing, and in most cases will end with testing. If you aren't adding a new feature to your mod, why should you even be cracking the raws open?

I had considered using a simple diff tool, but I've been developing software for a little under a decade now, and I've been burned many times by simple diff tools being too dumb for a particular situation. If I have to go over the diff results with a fine-toothed comb, it defeats the purpose; to avoid expanding on my 60-80 hour work weeks. I'd rather build a domain-specific tool which I can actually rely on to do the job without me reviewing the output in detail. I don't have confidence that a simple diff tool could handle taking a mod and applying it to subsequent DF versions without generating a fresh diff for each subsequent version.

36
DF Modding / Re: RantingRodent's Dwarf Fortress Raw Patcher
« on: November 03, 2010, 06:13:09 pm »
Well yes, for that one feature the point is valid. I thought there were more tags with a fixed number of parameters over 2-3, but on further investigation that's not the case (I only really do graphics modding, so my knowledge of the rest of the raws is limited). That was just an afterthought idea, though, not at all central to the utility.

To be clear, that isn't implemented right now and was pretty near the bottom of my priority list. Right now you enter whole tags and that's it.

37
DF Modding / Re: RantingRodent's Dwarf Fortress Raw Patcher
« on: November 03, 2010, 04:35:56 pm »
you'd not be able to tell by looking at that file what state it changes from nor what to (and neither would a program). Even with the base raws, you'd not know what it changes to without this tool.

I'm not sure what you mean by this. You know what it changes to; it changes to what you put in the file.

38
DF Modding / Re: RantingRodent's Dwarf Fortress Raw Patcher
« on: November 03, 2010, 01:21:27 pm »
Ah, yeah, I forgot to add that to my list. I would like to add that as well. Basically just by adding a token like so:

[REMOVE_TAG:AUTUMN] would remove the [AUTUMN] tag.
[REMOVE_OBJECT:WEED_RAT] would remove the [PLANT:WEED_RAT] object

Another feature I didn't mention above was that I would like to allow changing only some parameters from a list and leave the rest alone. My thought was this type of syntax:

[SOMETAG:...:...:...:42:42:...:...]

39
Got a few more to share. I think the last one still needs work I think.

Spoiler (click to show/hide)

40
DF Modding / Re: Community Mods and utilities list.
« on: November 02, 2010, 10:32:57 pm »
I just posted a raw merging utility: http://www.bay12forums.com/smf/index.php?topic=69655.0

41
DF Modding / RantingRodent's Dwarf Fortress Raw Patcher (Out of beta!)
« on: November 02, 2010, 07:52:47 pm »
What does it do?
Updating your mod for each release is a pain, right? Well hopefully not any more. I kept trying to solve the time problem with complex utilities, but this time I'm building something super simple. RawPatcher to the rescue. The utility goes through the DF raws and modifies the values that were changed in your Mod raws, and adds new entries where none previously existed.

The tool will attempt to intelligently merge raw objects according to this logic:

1. The first token in the tag is treated as the name of that "property".
2. If the property doesn't exist on the source object, it is added to the end.
3. If an exact match for the property is found in the source object, no changes are made.
4. If one instance of the property exists in the original and mod objects, the mod property replaces the original property.
5. If multiple instances of the property exist in either location, the mod property is added to the end of the object.

You can also force behaviour by using the following tag formats:

[ADD_TAG:METAL_ORE:IRON:100] will add the tag [METAL_ORE:IRON:100] to the end of the object, regardless of what is already there. If a tag is found which matches this exactly, it will not be added.

REMOVE_TAG removes a single property that best matches the provided tag. An error results if multiple tags ties for best match.
[REMOVE_TAG:METAL_ORE] will remove [METAL_ORE:IRON:100] if it is the only METAL_ORE on the object. There will be an error if it also has [METAL_ORE:LEAD:100]
[REMOVE_TAG:METAL_ORE:IRON] would remove [METAL_ORE:IRON:100] if both tags existed.

[REMOVE_ALL:METAL_ORE] will remove all METAL_ORE tags on the object. Only accepts a single parameter.

DFFD link: http://dffd.wimbli.com/file.php?id=3353

Installation
1. Install Adobe AIR
2. Double-click the AIR file
Should work on PC, Mac and Linux. Contact me if it doesn't, please

Usage
1. Create "mod raw" files containing ONLY your changes. (see below for example)
2. Point the utility to your mod files and a clean copy of the df raws
3. Point the utility to an output folder
4. Click "Do It"

Notes
- files in the source folder with no counterpart in the mod folder will be copied directly
- files in the mod folder with no counterpart in the source folder will be copied directly
- the order of objects in the raws don't matter. The tool is smart enough to match up tags to objects
- the tool is not smart enough to match things up well with hierarchical sub-tags at this point, so some of the more complex raws may not work well
- you can use this tool to combine several mods together by using the output from the first merge as the base for the next merge
- all comment text is completely stripped during this process

Roadmap
I'll eventually put up a poll to see what I should prioritize, but this is my personal order for now.
1. Eliminate the restrictions on sub-folders are raw file types
2. Save last selected folders
3. Generate a mod folder describing the difference between two sets of raws
4. Select multiple mods to apply at once, detect conflicts
5. Single file merge
6. Rule-based changes
7. Add support for init files
8. Retain comments

Example
In the DF Raw (inorganic_stone_mineral.txt)
Spoiler (click to show/hide)


In the mod Raw (inorganic_stone_mineral.txt)
Spoiler (click to show/hide)

In the merged Raw (inorganic_stone_mineral.txt)
inorganic_stone_mineral
Spoiler (click to show/hide)

42
Thanks.

Yep, the cave blob is a palette swap of the flesh ball. They are both amorphous blobs and I don't feel the need to make two sprites for that :P. Their descriptions are almost identical.

In case it's not clear, the Manera is structured like a spider. It's described as crawling around on the rock, so the sprite is what you would see looking at it on the cave wall, not a side view of the creature, but representative of a side view from a person standing next to it. The change in perspective might be a problem I guess. I'll shift the sprite up to be at the top of its tile, hopefully that will help.

43
Another batch. I've got a large chunk of the non-vermin covered now. The biggest challenge are creatures that are supposed to be huge. It's hard to convey that properly.

Spoiler (click to show/hide)

44
DF Modding / Re: A Vile Force of Spriting Approaches
« on: October 31, 2010, 11:52:55 am »
Even more new subterranean creatures. I'm skipping a few if you look at the raw order. Just trying to tackle the ones that I get a good immediate mental picture of.

Spoiler (click to show/hide)

45
DF Modding / Re: A Vile Force of Spriting Approaches
« on: October 31, 2010, 08:43:27 am »
Spoiler (click to show/hide)

Maybe doing all of the critique for these under spoiler tags is not especially practical :P

Pages: 1 2 [3] 4 5 ... 30