DF Map Archive

User info for SL




Maps and Movies

Favourites: 1

Favourite maps

Comments: 16

Submitted: 2010-01-12 (View movie)

Now that is an nice improvement, provided the water level can be maintained. I had designed and built previous autorepeaters which were built attached to pools or dwarf-made reservoirs, but the (two) pressure plates were not perfectly synchronized. The water level in the pools decreased over time, necessitating their eventual refilling from the outside river (while the repeater was shut off), and I would expect the same to happen to your autorepeater (I wasn't sure if it was due to evaporation or the pump, since I had confirmed that there were bugs with pumps that destroyed and created water magically, several versions earlier, but hadn't retested for them in the latest version). (http://dwarffortresswiki.net/index.php/User:SL/Logic_Gates#Repeater) - apparently others have made other repeater designs, some more similar and some more different, since I made my original repeater, too.

[Message edited on 2010/01/12 at 02:11 by SL]

Submitted: 2010-01-07 (View movie)

You'd be better off using magma as your fire-starting mechanism, then. I know it can start fires since I've had fires triggered by it in the past - If you pour some magma onto grass it should start a fire which will spread through the grass. What I don't know is whether pouring it onto wood will light the wood on fire.

Submitted: 2010-01-07 (View movie)

What are the plates and hatches supposed to do?

It looks like the fireballs might just be sailing over the wood-pile - Have you tried having the dwarves run across the wood-pile yet?

I think I'd put clothes-wearing goblins (assuming you can chain them; I've forgotten) right next to a wood stockpile and see if the imp can light them up, allowing the fire to spread to the wood. You should be able to put them on cages next to the stockpile and just channel out around them and the stockpile (except for continuing the stockpile to whereever you want the fire to go if need be), so the goblins can't get away from it and can't reach the imp, of course, and then use a lever to spring them from the cages along with the imp. What do you think?

If the wood won't light, you could try charcoal, on the off chance that it may burn easier, but they probably burn at the same temperature, since they don't seem to have entries in the raw files and have no temperatures for melting or boiling listed on the DF wiki. :P

[Message edited on 2010/01/07 at 06:05 by SL]

Submitted: 2008-03-24 (View map)

Could you check the original BMPs to see if they're the source of the scrunching? (pretty much every time someone's found a problem with a map, such as black bars in it, it turned out to be in the BMPs that DF wrote out, rather than the compressor)

Submitted: 2008-02-03 (View map)

He probably forwarded it to me, but I don't remember for sure. I hadn't ever seen a map where that kind of thing happened until now, though. So, now now that I've actually seen the weirdness in your map, and can run tests on it, it looks like a good idea to me. There actually is a factor like you described (except not user customizable in the version that's currently released) that's already built into the tile-identification code for the c# version of the compressor. That value is set to 12 by default right now. I had worried that having it too high would cause misidentification of tiles, resulting in tiles showing up with the wrong image, but that doesn't appear to be happening in the tests I'm doing on your map now. I needed values of around 150 or above to match all the matchable tiles in your map. (It's actually somewhere > 100 below 150).

