Bay 12 Games Forum

It might be worthwhile to try building a three-wide set of fortifications:

Where ~ is a water flow pushing to the left, and F is a fortification, and . is a chasm:
...FFF~~~

The flow on the right MIGHT only be able to push victims into the rightmost fortification, and they wouldn't fall into the cliff. Then again, it might not work that way - the flow might just push them all the way through all three fortifications... It's worth testing, at any rate.

What about using SFML instead? The license wouldn't be a problem: http://www.sfml-dev.org/license.php

The worldgen params are in DF's data/init/world_gen.txt, if that's what you mean.

An option that means "do not touch my init.txt"? Well, it does copy your original init file into the modbase folder, so unless you use the built-in editor afterwards, it will not be changed.

And it messing with inits during normal work is a necessary evil. Until I think of a way to reset tileset configs (so that tileset mods can be disabled) without copying over a backup copy, it will have to be done.

The reason is that I don't have ModBase loading any mod components which actually change the font bmp here. Those are disabled because I copied the font bmp into the folder it goes in to avoid having ModBase delete the comments in the init file and stuff. But it deletes them anyways even though there isn't anything in the init file for it to change, so I have to overwrite the stripped init file with a backed-up init file, and if I change an option in the init file directly later (rather than figuring out how to use ModBase's editor), and then have ModBase apply changes to a mod, ModBase overwrites the init file and deletes the changes because of its own backed-up init file. For a while while I was working on my mod it kept changing the window size back to 80x50 when I wanted 80x25 just because I happened to have been trying 80x50 when I ran ModBase for the first time with that version of DF (until I hunted down where it stored the original init file, and fixed it).

(Yes, the init file comments really are that important to me)

Maybe you downloaded the wrong rar. There are three - one has the modbase.exe and such, one has the mods, and one has the source code.

Also, could we please have an option for ModBase that says "Please do not touch my init.txt" ?

Yeah, I was noticing that myself. I actually have granite in one of my forts, and a bunch of granite doors near a bunch of gabbro doors. So I need to figure out a solution for that too.

[Some time later]
So, yeah, granite has a black background color, where most other stones have a light gray background color. However, doors' colors are also determined weirdly. Doors are using, for the door's FG:BG:FGbright, the stone's color's BG:FG:0, with the exception that if FG and BG are the same color, the FG color's brightness becomes 0 instead of 1.

So I was thinking I could just change granite to be the same color as the other medium-gray stones, but then I realized I couldn't remember actually SEEING any in the past several months... I could've sworn that there were medium-brightness grey stones that weren't dark and weren't light, but I couldn't find any in-game or in the raws except, of course, for bizarre granite. Since I distinctly remembered the 2d version making a distinction between the three kinds of stones, I ended up checking the 2d version. It turns out that the colors of stones apparently changed from the 2d to the 3d versions.

Obsidian, onyx, and jet were 0:0:1 in the 2d version. Dark stones are 0:7:1 now.
Limestone, marble, and moonstone were 7:0:1 in the 2d version. Light stones are 7:7:1 now.
Other light stones were 7:7:1 (talc, pumice, dolomite, chalk, flint),
Gray stones were 0:7:1,
and there were presumably brown stones that were 6:7:0, the same as now.

0:7:1, in the 2d version, was the color of medium gray stones, which is why I couldn't find any - medium gray and dark stone colors got merged at some point for 3d, apparently.

Actually, it looks like all those stones except granite had their BG color changed to 7. (I didn't check the non-gray stones to see if they changed too)

Anyways, veering back from that tangent, the problem isn't that granite reverses its color - it doesn't, it's light grey on black - it's that doors reverse BG and FG colors, and set brightness to 0, resulting in granite doors having a black foreground color because their BG color was black. Similar problems probably occur with things like cages and anything else that reverses fg:bg or anything like that.

Now, possible ways to fix this... Well, the only good ones I've thought of are:
1. Change it to the same color as some other kind of stone, either dark or light.
2. Change all the dark stone back to 0:0:1, and make granite 0:7:1 like normal stone. Problem: Dark stone stuff will be harder to see unless users adjust their init file color scheme (Or maybe I'm the only one with their monitor intentionally set to a very low brightness and contrast).
3. Make granite 0:0:1, which would make its doors look darker than other stone doors. This would work for doors because the identical-color-thing would give it a dark grey FG color - where gabbro etc have light grey. However, otherwise granite rocks and items and such would be just as dark as gabbro etc.

sphr:
I think I'll merge a few of your improvements back into my tileset too, like the black box lines around the X for bins, and the black pixels that you added around the white ON/OFF text which I had added to the levers. (And I just noticed the note you left on my user talk page, so I should look into that too - thanks, I hadn't noticed that mistake)

It should work fine, I think - I tried 80x50 earlier today for a few minutes and didn't notice any problems. (But I went back to 80x25 because I really like having DF only take up 1/3 of the screen or so)