Looks like the Mayday Pack.
Anyway, this sounds like a great tool for designing large, spiral staircases (man I love those things).
sun2design.com is safe for work, right? I only ask because there have been utilities available on NSFW sites, like the site finder (at least that's what the wiki said about its site. Took its word for it and was too paranoid to verify).
Anyway, this sounds like a great tool for designing large, spiral staircases (man I love those things).Check out the screw pump tower examples. Should be doable with a multilevel blueprint and QF's repeat function.
Anyway, this sounds like a great tool for designing large, spiral staircases (man I love those things).Check out the screw pump tower examples. Should be doable with a multilevel blueprint and QF's repeat function.
sun2design.com is totally SFW.
The graphics set is from the Mayday pack from http://mayday.w.staszic.waw.pl/df.php. I then replaced the character set in Mayday with this one http://dwarf.lendemaindeveille.com/images/3/3c/Belal_Smooth_Walls.png
Hmm, having a bit of trouble with the Quickfort tool, the shapes aren't working right in the digger (neither mine nor the examples). Does it matter what the key bindings are? I'm using the latest and greatest of Mayday's tileset, but I don't think the bindings are changed at all.The key bindings should be at the DF defaults.
I thought those walls looked familiar, I don't know why you are getting lineup issues though on some of your walls, I thought I had all of them fixed, does it look like that in game as well?Not sure what you're referring to with lineup issues. Can you be more specific?
Someone wanted a video of it in action; here you go (http://www.youtube.com/watch?v=Bk47h864sWw). I haven't bothered explaining how to use it, cos the readme does all that for you. Here are the steps I used to create it, anyway:Nice :) Thanks for doing that.
Couple of bugs or suggestions for improvement, though - running the game in windowed mode, the tooltip doesn't display very well. It flickers like a mofo and disappears if you leave the mouse still.Interesting. I'd had a similar problem during initial coding but had accommodated for that. The tooltip doesn't flicker here.
Also the tooltip seems to vanish completely once you've finished executing a script. Quickfort's still open and still works fine, but the tooltip with the instructions has vanished.Yeah that was kind of by design - I figured you don't necessarily want the tooltip showing all the time "in between" QF runs. Instead I put some instructions in the "run completed" popup box.
Other than that, HOLY CHRIST THIS IS THE BEST THING THAT HAS EVER HAPPENED TO THIS GAME.8)
I fixed that problem with the description before I published it, but youtube takes its sweet time getting updates down the pipe :(Haha :)
If the tip is above a window other than the DF window, does it still flicker?Nope, not even other stuff using the overlay like windows media player.
I'm using a Geforce 9800GT with the latest drivers and WinXP if that makes any difference.I'll try running it on my girlfriend's XP box later which has an 8800GT in it.
One request for an additional feature, too - being able to assign a start point in the file. The % character or something. You'd just need to add commands to get from the % to your corner of choice before you started printing.Good idea. Look for it in the next version.
I say this because for designs like the one in the film, you want to start with the cursor in the centre rather than a corner (trying to line it up with a set of stairs you've dug down would be a bit of a chore, otherwise).
Someone wanted a video of it in action; here you go (http://www.youtube.com/watch?v=Bk47h864sWw). I haven't bothered explaining how to use it, cos the readme does all that for you. Here are the steps I used to create it, anyway:Nice :) Thanks for doing that.
Note I'm the creator (joelpt) rather than Jhoosier (according to the video's description). I think you probably got Jhoosier because the forum link in the video's description goes to the second page of this thread.
Here are some files I've made with this; I was bored with revision :PTry putting your example within [ code ] and [ /code ] tags (minus the spaces):
#dig
d,d,d
d,i,d
d,d,d
Try putting your example within [ code ] and [ /code ] tags (minus the spaces):Code: [Select]#dig
d,d,d
d,i,d
d,d,d
Makes em a little more 'readable'.
Try putting your example within [ code ] and [ /code ] tags... makes em a little more 'readable'.Not really; I tried that first, but rows with empty cells go all out of alignment anyway. It looks just as jumbled inside code as inside spoiler, and I decided I'd rather take up less vertical space ;)
But to made all of the spaces, it's necessary to have the commas, no? If there were an easy way to upload the spreadsheet version, it would be easier on the eyes. Until then, I guess we're just going to have to post grids or screenshots of the plans.I think he means spaces made by hitting the space bar. Either way, the code tags are a forum thing. They line up all the letters and punctuation onto a grid so that it looks like those characters would in an ASCII art game. They also make it easier to select and copy the text.
BTW - I take it you're linking the AHK source in??Yep. Though the quickfort.ahk source file is included.
Here ya go
http://mayday.w.staszic.waw.pl/~mayday/upload/DFG18.zip
#dig These are for a spiral taircase 15 spaces across. The two floors shown are for the two different layouts that make the sequence work properly. Produces a double helix.
,,,ddddddddd,,,#
,,ddddddddddd,,#
,ddddddddddddd,#
,ddddddddddddd,#
ddddddddddddddd#
sssssdddddddddd#
rrrrrdddddrrrrr#
ddddddddddsssss#
ddddddddddddddd#
,ddddddddddddd,#
,ddddddddddddd,#
,,ddddddddddd,,#
,,,ddddddddd,,,#
,,,,,ddddd,,,,,#
#>##############
,,,,,ddrsd,,,,,#
,,,ddddrsddd,,,#
,,dddddrsdddd,,#
,ddddddrsddddd,#
,ddddddrsddddd,#
ddddddddddddddd#
ddddddddddddddd#
ddddddddddddddd#
ddddddddddddddd#
ddddddddddddddd#
,dddddsrdddddd,#
,dddddsrdddddd,#
,,ddddsrddddd,,#
,,,dddsrdddd,,,#
,,,,,dsrdd,,,,,#
################
Oh, I had used excel. I just copied it. Thanks though, that probably is causing some of the problems. There still is the issue with the files that came with it, though.
1.02 (2009 June 3)
* Start position can now be specified in CSV file. See readme.txt for further
details. Examples/Buketgeshud updated. (Xinael)
* Quickfort's tooltip now stays up all the time, but you can optionally hide it
when not in placement or playback modes with the Alt+H hotkey (Xinael)
* The 'macro completed' popup has been removed in favor of the permanent tooltip
* Leading or trailing spaces within cells should no longer cause problems (LegoLord)
* Possible fix for flickering tooltip problem (Xinael)
* Possible speed improvement for 40d11/Mayday users (Xinael, Jhoosier)
* Z-level up/down default keybindings changed to Shift+5/Ctrl+5 for better
compatibility (Jhoosier)
* Quickfort now emits a sound on playback completion (mutable in options.txt)
* New examples Examples/Tests/starting-location.csv and Examples/General/spiral-staircase.csv
1.03 (2009 June 7)
* start() position can now be overriden with Alt+Q/W/A/S.
* New option ShowOutOfWindowTooltip
ControlSend,, [Keys go here] ,Dwarf Fortress
I remember at some point there was a utility that edits DF memory to just set the necessary tiles as designated. It was almost instant. Does anyone know what happened to that?That was my auto-designation macro version 2.0. It was based off of Dwarf Companion, and updates to DF broke it. I tried unsuccessfully to fix it, but DC's tile edit API remained subtly broken. I think bartavelle is waiting for the next full DF release to update DC, so I'll try again when that happens.
Been trying this out, and I'm having trouble. It looks like the program is skipping keystrokes. I'll try playing with the keypress duration and Delay multiplier some more, see if that helps. I'm working with Mayday version 18, on a (somewhat slow) laptop.
@Vengeful Donut:
I converted the images to #dig templates and put them up on the sharing site with a couple others in a "template pack".
#dig
d,d,d,,d,d,d,,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",#
d,d,d,,d,d,d,,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",#
d,d,d,,d,d,d,,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",#
,d,,,,d,,,,d,"
",,,d,"
",,,d,"
",,,d,"
",,,d,"
",,,d,"
",,,d,"
",,,d,"
",#
,d,d,d,d,d,d,d,d,d,"d
",d,d,d,"d
",d,d,d,"d
",i,d,d,"d
",d,d,d,"d
",d,d,d,"d
",d,d,d,"d
",d,d,d,"d
",#
,d,,,,d,,,,d,"
",,,d,"
",,,d,"
",,,d,"
",,,d,"
",,,d,"
",,,d,"
",,,d,"
",#
d,d,d,,d,d,d,,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",#
d,d,d,,d,d,d,,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",#
d,d,d,,d,d,d,,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",,d,d,"d
",#
#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#Looks nice, I'm gonna try this out. Too bad there's no way to specify floor tiles/colors.
joelpt: what graphics set are you using? And where can I get it?
I've got a problem with the blueprints from http://drop.io/quickfort#list/sort_by_name/order_by_asc/180 everytime I start quickfort and let it build something it moves some colums tiles away. at first i thought that it was a problem with the blueprints but it happens with nearly every blueprint.Maybe someone can help me.Spoiler (click to show/hide)
Excuse me gents, but could someone please be so kind as to make a quickfort-compatible version of this? I mean if it wouldn't be too much trouble for you..
Building 1Building 2Spoiler (click to show/hide)Building 3Spoiler (click to show/hide)Spoiler (click to show/hide)
And this bedroom/dining room complexSpoiler (click to show/hide)
Just wondering if you can fill this request. I'll change the images to blueprints.
I have just tried my hand at this, but it goed straight towards the recording menu in DF, I thought it might be an error in my created csv, but I cannot find errors. I would appreciate help a lot.Maybe I did something wrong? (I started the file while in dig mode, cursor at the wanted location.)
Below is a link to the living pods I copied from the wiki, I set it up myself, so it can easily contain errors.
http://drop.io/quickfort/asset/living-pods-debugver-csv
Thanks.
Just wondering if you can fill this request. I'll change the images to blueprints.
Check the Drop.io site. I just uploaded "Jurph's Modular and Fractal Bedrooms Expansion Pack" which includes my Clover dorms, my Whiteoak dorms, and your requested modular rooms. I added a few more variants to your room setup. I named them as follows:
Zero - hallways only / no rooms
One through Four as requested
Hex - six 3x3 rooms with no connection to the exterior
I predict that you'll get the most mileage out of Hex because it's pretty trivial to drop a bunch of Hex rooms in and then manually add doorways where you want them.
Oh man, now I've got to post a .BMP from my mega-dormplex as well. I'll be back in a little bit.
Anyone feel like creating the following files for the masses?
circle-9.bmp
circle-11.bmp
circle-13.bmp
...
circle-33.bmp
Having all of the odd-diameter circles come standard with the program (or better yet, a "draw circle of diameter X" function) would be incredibly useful.
1.05 (2009 July 1)
* Big improvements to playback performance and reliability! Please update your options.txt.
* ControlSend send mode now makes window switching during playback possible (Valdemar);
note pressing Alt/Ctrl/Shift/Win keys can still mess up playback sometimes
* DisableSafetyAbort now set by default since window switching is possible
* "Switch to DF window" mousetip now only shows once per run of QF
1.04 (2009 June 9)
* Added diagonal cursor movement optimization
* Fixed start() data from one blueprint carrying over to a subsequent blueprint w/o start()
I love quickfort, but couldn't you make an easier way to make blueprints? I hate using Excel cause the letters aren't perfect. The boxes are rectangular and end up confusing you, cause it makes gaps.
I'd love if you made some sort of GUI where you just Click in, or dig in (like in DF with the keyboard) the blueprint, then save it. It saves having to do all that annoying key pressing in Excel, just to find out you missed a few spots.Yeah that would be really cool, but it would be a lot of work, particularly if you wanted to represent all the different building phases. At this time though, I find Excel to be quite effective with the use of the aforementioned macro and other Excel tips (see readme.txt).
EDITED TO ADD: can whoever moderates the drop.io kill the earlier versions? I had the "dig" and "not-dig" inverted. Oof.
Since you mentioned D12, I thought I might suggest taking a look at the macro capabilities being added to DF. The definition tags for them in the interface.txt is finialized as of D12. The only macro specific change I have planned for D13 is to lower the repeat maximum from 1000 to 255. It might be a nice addition to your utility to make it able to create the macro tags that a user could paste into the interface.txt.I was thinking about that too. QF already has a sort-of approximation of macros via its Alt+T 'command prompt' and aliases. But it would be much nicer to have it run natively in DF.
Though why are you lowering the repeat maximum? If anything, an increase (or even removing any practical maximum) would seem preferable from my perspective; this could enable players to stick their most used QF blueprints into DF macros regardless of size.
1.06 (2009 July 3)
* Fix KeyUpZ/KeyDownZ not working right when using ControlSend mode; QF will now
simply switch to the DF window and send these keystrokes using SendInput as needed
What do you all think of including some of these contributions to the drop.io site in the Examples/ folder of future releases? I'm thinking stuff like the common shapes would be nice to have included.
That'd be great. I think I'll look at the next version for potential inclusion of these common blueprints.What do you all think of including some of these contributions to the drop.io site in the Examples/ folder of future releases? I'm thinking stuff like the common shapes would be nice to have included.
You're welcome to use any of my contributions, and since you're doing the heavy lifting with the code, I'll be happy to chip in more simple shapes for folks who want a library to work from. Maybe a selection of rhombuses (squares tipped on a 45 degree angle) since those currently require line-by-line designation?
1.07 (2009 July 21)
* "Safe" key-sending mode added in 1.06 now uses a slow version of SendPlay
instead of SendInput; safe mode is also now used whenever a modifier key or
capital letter needs to be sent (they don't work w/ ControlSend & SendEvent)
* Improvements to keeping DF window focused and accepting keystrokes
* With these changes Quickfort appears to be fully working on DF 40d-40d13
* Visualization (Alt+V) now returns cursor to where it was beforehand
* "Switch to the DF window" tip now only shown when DF isn't active at QF start
#dig start(2;2;cursor at ud/down stairs)
u,d,u,#
d,i,d,#
j,d,j,#
#>,#
j,d,j,#
d,i,d,#
u,d,u,#
#>,#
u,d,u,#
d,i,d,#
j,d,j,#
#>,#
j,d,j,#
d,i,d,#
u,d,u,#
#>,#
#
I am trying to make a auto-starcase but it messes up on the third floor, just goes to the bottom of the z axis and then does some weird last floor. Any idea's why its wrong?It was a bug in Quickfort. :) I've uploaded a new version that should hopefully take care of this problem -- for good this time :D
1.08 (2009 July 30)
* Yet another fix for safe sending mode; now using Send to send these keys.
* Alt+T will no longer retain start() setting from a previous .csv file
#dig start(2;2;cursor at ud/down stairs)
u,d,u,#
d,i,d,#
j,d,j,#
#>,#
j,d,j,#
d,i,d,#
u,d,u,#
#
Slight 'mistake' I think in the update, there are NO EXAMPLES in it >.< I was wanting the exploritory mining but I guess I need to make one myself for now, but oh well, Thanks for the awsome program for assisting with things such as consistant rooms and whatnot.Woops! Fixed. No new version number, I just fixed the existing zip file already up on the site.
Bumping up something actually brilliant ;D
I would like to see more work on this.
Er, is there still a point to this, since 40d14+ has the capability built in?
One tip for Open Office people--make sure when saving as a CVS to toggle the "Edit filter settings" checkbox. Then, after clicking "Keep current format," highlight the " in the "Text Delimiter" box, and delete it, so nothing (not even a space) is present. This will keep you from having to manually edit/replace out the "s that separate tiles in your spreadsheets.Quickfort should be able to work with "s present in the spreadsheet tiles; it should strip those out before 'playing' your spreadsheet. Let me know if this isn't the case for you.
40d14+ just adds a facility to create keystroke macros of up to 100 chars in length (IIRC).I am not quite sure where you got the idea that there is some size limit on the built in macros. The only limits they have are technical ones like system RAM and OS file size limits. You can make a 4 billion entry macro if you want.
Though DF would first need to support much longer macros, and ideally have the ability to dynamically update its macros from an init file while DF is running.
I am not quite sure where you got the idea that there is some size limit on the built in macros. The only limits they have are technical ones like system RAM and OS file size limits. You can make a 4 billion entry macro if you want.
Macros have been able to be loaded without closing DF since they were first introduced. The Keybindings screen that provides a macro entry system can load and save the interface.txt anytime you want. Probably not the easiest editting method, but that hasn't been the primary focus.
Right; it's just that from the perspective of Quickfort, there's no real benefit to QF sending keystrokes in realtime into a DF macro entry vs. sending directly to the DF game proper. The need for QF to send keys to the DF window in any form is the part of QF most liable to breakage in new DF versions. Being able to dynamically update DF's macros through a file would enable me to do away with this key-sending entirely.
Why would you send keystrokes into the game? All you have to do is edit a text file.
I think there's something you're not getting...
Why would you send keystrokes into the game? All you have to do is edit a text file.
Mainly because Quickfort is designed around an "immediate mode" sort of approach to user interaction. You select the CSV blueprint you want to 'play back' with Quickfort while DF is running. This allows you to select your desired blueprints on the fly (without having to restart DF). Similarly you can create a new CSV blueprint or modify an existing blueprint in another app while DF is running, and then play it back immediately without a DF restart.
As I understand it, this approach is not possible by editing interface.txt; DF would have to be restarted between file edits.
Fortunately, the key-sending approach is now quite reliable on all current versions of DF, so I don't see much need to utilize the built-in macros at this time.I think there's something you're not getting...
It doesn't seem like you have even tried running Quickfort. Perhaps you should do that, then you'd have a clearer understanding of how Quickfort works and what it's useful for.
Right; it's just that from the perspective of Quickfort, there's no real benefit to QF sending keystrokes in realtime into a DF macro entry vs. sending directly to the DF game proper. The need for QF to send keys to the DF window in any form is the part of QF most liable to breakage in new DF versions. Being able to dynamically update DF's macros through a file would enable me to do away with this key-sending entirely.
#Dig DiagExplore
d,,,,,#
,d,,,,#
,,d,,,#
d,,d,,#
,d,,d,#
,,d,,d#
,,,d,,#
,,,,d,#
,,,,,d#
#######d
d
d d d
ddd
dd
ddAs Veroule said above, DF can reread interface.txt without restarting...Aha! That's what I missed. I didn't realize there was an actual 'load' option in the keybindings page.
There's no benefit to doing something that will make the program less prone to breakage and less complicated?
Trouble! :(I don't think I've tried QF specifically with 40d11, but it could be the source of your problem, since I think DF's keyboard input code went through a major rewrite between 40d11 and 40d12 or so (I'm not remembering the specific versions offhand here).
I made a small exploratory mining CSV, like so:
(...)
Trying the examples results in similar mangling.
I'm using 40d11, is that it?
Well, I'll do some experiments with the macro approach in the next while, and see if it can really stand in as an effective replacement for the key-sending method (DFWall-like features notwithstanding).
One thing that I have been wanting to add to Quickfort is DFWall's material-selection capability. I'm not sure this could be accomplished while using DF macros for playback. Thoughts?
On the flip side, DF's macros could pave the way for a cross-platform Quickfort, which would certainly be appreciated by some.
Well, I'll do some experiments with the macro approach in the next while, and see if it can really stand in as an effective replacement for the key-sending method (DFWall-like features notwithstanding).
I'm on Linux, which is why I haven't actually tried Quickfort yet. :P I've been following the thread since it started though, because it looked cool (same with the ultra site-finder). But when the macros got built in I said "oh, sweet! now I don't need to wait for QF" although you're right that it is easier to "draw" the fort than to write a macro from scratch.
I'm hopeful for good results from the experiment. :)
I would suggest just using the default characters for the translation to commands, rather then going to the effort to parse the interface.txt.
I would also suggest that you save the DF macro format as an independent file, and let the user splice it into the interface.txt. They may already have a macro at the number you would use.
I will consider adding a play macro file option for a future version. Such an option would load the file, execute the macro, and keep nothing of it in memory when done.
One thing that I have been wanting to add to Quickfort is DFWall's material-selection capability. I'm not sure this could be accomplished while using DF macros for playback. Thoughts?
One thing that I have been wanting to add to Quickfort is DFWall's material-selection capability. I'm not sure this could be accomplished while using DF macros for playback. Thoughts?
Since the game is paused when you're building anyway, just forbid the stone/materials you don't want used in the construction through the stocks screen? I find it easier to keep your material/wood stockpiles behind doors you can forbid at any time.
One thing that I have been wanting to add to Quickfort is DFWall's material-selection capability. I'm not sure this could be accomplished while using DF macros for playback. Thoughts?
Since the game is paused when you're building anyway, just forbid the stone/materials you don't want used in the construction through the stocks screen? I find it easier to keep your material/wood stockpiles behind doors you can forbid at any time.
The locked-doors idea is a great one; I hadn't even considered it. I think this is probably a "good enough" substitute for the DFWall approach for the time being, so I won't be focusing on that.
The easiest solution is probably for Quickfort to read DF's interface.txt to discover these bindings. Though that could get a bit tricky since some players run multiple versions of DF on the same box, between which keybindings might vary....uh...that doesn't seem easier at all :-| but then, I don't know your codebase.
The easiest solution is probably for Quickfort to read DF's interface.txt to discover these bindings. Though that could get a bit tricky since some players run multiple versions of DF on the same box, between which keybindings might vary....uh...that doesn't seem easier at all :-| but then, I don't know your codebase.
In the slightly longer term, I am going to be recoding the core CSV-to-keystrokes part of Quickfort as a Python library. It will also support converting CSV blueprints into the new DF macro syntax. This will let both Windows and non-Windows players use Quickfort for their construction efforts.
I'm also going to take a crack at generating more optimized keystroke patterns to generate a given blueprint, instead of just using the simplistic left-to-right, row-by-row approach. This will make digging out a large square room very quick, for instance -- we'll just draw one large region from corner to opposite corner instead of going line by line. It should be an interesting task, and will use some simple pathfinding algorithms to do the job. Which seems only appropriate for a Dwarf Fortress utility :)
Are you talking about something similar to LinDesignator (http://www.bay12games.com/forum/index.php?topic=36928.0) (a cross-platform python library for CSV template-to-keystrokes which can output in the new DF macro format)?
That's very sad...but I looked closer at Quickfort today, and it seems to just be inputting keystrokes. This makes it seem like it may automatically work with the new version...?
I use a keyboard with programmable macro keys, so i tend to use that, but i found if the inputs occour too fast, with a pause less then 10ms between each keystroke, DF can't keep up and you end with it either stopping half way through, or missing a few steps.
Could this be a similar fault?
Weird bug. I'll look into it. Could you post one of your build blueprints that is hanging near the end? (Post to the drop.io site linked in the first post)
Is there any easy way to rotate a design in Quickfort? Working on fractal layouts and it would be immensely easier if I could rotate a group of cells 90 degrees.
Good point. It is done.Could be another use for it, if you think about it. Couldn't somebody take a screenshot of something already made in DF and then use your program to extract a .csv in case they ever wanted to do it again?
In theory, yes... if you don't mind using a 1x1 tileset to take the screenshot.
Remember the program's making a CSV grid of pixels, not tiles.
In theory, yes... if you don't mind using a 1x1 tileset to take the screenshot.
Remember the program's making a CSV grid of pixels, not tiles.
That would work... after lots of raw modding so that all items of a certain type were the same RGB value regardless of what they were made of. ;) Imagine trying to play the game with it configured that way, it'd be even more matrix-y then playing in ascii.
something that takes a screenshot (along with a tileset bitmap) and converts it into something, but I don't know what
little DFD update; DF Designer can export Quickfort plans now, but it's a bit flaky. If anyone can find reliable and important ways to break it, let me know. Also, is 'making the Quickfort export work better' more important than 'making the GUI friendlier'?
Eh I've gottena similar problem as the poster up top, but I think it might be something with 40D17/18. My CSV I made for stripmining has suddenly started to get offset slightly when I use it now.If that's the case, I'm not aware of it. There were some problems with DF 40d17 and 18? not recognizing keystrokes properly if you send too many. It broke one of the dfhack example utils actually - one that used keypress events to set dwarf nicknames and professions.
Does QF use some of the stuff from DFhack? Might need to get the update bits
Eh I've gottena similar problem as the poster up top, but I think it might be something with 40D17/18. My CSV I made for stripmining has suddenly started to get offset slightly when I use it now.If that's the case, I'm not aware of it. There were some problems with DF 40d17 and 18? not recognizing keystrokes properly if you send too many. It broke one of the dfhack example utils actually - one that used keypress events to set dwarf nicknames and professions.
Does QF use some of the stuff from DFhack? Might need to get the update bits
I really like this plan:Look in the QF install folder in /Examples/Buketgeshud/bedrooms-*.csv
(...)
but can't figure out which csv file it is. Can anyone help?
This makes it seem like it may automatically work with the new version...?
Provided that the interface doesn't change (eg, [d] is still "dig up-down stairs").
Just did a quick test with the Linux version of 40d19, and no-go for me. But then, maybe I expect too much from WINE. It keeps telling me to go to the active DF window, while I'm playing.You can't expect a windows application to interface properly with X and whatever window manager you are using. It's hard enough to do this natively - every window manager behaves differently.
Just did a quick test with the Linux version of 40d19, and no-go for me. But then, maybe I expect too much from WINE. It keeps telling me to go to the active DF window, while I'm playing.I'll try QF in WINE in the near future and see if the issues can be squared away. QF's complaining about being in the DF window is just to make sure it doesn't send keys to some other window in Windows; it could be turned off easily. And I suspect at least one of AutoHotKey's key-sending methods may work within the WINE environment.
Hi,
I try to use quickfort, but output is messy - design is different from what i expect, looks like random click
Final output: d{Enter}%6666{Enter}%4441d{Enter}%6666{Enter}%4441d{Enter}%6666{Enter}%4441d{Enter}%6666{Enter}%4441d{Enter}%6666{Enter}%7777
I've just come across IronAHK (http://www.autohotkey.com/forum/topic54494.html) which promises to bring AHK scripts to Linux under Mono/.NET. IronAHK doesn't support all of QF's used functions yet, but once this list (http://www.ironahk.net/docs/developing/status/) goes mostly green, QF should be able to run under Linux natively.Just did a quick test with the Linux version of 40d19, and no-go for me. But then, maybe I expect too much from WINE. It keeps telling me to go to the active DF window, while I'm playing.I'll try QF in WINE in the near future and see if the issues can be squared away. QF's complaining about being in the DF window is just to make sure it doesn't send keys to some other window in Windows; it could be turned off easily. And I suspect at least one of AutoHotKey's key-sending methods may work within the WINE environment.
output looks like this - all moves are like with shift (5 line 41 square in length, 10 square in distance):Hi,
I try to use quickfort, but output is messy - design is different from what i expect, looks like random click
Final output: d{Enter}%6666{Enter}%4441d{Enter}%6666{Enter}%4441d{Enter}%6666{Enter}%4441d{Enter}%6666{Enter}%4441d{Enter}%6666{Enter}%7777
Strange; I ran your sample .csv and it worked for me; it also produced identical final output as what you included in your post.
What OS & DF version are you running?
Try this:
1. Try typing the sequence of keys in "Final output" manually into DF (ignoring % chars and hitting Enter for {Enter}) -- does it dig properly?
2. Assuming #1 worked, try editing your options.txt:
(a) Set DelayMultiplier=10, KeyPressDuration=10; save and retest
(b) Additionally set SendMode=SendPlay;save and retest
(c) Set SendMode to each of the other options (Send, SendEvent, SendInput); save and retest
Most likely one of those options changes should make things work for you.
sorry, no luck with standard plus minus divide keys, output is still the same.
i ran vanilla df 31.03 and vanilla quickfort. also with tips for options.txt, no success.
see here:
http://mkv25.net/dfma/movie-2127-quickfort111incorrectbehaviour
sorry, no luck with standard plus minus divide keys, output is still the same.
i ran vanilla df 31.03 and vanilla quickfort. also with tips for options.txt, no success.
see here:
http://mkv25.net/dfma/movie-2127-quickfort111incorrectbehaviour
Very strange. Well, I'll keep thinking about what else could be involved. I'll try running with Czech locale here and see if I can reproduce the problem. It is definitely acting like the shift key is being held down with the movement keys.
One more thing you could try is changing the KeyLeft, KeyRight, etc. settings in options.txt to use the arrow keys, for example 'KeyRight={Right}'. And set UseDiagonalMoveKeys=0. Maybe that'll circumvent the problem, maybe not.
Haleluja!I don't think there are any alternatives. Maybe you could set those up in interface.txt to match something that works on your system.
I can confirm it works!
now, what are equivalent for 7 9 1 3? {LeftUp} etc?
Linux version?
Does this work with .31.08?
. . . . . . .
. S X X X . .
. . x x x . .
. . x x x . .
. . . . . . .
As you'd move around, the S would change position. This would make it a lot easier to figure out where to start the cursor! I don't know how hard something like this is to do with AutoHotKey, but it sure would be convenient.#build QF1.x style #build QF2.x style
-- -- -- wt wt wt
-- wt -- wt wt wt
-- -- -- wt wt wt
#build QF1.x style #build QF2.x style
ga(3x3)- ga ga ga
-- -- -- ga ga ga
-- -- -- ga ga ga
This can make it a lot easier to visualize the final outcome in your spreadsheet editor. QF1.x style mechanisms will continue to work.*** Quick use guide for 2.00pre2:
***
*** All users: I highly recommend setting [MACRO_MS:0] in your data/init/init.txt
*** for best DF macro playback performance.
*** Windows users: Run Quickfort.exe for the GUI interface
*** Run qfconvert.exe for the command line conversion tool
*** Linux users: Run the command line conversion tool via python:
*** > cd src/qfconvert
*** > python ./qfconvert.py
*** or chmod +x qfconvert.py and run it like a shell script.
*** Example qfconvert command line (Linux):
*** > python ./qfconvert.py myblueprint.xls <DF folder>/data/init/macros/myblueprint.mak
*** ... then play your macro in DF with Ctrl+L, <select macro>, Ctrl+P.
***
1) Segmentation. Break the .csv file into four equal parts (or n parts). For example, NW, NE, SW, SE. Allow the user to quickly toggle any one of the four areas off before the script runs.An interesting idea. QF 2.0 supports Excel sheets which should help with blueprint 'stack' organization. As for DF's FIFO mentality, I've written to Toady asking if he could add support for selecting link targets via cursor selection instead of (or in addition to) the FIFO-ordered menu; haven't heard back yet.
2) Labels. Instead of just "Cx|Cx|Cx" you could have "Cx Inner stairs|Cx Inner Stairs|Cx Inner stairs." Quickfort could read anything after the space as a label, and then when you select a .csv file, just turn on or off whatever labels you don't need.I'll give this some consideration. Now that Excel files are supported in QF2.0, it might be cool to use Excel's cell coloring ability to act as the labels. This would be much nicer to work with than text-labelling cells.
3) Mutation.I've been pondering a substitution style syntax for the Alt+R transformation function in QF2.0 -- something like s/Ts/Tc to turn stonefall traps into cage traps on a blueprint for instance. I suppose that syntax could also be used for your idea -- s/?/> for example. I'd like to include a regex syntax option here also.
4) Browser. This one is probably a bit more difficult than the others, but essentially let the user pop up a mini-display window with a starting location and the nearby designations.Three things:
Repeat with transform: The blueprint repetition functionality has been improved. A few transformations are now supported -- rotcw, rotccw, fliph, flipv. Read the embedded help when pressing Alt+R in QF GUI, or just experiment.
Traceback (most recent call last):
File "/home/rain/.apps/quickfort/src/qfconvert/qfconvert.py", line 83, in run
output = blueprint.process_blueprint_file(infile, options)
File "/home/rain/.apps/quickfort/src/qfconvert/blueprint.py", line 90, in process_blueprint_file
output = convert_keys(keys, options.mode, options.title)
File "/home/rain/.apps/quickfort/src/qfconvert/keystroker.py", line 360, in convert_keys
return '\n'.join(convert_to_macro(keys, title)) + '\n'
File "/home/rain/.apps/quickfort/src/qfconvert/keystroker.py", line 393, in convert_to_macro
"Key '%s' not bound in interface.txt" % key
Exception: Key '0:3' not bound in interface.txt
When I run qfconvert on linux i get this.Found the problem. It was an issue with Windows line-endings in the included interface.txt; Python treated them differently on Linux than on Windows.Code: [Select]Exception: Key '0:3' not bound in interface.txt
I'm not really using Quickfort, yet I've got interested to check another tool ... and it works really sluggy.Interesting approach. In my earlier testing if I sent certain keys too fast DF would miss them. For example, in QF 1.x there is an extra delay added between {Enter} keys because DF would miss keys while working on displaying a menu with a lot of stuff (e.g. a list of all your stone).
The main idea is to flood DF with the keystrokes and then let some time for DF to process all the keys at one time.
sorry bout this necro, but I thought it might be geniunly usefull if it could have a undo thing, read the blueprint, go to the buildings and or designations and just send the delete.Cool idea. I'll think about adding this.
I'll just drop this here...This is pretty cool. Took me a few to work out exactly how it works. It'd be helpful to have the keystrokes associated with the different designation types shown next to the designations. Also, click-and-drag to do large rectangular areas :)
http://www.irritablegourmet.com/dwarf/index.htm
I've downloaded them all from drop.io just now.put it in the page itself, preferably inside a folding area.
I tried to create a place for them on the DF Wiki at df.magmawiki.com and upon uploading, received this error: ".csv" is not a permitted file type. Permitted file types are png, gif, jpg, jpeg, svg.
So unless they can loosen the upload restrictions to allow .csv and .zip (and .xls/x), the Wiki solution won't work. I'm not really finding a contact address on the DF Wiki site and/or don't know where I should be asking about this. Anybody connected into the Wiki admins?
I tried to create a place for them on the DF Wiki at df.magmawiki.com and upon uploading, received this error: ".csv" is not a permitted file type. Permitted file types are png, gif, jpg, jpeg, svg.May I make a suggestion?
So unless they can loosen the upload restrictions to allow .csv and .zip (and .xls/x), the Wiki solution won't work. I'm not really finding a contact address on the DF Wiki site and/or don't know where I should be asking about this. Anybody connected into the Wiki admins?
#dig start(11;11)
,,,,,,d,,,,,,d,,,,,,,,,
,,,,,,d,,,,,,d,,,,,,,,,
,,,,d,,d,,d,,d,,d,,d,,,,,,,
,,,,d,,d,,d,,d,,d,,d,,,,,,,
,,,,d,d,d,d,d,,d,d,d,,d,,d,d,d,,,
,,,,,,d,,,,,,d,d,,,d,,,,,
,,d,d,d,,d,,d,d,d,,d,d,d,d,d,d,d,d,d,
,,,,,d,d,,,,d,,d,,,,d,,,,,
d,d,d,d,d,d,d,d,d,d,d,d,d,,d,,d,d,d,,,
,,,,d,,,,d,d,d,d,d,,d,,,,,,,
,,d,d,d,,d,d,d,d,i,d,d,d,d,,d,d,d,,,
,,,,,,d,,d,d,d,d,d,,,,d,,,,,
,,d,d,d,,d,,d,d,d,d,d,d,d,d,d,d,d,d,d,
,,,,d,,,,d,,d,,,,d,d,,,,,,
d,d,d,d,d,d,d,d,d,,d,d,d,,d,,d,d,d,,,
,,,,d,,,d,d,,,,,,d,,,,,,,
,,d,d,d,,d,,d,d,d,,d,d,d,d,d,,,,,
,,,,,,d,,d,,d,,d,,d,,d,,,,,
,,,,,,d,,d,,d,,d,,d,,d,,,,,
,,,,,,,,d,,,,,,d,,,,,,,
,,,,,,,,d,,,,,,d,,,,,,,
mediafire doesnt like me. =/ it keeps refreshing and fails to start the download. what happen?! my mind is full of <magma> i dont evenHmm. its not working for me, either.
Whats a ramp staircase for?
Win7 64
Is macro meant to be faster? Because "macro" execution takes forever compared to "key" with 2.00pre3 :c
Whats a ramp staircase for?
seems regular stairs take alot more fps then ramps , thats is the main reason.
This have been actually helped my fps...
...it is a good 10 fps [decrease] with regular stairs...
and with ramps it has yet to pass the 1 fps decrease
this is all when starting out a fort of course.
and it is still hitting max fps (150 with me) and hardly any decrease with 40 dwarfs ^^
Win7 64
Is macro meant to be faster? Because "macro" execution takes forever compared to "key" with 2.00pre3 :c
The macro keystroke can be altered in either init or d_init in DF. I forget which file.
Hi,My Blueprints folder in .rar form. Hopefully not missing too much. (http://www.mediafire.com/file/8adij03kfv50tc9/Blueprints.rar)
as drop.io is down, do you have another repository of user blueprints?
thanks!
Hi,My Blueprints folder in .rar form. Hopefully not missing too much. (http://www.mediafire.com/file/8adij03kfv50tc9/Blueprints.rar)
as drop.io is down, do you have another repository of user blueprints?
thanks!
Same file, but on Wuala instead (http://www.wuala.com/Aklyon/Public%20Stuff/Blueprints.rar)
There you go.
Does quickfort support v0.31.25? I can't get .csv files to work with the lastest DF version (either modded or vanilla)?I'm running QF 2.00pre3 and 0.31.25 and it is working here. Which version of Quickfort are you using?
Does quickfort support v0.31.25? I can't get .csv files to work with the lastest DF version (either modded or vanilla)?
Lovin' QF 2 pre3 and have a question:
I've yet to mess around with a pump stack. In my current embark the lava is something like. I dunno. 50 z-levels below my fortress. Feels like forever at least. Constructing a pump stack seems to be quite a task, not to mention providing the power required for it to work.
Has anyone used Quickfort to mass-designate one? Can you even use construction commands while quickforting?
I was making a few custom dig scripts for bed rooms and workshops and decided I wanted to make some build scripts to go along with them. I'm running in to problems though with the build scripts placing other objects than what I designated for it to place. For example; it will place a door where I had a statue designated in the excel sheet. Here is a build script for the bed room design: http://dl.dropbox.com/u/12780033/Bedrooms-1-dig.csv <---Dig http://dl.dropbox.com/u/12780033/Bedrooms-1-build.csv <---BuildI haven't run your blueprints, but I did notice on your #build blueprint you have "i" commands (presumably left over from the #dig blueprint). These could very well be the cause, since 'i' in build mode opens the ballista/catapult build menu, after which point QF will probably have gotten itself stuck in that menu at the wrong time and subsequently gone "off the rails".
I've also noticed it will sometimes use thrones than tables. Anyone got some tips on what is causing it I'm all ears.
So is there any other program out there that is more up to date for the game?Quickfort doesn't require updating for new versions of DF like Therapist or Foreman, it should work fine in 31.25.
This is correct, though the aliases.txt in QF1.x won't work right in 31.25.So is there any other program out there that is more up to date for the game?Quickfort doesn't require updating for new versions of DF like Therapist or Foreman, it should work fine in 31.25.
...the aliases.txt in QF1.x won't work right in 31.25.
I have a fixed aliases.txt in QF2.00pre4 which I have not yet released, but will soon. I've got about 2-3 weeks left before I will have time to do that release, and the "non pre" release version should follow quickly afterwards. FINALLY. ;D
However, if aliases.txt is broken for 31.25, I'm wondering why you decided not to release your fixed aliases.txt as a temporary solution until you're ready to release the next version?The main reason is that 2.00pre3 doesn't handle aliases.txt at all. In 2.00pre4 this support has been added, along with handling some keystroke codes used a lot in aliases.txt, e.g. {Down 5}. QF2.x also supports a few new keystroke commands/shortcuts that weren't in QF1.x.
Is there any way to *rotate* a quickfort blueprint? Either with a command or by some sort of copy/paste on the original CSV?Yes, in Quickfort 2.00pre4 after loading up your CSV, hit Alt+R and enter: rotcw
Speaking of which, is it just me, or is the old quickfort .csv repository now down? I've got a fairly standardized fort layout I usually use (largely based on the fractal patterns in the wiki, modified for useability and efficiency etc.) and I'd like to upload it, but I'm not sure where to upload it to.The old .CSV Repository is gone now. But there are still sources available (http://www.bay12forums.com/smf/index.php?topic=35931.msg2131315#msg2131315) for the blueprints that were stored there.
Hi , as above poster I also made a simple ramp staircase.
It is a 3x3 4z (1 full spiral) , I also added an dug out area arround the staircase so it's 5x5.
Always start a zlevel down from where you want to start (ramps are upwards thus you need to dig from a zlevel higher)
I'll post both
the 3x3the 5x5 grid (also center start)Spoiler (click to show/hide)7x7 (starts at center) it's a combination of + & x formationSpoiler (click to show/hide)Later on I'l look into a more compact and usefull ramp staircaseSpoiler (click to show/hide)
Please do share your standardized fort layout. There are not very many complete fort layouts floating around (mostly bits & pieces) and I'd love to look at your design.
If you guys are going to be adding more blueprints, I'll try to keep my folder updated in Wuala, since these don't take much space and I've got a goodly amount left.Having it in a general folder would certainly be nice; would it be a pain to have it both ways?
Anyone want me to split the .rar into a general folder so you can be more specific, or is it fine as is? (also tell me whats its missing with links if you can)
Re: quickfort depository --
what about setting up a public-access Google Documents spreadsheet archive?
Not at all.If you guys are going to be adding more blueprints, I'll try to keep my folder updated in Wuala, since these don't take much space and I've got a goodly amount left.Having it in a general folder would certainly be nice; would it be a pain to have it both ways?
Anyone want me to split the .rar into a general folder so you can be more specific, or is it fine as is? (also tell me whats its missing with links if you can)
[Neat stuff]
- Smart designation: ~400% fewer DF commands required versus QF1.x for the same tasks
If you upload the template at least I'd be more than happy to start making modules for it...
- The /Modular project: I've created a new subfolder in blueprints titled Modular. The blueprints in this folder are built from a common template (__template.xls) and are designed to be easily connected to adjacent Modular blueprints in a fortress. The intent is to build up a library of blueprints of various types that conform to this template. To that end, I am looking for contributions if anyone would like to help populate this folder for future QF releases. Check out blueprints/Modular for more details. *NOTE: /Modular was later shelved for Quickfort 2.0's release; it will be back.*
QF2 is smarter about designating objects of various sizes. For example, workshops can now be designated by filling a 3x3 area of a blueprint with 'wc' instead of just a single 'wc' in the center of a 3x3 area. This makes some kinds of blueprints easier to create and read.I take it, then, that some of us will be creating blueprints that take advantage of these new features, but which will not work properly if used in an older version of Quickfort?
[rant]400% less would mean that now it uses a negative number of commands. Now that's something I'd like to see... Try "75% less", or "one quarter of the"[/rant]Yeah I had trouble figuring out how to word that. Will revise.
If you upload the template at least I'd be more than happy to start making modules for it...Couldn't decide on a template! :D
Why was it shelved anyways?
dimx dimy rooms area rooms/sqft rooms/edgelen
20 20 28 400 0.07 1.4
15 15 16 225 0.071111111 1.066666667
20 30 39 600 0.065 1.95
30 30 64 900 0.071111111 2.133333333
EDIT: Can you put in a function to just export the macro to DF, with a custom name?Added to the issue tracker. http://code.google.com/p/quickfort/issues/detail?id=41
One thing I noticed, however, was how the list of FEATURES in the OP seems to be missing some features that were stated in older versions. Specifically, I could not find:You're right, these bullet points were wrapped into other bullet points.
* Simple "command line" entry
* Minimalist (and optional) GUI
* Keystroke (construction speed) optimizations
The "Minimalist (and optional) GUI" was replaced with "Windows minimalist GUI with built-in command prompt". From this users might assume that the GUI is no longer optional. (But examining the options.txt file seems to indicate that it can still be turned off.)You can turn off the mousetip with Alt+H while Quickfort.exe is running. QF's Alt+T "command prompt" hotkey will still work.
The "Keystroke (construction speed) optimizations" or something similar should definitely be mentioned because this 2.00 release has a lot of speed optimization.I'll come back through and re-add/accentuate the bullet points you noted soon or at next release.
Yes - and definitely in the case of the 'automatic area expansion' you mention. QF1.x would freak out just thinking about it.QF2 is smarter about designating objects of various sizes. For example, workshops can now be designated by filling a 3x3 area of a blueprint with 'wc' instead of just a single 'wc' in the center of a 3x3 area. This makes some kinds of blueprints easier to create and read.I take it, then, that some of us will be creating blueprints that take advantage of these new features, but which will not work properly if used in an older version of Quickfort?
From this and other changes in the way blueprints are created, I suggest that we agree on some method to differentiate blueprints created for the new Quickfort 2.00 and old Quickfort versions. I'm thinking it would help avoid confusion if, from now on, we all agree to mention "4QF2" (for QuickFort 2.00) at the very beginning of blueprint descriptions. (This should be mentioned in "blueprints/Modular".) That abbreviation would be mostly self-explanatory while still saving space.A fair idea. I'll consider tagging all the Modular blueprints as you suggest. However, with the addition of XLS/XLSX file and multi-worksheet support in QF 2.00, I'm hoping more people move towards using those formats. Any blueprints in XLS/XLSX form will probably be impicitly understood as being QF2-only.
ISSUE 1: What should the dimensions be? It must be perfectly square for easy rotation & repetition. I've experimented with 15x15, 20x20, 30x30, and 40x40 sizes. Currently tending towards 20x20 due to its not being too small or too big, and it's evenly divisible by 10 which makes Shift+<movement key> work well in DF. 30x30 gives notably more freedom in how blueprints are laid out, but may be too large for some uses -- and the whole idea of the "Modular" set is that you repeat smaller modular blueprints as often as needed.
For reference, here is how many bedrooms and the bedroom densities I was able to obtain at different blueprint sizes, using 4 cells per bedroom:I think a lot of players still use the old 1x3 style (3 cell) bedrooms for peasants, reserving anything larger for nobles and the like. (Or would that make 4 cells with a door?) But, again, this has to do with tastes, preferences and play style.Spoiler (click to show/hide)
ISSUE 2: How should the stairs be arranged? Three basic possibilities:If 20x20 or larger size levels were considered, then having at least 1 staircase near the corners seems the way to go, rather than a large central staircase. However, if the level is large enough, I could see having both a central staircase and some staircases near the corners.
a - 2x2 staircase in the center of the blueprint
b - 1x1 staircase in each corner of the blueprint
c - 1x1 staircase at the midpoint of each edge of the blueprint
I'm tending towards option b currently, because it leads naturally to a template design where the outer edges of every blueprint are 1-wide hallways with stairs at each corner-intersection. When such a blueprint is repeated 2e, the 1-wide hallways on each blueprint combine to form a 2-wide hallway between them. Repeating 2e 2s, we get a 2x2 staircase in the center. This helps the fortress hallways/stairways scale up the main thoroughfares as the fort increases in size.
...The main downside of this option is what to do when you get to the surface level. Now you've got 4 1x1 staircases emerging at the surface. This makes surface blueprint design rather tricky and/or you try to funnel those 4 1x1 staircases into a centralized 2x2+ staircase on the first sub-surface z level. Either way seems like a bit of a hack and may stymie efficient dwarf movement from surface to underground.Yes, having 1x1 staircases in each corner would cause a problem for the z-1 level. Most players only want 1 main entrance to their fort for security reasons, at least to begin with. (However, 2 or more entrances are doable later, esp. for experienced players.) As you said, one solution would be to have the z-1 level with 1x1 down staircases in the corners and only have a centralized staircase (or side entrance) to breach the surface.
#dig start(4; 4; Center tile of a 7-tile square)
Thanks[rant]400% less would mean that now it uses a negative number of commands. Now that's something I'd like to see... Try "75% less", or "one quarter of the"[/rant]Yeah I had trouble figuring out how to word that. Will revise.
I'd personally say do a 20x20 design - it is easy for those people who want to expand the design to 3x3 corridors to simply align them on a 21x21 grid and add the extra row/column of corridors manually. (Or actually, could you add a function to only print a specific region of a blueprint?)QuoteIf you upload the template at least I'd be more than happy to start making modules for it...Couldn't decide on a template! :D
Why was it shelved anyways?
A little background on where this project stands:
I'll release the Modular pack soon (probably with next version of QF2). Just need to decide on a template and crack out the first half dozen or so fully working, all-phases blueprints.
The basic idea is to develop a full set of all-build-phases blueprints which can be rotated and repeated in any direction and still adjoin/connect to any adjacent Modular blueprint nicely.
The key issues with choosing the template I've been wrestling with:
ISSUE 1: What should the dimensions be? It must be perfectly square for easy rotation & repetition. I've experimented with 15x15, 20x20, 30x30, and 40x40 sizes. Currently tending towards 20x20 due to its not being too small or too big, and it's evenly divisible by 10 which makes Shift+<movement key> work well in DF. 30x30 gives notably more freedom in how blueprints are laid out, but may be too large for some uses -- and the whole idea of the "Modular" set is that you repeat smaller modular blueprints as often as needed.
For reference, here is how many bedrooms and the bedroom densities I was able to obtain at different blueprint sizes, using 4 cells per bedroom:Code: [Select]dimx dimy rooms area rooms/sqft rooms/edgelen
20 20 28 400 0.07 1.4
15 15 16 225 0.071111111 1.066666667
20 30 39 600 0.065 1.95
30 30 64 900 0.071111111 2.133333333
ISSUE 2: How should the stairs be arranged? Three basic possibilities:
a - 2x2 staircase in the center of the blueprint
b - 1x1 staircase in each corner of the blueprint
c - 1x1 staircase at the midpoint of each edge of the blueprint
I'm tending towards option b currently, because it leads naturally to a template design where the outer edges of every blueprint are 1-wide hallways with stairs at each corner-intersection. When such a blueprint is repeated 2e, the 1-wide hallways on each blueprint combine to form a 2-wide hallway between them. Repeating 2e 2s, we get a 2x2 staircase in the center. This helps the fortress hallways/stairways scale up the main thoroughfares as the fort increases in size.
The main downside of this option is what to do when you get to the surface level. Now you've got 4 1x1 staircases emerging at the surface. This makes surface blueprint design rather tricky and/or you try to funnel those 4 1x1 staircases into a centralized 2x2+ staircase on the first sub-surface z level. Either way seems like a bit of a hack and may stymie efficient dwarf movement from surface to underground.
So that's where I am with Modular right now ... committing to a specific template and doing the first batch of working blueprints. Tending towards a 20x20 base size with 1x1 stairs in each corner and hallways along the blueprint edges.
Thanks again!QuoteEDIT: Can you put in a function to just export the macro to DF, with a custom name?Added to the issue tracker. http://code.google.com/p/quickfort/issues/detail?id=41
X.........XX.........X
.#########..#########.
.#...#...#..#...#...#.
.#...#...#..#...#...#.
.#...#...#..#...#...#.
.#########..#########.
.#...#...#..#...#...#.
.#...#...#..#...#...#.
.#...#...#..#...#...#.
.#########..#########.
X.........XX.........X
For modular blueprints, I've found that a 11x11 grid works best, i.e.,Now I understand what was meant by "modular". :DSpoiler (click to show/hide)
The relevant "Base Unit" of dwarf fortress isn't the ten spaces because of the shift key -- it's the basic 3x3 workshop block. Everything else builds off of that.
For modular blueprints, I've found that a 11x11 grid works best, i.e.,The relevant "Base Unit" of dwarf fortress isn't the ten spaces because of the shift key -- it's the basic 3x3 workshop block. Everything else builds off of that.Spoiler (click to show/hide)
I have problems with using 3x3 as a basic workshop block. While it's true that most workshops are 3x3, that fails to leave any space for a stockpile or two. If one does not have at least one or two stockpiles next to a workshop, then it can take longer for haulers to haul stuff from/to workshop and said workshop could get cluttered. And cluttered workshops do not produce nearly as fast.
Of course, one may (also) have a storage level immediately above or below a workshop level. But wouldn't having workshops rely entirely on stockpiles in the storage level be less efficient? And it's much more difficult to control access to specific raw materials that way. It's nice to be able to create stockpiles specific for each workshop that exclude certain materials you do not want them to use.
Also, it's not necessary to have every workshop completely walled off. Mostly, it's important for workshops that are moodable:Oh, and I'm partial to the idea of having moodable workshops "ventilated". This means having fortifications so marksdwarves can easily shoot insane dwarves who failed their mood.Spoiler: "list of workshops that can have a mood" (click to show/hide)
To be specific: I think non-moodable workshops might be better off with either a 4x4 or 5x5 space and no walls to leave room for stockpiles, rather than a 3x3 space with walls. And moodable workshops might be better off with either 4x4 or 5x5 space and walls.
You can in fact work with an 11x11 block with space for individual stockpiles. Just do this:Yes, that could work for non-moodable workshops. But for moodable workshops, if you want to both surround each workshop on all sides with walls and provide immediate access to either stockpiles or a ramp/stairway to another level, it does not seem possible to stick with 11x11 blocks.Spoiler: Z (click to show/hide)Spoiler: Z+1 (click to show/hide)Spoiler: Legend (click to show/hide)
EDIT:Spoiler: Some quick examples (click to show/hide)
If you guys are going to be adding more blueprints, I'll try to keep my folder updated in Wuala, since these don't take much space and I've got a goodly amount left.
Anyone want me to split the .rar into a general folder so you can be more specific, or is it fine as is? (also tell me whats its missing with links if you can)
Well, I see right away that your /Tests/ folder is missing 18 files that are found in Quickfort_2.00.zip (in the \blueprints\Tests\ folder). I can see leaving out empty.csv as it's rather pointless, and a lot of those files are just much larger .xlxs versions of the .csv. Some are pretty useless. Were they left out on purpose? But if that was the reason, why was quote-test.csv included? (Again, rather pointless aside from demonstrating that it's possible to use quotes.) And for some reason you have a dig-5x5.csv.xls duplicate of dig-5x5.csv, while you're missing dig-15x15.csv.Honestly, I don't know why i had it like that Possibly was deleted by mistake, or I copied the wrong things from my old DF folder.
You can in fact work with an 11x11 block with space for individual stockpiles. Just do this:Yes, that could work for non-moodable workshops. But for moodable workshops, if you want to both surround each workshop on all sides with walls and provide immediate access to either stockpiles or a ramp/stairway to another level, it does not seem possible to stick with 11x11 blocks.Spoiler: Z (click to show/hide)Spoiler: Z+1 (click to show/hide)Spoiler: Legend (click to show/hide)
EDIT:Spoiler: Some quick examples (click to show/hide)
Anyway, I was thinking about 12x12 blocks, like this:It's just like your design above, except the corridors have been expanded to 2-tiles wide. This allows them to be combined and/or overlapped as either 2-tile wide, 3-tile wide, or 4-tile wide corridors, like this:Spoiler: Z (click to show/hide)Spoiler: Z (click to show/hide)
I kind of like the 12x12 idea also, but 4-wide hallways by default (e.g. using Alt+R -> 2e 2s) seem a bit excessive. If we use 2x2 staircases in each corner, too ... well you tell me:Anyway, I was thinking about 12x12 blocks, like this:Nice modification [....] Any particular reason for the X pattern of staircases beyond asthetics?Spoiler: Z (click to show/hide)
I like your 3 moodable workshops idea, and the 11x11 (I like odd numbers for these for some reason). The idea of a 22x22 series also works well. Oh, and I noticed that a DWR fits nicely in a 11x11 space:I kind of like the 12x12 idea also, but 4-wide hallways by default (e.g. using Alt+R -> 2e 2s) seem a bit excessive. If we use 2x2 staircases in each corner, too ... well you tell me:Anyway, I was thinking about 12x12 blocks, like this:Nice modification [....] Any particular reason for the X pattern of staircases beyond asthetics?Spoiler: Z (click to show/hide)Spoiler: 12x12 with 2x2 staircase corners (click to show/hide)Spoiler: After Alt+R -> 2e 2s (click to show/hide)
Is this excessive? I imagine it would minimize FPS loss due to pathfinding around traffic very well, but the rooms:hallways ratio seems pretty low.
Perhaps an 11x11 design would make more sense, relying on the user to incorporate wider hallways and/or a fort-central staircase as they deem fit.
This would make 4 moodable workshops basically impossible to fit, though we could possibly fit 3:Spoiler: 3 moodable workshops in 11x11 layout (click to show/hide)Spoiler: 3 moodable workshops after Alt+R -> 2e 2s (click to show/hide)
I'm also considering the idea of including some 'double size' blueprints in /Modular. Say we do an 11x11 series of /Modular blueprints, it might be nice to have a 22x22 folder of blueprints that mesh appropriately with the 11x11 template. This would allow for grander designs like all-in-one industry blueprints, banquet halls with built-in kitchen, etc.
I've also been considering adding an Alt+R transform command to add on-the-fly borders to blueprints. This might accommodate the addition of wider hallways pretty nicely.I likey
The syntax I have in mind would have two forms:
border[corner;edge] // compact syntax
border[nw;n;ne;e;se;s;sw;w] // full syntax
For example, to border an 11x11 blueprint with edge hallways (d) and corner stairs (j), per the above syntax examples, you might do something like:
border[j;d] // compact assumes we want edges to be repeated d's here
border[j;d(11x1);j;d(1x11);j;d(11x1);j;d(1x11)] // edges must be fully specified in full syntax
Cloned onto github, for anyone who wants to play around with the source but hates mercurial as much as I do.Thanks for this. Here's the most recent document (http://code.google.com/p/support/wiki/DVCSAnalysis) I could find addressing Google Code's lack of git support.
http://github.com/bakergo/quickfort (http://github.com/bakergo/quickfort)
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.
"#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,#
#,#,#,#,#,#,#,#,#,#,#,#
#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,`,`,`,#
#,#,#,#,#,#,#,#,#,#,#,#
>.........>
...........
...........
...........
...........
...........
...........
...........
...........
...........
>.........>
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.
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.
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.
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.
#build U-shaped
Cw:1,Cw:2,Cw:1,#
Cw:1,Cw:2,Cw:1,#
Cw:1,Cw:1,Cw:1,#
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 is1 (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.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.
Takes significantly fewer bitmap matches to do, so it should run more quickly than the player could do it themselves.
1(Match y - Top of List y2 ) / Height of the saved clip
2should be able to figure this out, blanking at the moment.
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! :P
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
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?
Just realized one problem: my graphics pack doesn't use the background highlights. See:
(http://dl.dropbox.com/u/261199/Rimslaughters/highlighted%20object.png)
Obviously I could always change graphics packs, but just an FYI.
Just realized one problem: my graphics pack doesn't use the background highlights. See:
(snip)
Obviously I could always change graphics packs, but just an FYI.
Crap.
Probably time to rethink things a bit. Thanks for pointing that out.
Now, UN-highlight the current material with + or - key, but keep it visible on-screen (if possible).
Press Y if the UN-highlighted material is now visible on-screen.
Press N if the UN-highlighted material can't be shown (i.e. it's all by itself on a mats list page).
I remember that DFWall had to memorize the spritesheet used by the player before it could attempt to look for selected materials.
In any case, if you want to go with 1-click solutions, simply:
"Click highlighted material. If no background highlight, click ON the letter."
(snip)
Hmm. You could ask the user to drag-select the desired material, and use that as your clip region.
I'm an die-hard quickfort user. I cannot express how much time it has saved me. A friend of mine wasn't as convinced. So I tried to think of a way to entice him; this is the result:
http://youtu.be/czrCvZqIMEc
ed note: I realize it is far longer than it needs to be; I don't imagine many people will watch until the end.
I'm an die-hard quickfort user. I cannot express how much time it has saved me. A friend of mine wasn't as convinced. So I tried to think of a way to entice him; this is the result:
http://youtu.be/czrCvZqIMEc
ed note: I realize it is far longer than it needs to be; I don't imagine many people will watch until the end.
Haha nice one. Especially the "reaction" webcam in the corner ;)
Your DF macro playback looks like it's going quite slow: you may need to set [MACRO_MS:0] in your DF data/init/init.txt.
I should probably just code a check for this init setting into QF; I bet it's catching up more than a few QF2 users.
It typically doesn't run that slow. I suspect the capture program was bringing the processor to a halt; I should have made sure QF and DF had their own core, and the capture program had one to its self as well. Ah, hindsight.Haha I see. Well at least it gave you adequate time for mugging at the webcam ;)
Anybody got a mature 0.31.25 fort save file they'd like to send me? I need a midsize fort I can conduct experiments in, but I'm too lazy to actually PLAY DF long enough to get one :D
I downloaded Rimslaughters but just unpausing it makes my PC cry uncle.
Anybody got a mature 0.31.25 fort save file they'd like to send me? I need a midsize fort I can conduct experiments in, but I'm too lazy to actually PLAY DF long enough to get one :D
I downloaded Rimslaughters but just unpausing it makes my PC cry uncle.
Oops, yeah, the save that was up there was made right before a massive temperature recalculation was needed, if I recall correctly. Here's (http://dl.dropbox.com/u/261199/Rimslaughters/Rimslaughters.zip) an updated one if it helps.
Please do share your standardized fort layout. There are not very many complete fort layouts floating around (mostly bits & pieces) and I'd love to look at your design.
$ python ./qfconvert.py bedroom-build.csv foo.mak
File "./qfconvert.py", line 65
raise Exception, \
^
SyntaxError: invalid syntax
I hope this is the right place to ask. I am on linux and trying to follow the guide to run qfconvert, but something is off.Try using 'python2' instead of 'python'.Code: [Select]$ python ./qfconvert.py bedroom-build.csv foo.mak
File "./qfconvert.py", line 65
raise Exception, \
^
SyntaxError: invalid syntax
I did update python2 so I don't think that's the problem. It seems like my python finds an error in the syntax of the source code, I also think that's impossible (I never used python, I wouldn't know)
Thank you so much, that fixed it.Sounds like maybe something that I should update in QF's readme.txt though.
(sorry if that was a newbye question)
Will 'python2' work reliably on any Linux/OSX install with Python 2.x installed?Yes, it should. See this: http://www.python.org/dev/peps/pep-0394/
Thanks. I'm guessing older installs probably wouldn't have a current enough Python 2 install to work with Quickfort anyway, so I will probably update readme.txt to use python2 instead.Will 'python2' work reliably on any Linux/OSX install with Python 2.x installed?Yes, it should. See this: http://www.python.org/dev/peps/pep-0394/
It really depends on the distro release though. Ancient linux installs might have only 'python'.
Ideally, quickfort would work with both python 2 and python 3 and none of this would be an issue.Python 3 compatibility should happen fairly soon (next release or two). The main holdup has been finding 3rd party libs that would work with Python 3. That has just recently been rectified.
For some reason, multi-level stockpiles and builds seem to bug out on me pretty badly.
The Quickfort's surface-build, surface-stockpile specifically do not work when I attempt to use them.
If I split them into separate sheets and call them individually by floor it's fine, but when combined it seems to reset the start position to the last known Corner (alt + QWAS), rather than respecting the Start position.
Seems to work fine for Dig, however.
If you make anything you'd like to share Nil, send me it and I'll update the Wuala folder.
###
###d##
##^hh^##
######h#d##h#
## d#hX####hX#
# ##^###hd^####
# # ### ###d ##
# # h## ###### #
# # h # ###hX# #
# # h # hh^### #
# # h # ###d #
# ##h # ###### #
#h#d ## ###hX# #
##^##d# dd^### #
#h#h#d# ###d #
#X# #d# ###### #
# #d#d# ###hX# #
# #^##d#dh^### #
##h#h######d ##
#### ###
#########
One thing that would just blow me away would be if quickfort could designate linkages (from lever or pressure plate to building). I realize that such functionality would require that quickfort know where in the build queue every single door or hatch (or whatever) was, meaning that all linkable buildings would have to be placed by quickfort, but for doing some crazy logic things involving thousands of mechanisms, such functionality just couldn't be beat. With large circuits, manual linkage creates a huge headache that means that I have to build my doors and hatches in a specific order, just so that I can find them on the link list.
This is all assuming that DF generates the link queue based on designation time rather than actual build time-- otherwise, none of these would work.
Can DF hack pull the current cursor position when setting linkages? it would massively simplify the problem. instead of trying to keep track of everything it only needs to know the x,y,z in relation to a specific point and could link from there running down the list until it finds the right x,y,z.it'd be slow but still orders of magnitude faster than any human doing the same task.
<Group name="Position">So I would assume so.
<Address name="cursor_xyz"
EDIT2: I made a proof of concept! It's severely hacky and slow though, as currently the only way to pass the co-ordinates on to another program is by creating a temporary file. Get it here (http://dffd.wimbli.com/file.php?id=4992). Now someone just needs to come up with a version of Quickfort that would work with it...
Yay! No more designating 1000+ linkages by hand! (Don't ask - I'm experimenting with computing).EDIT2: I made a proof of concept! It's severely hacky and slow though, as currently the only way to pass the co-ordinates on to another program is by creating a temporary file. Get it here (http://dffd.wimbli.com/file.php?id=4992). Now someone just needs to come up with a version of Quickfort that would work with it...
Sweet! I'll definitely look at integrating this into Quickfort 2 in the next version or two. This could be a game-changer for certain types of DF projects.
is it possible to use this tool to designate separate low value, (2-10), mid (15-20), high (25-30) and rare (40-60) stockpiles on separate places with a blueprint? I hate to always set up these stockpiles myself to see what my dorfs found in the deeps. If so, can you tip me about the script?
is it possible to use this tool to designate separate low value, (2-10), mid (15-20), high (25-30) and rare (40-60) stockpiles on separate places with a blueprint? I hate to always set up these stockpiles myself to see what my dorfs found in the deeps. If so, can you tip me about the script?
This is possible using QF's aliases.txt and a #query blueprint. Look at the included aliases.txt aliases 'artifacts', 'noartifacts', and 'junkgoods' to get an idea of how you do this. Also look at the Blueprints/TheQuickFortress/basic-*.csv blueprints to see an example of placing stockpiles in one blueprint and adjusting them in another.
...[F]or some reason youtube really likes to screw up the video for the first 15 seconds. Fine on my local machine, but no amount of reuploads seems to fix it after youtube does its conversion magic.
...
Hi, just for the people interested, I decided to go completely overboard with the raynard fractal bedroom design :)
Does this link work?Worked for me.
Hi, just for the people interested, I decided to go completely overboard with the raynard fractal bedroom design :)
That's pretty.
Any plans to write a #build blueprint to go with this? :D
question how do you exactly use up down stairs? a lot of the blueprints have these placed as x's and yet i never can build them myself.Up/down stairs are in the same build menu in DF as the plain up and plain down stairs.
question how do you exactly use up down stairs? a lot of the blueprints have these placed as x's and yet i never can build them myself.
On a less bright note, I've decided to drop the Modular blueprint set from this upcoming release - again. I've developed about 20 functional 11x11 Modular blueprints that all work. However, what I've found is that working with Quickfort and these 11x11 sized blueprints tends to get very tedious.
Because 11x11 is quite small, I find myself spending a lot more time manipulating QF to pick-and-play these blueprints than I ever did with (for instance) TheQuickFortress blueprints. Those blueprints were around 30x20 in size -- meaning it takes about six 11x11 Modular blueprint designations to accomplish the same effect as one TheQuickFortress blueprint designation. Multiply that by the multiple phases per blueprint (dig/build/place/query) which you have to continually switch between, and you start to see the problem.
Some feedback on the material selector ... it doens't work with me...Hmm. Would you be willing to zip up your DF installation and savegame that you are experiencing the problem with and ship it to me at qfmat@joelpt.net? This will probably be the easiest way for me to identify what's going awry.
I'm having trouble with a query blueprint. I've set it to set beds in a particular design as bedrooms (ie: r where beds are). The footprint is correct, but when I play it, it goes out of whack with the views going all over the place and then ending a little northwest of the original cursor placement.I'll take a look. Please post the blueprint that's giving you trouble if you can. Thanks!
I've triple checked the blueprint. No errors on my part.
I'm having trouble with a query blueprint. I've set it to set beds in a particular design as bedrooms (ie: r where beds are). The footprint is correct, but when I play it, it goes out of whack with the views going all over the place and then ending a little northwest of the original cursor placement.I'll take a look. Please post the blueprint that's giving you trouble if you can. Thanks!
I've triple checked the blueprint. No errors on my part.
#query
r+`r+`r+
I'm having trouble with a query blueprint. I've set it to set beds in a particular design as bedrooms (ie: r where beds are). The footprint is correct, but when I play it, it goes out of whack with the views going all over the place and then ending a little northwest of the original cursor placement.OK, found the problem and fixed it. Will post an updated Quickfort.zip shortly with the fix in place.
I've triple checked the blueprint. No errors on my part.
"designate": ["moveto", "cmd", "setsize"],
to "designate": ["moveto", "cmd", "setsize", "&"],
They're a bit odd as they cannot be built on the surface level; you can only build them underground where you have "non built wall" tiles (not yet dug out).
I've been playing with Quickfort for a few days now, and I'm finding it really useful, but I'm having some trouble getting everything to work.I just ran your blueprints here and was able to run your 4-room #build blueprint successfully on the latest QF version 2.03.
My digging blueprints are working fine, though I haven't tried anything really complicated yet, but my building prints just refuse to work.
I've tried using both .csv and .xls files as sources (both generated by OpenOffice), but that didn't seem to change anything. Every time I run the build blueprint, it places the first bedroom's furniture correctly, then seemingly just spews the rest of the furniture all over the map.
My dig and (very cut-down for testing) build .xls files are at http://dffd.wimbli.com/file.php?id=5370 (http://dffd.wimbli.com/file.php?id=5370). I know they can be different sheets in the same file, but I was trying to eliminate that as a cause of the problems I'm having. I'm running qfconvert.py directly from the command line, on MacOS 10.6.
If anyone has any ideas, I'd be very appreciative. It's probably just me getting something very simple completely wrong.
I've been playing with Quickfort for a few days now, and I'm finding it really useful, but I'm having some trouble getting everything to work.I just ran your blueprints here and was able to run your 4-room #build blueprint successfully on the latest QF version 2.03.
My digging blueprints are working fine, though I haven't tried anything really complicated yet, but my building prints just refuse to work.
I've tried using both .csv and .xls files as sources (both generated by OpenOffice), but that didn't seem to change anything. Every time I run the build blueprint, it places the first bedroom's furniture correctly, then seemingly just spews the rest of the furniture all over the map.
My dig and (very cut-down for testing) build .xls files are at http://dffd.wimbli.com/file.php?id=5370 (http://dffd.wimbli.com/file.php?id=5370). I know they can be different sheets in the same file, but I was trying to eliminate that as a cause of the problems I'm having. I'm running qfconvert.py directly from the command line, on MacOS 10.6.
If anyone has any ideas, I'd be very appreciative. It's probably just me getting something very simple completely wrong.
Are you using QF version 2.03? Are you using DF version 0.31.25? Are you using DF's default interface.txt unmodified? Are you sure you have adequate constructables available (f:8, c:4, b:4, d:4, t:4)?
If yes to all of the above, can you PM me the .mak file that is generated when you run "qfconvert.py bedrooms-build.xls > test.mak"? I'll compare it with what my qfconvert is outputting here and see if there is any difference.
I am using QF 2.03, DF 0.31.25, and I have more than enough of the furniture available. I haven't modified interface.txt to the best of my knowledge.
I normally use Mayday, but testing shows that the blueprints work fine in a 'vanilla' DF install, and using the Phoebus graphics set. It must be something odd with either Mayday, or my installation of it. Any ideas for other stuff to check? I copied the vanilla interface.txt to my Mayday install, just in case, but that didn't fix the problem.
I'm having trouble getting the material selector working properly. My design will build if I don't designate a material, but when I do, it always stops with this message: "Error:Quickfort timed out waiting for DF menu. Aborting playback."Are you going through the "click to the left / click to the right" mat-picking process before you get this error?
Yep it happens after the first wall is placed after i selected the material. I'll frap it when I get home and throw it on YouTube.Awesome, thanks.
With material selection enabled: http://youtu.be/MYAqKGQccH4
Added it to the folder. You still need to update the link in the first post to the Mediafire one instead of Wuala, joelpt.
Have you tried updating to 2.03?Hmm, tried both of those, but it's still doing it when I try macro mode.
Also, make sure none of your df folder is read-only. Can't add to it if its read-only, but the df folder shouldn't be by default.
when i try to load any blueprint in game through GUI using ALT+F i'm getting this kind of error :Thanks for this, I'll incorporate this into the next version.
...
Issue seams to appear in GetWinPath function only when running on 64 bit system ( DllCall("CreateRemoteThread"... to be exact).
I'm to lazy to learn how it work, so i copy/past similar function from google, and it's working quite well for me :P
here is patch for Mercurial project:
...
Will this utility work for version 34.02?Have not tried it yet, though I'd be surprised if it didn't.
#dig,,,,,,,,,,,
,,,,d,d,d,,,,,#
,,,,d,d,d,,,,,#
,,,,d,d,d,,,,,#
,,,,,d,,,,,,#
d,d,d,,,d,,,d,d,d,#
d,d,d,d,d,i,d,d,d,d,d,#
d,d,d,,,d,,,d,d,d,#
,,,,,d,,,,,,#
,,,,d,d,d,,,,,#
,,,,d,d,d,,,,,#
,,,,d,d,d,,,,,#
#,#,#,#,#,#,#,#,#,#,#,#
---------------------------
Quickfort.exe
---------------------------
Error reading blueprint information from qfconvert.py output file D:\games\LazyNewbPack last\LNP\Utilities\2-Advanced\Quickfort\Quickfort 2.03\~qf120321181850.tmp
---------------------------
OK
---------------------------
And this is error that I got from quickfort:Code: [Select]---------------------------
Quickfort.exe
---------------------------
Error reading blueprint information from qfconvert.py output file D:\games\LazyNewbPack last\LNP\Utilities\2-Advanced\Quickfort\Quickfort 2.03\~qf120321181850.tmp
---------------------------
OK
---------------------------
Did you extract them from the archive first?
What is the exact *blueprint location* that is reported in the error?Did you extract them from the archive first?
Yes, the CSV files are sitting in their own folders in my Downloads folder.
Most recent one I tried is:
What is the exact *blueprint location* that is reported in the error?
I'm wondering if this is some oddness with how Windows aliases the My Downloads/My Documents folders.
Try taking out one of the \blueprints\ folders.
So you have U:\Users\Sean\Downloads\blueprints\Circle Pack\circle21.csv
Okay, I did a check on a few blueprints in each folder in the community blueprints collection.Thanks for investigating that. This should make it much easier to track down what's gone awry.
It seems the ones in Circle Pack, Jurph's Fractal and Modular Expansion Pack, Large Diagonal Hallways and templates do not work correctly, all giving the same error indicated in my previous posts.
And this is error that I got from quickfort:Code: [Select]---------------------------
Quickfort.exe
---------------------------
Error reading blueprint information from qfconvert.py output file D:\games\LazyNewbPack last\LNP\Utilities\2-Advanced\Quickfort\Quickfort 2.03\~qf120321181850.tmp
---------------------------
OK
---------------------------
I have same error in new version of Quickfort. Version 2.01 work fine though.
Nice find! I will change that (and/or find a better solution than using a weird char there) in next version.And this is error that I got from quickfort:Code: [Select]---------------------------
Quickfort.exe
---------------------------
Error reading blueprint information from qfconvert.py output file D:\games\LazyNewbPack last\LNP\Utilities\2-Advanced\Quickfort\Quickfort 2.03\~qf120321181850.tmp
---------------------------
OK
---------------------------
I have same error in new version of Quickfort. Version 2.01 work fine though.
I solved this issue for me by changing the delimiter character in parse loop in function GetBlueprintInfo in blueprints.ahk, original "crossed c" somehow ended like regular c while the program was running and this broke whole parsing.
I can share new Quickfort.exe somewhere if anyone is interested. Just download original 2.03 and replace the file.
THere should be a 'blueprints.rar' downloadable.Nothing shows on my end. =/ But youve verified it's there and visible? Not sure how that's even possible...
Seems like its a mediafire problem, then. Joelpt, can you use the direct link to the file instead?Changed in this thread's original post. I'll change it in the readme for the next release.
The folder apparently appears as empty to everyone but me.
What is the correct way to represent
Hives alt-h
Stone slabs alt-s
Floor bars alt-b
into build blueprints
"<": "<",
">": ">"
},
"key": {
"<": "<",
">": ">",
"{alt b}": "4:b",
"{alt s}": "4:s",
"{alt h}": "4:h"
},
"key": {
I'm having problems using .xls and .xlsx files with the new version.(edited)
When I try to load a file this error appears:
(http://s17.postimage.org/5l0grbyvz/Sem_t_tulo.jpg)
So far I'm using 2.03, this one works fine with those files.
.xls is a better format for compatibility anyway, The only thing I know that specifically uses .xlsx is Office 2007 or newer.Sorry I misspoke in my earlier post (now edited); Aklyon is referring to a suggestion I made and then removed of saving .xlsx as .xls as a quick-fix -- which I have now found doesn't actually fix the bug we're seeing here.
I'm not sure if this is an error anyone else is having with sending by "Key" rather than "Macro", so I thought I'd double-check here first before I delve too deeply into the source-code:
https://www.youtube.com/watch?v=vHx1VGdkFyM
Can anyone else replicate this issue?
Even if I fully wipe the folder and replace it, I still get the issue (though SendInput was working perfectly for the majority of yesterday, until this started to occur). I do have other AHK scripts running, which I'm assuming is partially responsible if it's just me; I'm manually dumped the output of qfconvert to a text file and it would appear that it's an issue on the QuickFort side of things. More details to follow, if anyone can confirm it's not just my problem.
#dig,,,
`,`,d,
`,i,d,
`,h,d
#>,,,
d,h,`,
d,i,`,
d,`,`,
#dig,,,
`,T,T,
`,`,T,
`,T,T,
#>,,,
T,T,`,
T,`,`,
T,T,`,
I've got a question about track support in the current version. Is it right that we can only designate built tracks and not carve them atm? And shouldn't there be more possibilities with roller, i.e. NS, SN, EW and WE?
Are there plans, that you add support for designating minecart tracks or am I missing something?
The following Code for digging and designating a spiral track does not work. The problem is, that Quickfort does not designate the overlap on the turns. It is possible to record the overlap in a macro. Quickfort only needs a way to recognize them.
i was loving this utility. but i cant seem to use it anymore. yesterday it worked just fine i didint mess around with it or anything. but now when i load up quickfort and press alt+f nothing happens i dont get the choose blueprint option and neither does alt+t. any help?Are you seeing the Quickfort "mouse tip" when you switch to DF?
[...]
Regarding tracks that span multiple Z-levels: do you have to overlap carved tracks from the upper z-level to the lower z-level in order for the tracks on the two z-levels to be connected?
I think I found the issue here: SendInput does not obey SetKeyDelay (http://www.autohotkey.com/docs/commands/SetKeyDelay.htm). As a result when using SendMode=SendInput in QF 2.04, QF just goes as fast as possible playing the keys back, and DF can't cope.
Regarding tracks that span multiple Z-levels: do you have to overlap carved tracks from the upper z-level to the lower z-level in order for the tracks on the two z-levels to be connected?
.xls is a better format for compatibility anyway, The only thing I know that specifically uses .xlsx is Office 2007 or newer.Sorry I misspoke in my earlier post (now edited); Aklyon is referring to a suggestion I made and then removed of saving .xlsx as .xls as a quick-fix -- which I have now found doesn't actually fix the bug we're seeing here.
Investigation in progress...
Regarding tracks that span multiple Z-levels: do you have to overlap carved tracks from the upper z-level to the lower z-level in order for the tracks on the two z-levels to be connected?
Quick summary on multi z-level tracks and the designation of carved tracks:
The first pass would designate all 'T' track-carving cells just like a normal blueprint.You mean like moving the cursor on a cell and press Enter twice? Because that won't actually result in any designation (actually logical, a track needs a direction and you don't provide that by just pressing enter twice).
.......
.╞═══╗.
.....║.
.....║.
.....║.
.....╨..123456
A......
B╞═══╡.
C....║.
D....║.
E....╨.
how to make C5 connect to B5 without the upper cell also getting a south link? You'd have to designate E5 to B5, remove B5' designation and B1 to B5 then. Now QF must of course be able to realize that it needs to do these stepts in that order to get the result pictured.PSEUDO-EDIT: Do you mean "'T'-cells" like in T-intersection or as in the designation command d->T? I assumed the latter and just spent maybe 15 minutes writing the following:Correct I meant the latter.
The first pass would designate all 'T' track-carving cells just like a normal blueprint.You mean like moving the cursor on a cell and press Enter twice? Because that won't actually result in any designation (actually logical, a track needs a direction and you don't provide that by just pressing enter twice).
T T T
. . T
. . T
(position cursor at intersection point cell)
{Enter}{Left}{Enter}{Right}{Enter}{Down}{Enter}{Up}
. . . . . . T . . . . . .
T T T T T T T T T T T T T
T . . T . . T . . T . . T
T T T T T T T T T T T T T
. . . . . . T . . . . . .
I have yet to test powering the the whole thing.
Hi there joelpt. Let me start by saying the tool you have created is really great. Along with dwarf therapist makes the game more enjoyable to a wider population!
Now, the issue at hand. I already post it on github.com but I'm not sure how frequently you check there.. well. In either case here is the problem I found.
After successfully using the manual material function for a few times now I get this weir error every time I use the tool, even with the following error appears:
Quickfort.exe
Error: Out of memory. The current thread will exit.
Line#
---> 2162: sz:= VarSetCapacity(bits,w*h*4,0)
When you click on accept it appears again and then quickfort says that the time waiting for the menu as run out.
At first I believed it was the blueprints. But I tried the example ones and I get the same error. I tried rebooting the pc and also deleting and using a fresh quickfort copy but to no avail. The only solution I find is to use a fresh copy of both quickfort and dwarf fortress (if you only replace one or the other the manual selection will present the same error) and after a while it goes back to not work again.
I wonder what could it be. I tried looking at the code but there's no singe part of it with that many lines besides interface.txt which I doubt has something to do with this problem.
DllCall("DeleteObject", "Uint", hBM)
current := CRC32(bits, sz)
}
return true
}
DllCall("DeleteObject", "Uint", hBM)
current := CRC32(bits, sz)
}
bits := ""
return true
}
# Magma Safe Stone
# Only Non-Economic (and no Adamantine)
# Other Stone: Sandstone, Chert, Gabbro, Basalt, Obsidian, Quartzite, Talc, Periclase, Ilmenite, Rutile, Chromite, Pitchblende, Bauxite, Olivine, Mica, Orthoclase, Anhydrite, Alunite
magmasafe: s{Down 5}deb{Right}{Down 2}{Right}&{Down 7}&{Down 3}&{Down 2}&{Down 3}&{Down 1}&{Down 7}&{Down 3}&{Down 10}&{Down 1}&{Down 1}&{Down 1}&{Down 2}&{Down 1}&{Down 2}&{Down 3}&{Down 2}&{Down 2}&{Down 1}&^
# All Magma Safe Stones
# Economic: Dolomite, Kaolinite, Calcite
# Other Stone: Sandstone, Chert, Gabbro, Basalt, Obsidian, Quartzite, Talc, Periclase, Ilmenite, Rutile, Chromite, Pitchblende, Bauxite, Olivine, Mica, Orthoclase, Anhydrite, Alunite, Raw Adamantine
magmasafe_all: s{Down 5}deb{Right}{Down 1}{Right}{Down 1}&{Down 6}&{Down 1}&{Left}{Down 1}{Right}&{Down 7}&{Down 3}&{Down 2}&{Down 3}&{Down 1}&{Down 7}&{Down 3}&{Down 10}&{Down 1}&{Down 1}&{Down 1}&{Down 2}&{Down 1}&{Down 2}&{Down 3}&{Down 2}&{Down 2}&{Down 1}&{Down 1}&^
I created an alias for Magma-Safe stone, it might be useful to include in the readme or the default aliases.txt file.Code: [Select]
# Magma Safe Stone
# Only Non-Economic (and no Adamantine)
# Other Stone: Sandstone, Chert, Gabbro, Basalt, Obsidian, Quartzite, Talc, Periclase, Ilmenite, Rutile, Chromite, Pitchblende, Bauxite, Olivine, Mica, Orthoclase, Anhydrite, Alunite
magmasafe: s{Down 5}deb{Right}{Down 2}{Right}&{Down 7}&{Down 3}&{Down 2}&{Down 3}&{Down 1}&{Down 7}&{Down 3}&{Down 10}&{Down 1}&{Down 1}&{Down 1}&{Down 2}&{Down 1}&{Down 2}&{Down 3}&{Down 2}&{Down 2}&{Down 1}&^
# All Magma Safe Stones
# Economic: Dolomite, Kaolinite, Calcite
# Other Stone: Sandstone, Chert, Gabbro, Basalt, Obsidian, Quartzite, Talc, Periclase, Ilmenite, Rutile, Chromite, Pitchblende, Bauxite, Olivine, Mica, Orthoclase, Anhydrite, Alunite, Raw Adamantine
magmasafe_all: s{Down 5}deb{Right}{Down 1}{Right}{Down 1}&{Down 6}&{Down 1}&{Left}{Down 1}{Right}&{Down 7}&{Down 3}&{Down 2}&{Down 3}&{Down 1}&{Down 7}&{Down 3}&{Down 10}&{Down 1}&{Down 1}&{Down 1}&{Down 2}&{Down 1}&{Down 2}&{Down 3}&{Down 2}&{Down 2}&{Down 1}&{Down 1}&^
I've tested this with 0.34.11, it seems to work.
Nope. I made the change and it's not working. Curiouser and curiouser this only happens on the machine here at work. My pc (in my apartment) has not this issue, I tried there to make the error surface but to no avail. Here at work I can't use the thing but a few times before getting the error.
Ok, now AHK gives me an error at line 115 of df_manualmats.ahk, it says
<snip>
Yes, you can. Read the manual, of if you are really lazy read this:
Specifying a starting position
------------------------------
You can optionally specify a cursor starting position for a particular
blueprint, simplifying the task of blueprint alignment. This can be helpful
for blueprints that are based on a central staircase, for example.
To specify a cursor starting position, use the following modified format
for the header line of your blueprint:
#mode start(X;Y;STARTCOMMENT) comment
where X and Y specify the starting cursor position (1;1 is the top left cell)
and STARTCOMMENT (optional) is a description displayed to the QF user of
where to position their cursor. This description appears in the pre-playback
mouse tooltip.
A couple examples:
#dig start(3; 3; Center tile of a 5-tile square) Regular blueprint comment
#build start(10;15)
When a start() parameter is found in a CSV file, the normal Alt+Q/W/A/S
keys will override (ignore) said parameter. Alt+Z will un-ignore the start()
parameter.
See Blueprints/Tests/starting-position.csv for a simple example.
The Blueprints/TheQuickFortress/*.csv examples all utilize start().
Oh carp... using ahk, this happens every time I try to select a blue print. Any blue print.
Ok, I'm using the .exe qf uses about 12 mb and df uses around 1gb (its a big map, 6x6 or 7x7 can't remember). I select a regular blueprint to clear out of threes and bushes the surface and it works. The amount of memory don't change.
Next I select the blueprint for building a perimeter wall with four archer towers and bang, the error. But the memory of both df and qf remains the nominal though.
Could you translate the Specifically: part, for reference?
Thank you. I was simply hoping there was a less convulated way of doing it, considering I have 16 blueprints of different sizes to modify.
Thank you. I was simply hoping there was a less convulated way of doing it, considering I have 16 blueprints of different sizes to modify.
I previously considered allowing you to specify percentages to the start() parameter, i.e. #dig start(50%;50%), but I decided not to because for blueprints with an even number of rows or cols, where 50% is would be indeterminate; is the center column of a 10-wide blueprint column 5 or column 6?
For the same reason I have not added a hotkey like Alt+QWAS for setting a "center cell" start position on the fly.
#dig
ju#
uj#
#>#
uj#
ju#
###
Are there any better ways of making blueprints outside of spreadsheets?Do you know of Chromafort, Webfort, Paintfort and DFHelper (that one is quite new I believe)? Google and the forum search function should help you find them.
I've just recently started using Quickfort and have immediately run into a problem: I can place my blueprint (Alt + D) but once it's finished my [Esc] key no longer works, and neither to the + and - keys, so I can't back out of the designate menu and get on with the game, or even save it and restart. I've tried suspending and quitting Quickfort but it makes no difference.* After it finishes try tapping each of the Alt, Shift, and Ctrl keys once each (I mean tap each of the 2 Alt keys once, etc.). Do the keys start working after that?
Am I missing something obvious, or has anyone else had this problem? I'm using the latest version of DF and QF, and the Phoebus tileset.
Does it work if you stick it in WINE? If it does it'll technically also work on Linux.
AutoHotkey/Python need not be installed for Windows users. Non-Windows users need to have Python installed.
decided to try making an Automatic Quantum Stockpile (AQS) blueprint with a 3x4 cell (previously dug in a fortress blueprint),
realized threw fit on hauling command ( i used #h at beginning to represent pressing h, to configure routes), since this is dependent on track stop, is there a way to configure a route? in particular configure the stock retention screen.
Is there a workaround for that?
also a question, could i stack "in one worksheet", #build, #place and #query?
However, this version is huge!
Hum... thought I should just mention my install experience on linux
then just out of curiosity i switched to 2.7.3, and qfconvert worked on that too :/
moral of the story, try running it on what you got first hehe, although it was a good experience, do we really need 2.6.4?
But when the MultiLevel csv file grows bigger than 15~ levels I get this error: quickfort "error reading blueprint information from qfconvert.py output file bla bla bla .tmp"
making it a xls file seems to grow up this limit to 25~ levels. All of this levels are a centered-matrix of 91-wide tiles.
Are there any plans to build a gui similar to windows for osx? I like how in windows you can center the blueprint instead of working from the upper left corner, or is that possible on on osx? Thanks!
python qfconvert.py --position=nw ..\Blueprints\Tests\dig-10x10.csv output.mak
python qfconvert.py -p se ..\Blueprints\Tests\dig-10x10.csv blueprint.csv output.mak
python qfconvert.py -p (5,5) ..\Blueprints\Tests\dig-10x10.csv blueprint.csv output.mak
But when the MultiLevel csv file grows bigger than 15~ levels I get this error: quickfort "error reading blueprint information from qfconvert.py output file bla bla bla .tmp"
making it a xls file seems to grow up this limit to 25~ levels. All of this levels are a centered-matrix of 91-wide tiles.
Can you send me one of your error-causing 15+ level blueprints to quickfort@joelpt.net? I'll take a look.
I'm not aware of any practical reason why QF should be limited in this way so it definitely sounds like a bug of some sort.
| A | B |
| ^ | ^ |
| rotcw | |
| ^ | > |
| 2e | |
| ^> | ^> |
| fliph | |
| <^ | <^ |
| flipv | |
| <v | <v |
| 2s | |
| <v <v | <v <v |
d
iii
diiid
iii
d iid
ii
d d
ii
diiand rotates that, since with "my" version I can just set the cursor in the middle of the central staircase at the start. Instead of having to count out from the staircase every time I want to designate something, or marking a tile in one of the corners to be the "start tile" (with fixed location relative to the 3x3 central staircase) throughout all the z-levels in the embark.diiiid
iiii
dd ...which adds an extra tile of width.Hey everyone! I'm trying to designate my stockpile area in Quickfort 2.04 and I keep getting this error:
(http://abload.de/img/quickforterror0ks8j.jpg)
Here is the associated blueprint:
http://www.mediafire.com/download/65oxkuwu4785t9j/Quantum_Stockpiles.xlsx (http://www.mediafire.com/download/65oxkuwu4785t9j/Quantum_Stockpiles.xlsx)
As far as I can tell I have designated everything correctly, it's just a simple dig blueprint, but maybe I'm missing something. I'm a DF veteran, but not a QF one.
I'm on Windows 7 64 bit, if it makes a difference.
However, this version is huge!
Haha, yes indeed the size increased rather significantly in the current release. Thank you for your research into compression and size-reduction options. I'll look into utilizing some or all of your suggestions in the next release.
As you noticed, the qfconvert stuff accounts for a lot of the size increase. A big part of that is the transition to using the numpy library within qfconvert, which makes the conversion routine run 10x-100x faster compared to older versions. Which entails the inclusion of the whole numpy library in the packaged build.
I do like the idea of releasing a "compact" version in parallel with the standard version, and if the size difference is significant enough, I will do just that. Of course for Lazy Newb Pack, including the prebuilt Python binaries would probably be a must-have, or else it would not be a simple "one click install" for many users.
I'll see what I can do :D
I'd love to see a GUI for Mac/Linux. Unfortunately AutoHotkey doesn't (yet) run on those platforms so it would entail a total rewrite of the GUI part of Quickfort. And as this GUI utilizes global hotkeys and a "mouse anchored tooltip" as the UI mechanism, this may require unique code for each platform (or a break from this UI paradigm).
Quickfort's minimalist Windows-only "GUI" is a partial rewrite of the AutoHotKey script that was Quickfort 1.x. It has seen a number of significant improvements, such as blueprint previews and the ability to choose a worksheet from a multisheet XLS/XLSX file. It is now a "thin" GUI implementation, providing only the mousetip-based GUI and DF-keysending functionality, and relying on qfconvert for all blueprint processing and manipulation.
It's not working for me. I start Quickfort.exe, I get an icon in my system tray that has a pop-up that says "Quickfort Version 2.04", and then nothing happens.
Alright I'm sorry. I read "Quickfort 2.x is a utility for Dwarf Fortress, built with Python and AutoHotKey, that helps you build fortresses" and thought it was an app that would let me build fortresses. Now that I know it's useless I can un-install it. Thanks for your time.
Alright I'm sorry. I read "Quickfort 2.x is a utility for Dwarf Fortress, built with Python and AutoHotKey, that helps you build fortresses" and thought it was an app that would let me build fortresses. Now that I know it's useless I can un-install it. Thanks for your time.
I made this account so I can ask this one question. Anyone has any idea why QF gives me these results?
(http://img577.imageshack.us/img577/4462/ycdx.png)
No matter if I use macro mode or key mode. It happened on several different Build blueprints. Dig and Adjust works ok.
http://dffd.wimbli.com/about.php
#dig start(16;19; bottom-center bottom-middle large room for finished food),,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,,d,d,d,,,,
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,,d,d,d,,,,
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,,d,d,d,,,,
d,d,d,d,d,d,d,,,,,,d,d,d,d,d,d,d,,,,,,,,,,,,,,,,
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
d,d,d,,d,d,d,,d,d,d,,d,d,d,,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d,d,d,,d,d,d,,d,d,d,,d,d,d,,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d,d,d,,d,d,d,,d,d,d,,d,d,d,,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,,,,,d,d,d,d,d,d,d,,,,
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d,,d,d,d,d,d,d,d,,d,d,d
d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d
d d d d d d d d d d d d d d d d d d d d d d d d d d d d d d
Anyone having issues with Beds/Tables/Chairs placed in planning mode which don't get placed once they're manufactured? I'm using Ordinary/*any as filters (default) in from the 40_10 Starter Pack r4.
There's a dfhack plugin (https://github.com/DFHack/dfhack/issues/479) in progress to export the current state of part of your fortress to quickfort csv files. It doesn't look at designations though, just current tile state. It might be good to add a comment to that issue so we can see if there's enough interest to make adding designation reading an option.
Tried building Buketgeshud for some pics, but the stockpile adjust files didn't work for me. Could be LNP related?Possibly. To tell the truth I never managed to get anything working besides digging blueprints.
It's not hard to look through the file and set the stockpiles manually, which is what I did.
Lastly the instructions call for designating several z-levels of stairs/halls at once. Doing this causes the whole project to take significantly longer as the miners keep pathing to stone on z-levels above or below them and walking back to whichever stairs are done yet to get there.That's a new bug introduced by 40.20+. (http://www.bay12games.com/dwarves/mantisbt/view.php?id=8784)
Possibly. To tell the truth I never managed to get anything working besides digging blueprints.I can get build prints to work, but manual material selection is totally spotty.
For a workaround take a look at the new save/load stockpile menu in dfhack. (q over any stockpile)
Hey everyone! I'm trying to designate my stockpile area in Quickfort 2.04 and I keep getting this error:
(http://abload.de/img/quickforterror0ks8j.jpg)
Here is the associated blueprint:
http://www.mediafire.com/download/65oxkuwu4785t9j/Quantum_Stockpiles.xlsx (http://www.mediafire.com/download/65oxkuwu4785t9j/Quantum_Stockpiles.xlsx)
As far as I can tell I have designated everything correctly, it's just a simple dig blueprint, but maybe I'm missing something. I'm a DF veteran, but not a QF one.
I'm on Windows 7 64 bit, if it makes a difference.
Found it: delete # from BD1.
#dig start(12;8;) - Bottom Level - DwarfMockup(107;115;0)
´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,#
´,,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,#
´,´,´,´,s,´,s,´,´,´,s,´,s,´,´,´,s,´,s,´,´,´,´,#
´,´,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,´,´,#
,´,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,´,´,#
,´,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,´,´,#
´,´,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,´,´,#
,´,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,´,´,#
,´,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,´,´,#
´,´,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,´,´,#
´,´,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,´,´,#
,´,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,s,´,´,#
´,´,´,´,s,´,s,´,´,´,s,´,s,´,´,´,s,´,s,´,´,´,´,#
´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,#
,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,´,##,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#,#
Bedroom Bottom With Furniture-dig_alt.csv
#dig
Command usage frequencies:
s:183, ´:155, #dig start(12;8;) - Bottom Level - DwarfMockup(107;115;0):1, ##:1
Dimensions: 24w x 16h
123456789012345678901234
+------------------------+
1|ï.......................|
2|ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ.|
3|Â.ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ.|
4|ÂÂÂÂsÂsÂÂÂsÂsÂÂÂsÂsÂÂÂÂ.|
5|ÂÂsssssssssssssssssssÂÂ.|
6|.ÂsssssssssssssssssssÂÂ.|
7|.ÂsssssssssssssssssssÂÂ.|
8|ÂÂsssssssssssssssssssÂÂ.|
9|.ÂsssssssssssssssssssÂÂ.|
0|.ÂsssssssssssssssssssÂÂ.|
1|ÂÂsssssssssssssssssssÂÂ.|
2|ÂÂsssssssssssssssssssÂÂ.|
3|.ÂsssssssssssssssssssÂÂ.|
4|ÂÂÂÂsÂsÂÂÂsÂsÂÂÂsÂsÂÂÂÂ.|
5|ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ.|
6|.ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ#|
+------------------------+
I'd manually check the syntax of the first line, and maybe also try ending lines with a comma. You could also try instantiating the blueprint with the fortplan plugin, and test that Quickfort is working with a known blueprint file from the community pack.
How do walls work?You need to select the materials I think.
I typed in each cell "Cw" as per the sketchy manual I found at joelpt, but all it does is select the wall - then proceed to max it out to the 10x10 square without building anything.
So it follows the plan, but unable to place any walls. What am I missing?