Print

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

[madk]

Download PyDwarf 1.1.4
View PyDwarf on GitHub

For players, PyDwarf is an easy way to manage your preferred mods. Never worry about incompatible or obsolete mods again! (Or, at least, not nearly as often.) And for modders, PyDwarf is your new best friend. PyDwarf's mod manager exposes a very handy API for interacting with the raws. Here's an example of how effortless it is to customize raws even from a python console:

Code: [Select]

>>> import raws
>>> df = raws.dir('raw/objects')
>>> elf = df.getobj('CREATURE:ELF')
>>> description = elf.get('DESCRIPTION')
>>> print description
[DESCRIPTION:A medium-sized creature dedicated to the ruthless protection of nature.]
>>> description.setarg('A medium-sized creature undeserving of life.')
>>> df.write('raw/objects')

client-170:PyDwarf pineapple$ grep 'CREATURE:ELF' raw/objects/creature_standard.txt -A 4
[CREATURE:ELF]
    [DESCRIPTION:A medium-sized creature undeserving of life.]
    [NAME:elf:elves:elven]
    [CASTE_NAME:elf:elves:elven]
    [CREATURE_TILE:'e'][COLOR:3:0:0]

Here's just a few examples of the mods included with this release of PyDwarf:

• Omniclasm's State of Decay.
  
• DragonDePlatino's Gemset.
  
• Umiman's Small Things.
  
• Stalhansch's Armoury Packs.
  

Normally you'd be bound to run into compatibility issues when trying to install so many of these mods at once, and you'd surely have to wait for authors to update their mods before reinstalling everything whenever Dwarf Fortress updates. Not so with PyDwarf. PyDwarf is highly capable of avoiding conflicts between mods, and it cares little about which version of Dwarf Fortress you're modifying. Not only does PyDwarf make it much easier for the player to install mods, it also makes it easier for the modder to craft something excellent. Instead of editing text files on your own, PyDwarf allows you to write scripts which edit them for you: What this means for you is an enormous reduction in tedium.

Here's a step-by-step tutorial to guide you through your first time configuring and running PyDwarf, and here's another tutorial to help you get started creating your first mod. Also, here's a handy list of scripts with which PyDwarf comes packaged. And here's where all those scripts are actually located, in case you'd like to see what their innards look like.

PyDwarf is cross-platform. Only Python 2.7 is required to run PyDwarf.

[Max™]

Looks pretty neat, naturally just as I'm getting comfortable screwing around in lua I'm looking at this trying to see how it works like:

Spoiler (click to show/hide)

[Putnam]

Yeah, this'll probably be way better than find in files.

[madk]

Looks pretty neat, naturally just as I'm getting comfortable screwing around in lua I'm looking at this trying to see how it works like:

Ha, as far as mod creation goes it may seem a bit complex but that's partly due to the fact I haven't made much in the way of documentation yet. If you know the basics of Python - which are easier to pick up than Lua, in my personal opinion - then PyDwarf should be really very easy to use as a modder. I'd like to also make things easier on users, too, though I'm not yet sure how I'm going to do that.

Yeah, this'll probably be way better than find in files.

I should hope so!

[DragonDePlatino]

Ohh! I spend a lot of time doing repetitive Notepad++ replace functions, so this could certainly come in handy. I'm not really a programming guy, so Python is the only language I've ever gotten a grasp on.

Here's a suggestion...why not structure your documentation like the PyGame documentation? You list a command, what the output is, what it's best use is and possible values for your arguments. It's really straightforward for newbies.

[madk]

Ohh! I spend a lot of time doing repetitive Notepad++ replace functions, so this could certainly come in handy. I'm not really a programming guy, so Python is the only language I've ever gotten a grasp on.

Here's a suggestion...why not structure your documentation like the PyGame documentation? You list a command, what the output is, what it's best use is and possible values for your arguments. It's really straightforward for newbies.

This will definitely be better-suited than find/replace. And making proper documentation is a priority, but I want to make the querying functionality more final before I start to document it, otherwise I'll be changing it too frequently to be practical. I'll mind to look into PyGame for an example of how to structure the docs.

[madk]

I added a much more complex example script to help show just how powerful PyDwarf can be: https://github.com/pineapplemachine/PyDwarf/blob/master/scripts/pineapple/pydwarf.stoneclarity.py

Using the default settings, stoneclarity will cause ores and gems and such to assume standard appearances. Using this script, there'll be no more confusions for beginners like "Is that coal or is it a gem?" and "Why does cobaltite look like a metal?"

[Putnam]

"Why does cobaltite look like a metal?"

(mostly because it is)

[madk]

"Why does cobaltite look like a metal?"

"Why does cobaltite look like something I can smelt?"

[notfood]

This is very handy. Thanks for sharing. I'm often overwhelmed by the amount of search and replace I have to do, this is going to make things easier.

[Smurfton]

'd like to also make things easier on users, too, though I'm not yet sure how I'm going to do that.

To do this, create two functions, void install(string filename) and void uninstall(string filename). Both of them will need to be part of an object (Python allows objects, right?) for ease of use purposes. The object should contain a private variable which has a list of mods installed. You'll also need a copy of the raws for reverting purposes.
install() would accept a filename, open that file (which hopefully contains the mod), read it, and eval() the mod contents. Once the mod is installed, append the filename to the private list variable.

uninstall() would accept a filename, make sure that was in the list of installed mods, remove it from the list, copy the list to a temporary variable, delete the remainder of the list, copy the unmodified raws over, then run install() on every item. Alternate solution: have a version of install() that doesn't append to the installed list, and call that.

As an extra, you can overload (Python does that, right?) both so that if no arguments are given, install() is run on a specific folder, and uninstall copies over unmodified raws, and clears the list.

Probably a better way to do uninstall(), but that should work, as a start.

[Putnam]

Python is object-oriented.

"Overloading" there seems to be referring to duck typing, which Python has. Or it refers to one function being able to operate on different types by defining a function of the same name for multiple types of arguments, which is not necessary since Python is dynamically-typed.

[PeridexisErrant]

PTW.  If easier for users is a goal, maybe this could be incorporated as an upgrade to PyLNP's mod merger?  The only requirement is that it take whole modified raw files as inputs and outputs.

<snip>

Setting up default arguments is certainly a good idea, but the rest of the psudeocode is more C (or Java?) than Python.  A detailed response would be more nitpicks than productive.

[lethosor]

"Overloading" there seems to be referring to duck typing, which Python has. Or it refers to one function being able to operate on different types by defining a function of the same name for multiple types of arguments, which is not necessary since Python is dynamically-typed.

It sounds to me like Smurfton is referring to functions taking a variable number of arguments (which is also possible).

PTW

[Putnam]

Yeah, with *args and **kwargs.