Print

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

[zagibu]

This is an AutoIt script that can automatically generate DF worlds and scan them for interesting fortress locations. It works by reading screen info, and not by analyzing the world data directly, so it is pretty slow.

   1. download AutoIt and install it: http://www.autoitscript.com/autoit3/downloads.shtml
   2. download and/or create a new Dwarf Fortress installation, change the default embark rectangle to 2:2 in DF's init file (but leave all other settings alone)
   3. download the current script and unpack it to a new folder in your DF installation: http://www.geocities.com/qrphome/df_asl_v0.6.4.zip
   4. download the latest version of regional prospector and put it into your DF folder: http://dwarf.lendemaindeveille.com/index.php/Utilities#Regional_Prospector
   5. edit the asl_bla.au3 script (found in the folder created in step 3) in notepad and set the global variables as you need them (especially the width and height of the world map, and check that tabula_rasa is True)
   6. Run DF, leave it at the start screen, then run regional_prospector and finally run the script by doubleclicking the asl_bla.au3 file
   7. wait until the script has generated and scanned all worlds (which can take a loooooooong time if you set it to generate and scan a bunch of 257x257 worlds)
  8. check all found positions by manually navigating to the coordinates (x is tiles from left edge, y is tiles from top edge) logged in locations.txt (found in the folder created in step 3)

The script generates worlds on the fly, checks all tiles of these worlds' maps and scans the local regions for the features set in the global variables of the script. It can currently search for all six of the regional prospector's special tiles. In addition, the script checks if the found features can be matched in an embark rectangle of user-defined size, and if it's even possible to embark there. It can also scan for flux and sand layers in this step.
If the script finds an appropriate location, it logs the current position on the world map to a text file in the same folder as the script, called "locations.txt". To see if you can get the script to work, it is best to set the map_width and map_height both at 17, worlds_num to 1 and scan for adamantium only (ignore every other feature). If you don't get any entries in locations.txt, something is wrong, as I've never seen a pocket world without at least one embarkable adamantium location.

Note: The script only works on systems where DF is reasonably responsible. If the script doesn't work as expected, you can try a higher value for the step_delay, but if DF alone already takes 100% cpu time on your system, just forget it.
I developped it on an Intel Core 2 Duo E6400, but I've also succesfully tested it on a regular P4 2.8 GHz. It didn't work on an AMD Sempron 3000, though.

The script is pretty much done. What remains are usability improvements and speed optimization.

Older versions:
http://www.geocities.com/qrphome/df_asl.zip
http://www.geocities.com/qrphome/df_asl_v0.1.zip
http://www.geocities.com/qrphome/df_asl_v0.4.zip
http://www.geocities.com/qrphome/df_asl_v0.4.5.zip
http://www.geocities.com/qrphome/df_asl_v0.4.6.zip
http://www.geocities.com/qrphome/df_asl_v0.4.7.zip
http://www.geocities.com/qrphome/df_asl_v0.4.8.zip
http://www.geocities.com/qrphome/df_asl_v0.5.2.zip
http://www.geocities.com/qrphome/df_asl_v0.5.5.zip

[Akroma]

quote:It's an automatic site locator for Dwarf Fortress. It scans all world tiles and logs all interesting locations. Currently, interesting means locations that contain at least one tile of: magma vent, magma pool, cave river, cave lake, chasm, adamantine. The script actually does the same thing as you do, when you look for interesting locations (it takes screenshots and looks for bitmap patterns in it), just faster.  

You mean it will locate EVERY mountain tile ?

[zagibu]

No, it currently finds locations with one or more tiles of each "special" tiles that regional prospector uncovers by looking at ALL TILES of the world map. That means it logs all areas on the world map where it finds one tile of magmavent, magmapool, cave river, cave lake, chasm and adamantium on the "local" screen.
I've let it run overnight on a 256x256 map and it yielded over a hundred such locations.
The next step I will do is make it look for places with magmavent OR magmapool and  caveriver OR cavelake and chasm and adamantium, and make sure magma, adamantium and water are close together.
My final plan is to make it check for flux layers, sand, civilizations and possibly region alignment, too. But that's still a bit of work off...

