Print

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

[Markham]

Of all the utilities created, I have thought (not created) one that would be very useful.  With the number of programmers here, I imagine someone can make it work.

Here's what it would do:
1. In the area selection screen of the embark menu, it navigates the cursor to the upper left most corner.
2. The program looks at the terrain on the left panel, checking for any dark red indicating a magma vent on that section of the map.  Since magma is the only thing that uses dark red, you don't have to check for the particular tile's shape.
3. If there is a dark red tile, add the coordinates to a list.
4. Move left one.  If the program has already moved left a certain number of times, move down once and shift all the way left.
5.  Goto 2 and repeat until the program has reached the bottom rightmost area.
6.  Export a text file containing coordinates for all magma maps found.  Even better if it can take an exported map and mark all the locations on it.

I can't be the only one who would rather have the computer find potential good locations for me rather spend many hours scouring the embark screen in search of a decent magma location.

[qalnor]

I actually thought about doing this a few weeks ago. I think you could actually do it visually with autohotkey, but I'm not sure, I didn't ever get around to playing around.

[Mechanoid]

I disagree with 4 and 5. It should shift down one, and then deal with the tiles moving right to left. That way it should take half the time, otherwise you'll be passing over the same square twice.
Also, making the program check to see if the regional area isn't totally inaccessable would also be a good idea.

[Having a magma map location utility is definitely a sweet idea though]

[ December 05, 2007: Message edited by: Mechanoid ]

[Nesoo]

I've thought of doing something like this to help me locate volcanoes on the exported world map.

As for this idea, I haven't really done anything involving interacting with another program though, so it's not something I'd have the knowledge to do right now. It doesn't help that I haven't done any programming in a while either, so my C++ is a bit rusty  

[Greenwolf]

I've done some macros with autohotkey before that worked something like this, so it is definitely possible.  Might be more trouble than it's worth though.
I've even tinkered with the idea of creating one supermacro that could run overnight perhaps, that would sort through an entire map and locate all instances of a specific combination of rock layers and visible features in a given area.

It could even go so far as to embark into each site, assign the entire bottom layer to be dug, remove the designation, run reveal.exe, and perform a quick and dirty check for underground cave features.  Then it'd alt-ctrl-del out and continue to the next.  At the end you'd have a list of all possible site that include everything you want.

But unless you create a lot of new sites, it'd be faster to just search around yourself and hope you get lucky, rather than spend many many hours writing such a macromacro.

PS: errr, got carried away... but something that would just search out topside magma vents should be fairly easy, just have to figure out the relative coordinates and color of a pixel that would indicate magma, in each tile of the local map.  Have the macro check each, then scroll to the next square and repeat.  It could move through the map space-invader style till it hit the end.  Any positive matches would output coords to a file.

[ December 06, 2007: Message edited by: Greenwolf ]

[Ziusudra]

My AHK script is in private alpha testing (i.e. me), I'll release it as beta when I squash that last bug and fix another minor thing I just thought of.  (After I get home from work, hopefully.  And a couple of interface tweaks.)

It currently only finds magma, takes 2-3 hours during which you can't use the computer for anything else (the DF window has to remain active) and still leaves you with hundreds of locations to scout.  While all you Armoks beta test it, I'll work on looking for other features when magma is found to narrow the list.

Brooks and Streams will be easy and should add less than five minutes to the total search time. Sand, aquifers and layer types will be more complex but doable and might add 15-30 minutes.  I want to add checks for mountains and trees but those could be really complex and I'll guess 20-40 minutes.  All told I'd say the total time could increase 30-90 minutes.  Once I get all those feature checks in I might add a function to set options to skip checks.

It also includes a function to go to a coordinate.  That way you don't have to count your key presses to check out that magma in region 198,245.

Interesting note on that, my coordinates start at 0,0 which if the wiki were correct that there are 256x256 regions would mean the region in the lower right corner would be 255,255.  But that region is 256,256 meaning there are actually 257x257=66,049 regions and 38,957,285,376 total tiles (not 38,654,705,664.)

Edit: Oh, yeah, got to add an embark check, that'll be next, thanks Mechanoid.

[ December 10, 2007: Message edited by: Ziusudra ]

[Scorpios]

