Version 0.4 is now available from DFFD:
http://dffd.wimbli.com/file.php?id=404Changes:
- general interface improvements
- fixed undo bug, when the maximum undo/redo depth was infinite
- added z_distance_to_surface
- renamed is_ramp to is_upward_ramp
- added is_ramp, is_downward_ramp, is_above_upward_ramp and make_downward_ramp
- renamed is_lava to is_magma_source, and make_lava to make_magma_source
- added traffic designation queries, which had erroneously been left out
- added a few additional example operation sets to the included file
Improvements to the wiki page will come sporadically, but it's still a work in progress, and I'm hoping that my program is intuitive enough to limit the need for much documentation. Note the tooltip help things that popup when you hover your mouse over most items in the insert menu/insert toolbar buttons, as those contain the bulk of the documentation that I have written.
Placing a River Source tile in the air will cause a crash. (I suspect the same for chasms, etc.
I was unable to reproduce this crash. I successfully placed river sources in the air, and when I placed on in the air but next to a cliff that I could mine, I successfully produced a working river source in the air. I also placed a chasm in the air, and dwarves successfully dumped stuff into the chasm, even though it wasn't on the bottom z-level. The items disappeared entirely, as I hoped would happen. Since I couldn't reproduce the crash, I left the relevant code as-is, with no extra checks to avoid crashes.
Anyone figured out how to use the set_raw_type stuff yet? I'm stumped...
The raw functions are there just in case someone wanted to and knew how to access stuff that I haven't figured out or implemented yet. The set_raw_type(double type) function expects one argument which is the numeric value corresponding to
this post by Toady one. Changing types often seems to involve more work than simply changing this one value, however, so I wouldn't expect much. For example, changing from a piece of dirt to a tree would require also specifying what type of tree. This information is probably stored in a separate piece of memory allocated independently, and without it, the game would probably get confused, or ignore the tile, or something. But feel free to experiment.
The
and_raw_ and
or_raw_ versions take the argument they are given, convert it to an unsigned integer, and the either binary-and or binary-or it with the current value. This is for setting subsets of the field, for example, the liquid level of the designation flag, which takes up three bits. If this is all over your head, it's probably best to avoid the raw functions, but if not, feel free to hack away and see what happens.