Print

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

[kalamus]

Does it work if you stick it in WINE? If it does it'll technically also work on Linux.

No clue, I'm a Linux noob. I think .Net will work on Wine but don't think XNA will.

[Otherwise]

I'm having some trouble getting Quickfort to work for me.  When I hit Alt f I get an error message:  qfconvert did not return any results.  I have python 2.7.3 installed and have Windows Vista.  Any ideas?  Thanks. 

EDIT:  I am trying to use some of the test blueprints that come with quickfort.

[Otherwise]

Update:  I've gotten around the above issue by creating my blueprints in quickfort and then loading them into DF Designator and using that to run them in DF.  So far it's working well. 

[Thormgrim]

I can't get QF to load my blueprints either.  I haven't really played DF in around a year or so, but IIRC this is pretty much how I used to make my blueprints...

I'd upload my blueprint, but i'm not sure how.  I'll post the errors later on tonight.

[Thormgrim]

The error it gives me is "Error in qfconvert: 'NoneType' object has no attribute 'group'

which isn't very informative to me...

[LtGreeneyes]

I'm having an issue and I'm not sure if its chromafort or QF, but I redid the 61x61 housing plan in the wiki http://dwarffortresswiki.org/index.php/DF2012:Bedroom_design in paint, in black and white, then used chroma to export as excel and finally accessed with QF.  The problem is that QF is reading it and printing it onto DF all weird. :/  Is there some restriction on blueprint size, or am I missing something? lol.