quote:Originally posted by Ziusudra:
<STRONG>It currently only finds magma, takes 2-3 hours during which you can't use the computer for anything else (the DF window has to remain active) and still leaves you with hundreds of locations to scout.</STRONG>

You can't even toggle it to non-fullscreen and have it run in the background?

[Ziusudra]

Actually, it doesn't work in full screen mode, though I think it could with work.

It currently only works in windowed default, 640x300 text mode with default colors.

A limitation of AutoHotKey is that DF has to be the active window at all times.  Welcome to the world of macro-gaming.

The script is next to useless right now anyway, since it would take you longer to look at each magma vent it finds than it takes to find them.  At some point, I'm going to try to add a pause and resume capability, I'm pretty sure that's possible.

If anyone would like to play with 0.1 you can find it here.  There's the script, a compiled .exe file, and some .bmp files used to find stuff.  Just unzip any where and run the .exe file.  At the Choose Fortress Location screen, press f to start the search or g to go to a coordinate, enter the X in the first window, the Y in the second (there's something else to fix.)  The coordinates will be output to log.txt in the script's folder.

Edit: When the script is running there will be a tray icon for it, you can control it from there.  Like if you don't enter anything for the go coordinates and it gets stuck in a loop sending '3' to DF.

[ December 11, 2007: Message edited by: Ziusudra ]

[Flame11235]

Would it be faster if it scanned the exported BMP for the magma tile instead of the DF game window?

[Merlon]

The exported map is on the regional level, not local. Only volcanoes would show up.

As for speeding it up, surely this would be something for the memoryfetching programmers around here? I realize it must be no small task, but it must be so much speedier to ask the game if there's magma, than trying to tell a computer to scan for it visually.

If memoryhacking is out of the question I recon the visual scanning program could be sped up if it only scanned tiles with a dark mineral layer (obsidian etc). They form around vents, and no vent is without them. So, if the program first checks for them and only continues scanning manually for magma if one is found. That should speed things up.

[Ziusudra]

quote:Originally posted by Merlon:
<STRONG>If memoryhacking is out of the question I recon the visual scanning program could be sped up if it only scanned tiles with a dark mineral layer (obsidian etc). They form around vents, and no vent is without them. So, if the program first checks for them and only continues scanning manually for magma if one is found. That should speed things up.</STRONG>

Oh hell no, visually scanning for dark layers would be much slower as you would have to maximize the selection area and step through the different biomes.  Even if you just looked at the biome displayed by default it would be just as slow, maybe a few milliseconds faster.  But even if you saved 10ms x 66049 regions you'd save a grand total of 12 seconds.

As it is, the script spends 75-80% of it's time waiting for the DF window to update.  The AHK image and pixel scanning is quite fast.  I've tried both and it comes down to needing the 'Sleep 100' line for the scan to be accurate.

Yeah, the only way to do it faster would be to hook into the API, memory poking or just load up the world files in a separate program.  I figure that would be 80-90% faster, depending on the computer, 10-20 minutes, 30 tops.  About as long as the script would take without the waiting.  

[ December 11, 2007: Message edited by: Ziusudra ]

[Erasmus Darwin]

quote:Originally posted by Merlon:
<STRONG>As for speeding it up, surely this would be something for the memoryfetching programmers around here? I realize it must be no small task, but it must be so much speedier to ask the game if there's magma, than trying to tell a computer to scan for it visually.</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.

[Ziusudra]

Hmm, even if a program could examine each tile in 50ms, 38,957,285,376 tiles would take over 61 years.  There'd have to be some serious parallelism going on.  And searching or indexing the resultant data...

Lets see, the map I'm testing has 533 magma vents, if we assume an average of 500 per map that gets us down to 171 days.  Some of those 500 aren't embarkable and many more probably don't have mountain biomes which is where the Hidden Fun Stuff is hidden.  But even narrow it down to 100 regions and you're looking at 35 days or about 8 hours with 100 threads.

And you'd still have to index and search data for 58,982,400 tiles.

[Erasmus Darwin]

quote:Originally posted by Ziusudra:
<STRONG>Hmm, even if a program could examine each tile in 50ms, 38,957,285,376 tiles would take over 61 years.  There'd have to be some serious parallelism going on.  And searching or indexing the resultant data...</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.

[xzzy]

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.

Memory editing and macro programs get your foot in the door, but are limited by what the game wants to show you.