Print

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

[Erasmus Darwin]

quote:Originally posted by xzzy:
<STRONG>Could probably find the "ultimate spot" in a few seconds if you reverse engineered the data files and just analyzed them directly.   Could use those 229 days to program instead of watching a program run.</STRONG>

There are a few problems with that.  The data file's had the least amount of hacking done to it compared to everything else.  So you'd have a lot more work to do just to get at the information.

In addition, there's only so much world data that's saved in the save file.  It seems that the actual map generation uses some sort of deterministic technique to generate the actual layout after the fact.  It's entire possible, for example, that the world data doesn't explicitly encode the existence of a chasm on a given map square.  Instead, it may just have a seed and some environmental factors that result in the deterministic invocation of rand() leading to the creation of a chasm on that square.

Finally, I'd rather let a program run for 229 days while I go off and do other stuff rather than spending 228.5 days working on a program that runs in 5 minutes.  My time is valuable.  Computer time is cheap.

[Ziusudra]

quote:Originally posted by Erasmus Darwin:
<STRONG>

I think that estimate might be a little off.  Each tile goes really quickly.  It's generating the 16x16 map and forcing it to allocate (by designating the bottom level for digging like with reveal) that goes slowly.  After that, reading the data's real quick.

Anyway, I'd say the entire process takes under 5 minutes for a full 16x16 (maximum) region.  Using Ziusudra's figure of 66049 regions, that's 229 days.  That's not trivial, but it's certainly doable -- especially with parallelism.  Also, that's with a conservative estimate based on the performance on an older machine.</STRONG>

Hmm, let's do the math, at 589,824 tiles per region (wiki) that's 0.5ms per tile.  While I do think I over-estimated, I doubt it was by a factor of 100.

Let's split the difference and say 5ms per tile.  5ms x 589,824 tiles = 2,949,120ms or 49 minutes.  That's too high, the game takes a few minutes at most to generate a 6x6 block.

OK, lets start there, though it all depends on the computer.  Thats 36 x 2304 tiles per block, or 82,944 tiles.  At 1 minute that's 0.72ms per tile, but while the game is looking at multiple z-levels it isn't looking at every one, maybe double it or about 3 times what you figured.  Still doable with parallelism.  And I could see ~200 days on a modern multi-core system with multi-threading.

But even if it took 100 days, that still leaves you with the incredible task of indexing and searching 38-39 billion multi-level tiles.  Well, no, you'd index while you generate, while you have the data in hand.  It would of course take longer, but at the end you'd know which are the rarest features and which tiles have them.

OK, it's possible.  But you're talking about a lot of work for something that could be made useless with the next release of the game.

[Alfador]

quote:Originally posted by Erasmus Darwin:
<STRONG>

That should be doable, however I don't recall seeing any memory work with the embark maps, yet.  If you can read the entire map rather than just what's active, it seems like you'd be able to circumvent the map refresh bottleneck associated with the macro process.

What I'd really like to see is something that can check every the entire map.  Someone was proposing a dwarven cartography project to map out every single tile of an entire seed.  If you had something like that, you could run site location searches based on anything and everything.  You could get really picky with your queries.

Ideally, I could see it being able to find all locations that would meet a picky request like: I want a fortress location of size 3x3 with a renewable source of water (brook, river, or aquifer), at least one aquifer-free area, a climate between temperate and warm, at least 100 trees, at least 500 squares of flux material, at least 500 squares of iron-producing ore, at least 20 squares of rock crystal, a magma vent open to the surface, a chasm, an underwater river, sand, and Hidden Fun Stuff.</STRONG>

This would not only be useful for finding great sites, but also for testing! You could test an extremely wide range of biomes with odd characteristics, as well as figuring out whether that rare gem you modded in is not working, or if it's just as rare as you designed and that's why you haven't found it.

The real problem with such useful testing utilities is that everything they depend on is subject to change. That's why Toady hasn't made them himself--there are three main priorities in the development: Finishing features he wants to be in the finished product, creating utilities/wizard mode to make testing easier, and exterminating bugs so the testers have a halfway stable version to work with. While the features are obviously the highest priority (this is alpha!), a quasi-stable version at each "level" of feature production is necessary for us testers to have something to work with. However, utilities to make such testing more efficient are not as high a priority as making the product to be tested itself, so that gets cut out and left mostly to third-party programs like reveal.exe.

