Print

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

[MOK]

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...

[Aklyon]

Yes, I have. The folder itself is public, the file is public, and the download link for the file works if you click on it.

[MOK]

I used the link on the first page.  That goes to a mediafire location, but gives me nothing.
Your link, however, gave me the .rar.  Thanks!

[Aklyon]

Seems like its a mediafire problem, then. Joelpt, can you use the direct link to the file instead?
The folder apparently appears as empty to everyone but me.

[joelpt]

Seems like its a mediafire problem, then. Joelpt, can you use the direct link to the file instead?
The folder apparently appears as empty to everyone but me.

Changed in this thread's original post. I'll change it in the readme for the next release.

[joelpt]

What is the correct way to represent

Hives alt-h
Stone slabs alt-s
Floor bars alt-b

into build blueprints

Oops. I thought I had accounted for these but evidently I didn't.

Until the next QF release, you can add the 3 keycodes you mentioned yourself ... edit your quickfort/config/keys.json and insert 3 new lines at line 74 for those keycodes.

Before:

Code: [Select]

        "<": "<",
        ">": ">"
    },
    "key": {

After:

Code: [Select]

        "<": "<",
        ">": ">",
        "{alt b}": "4:b",
        "{alt s}": "4:s",
        "{alt h}": "4:h"
    },
    "key": {

Then, in your blueprints, put {alt b} in cells where you want to place floor bars, {alt s} for slabs, {alt h} for hives. Case is irrelevant; you can use e.g. {Alt B} if you prefer.

I'll add generic support for {alt X} style keycodes in the next release, so that if Toady adds new alt-codes in the future it won't require modifying keys.json.

[chewie]

Hello

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?

(Mind you, I haven't actually tried this, I only read the manual and it gave me the impression that there's stuff missing.)

[Flavio]

I'm having problems using .xls and .xlsx files with the new version.
When I try to load a file this error appears:


So far I'm using 2.03, this one works fine with those files.

[LordBaal]

I found that those

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   

Errors are only errors to display the file. If you open the .tmp file with notepad you will see the resume that quick fortress shows you how many times this or that command is used, the start position and the commentary (if any). Regardless of the error, you can still press alt+d and the blueprint will be executed flawlessly (if you previously opened another blueprint, any blueprint, more on this next*), so it's more a annoying bug than a fatal one. My guess is that is related to the size, I'm executing a huge arse blueprint with more than 20 levels (it's an entire fortress made to be easy on the eye, not taking into account much efficiency), but I could be wrong.

*If you open Quickfortress and the first thing you try is to load a faulty blueprint the program will show the error and you won't be able to use the blueprint. That is, if you press alt+d nothing will happen.

Ok, how to make those blueprints that turns out in the error work?
Easy, load any working blueprint first, then load the offending blueprint, get the error, press accept and then simply press alt+d. The blueprint will execute just fine. This is working, at least for me.

[Aklyon]

So its not as much an error in the formatting as it is your file is dang huge compared to what QF is expecting.

[LordBaal]

Oh yes... it's demential! Although I reduced the deep to 15 levels to reduce a little the risk of running into a cavern. It's about 100 x 100, with 15 levels... of course a lot of the levels are merely stairs. However the thing goes crazy when I try to put the furniture for the:
- 256 small rooms for poor dwarfs and the twelve dorms with space for 108 of the most needed souls.
- 128 medium rooms for the middle class dwarfs, with more space and value
- 18 noble rooms, with their own office each
- 24 jail cells, 3x3 bed, chair and table made from a central chain and food and booze stockpiles to prevent dwarfs from dying thanks to an stupid noble, but also preventing said noble from trowing tantrums.
- 28 hospital beds with 10 operation tables and 10 traction benches.

Total: 510 dwarfs of installed capacity.

In the process I made an aliases to designate dormitories (dorm) and prisons from chains, making them a room then assigning them to the justice system.

I bought 8 gigas of ram only for DF and Shogun 2 to run better on my machine

P.D. the main dinning hall has 136 seats... it's just ridiculous... I know it's not the biggest thing out there there should be bigger fortress, but still I'm thinking in reducing the whole dam thing about in half (the dinning hall, hospital and prison should remain the same although).

[Barrow]

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.

[joelpt]

I'm having problems using .xls and .xlsx files with the new version.
When I try to load a file this error appears:


So far I'm using 2.03, this one works fine with those files.

(edited)
Upon investigation this doesn't seem to be xlsx-specific, but I'm not sure just what the problem is yet... Blueprints/Tests/excel-test2.xlsx fails but Blueprints/Tests/obama.xlsx works fine.

Guess it's time to implement some proper unit tests for QF ...

Would you be willing to post your monstrous blueprint or send it to me at quickfort@joelpt.net? I'd like to test against it before releasing 2.05 just to make sure it can load and run properly after this bug is fixed.

[Aklyon]

.xls is a better format for compatibility anyway, The only thing I know that specifically uses .xlsx is Office 2007 or newer.

[joelpt]

.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...