Bay 12 Games Forum

Where did you put that text, specifically? What isn't working? Is the reaction not showing up in the smelter?

For one, having [IS_METAL] in the inorganic and not having [FUEL] in the reaction may result in unintended behavior. I believe you would also omit "ore" from [STATE_NAME_ADJ] for the inorganic. And the convention, as far as I know, is to have separate inorganic entries for the ore and the bars. But I don't think any of that would break things completely?

The most obvious error, though, would be if you haven't added a [PERMITTED_REACTION:CRYOCYTE_MAKEING] (sic) underneath [ENTITY:MOUNTAIN] along with the other similar tokens in the entity_default.txt file.

Here's the second release, v1.0.1: Strange Mood. Mostly it adds a lot of documentation and fixes/improves stuff that was already there.

I'm still trying to gain traction for PyDwarf! I believe the best way to do this is to add more mods. If you have a mod you'd like to see rewritten for PyDwarf, please let me know and I'll work with you to get it done. PyDwarf is very good at this sort of thing! Mods that might previously have been limited to a small range of Dwarf Fortress versions, and might have been troublesome to merge with other mods, can now be written in such a way that compatibility becomes almost a non-issue.

Changelog:

Holy shit, just look at all that documentation!

OK, although that doesn't really address my question because you started with NONE and went to ALL, I see from your example that I could accomplish what I would be looking for with a slice.

Your example does bring up another question though - what about growths with multiple GROWTH_PRINTs? ... There are 4 growth prints which vary only in their args. Can I change the color (args 2-4 inclusive 0-based) of the 2nd GROWTH_PRINT without touching the others?

I'm not sure I understand what you mean, then. Can you provide some sort of pseudocode example of what you would expect to be able to do?

As for multiple GROWTH_PRINTs, they could be handled like this:

>>> pomegranate = df.getobj('PLANT:POMEGRANATE')
>>> print pomegranate
[PLANT:POMEGRANATE]
>>> growths = pomegranate.allprop('GROWTH_PRINT')
>>> print growths
[
                [GROWTH_PRINT:0:6:2:0:0:0:209999:1],
                [GROWTH_PRINT:0:6:6:0:1:210000:239999:1],  autumn color
                [GROWTH_PRINT:0:6:4:0:1:240000:269999:1],
                [GROWTH_PRINT:0:6:4:0:0:270000:300000:1],
                [GROWTH_PRINT:5:5:4:0:1:60000:119999:2],
                [GROWTH_PRINT:'%':'%':4:0:1:120000:200000:3]]
>>> growths[1].args[2] = 'some value'
>>> growths[1].args[3] = 'some other value'
>>> growths[1].args[4] = 'some other value again'
>>> print growths
[
                [GROWTH_PRINT:0:6:2:0:0:0:209999:1],
                [GROWTH_PRINT:0:6:some value:some other value:some other value a
gain:210000:239999:1],  autumn color
                [GROWTH_PRINT:0:6:4:0:1:240000:269999:1],
                [GROWTH_PRINT:0:6:4:0:0:270000:300000:1],
                [GROWTH_PRINT:5:5:4:0:1:60000:119999:2],
                [GROWTH_PRINT:'%':'%':4:0:1:120000:200000:3]]
It might be helpful to see PyDwarf's querying functionality as a bunch of methods that look for tokens in a linked list, starting with some particular token, that match some particular conditions, and ceasing to accumulate matching tokens on some condition. Because that's exactly what it is. All of the querying methods are built on top of a generalized query method that takes filter objects and an iterable collection of tokens as arguments. For example, the method allprop as used in the above code starts from the current token and returns everything with a value of 'GROWTH_PRINT' until it encounters the next token with a value of 'PLANT'. And each of the token objects in the list returned can be operated on in any way from adding more tokens before or after, removing the token, or accessing/modifying its attributes e.g. its arguments.

If you navigate a terminal to your PyDwarf directory, try entering python and entering the same commands as above. (Don't forget to import raws and df = raws.dir(path="..."). You will need to change the path in raws.dir(path="...") to refer to actual raws on your machine.) Screw around with them as you see fit, and the workings should become more apparent.

Well, if that's the definition then that's the definition, but it's an extraordinarily unhelpful one for performing lexical analysis.

Given the raws snippet [CREATURE:DWARF] a lexical scanner would break it down into these elements: '[', 'CREATURE', ':', 'DWARF', ']'. These are formally called lexemes, but are typically referred to as tokens in the context of lexical scanners. In no context that I know of would tokens conventionally refer to 'CREATURE' and 'DWARF' only. The term I've most frequently seen to refer to the tags/tokens in raws is token, for example this wiki page. The first item in the list delimited by colons represents the purpose of the token, and value seemed to me a reasonable term to use. The others elaborate on the first in much the same way as arguments passed to some procedure.

Hey madk,

Does this support changing individual tokens within tags?

Could you elaborate? I always understood the terms "token" and "tag" to be synonymous when speaking of the raws.

Do you mean changing the arguments of a token? i.e. a token being like [VALUE:ARGUMENT_0:ARGUMENT_1:...:ARGUMENT_n]? If so then absolutely. A raws.token object has a value attribute, corresponding to the first item in the list delimited by colons, and an args attribute which is a list of all the other items. There are also helper methods like token.nargs(), token.getarg(), and token.setarg() for things like convenience and input sanitization.

Would you add PyDwarf to the list? It's a tool in the vein of ModBase and Rubble but it aims to be friendlier and more comprehensive. Essentially its purpose is to provide capable querying and modification of raws to modders, and easy management and use of modders' scripts by players.

I wrote a PyDwarf script which is able to fairly intelligently merge modified raws provided the DF versions all line up. (Understanding changes based on disparate vanilla raws would be a highly nontrivial problem.) It should be listed as the first script to run and given, as an argument, paths to each file or directory that should be merged and applied.

https://github.com/pineapplemachine/PyDwarf/blob/master/scripts/pineapple/pydwarf.diff.py

Scripts are already allowed to take whatever arguments that Python will allow them to take, though there's not currently a mechanism for allowing *args. (But that's okay, because it's exactly the same thing to just pass a list or other iterable as a named argument.) I don't believe it's practical to have an "uninstall" functionality - making the changes is much easier than reversing them. Instead the user would be expected to keep backups, and if they decide they want to remove some mod or change the load order they would need to re-run the manager with the updated settings.

I understand the documentation is shitty - I'm working on that - but it you might look into how it works before speculating about how to change it. You may find that many of the things you're asking for are there already.

For me, concern regarding ease-of-use is more to do with making it so that users won't need to have programming knowledge to use the mod manager. Eventually I'd like this to mean having easy ini or ini-like configuration files as an option, perhaps even a more graphical interface that could abstract aspects of configuration and management. For usability from the perspective of modders, I believe what I have is a solid foundation. There are improvements I want to make but the essentials are present if not a little buggy in places. Also worth nothing that it's my on the todo list to write diff-based mod functionality into PyDwarf as a mod itself that accepts existing diff-based mods as input and merges them as best it can. (I believe this would actually be simple compared to the querying functionality that's at the core of PyDwarf.)