[ April 20, 2008: Message edited by: zagibu ]

[Chaz Turbo]

Every regional tile of mountains has at least a chasm, cave lake/river and adamantine, so there will be a lot of site-spam.

[zagibu]

No, because it only logs those with also magma on it.

Anyway, here is a new version that delivers accurate X / Y coordinates in the log (didn't know Toady's maps are actually 2^x + 1 in side length): http://www.geocities.com/qrphome/df_asl_v0.1.zip

I'm currently working on getting the distance between the tiles in, but it's more complicated than I thought...

[ April 20, 2008: Message edited by: zagibu ]

[Shamasu]

That's a great idea. Are you going to let people select what the program is looking for? IE: I want a 4x3 site with magma and underground pool. Is it going to be able to scan multiple worlds? Is it going to be able to generate said world automatically until it finds a given number of possible sites?

[ April 20, 2008: Message edited by: Shamasu ]

[PTTG??]

THEY SAID IT COULDN'T BE DONE! An achievement! YAYYYYYYY!

[zagibu]

This is all theoretically possible, but of course, needs lot of work. My current plan is to make it flexible, so you can select which tiles you want, and to make it incorporate distance between those tiles (no use when magma and adamantine are 10 tiles apart). Then I'd like to make it expand the local map on potential "good" locations, and scan for stone layers (flux and sand mainly). Maybe civilisations, trees, temperature and surroundigs could be useful, too, but I'm not sure it's worth the work.
Ultimately, the tool would be extensible, to look for any feature, but that would probably mean a complete redesign of the current code. Maybe someone not as lazy as I could do it...the ingredients are all there in my script.

[Goblin Dragoon 085]

Less lurking, more influencing this potentially most awesome tool is what brings me here.

So first of all: A big thank you!

I know, it is not polite to just tell someone how I feel that their work should be like, but I am doing it anyway and hope you might consider using the good parts of my idea/vision and combine them with yours to make this tool even better.

Currently you have a autiit script, that screenshots every region. Then this screenshot is analyzed send through a filter and a logfile created naming every region that passed the filter..

May I suggest splitting the whole thing into two applications/scripts.
One, that does the screenshotting and logging and one that filters the locations.

What I have in mind, is that script one works like this:
(you have to change the embark rectangle to maximum for this to work)
Script screenshots region once.
Checks if the embark option is availabe! (It grays out when its not, so this should work just as the rest of the pixel detection.)
If not available, skip to next region.
If available, check for site features and write them down, together with their corresponding coordinates, inside the region. (site features includes everything revealed by regional prospector)
Press F1 to show the first biodome
screenshot ,check the layers, aquafire, tree count, brook etc. Just basically check everything thats one the right site of the screen.
Repeat for every other biodome.

Once region is finished, move on to next and repeat.

Output would then looks something like this:

x1y1 mpipe0a0b0 mpoola2b1 ada0a0b0 ... ... bio1 aquafier1 "Sandy Loam" "Silt" "Obsidian" "Scary" "Trees Scare"...

So, what does the output tell us?
Region has the coorinates 1 1. There is no magma pipe, but a magma pool on the 2nd from the left, first from top field. No adamantine. ... ... Biodome 1 consists of sandy loam, silt and obsidian. There is an aquafier and its a scary biodome with a few trees.

As you can see, I basically want to copy all important data from the world. In fact, I want to copy the world map into a format, readable by another program!

Part two would be of course the program that filters the output and is very userfriendly. A small window, where we can set the following for every site feature (adamantine, chasm, magma pool, river, brook, underground cave, magma pipe, aquafier etc)

