Print

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

[joelpt]

Hi folks, here's the next release of Quickfort.

This version has incorporated many suggestions received since 2.00 release, as well as some optimization and polish work.

Download Quickfort 2.01
Online user manual
Issue tracker

What's New in v2.01:

• Added Alt+N "save named macro" function to QF GUI (Root Infinity)
• Set keys used by QF GUI for DF macro playback via options.txt (kurzedmetal)
• Macros produced by Alt+D will now be added to the bottom of DF's Ctrl-L list instead of the top, and include helpful titles
• Single-line QF command support for qfconvert.py via --command="dig d,d#d,d"
• Found that DF 0.31.25 will stop playing back any macro if you move your mouse pointer off the DF window (including ONTO Quickfort's mouse-tip). Warnings added to troubleshooting section and the QF GUI on-playback mousetip.
• qfconvert.py/exe will now find its config/ files regardless of working dir
• 2d/2u style z-repetitions are now performed after plotting/routing rather than beforehand; greatly improves speed of e.g. Alt+T->x(100x100), Alt+R->100d
• DF cursor is no longer returned to the starting z-level after a multi-z-level blueprint playback; that behavior was unintuitive
• Macro playback started faster (removed delays between ^L {Up} {Enter} ^P)
• QF GUI mousetip positioning tweaked
• readme.txt improvements (Thundercraft)
• blueprints/Tests/*.csv cleanup (Thundercraft) and a couple new ones
• Removed unused KeyExitMenu option from config/options.txt; this can now be configured in config/keys.json

I'll probably take a short break from QF coding here. The 2.02 release has two main tasks slated for it: the Modular blueprints and doing some Youtube tutorial/documentation videos for QF2, especially covering some of the newer stuff e.g. advanced transforms. 

I think I'll probably start on the Modular blueprints in the next week and I'll probably post the first few blueprints I put together for you folks to review, prior to 2.02 release.

2.03 has some interesting features slated for it. Some of these may end up on the cutting room floor, but we'll see. I may post a forum poll to see what new features QF users are most interested in seeing.

[Dr. Hieronymous Alloy]

Any special tricks on adapting this for use with large scale constructions, rather than digs? I want to build a spiral-staircase tower out of ice, but designating each floor could be a real pain.

[joelpt]

Any special tricks on adapting this for use with large scale constructions, rather than digs? I want to build a spiral-staircase tower out of ice, but designating each floor could be a real pain.

I don't think there's a whole lot we can do at this point, because of how DF only lets you designate a construction when there's something on the z-level below.

Really, the best fix would be for DF to actually permit construction designation when there's only a *designation* of wall/stairs on the z-level below, rather than requiring something be already built by dwarves below. This would enable us to designate entire towers (or at least scaffolding) bottom-up.

Failing that, conceivably we could write some AHK script to perform a "designate a tower z-level; unpause for a fixed amount of time to let dwarves build; designate next z-level" loop for you. But since unpausing requires exiting the designate menu, we would lose our DF cursor position. This could be accommodated for by first requiring the user to move the cursor to the top-left corner of the map, then monitoring the movement keys they use to position the cursor to their desired start point. Those cursor movements could then be replicated before each designation step.

Which is a rather ugly solution IMHO, though it would work.


Perhaps I should lobby Toady for getting a few changes to DF for the benefit of DF macroing tools, such as the aforementioned "permit predesignation" idea for towers. Another would be to allow lever/pressureplate target-selection to be done via cursor movement & map selection, rather than choosing from an unpredictably-ordered side menu.

These two changes alone would dramatically increase the possibilities of what could be blueprinted in QF. A fully functional boolean calculator in the shape of a pyramid? Yes!

[joelpt]

What do you guys think about this post embark workshop blueprint? It is 11x11 ("Modular" size), but makes no accommodation for walls/edges, assuming that this will be deployed on the surface just after embark as a temporary base of operations, until your actual fort entrance is ready.

Code: [Select]

"#build Post-embark surface workshops: 3 mason's, 2 mechanic's, 2 carpenter's, 1 craftsdwarf's, and 1 bowyer.",,,,,,,,,,,
wm,wm,wm,``,wm,wm,wm,``,wm,wm,wm,#
wm,wm,wm,``,wm,wm,wm,``,wm,wm,wm,#
wm,wm,wm,``,wm,wm,wm,``,wm,wm,wm,#
``,``,``,``,``,``,``,``,``,``,``,#
wt,wt,wt,``,wr,wr,wr,``,wt,wt,wt,#
wt,wt,wt,``,wr,wr,wr,``,wt,wt,wt,#
wt,wt,wt,``,wr,wr,wr,``,wt,wt,wt,#
``,``,``,``,``,``,``,``,``,``,``,#
wc,wc,wc,``,wb,wb,wb,``,wc,wc,wc,#
wc,wc,wc,``,wb,wb,wb,``,wc,wc,wc,#
wc,wc,wc,``,wb,wb,wb,``,wc,wc,wc,#
#,#,#,#,#,#,#,#,#,#,#,#


Code: [Select]

#place Small stockpiles of wood and stone to feed your post-embark workshops.,,,,,,,,,,,
`,`,`,s,`,`,`,s,`,`,`,#
`,`,`,s,`,`,`,s,`,`,`,#
`,`,`,s,`,`,`,s,`,`,`,#
s,s,s,s,s,s,s,s,s,s,s,#
`,`,`,s,`,`,`,s,`,`,`,#
`,`,`,s,`,`,`,s,`,`,`,#
`,`,`,s,`,`,`,s,`,`,`,#
w,w,w,w,w,w,w,w,w,w,w,#
`,`,`,w,`,`,`,w,`,`,`,#
`,`,`,w,`,`,`,w,`,`,`,#
`,`,`,w,`,`,`,w,`,`,`,#
#,#,#,#,#,#,#,#,#,#,#,#


[joelpt]

I've been working on the 11x11 Modular blueprints. In doing so I'm finding out just how little I know about DF!

Are doors important? I often try to create rooms with defined walls and doors, but other than for specific uses (moodable workshops, fluid containment, etc.) is it worth the space (and doors) used?

If doors/walls aren't really worth using in the general sense, I think many of the Modular 11x11 blueprints will end up with a #dig layer that's completely dug out:

Code: [Select]

>.........>
...........
...........
...........
...........
...........
...........
...........
...........
...........
>.........>

Even something like a 3x3-bedrooms-grid layout could be done without any walls or doors.

How would having a large, many-z-level fort that is almost entirely dug-out affect FPS?

[jfsh]

Any special tricks on adapting this for use with large scale constructions, rather than digs? I want to build a spiral-staircase tower out of ice, but designating each floor could be a real pain.

I don't think there's a whole lot we can do at this point, because of how DF only lets you designate a construction when there's something on the z-level below.

Really, the best fix would be for DF to actually permit construction designation when there's only a *designation* of wall/stairs on the z-level below, rather than requiring something be already built by dwarves below. This would enable us to designate entire towers (or at least scaffolding) bottom-up.

Failing that, conceivably we could write some AHK script to perform a "designate a tower z-level; unpause for a fixed amount of time to let dwarves build; designate next z-level" loop for you. But since unpausing requires exiting the designate menu, we would lose our DF cursor position. This could be accommodated for by first requiring the user to move the cursor to the top-left corner of the map, then monitoring the movement keys they use to position the cursor to their desired start point. Those cursor movements could then be replicated before each designation step.

Which is a rather ugly solution IMHO, though it would work.


Perhaps I should lobby Toady for getting a few changes to DF for the benefit of DF macroing tools, such as the aforementioned "permit predesignation" idea for towers. Another would be to allow lever/pressureplate target-selection to be done via cursor movement & map selection, rather than choosing from an unpredictably-ordered side menu.

These two changes alone would dramatically increase the possibilities of what could be blueprinted in QF. A fully functional boolean calculator in the shape of a pyramid? Yes!

One more I would add: "use last material" or something similar.  Would allow you to build all your constructions out of one material easily - pretty much my dream.

[joelpt]

One more I would add: "use last material" or something similar.  Would allow you to build all your constructions out of one material easily - pretty much my dream.

Great idea.

[Draco18s]

One more I would add: "use last material" or something similar.  Would allow you to build all your constructions out of one material easily - pretty much my dream.

Great idea.

That's tricky to do for a macro program, as it has to do OCR on the materials list and find the "last one" you used.

There was a program (...DFWall?) that did that, though.

[jfsh]

One more I would add: "use last material" or something similar.  Would allow you to build all your constructions out of one material easily - pretty much my dream.

Great idea.

That's tricky to do for a macro program, as it has to do OCR on the materials list and find the "last one" you used.

There was a program (...DFWall?) that did that, though.

This would be on Toady's end, e.g. hit "m" (or whatever) on the construction screen to use the last material selected.  So, if you wanted to build a tower made of ice, you would just build a wall somewhere with ice, and then Quickfort would just hit "m" each time to pick ice.  Frankly, it would be incredibly helpful even for constructing by hand.

[joelpt]

One more I would add: "use last material" or something similar.  Would allow you to build all your constructions out of one material easily - pretty much my dream.

Great idea.

That's tricky to do for a macro program, as it has to do OCR on the materials list and find the "last one" you used.

There was a program (...DFWall?) that did that, though.

Well, I've just written a proof-of-concept prototype of this functionality in AHK, and it works! Windows only of course. jfsh's suggestion finally crystallized my idea of how this could/should be tackled in Quickfort.

Draco is right, it requires some kind of screen reading to work. The approach I took works like this:

The first time we enter a material selection menu, memorize the user's choice of material:
1. User uses +-/* keys to highlight the desired material in DF
2. User clicks on the highlighted item's *background* in DF (which is a unique color compared to the unhighlighted items)
3. From the user's click, QF searches UPWARDS onscreen for contiguous pixels of the same color, to the top edge of the highlight-background
4. DF then repeats the pixel-search process to locate the top-left, top-right, and bottom-right corners of the highlight-background
5. At this point we know the four corners of the user's highlighted mat selection
6. Take a screen clipping of the highlighted mat-selection, call it matclip.bmp

Now, when QF needs to select mats again later in the same blueprint, it will:
1. Use AHK's ImageSearch function to try and locate the matclip.bmp image in the DF window
2. If found, it means the correct material is currently highlighted, so build with it
3. If not found, send the + key to DF to highlight the next material in the list and repeat the ImageSearch (loop back to step 1), probably up to 20 times or so
4. If still not found, we could prompt the user with a yes/no box: "Cannot find material. Select a different material or cancel playback?" and act accordingly.

That's the basic operation. While it's a little klunky to require the user to both keyboard-select AND (carefully) click on their desired material, the benefit is that this method should work with any DF version, using any tileset, using any color scheme, at (nearly) any zoom level. Without the user's mat-mouse-click to go on, it becomes a much trickier task.

I haven't wired any of this up to actual QF2 code yet, but my prototype for memorizing and later selecting for a specific material does work.


I'm considering a blueprint syntax that looks like this:

Code: [Select]

#build U-shaped
Cw:1,Cw:2,Cw:1,#
Cw:1,Cw:2,Cw:1,#
Cw:1,Cw:1,Cw:1,#

The Cw:1, Cw:2 syntax would tell QF we want to use manual material selection during playback, and support multiple material-selections per blueprint. QF would ask the user to highlight their desired material when it first encounters a unique :# code, and will then use that chosen material for all subsequent cells with the same :# code.

I'll probably just let the user specify anything they like after the : as a label -- Cw:A, Cw:outer, Cw:microcline, etc. QF will present the user with this label when it comes time to do the manual mat selection.

One problem with this approach is that existing blueprints without : syntax won't utilize manual mat-selection, and it would be a pain to retrofit a large number of blueprints with it. My idea for addressing this is to support a regex search-and-replace function in the Alt+R transformation syntax, e.g. Alt+R -> s/Cw/Cw:1/


Also, may I just say AHK is kinda awesome at what it does. Implementing all of the above prototype functionality took about 4 hours and 50 lines of AHK script.  

[Draco18s]

Seems a little expensive.  You should replace that background color with black and then match.  That way if it's visible you have a location and can approximate where in the list it is¹ (hit + to the expected location, run a match again: if it fails, the right item is selected).  If no match is found, hit * to do a page-down and run the match again.

Takes significantly fewer bitmap matches to do, so it should run more quickly than the player could do it themselves.

¹(Match y - Top of List y² ) / Height of the saved clip
²should be able to figure this out, blanking at the moment.

[jfsh]

Holy crap, that's amazing.  Since I'm currently replacing the hallways of my fort with glass, which is INCREDIBLY PAINFUL when you have a 3 second lag to generate the material list each time, followed by 30 seconds of paging slowly through the list trying to find the right material... gimme! 

[joelpt]

Seems a little expensive.  You should replace that background color with black and then match.  That way if it's visible you have a location and can approximate where in the list it is¹ (hit + to the expected location, run a match again: if it fails, the right item is selected).  If no match is found, hit * to do a page-down and run the match again.

Takes significantly fewer bitmap matches to do, so it should run more quickly than the player could do it themselves.

¹(Match y - Top of List y² ) / Height of the saved clip
²should be able to figure this out, blanking at the moment.

That's an interesting idea. The color-replacement stuff would be a little tricky though; consider that we have both foreground and background colors to contend with as well as antialiasing around the edges of the letters.

The current approach, while a bit expensive, is acceptably fast. I made a video showing it in action: http://youtu.be/l5dzw6tDgXc

[joelpt]

Holy crap, that's amazing.  Since I'm currently replacing the hallways of my fort with glass, which is INCREDIBLY PAINFUL when you have a 3 second lag to generate the material list each time, followed by 30 seconds of paging slowly through the list trying to find the right material... gimme! 

Thanks for that note. I will have to compensate for that menu-loading initial lag somehow.

How many pages of materials do you typically see in your large, mature forts' materials list?

[Draco18s]

That's an interesting idea. The color-replacement stuff would be a little tricky though; consider that we have both foreground and background colors to contend with as well as antialiasing around the edges of the letters.

The current approach, while a bit expensive, is acceptably fast. I made a video showing it in action: http://youtu.be/l5dzw6tDgXc

Oh neat.  There are some constraints on the image search, that's good.