The good news is, one day when (nearly) all of the features are implemented, we'll start seeing cheat codes to make that kind of sandboxing easier. Right now, if you think about it, the 1000-point anvil is kind of a bone thrown to us in that direction. Modding the raws so the least-valuable anvil metal is worth even more... is just excessive.  

[Ziusudra]

Note to self: Keep it simple.

Tried to get fancier than AHK could do.

Did get it finding mountain blocks and named region features (peak, volcano, stream and brook.)  Will add neighbors and highest cliffs tomorrow.  Those should be easy enough that I can start working on biomes.

[Boogaloo]

here is a really really simple magma finder program i wrote a while ago.. it basically just takes a screenshot and scans relevant pixels for the magma color.

limitations:
-dwarf fortress window must be at the top left hand corner of the screen
-runs forever unless you locate some magma, so once it reaches the right hand side of the screen use shift-left arrow to get back over to the left
-if you are going back to the left hand side of the screen and it does find some magma and stops scanning, there's a good chance you'll miss it
-you've got 4 seconds to refocus on the dwarf fortress window before scanning begins
-some false positives, not only magma is that dark red color
-god help you if there's somehow no magma on the entire map

here's the source code:

import java.awt.AWTException;
import java.awt.Graphics2D;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Rectangle;
import java.awt.RenderingHints;
import java.awt.Robot;
import java.awt.Toolkit;
import java.awt.event.KeyEvent;
import java.awt.geom.AffineTransform;
import java.awt.image.BufferedImage;

public class MagmaFinder {

   static Robot robot;

   public static void main(String[] args) throws AWTException {

      robot = new Robot();

      robot.delay(4000);
      System.out.println("go!");
   
      BufferedImage cap;
       new Robot().createScreenCapture(
            new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()) );

      Boolean magmafound = false;

      search:
      while(!magmafound){

         cap = new Robot().createScreenCapture(
               new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()) );         
         
         
            for(int x=0;x<145;x++){

               for(int y=0;y<250;y++){

                  if (cap.getRGB(x, y)==-8388608){
                     System.out.println("magma!");
                     magmafound = true;
                     break search;
                  }

               }

            }

            
         
            robot.keyPress(KeyEvent.VK_RIGHT);
            robot.keyRelease(KeyEvent.VK_RIGHT);
            
            
                  
      }

      

      robot.keyPress(KeyEvent.VK_LEFT);
      robot.keyRelease(KeyEvent.VK_LEFT);
      
      System.out.println("done");

   }

}

and, if you really want, a download link: http://rapidshare.com/files/76918237/MagmaFinder.jar.html

maybe someone can make it more useful, i dunno.. i used it to find a nice spot with a dolomite layer surrounding a magma vent, which means boatloads of magnetite and flux, so i'm happy    

[ December 16, 2007: Message edited by: Boogaloo ]

[Ziusudra]

I never did trust the whole 'magma is the only thing that color' idea, what with all the different surroundings colors for selected blocks.  I never bothered to test the idea as I have to look for images for most every thing else so I might as well just use that function for magma too.

Of course, now rather than add stuff I get to figure out how I broke the embark check. ... Ah, it's only broke when debugging, one of these FileAppends always runs and resets ErrorLevel. Fixed.

 If Debug
   If ErrorLevel
     FileAppend, Fail to find %File% image.`n, debug.txt
   Else
     FileAppend, Found %File% image.`n, debug.txt
 Return ErrorLevel

I wish the text mode really was text so the script could read it.  Well, read it easily.

[Quarthinos]

I've been trying to help Ziusudra to get his AHK script doing all the work, but what I'd like to do is write a program that uses the world.dat data file to do the same thing.  While it'd be BEST to be able to determine if the region I'm embarking to has <Hidden>, I'd be happy if I could just guarantee magma, some trees, a cliff and flux.  World.dat is most likely place that information on each block is stored.  If I can get soil, stone layers, flora, fauna and temperature for each block (the information available to an embarking player), I'll write a program to find a block containing user specified things in a user-specified area.  Which isn't as nice as scanning the 38,957,285,376 tiles to find the admantite and chasms, but sure beats looking at each individual block myself.  Ziusudra's script is a big step in the right direction as far as I'm concerned, but I'd much rather write a program to process the world file directly.

As far as time, DF doesn't take more that a few minutes to read the world data and start displaying it, so it won't take more than 100x longer to read and process the same data to look for a "good" site.