To get additional debug output which shows how many tiles were identified and how many were not, you can run the compressor like this from cmd.exe with a pipe to a text file: DwarfFortressMapCompressor[press tab one or two times here to autocomplete the program's filename] > output.txt

Look in output.txt when it's done compressing and the output should be there.

If you're using a graphical tileset, there will always be some unidentified. The key hint as to whether you're getting all the tiles will be to run it again with a higher value, say, around 50 higher (When I release a version which lets you change this :P). If you get the same amount of failed-to-identify, you probably got all the tiles you could. For example, on my test map, there are 151 unidentified tiles. On yours, there are 110 (once we get the value high enough to identify everything else). I'm using the DQ graphics that veryinky modified to have more variation, so there are probably more different graphic tiles in mine than in yours, which would be why there are more unidentified ones in mine.

It's funny how your map has this nowhere-near-precise color, and actually seems to need a DeltaR˛ + DeltaG˛ + DeltaB˛ of above 100 (somewhere between 100 and 150), but has no vertical black bars, and yet my map only needs 12 but DF writes it out with vertical black bars on it. (Especially considering we have the same font size and the same window size and the same bit depth (32)...)

By the way, I tested it with the following values: 12, 25, 50, 75, 100, 150, 200, and 300. As I increased the value from 12 to 150, the number of identified tiles increased from 638 to 3142, failed to identify dropped from 2614 to 110, and duplicates increased from 541 to 2900. Above 150 these values remained the same. Unique tile images ratio remained the same (0.2566288%), except that it was calculated before tiles were identified and duplicates were eliminated. If we recalculate it, it drops significantly due to the few thousand duplicate tiles which were eliminated. (For comparison, my map has 0.04048388%, 481 identified, failed to identify 157, and 6 duplicates.)

I've also made the compressor also check (after the normal check to see if the unique tile ratio is so high that something must be terribly wrong) to see if the unique tile percentage exceeds 0.1%, and, if your color match sensitivity is less than 200, to say "This multi-level map may have color damage - Dwarf Fortress may have written out the images oddly, for instance. We may, however, be able to correct for it, by increasing the color match sensitivity. It'll make tile identification take longer, but the end result will be a smaller filesize, if it works. Would you like to increase the color match sensitivity to 200?" (It also lists your unique tile percent and so forth there). If you say yes, it'll also let you know how successful it was at correcting things once it has finished tile identification and pruning duplicates.

It's funny how your map has this nowhere-near-precise color, and actually seems to need that value to be above 100 (150+ does it), whereas mine only needs 12, and yet we have the same font size and window size. Actually, I wonder if it's because of your CPU, graphics card, or graphics drivers instead. Also, as a side note, the graphical tiles (the Dystopian Rhetoric art, I mean) don't appear to have been screwed up the way the other tiles were, so perhaps it's fuzzy math or something in whatever's coloring the font characters for each tile?

[Message edited on 2008/02/03 at 09:56 by SL]

Submitted: 2008-02-01 (View map)

Did you change any other colors or edit the font at all? I'm trying to re-compress it with the in-development version of the compressor to see how well the filesize-reducing enhancements I've been working on work on it, but I'm currently getting "Identified 638, failed to identify 2614, found 541 duplicates." Not quite sure what the 541 duplicates are at the moment, will have to mess with the compressor's innards a bit to find out. The 2614 unidentified tiles are what concern me the most at the moment. I don't think DR's dwarf graphics have 2614 different tiles in them, so maybe something is wrong somewhere (My main fort gets "Identified 481, failed to identify 157").

(Even so, the filesize is down to 247 KB)

At the moment I'm using the Herrbdog_16x16_tileset.bmp font downloaded from the wiki, and the default colors also downloaded from the wiki, except I changed brown to RGB 160,96,48 (copied from the color of one of your bins).

Edit: You don't happen to have your color depth at 16bpp instead of 32bpp or something, do you?

[Message edited on 2008/02/01 at 04:41 by SL]

Edit #2: As best I can tell, some of the font characters seem to be different. The first one I've been examining - originally to see if the colors were correct, starting with white - was a white statue. But it appears that the statue tile itself in this font doesn't completely match the one in your image.

[Message edited on 2008/02/01 at 07:20 by SL]

Submitted: 2008-01-31 (View map)

What font and color scheme did you use for this map, by the way?

Submitted: 2008-01-19 (View movie)

It's not backwards - It pumped before I built the wall two spaces to the right of the lower pump. Also, I deconstructed and reconstructed the entire thing (both pumps and their power apparatus), and it still doesn't pump.

I'm uploading the save now.

Bug post: http://www.bay12games.com/cgi-local/ultimatebb.cgi?ubb=get_topic&f=6&t=002651

Save: http://shadowlord13.googlepages.com/magmaPumpOnStrike.7z

[Message edited on 2008/01/19 at 02:26 by SL]

Submitted: 2008-01-11 (View movie)

Basically it repeatedly toggles two pressure plates, which can be linked to whatever you want.

Submitted: 2008-01-11 (View map)

Quite probably. I've been butchering them nonstop, but I think I'm going to have to designate something like 8 dedicated butcher/tanners and 8 butcher's workshops to actually get rid of them all.

Submitted: 2008-01-03 (View movie)

The device which toggles the tiles is something I call a repeater. I've uploaded a movie now which shows an improved version, toggling two hatches and two spikes - You may notice that the second hatch usually flips at the same rate as the first one in that movie, whereas the repeater currently hooked to the Hand of Armok flips the second set of hatches much more slowly than the first.


Browse more map comments...

Browse more movie comments...