Require (If a region does not have it, it wont show the region to us)
Do not want (If a region has it, it wont show the region to us)
Bonus [number] If the region has this feature, a number of bonus points will be added. Found regions can later be sorted according to the number of bonus points they have.

Then additional site feature options:
Most have any scource of mamga! This overrides the pool/pipe search and just looks if either of the two, or both are present.  
Most have any underground water source. Either cave river/lake or both.
Must have any infinte water source. Either brook/river/underground river/aquafier or any combination.
----------------------------------
Then an option to look for specific stone layers!  
Some as above should apply:
Require
do not want
bonus.

Additional options:
Any flux
Any sand
----------------------------------
filters for trees, surroundings etc.

Because the whole process would be split into two aplications I can simply analyze the world map and then alter apply any filter I like, instead of having the filters integrated ito the analyzing tool.

Puh, good luck with this great tool and I hope that we can see a new version very soon. Good work so far.

[Tacroy]

A user named Ziusudra made something that, I think, was exactly like this except he released it about half a week before 0x517A5D released his Regional Prospector, and thus they were not compatible.

Just fyi.

[ April 22, 2008: Message edited by: Tacroy ]

[zagibu]

Thanks for your input. One big problem with your suggestions, Goblin Dragoon, is that DF has a lower limit on key response times. Enlarging the starting rectangle in every locale will take a lot of time (several seconds per locale). The tool is already slow enough...it takes around 3 hours to scan a 256x256 map on my computer. So I will only do a more elaborate scan, if a locale contains at least magma and adamantine. There are still hundreds of such spots, so it might increase the duration to 4 or 5 hours...

Tacroy's post reminded me, that this tool is dependent on regional prospector. I didn't think about it much, yet, but it could become a problem. If regional prospector stops working for a new version of DF, my tool will be useless.

[Goblin Dragoon 085]

Well, I actually meant to tell the player, to increase the starting rectangle in the init.txt.

[EMBARK_RECTANGLE:x:y]

And yes, it already takes some time to run, but if you allowed it for smaller maps and split it, as suggested, into 2 applications you only have to analyse the map once. And then the search for a suited location can be done as often as one likes and most importantly: extremely quick.

My guess is, judging from the speed of the current tool, that it would take roughly 12hours to completely analyse a 257x257 map. This includes site features, environment and stone layers.

Come to think of it: You can most likely save alot of time, if you check for embarkability first. If you cannot embark in a region, then there is little reason to analyse it further. It might be even worth doing in its current state, mainly because most site features are located in mauntain regions you cannot embark in.

Small question: is changing: $map_size = 257 into 17 enough to make it analyse pocket maps sucesfully, or am I missing something?

[zagibu]

Hmm, very interesting, didn't know about the embark-rectangle init setting. I see where you are going now, and I have to agree, that designed after your suggestions, the tool would be much more useful. It would indeed be very close to a direct analysis of the world.dat file. Just slower, of course.

I'm not sure if I have the patience to do that, though. What I certainly will do is make the tool useful in the originally planned way, because I'm almost there. What comes after...only Moebius knows.

Enlarging the map size should be enough, yes. I haven't tested it, but it's designed this way.

[Edit]
Enlarging the embark rectangle doesn't work consistently. I've set it to 16:16, but it's not the whole local map on many world tiles, and it cannot be moved at all...

[Edit 2]
Seems to be a bug.

[ April 22, 2008: Message edited by: zagibu ]

[Goblin Dragoon 085]

You are right, setting it to 16x16 is kinda strange.

But setting it to 15x15 seems to work consistently, except for regions you cannot embark in (and those are of no interest anyway). I really ought to look up on known bugs, whether the embark rectangle set to 16x16 acting up is there. In the meantime, working with 15x15 might not be perfect, but should be sufficient enough to get 999 out of 1000 biodomes  

[Derakon]

This is the program I was wanting to make, except my approach involved parsing world.dat directly (can't use Regional Prospector as I'm on a Mac) and I never managed to get it into a state that I could actually read. Oh, well.