Also, does anyone else have a spreadsheet for that particular design, or something similar, with 3 tile wide hallways, a 3x3 staircase, and high density rooms? (the rooms should be just about as small as possible... I'm looking for high efficiency here. )

[Thormgrim]

if anybody is interested, i figure out my problem... I had done a find/replace for d/h and had #hig in the upper left corner instead of #dig.  That's the error you get...

[Arano-kai]

I just put it here, just in case...

Spoiler (click to show/hide)

DOWNLOAD

All instructions inside
Please PM me about Your suggestions / requests

[rynait]

Hello Joelpt

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?

R

[Thundercraft]

Woah!

joelpt, I've been away from DF for a while and I'm glad to see this updated. I really am.

However, this version is huge! Uncompressed, it is nearly 21 MB (or 8.9 MB in a .ZIP). Compare that to Quickfort 2.0 at a mere 8.26 MB or even Quickfort v2.00pre3 at merely 6.84 MB (uncompressed). That's an increase of over 300% since 2.00pre3! This makes including Quickfort in DF mods like Lazy Newb Pack problematic as most do not want a download that big. (It seems Lazy Newb Pack has regular and "advanced" packs now to save space.)

I suspect a significant part of this program bloat comes from trying to make it completely platform independent. You say it "works on Windows and Linux/OSX/(anything that runs Python)". But you also say:

AutoHotkey/Python need not be installed for Windows users. Non-Windows users need to have Python installed.

If you made a version of the 2.04 release that is dependent on Python and/or AutoHotkey, it would probably require much less space. A lot of us Windows users already have Python installed, anyway, as a lot of other programs require it. (I also keep AutoHotkey installed. It's small and quite handy. And there are other useful DF macros and AutoHotkey scripts.)

Oh, and since the download includes the source code, that's another 732 KB that most Quickfort users don't need.

On modern computers, many DF fans might scoff at 21 MB. But some of us are on laptops with small drives crammed full and we realize ever bit adds up. For me, it's enough that I'd consider an old version, if it wasn't for the fact that I'd probably use some of the new features like designating mine tracks...

With that it mind, would you consider looking into the size issue for the next release? Maybe you could upload a "compact" python dependent version - without the source code - to DFFD? (It's where a lot of DF fans search for new releases.) And also the source code as a separate download?

Edit:
Hmm... I forgot that Quickfort was built in AutoHotkey. The source code is useful in that I could just install that instead of the "compiled version". AutoHotkey is about 7.6 MB and the Quickfort code is about 0.7 MB.

When I first tried to run Quickfort.ahk it stopped with an error message. But then I updated AutoHotkey to the latest and it worked fine.

Then I tried compiling Quickfort.ahk to an .exe. As long as I included the contents of the config subdirectory, it works fine and it's only 860 KB total. And one does not even need AutoHotkey after compiling. This saves about 20 MB (a savings of over 2400%)! Even keeping the "blueprints" and Chromafort directories, that's still only about 1157 KB (saving about 2000%).

It runs, but I haven't tested it fully. The only downside I see is that it would be Windows-only. Is the AHK version missing some features? Perhaps it has less config options?

Edit of Edit:
I found out about the free MPRESS .exe compressor. Using that with AutoHotkey's Ahk2Exe tool compiled Quickfort.ahk to a mere 319 KB (compared to the usual 711 KB) and it still works. Combining that with the config subdirectory and the "blueprints" and Chromafort directories would be only about 765 KB in total! 

Ah, but that still leaves the qfconvert tool. I did manage to use MPRESS to compress the .exe from 2959 KB to 2376 KB by using the "preserve EOF data" switch and it still works. (It won't run if the EOF data is not preserved.) But that's not much savings when one considers all the large .pyd and .dll file dependencies...

[mordrax]

Hum... thought I should just mention my install experience on linux

followed instructions on wiki to install on linux, specifically ubuntu 12.10
getting python 2.6.4 was a major pain because you can't just install it along side 2.7.3
so installed pythonbrew,
tried to run qfconvert, needed numpy,
couldn't install numpy because of a http connection issue when running pip install numpy
googled and found you need libssl-dev, installed that
re compiled 2.6.4, install numpy, ran qfconvert, worked, yayay
so this was a couple hours later

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?

itching to apply it to my next fort, will report back if errors

[joelpt]

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?

I don't think this is possible at present with Quickfort. I'm adding this to the list of possible todos for the next version. I suspect it will be a pretty trivial thing to add.

also a question, could i stack "in one worksheet",  #build, #place and #query?

Not at present, though I have considered supporting some sort of "all in one" blueprint, where you could for example use something like "d;b;;r" in a single cell to perform Dig; build Bed; (place no stockpile); make a Room. Of course due to how DF works, each phase would still have to be executed in a separate pass manually, once the dorfs actually finished the prior phase(s).

I think this style of blueprint could definitely be useful in some cases, though I imagine it could also be a nuisance in other cases; for example it may sometimes complicate modifying existing detailed blueprints.

Nonetheless, if the blueprint designer gave due consideration to the tradeoffs of using such a "#all" blueprint, I think it could prove quite useful. Also, QF is a power tool for power users, so I'm of a mind to give QF users as much power as possible, and let them deal intelligently with the possible downsides of that added flexibility.

[joelpt]

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

[joelpt]

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?

Thanks for your notes on the Linux install process. I will look into streamlining the Linux install process/instructions for the next release; your notes give me a good starting point.

In particular I would like to see if it is possible to utilize pythonbrew and/or virtualenv to create a simple installation Python or bash script that performs all the necessary steps to get QF running on a "bare" Linux system that has nothing more than Python installed (or perhaps even installs Python if it's not already). I haven't got much experience with using these tools yet so I'm not sure how feasible this is, but it seems doable from what I have read.

Also, I agree there is no reason that QF should be dependent on a specific Python version, and indeed I would like to make it work on any version of Python from 2.6.4 up through the latest 3.x versions without complaint.

[Nokao]

Hi there !

I'm trying to create a Mega-Project for quickfort, first file is a 91 tile wide and deep designation. I nearly finished that.

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.

I ask you if it's a known limitation, and if there is any hope to remove it somehow.
I CHECKED and with smaller hxw size it works with more than 20-30 levels, so actually the problem is my total lenght (91x91x91)=753571
but also making something like 200 levels of 10x10 takes to the same result.

ATM, I resolved splitting it into 3 files, but 3 files for digging, 3 files for building .... 3 files for query ... it will became too much hard, expecially because I also want to make some special files for the beginning, so it actually became a replicable mega-project indipendent (as much as possible) from the world generation.

So I kindly ask you for a solution ! or either advices on making a special version for me with bigger indexes.

p.s.
i'm windows 7 64 bit with 6 Gb RAM (4 free). I'm trying now to understand if it's a QuickFort limit or if it's free-ram-related or if it's related to OS's push-pop paging.
in this last case is it possible to use the actual python script from windows command line ? will it be better ?

p.p.s.
my guess as a programmer is just that QuickFort while doing it's endless while cycle reading my file, goes into a state of "index overflow", a possible easy solution would be to change that index to a bigger vartype, but I don't know nothing of python and neither I'm sure of my diagnosis.
Another idea is .... why instead of going down in "vertical scroll" you don't use "excel tabs"? So that instead of scrolling down you do change tab to change level. This idea of course is also usable for another great task "first tab is always dig" "second tab is always build" "third tab is always query" etc