Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 19 20 [21] 22 23 ... 42

Author Topic: [Quickfort] 2.04 released -- now with minecart track support! [DF 0.34.10]  (Read 309544 times)

Aklyon

  • Bay Watcher
  • Fate~
    • View Profile
Re: [Quickfort] Version 2.00pre5 released
« Reply #300 on: June 19, 2011, 09:48:16 pm »

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)
Logged
Crystalline (SG)
Sigtext
Quote from: RedKing
It's known as the Oppai-Kaiju effect. The islands of Japan generate a sort anti-gravity field, which allows breasts to behave as if in microgravity. It's also what allows Godzilla and friends to become 50 stories tall, and lets ninjas run up the side of a skyscraper.

Root Infinity

  • Bay Watcher
  • Why?
    • View Profile
Re: [Quickfort] Version 2.00pre5 released
« Reply #301 on: June 20, 2011, 06:02:00 am »

Is there any way to be able to minimise DF while Quickfort is running? Macro mode seems to stop as soon as I move the mouse...
Logged
Classic Medieval sexist views are awesome when they work out in your favor.
Noone likes my witty comments enough to sig them.

Dr. Hieronymous Alloy

  • Bay Watcher
    • View Profile
Re: [Quickfort] Version 2.00pre5 released
« Reply #302 on: June 20, 2011, 08:25:34 am »

Re: quickfort depository --

what about setting up a public-access Google Documents spreadsheet archive?
Logged

joelpt

  • Bay Watcher
    • View Profile
    • Quickfort homepage
Re: [Quickfort] Version 2.00pre5 released
« Reply #303 on: June 20, 2011, 08:52:28 am »

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)
Having it in a general folder would certainly be nice; would it be a pain to have it both ways?

Re: quickfort depository --

what about setting up a public-access Google Documents spreadsheet archive?

That's not a bad idea.


I've thought about adding a built-in 'community blueprints browser' in a future Quickfort. Basically something that's at least as simple as the Windows file browser, but browses through some folders on a public ftp site or website and shows blueprint previews.

If we go down this path, I'd eventually like to see stuff like descriptions, ratings and comments on the blueprints. And though there are probably some free/cheap third party services that would support all this, I generally don't like the idea of writing code against a service that might cease business in future (see: drop.io).

I would consider abusing something like Google Docs to pull it off, though its UI is not really set up to handle descriptions/rating/comments. A mashup using Google App Engine and Google Docs might do the trick though.

Aklyon

  • Bay Watcher
  • Fate~
    • View Profile
Re: [Quickfort] Version 2.00pre5 released
« Reply #304 on: June 20, 2011, 09:46:18 am »

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)
Having it in a general folder would certainly be nice; would it be a pain to have it both ways?
Not at all.
http://www.wuala.com/Aklyon/Public%20Stuff/Blueprints.rar/
http://www.wuala.com/Aklyon/Public%20Stuff/Blueprints/
There you go.
« Last Edit: June 20, 2011, 09:49:23 am by Aklyon »
Logged
Crystalline (SG)
Sigtext
Quote from: RedKing
It's known as the Oppai-Kaiju effect. The islands of Japan generate a sort anti-gravity field, which allows breasts to behave as if in microgravity. It's also what allows Godzilla and friends to become 50 stories tall, and lets ninjas run up the side of a skyscraper.

joelpt

  • Bay Watcher
    • View Profile
    • Quickfort homepage
[Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #305 on: June 21, 2011, 02:48:47 pm »

Quickfort 2.00 has been released!

> Quickfort 2.00 "final" download & user manual


Quickfort 2.0 is a major rewrite of Quickfort 1.11.

The new blueprint conversion engine 'qfconvert' has been rewritten in cross- platform Python, enabling non-Windows users
to utilize the app via the command line. More importantly, the use of Python made possible a much more advanced
implementation of how Quickfort does its job.

The new conversion engine is much smarter about how it designates your blueprints. Instead of using the "typewriter"
(line-by-line) approach of QF1.x, QF2 now tries to minimize the total number  of commands/keystrokes sent to Dwarf
Fortress. It does this by designating the largest contiguous areas/"chunks" possible while minimizing the distance
travelled between areas whilst designating.

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.

The new engine also has a reworked blueprint transformation framework which supports things like blueprint rotation and
tesselation.

Lastly, QF2 supports outputting and executing DF macros instead of sending keystrokes to the DF window  (QF1.x style).
This results in blueprint playbacks that are faster and more reliable vs. keysending. Since DF macros are native to DF,
they can be used on any OS that runs Dwarf Fortress. Keysending is still used by the Windows-only Quickfort GUI for
certain operations, i.e. Alt+V "visualize".

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.

A list of the shiny new bits:
  • Conversion engine rewritten in cross-platform Python
  • Smart designation: ~400% fewer DF commands required versus QF1.x for the same tasks
  • DF macros support: faster, more reliable, works cross-platform
  • XLS/XLSX (Excel) workbooks support makes it easy to bundle multi-phase blueprints
  • Improved Windows GUI, including enhanced blueprint info/select GUI and shrinkable mousetip
  • Alt-R repeat syntax expanded to support basic transformations, e.g. `fliph flipv 2e`
  • Alt-T command line supports multi-row entry, e.g. `dig d,d#d,d`
  • Multi-cell buildings can be plotted in multiple cells instead of from the 'center' tile
  • Build logic and keystroke/macro mappings configurable via config files
This new codebase for Quickfort 2.0 will enable lots of interesting new features and experiments in future releases.
Features such as '#all' blueprints, '#meta' blueprints, and an Undo mode are all on the 2.x release schedule.

I encourage you to use the issue tracker for any bugs or feature requests you'd like to submit.

Enjoy!

Changelog since 1.11:

### 2.00 (2011 June 21) ###
  • Updated documentation (readme.txt) covering all new 2.00 features.
### 2.00pre5 (2011 June 19) ###
  • Optimized how Alt+D works: we now only call qfconvert the first time a conversion needs to be performed, and will remember/reuse that result for subsequent uses of Alt+D.
  • Made Alt+T command line's temp file not affect the remembered last file/folder.
  • Made keysending start faster by reducing a few Sleep durations.
  • Improved in-QFAHK Alt+R help text.
  • Changed >> TRANSFORM: in tooltip to ALT+R: (more consistent with ALT+T text in command line mode and is a helpful key hint)
  • Changed default PlaybackMode for new users from key to macro.
  • options.txt tidy-up.
### 2.00pre4 (2011 June 17) ###
  • Added Alt+T command line support with new multiline ability: dig d,d#d,d  digs a 2x2 area
  • Full support for QF1-style aliases.txt is back.
  • The included aliases.txt has been updated to work correctly with DF 0.31.25 and a few new aliases were added. Please review the new config/aliases.txt as the format has changed slightly and a few aliases have been renamed for consistency.
  • Alt+R gained new syntax: halign and valign. This solves the problem with non- square blueprints failing to work with e.g. rotcw 2e 2s.
  • Build configuration, keycode mappings, and other config files externalized to config/ folder.
  • Proper quote handling in CSV files (thanks bakergo).
  • Various bug fixes, performance improvements, and UI tweaks.
### 2.00pre3 (2010 July 31) ###
  • Major rewrite: The code structure and flexibility has been massively improved (no more single monster AHK script).
  • Linux/Mac support: the code is now split into an AHK portion (*Windows only* GUI, for now) and a Python portion (cross platform blueprint conversion tool). Linux/OSX users can run `qfconvert.py` to convert blueprints to DF macro files.
  • Smarter playback: Quickfort now tries to be smarter about its building strategy to minimize keystrokes, utilizing some simple pathfinding logic coupled with a strategy of constructing the largest areas possible.
  • DF macro support: QF2.0 can convert blueprints to DF macro format (DF 0.31+). Set `[MACRO__MS:0]` in your `data/init/init.txt` for best performance. At least for this release, Alt+K in the QF GUI will toggle between macro and keystroke playback modes.
  • Excel support: QF can now read blueprints in Excel formats (.xls, .xlsx). The Windows QF GUI supports selection of specific worksheets within Excel files. `qfconvert.py` also takes a `--sheetid` argument for this purpose.
  • GUI, revisited: The Windows QF GUI has been redesigned. One important difference is that the function of the Alt+D key has changed. Alt+F is now used only for opening (changing) blueprint files; Alt+D is now used only for playing the current blueprint. This lets Alt+D work a bit more like a "stamp" tool; you can use Alt+F once and then Alt+D repeatedly. This is likely to catch up QF 1.x users at least once ;) but I think you'll come to like it quickly.
  • 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.
  • 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.*
  • Safer material selection: For multi-cell constructions like a 10x10 floor, QF2.0 uses a more reliable material selection mechanism which should reduce the frequency of "out of this material" playback failures. Essentially it now hits +{Enter}{Down} during material selection `sqrt(# tiles in area)` times. This should make out-of-mat fails very infrequent, though you can end up building stuff out of multiple mat types if you don't take care with stockpile/mat proximity.
  • Multi-cell auto expansion: Workshops and trade depots can now be constructed by populating all the blueprint cells that the object should occupy in the blueprint.
« Last Edit: June 21, 2011, 03:01:04 pm by joelpt »
Logged

Root Infinity

  • Bay Watcher
  • Why?
    • View Profile
Re: [Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #306 on: June 21, 2011, 03:25:29 pm »


[Neat stuff]

  • Smart designation: ~400% fewer DF commands required versus QF1.x for the same tasks

[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]

  • 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.*
If you upload the template at least I'd be more than happy to start making modules for it...
Why was it shelved anyways?

Looks great by the way!

EDIT: Can you put in a function to just export the macro to DF, with a custom name?
« Last Edit: June 21, 2011, 03:28:08 pm by Root Infinity »
Logged
Classic Medieval sexist views are awesome when they work out in your favor.
Noone likes my witty comments enough to sig them.

Thundercraft

  • Bay Watcher
    • View Profile
Re: [Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #307 on: June 21, 2011, 07:19:17 pm »

Nice!  8)

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:

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

The "Keystroke (construction speed) optimizations" or something similar should definitely be mentioned because this 2.00 release has a lot of speed optimization.

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

joelpt

  • Bay Watcher
    • View Profile
    • Quickfort homepage
Re: [Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #308 on: June 21, 2011, 08:48:55 pm »

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

Quote
If you upload the template at least I'd be more than happy to start making modules for it...
Why was it shelved anyways?
Couldn't decide on a template! :D

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.

Quote
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

joelpt

  • Bay Watcher
    • View Profile
    • Quickfort homepage
Re: [Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #309 on: June 21, 2011, 09:01:34 pm »

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:

* Simple "command line" entry
* Minimalist (and optional) GUI
* Keystroke (construction speed) optimizations
You're right, these bullet points were wrapped into other bullet points.

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

You could also use qfconvert.exe directly at the Windows command line.

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

Quote
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?
Yes - and definitely in the case of the 'automatic area expansion' you mention. QF1.x would freak out just thinking about it.

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

The Modular series will very probably be released as XLS or XLSX.

Aklyon

  • Bay Watcher
  • Fate~
    • View Profile
Re: [Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #310 on: June 21, 2011, 09:12:20 pm »

XLS please. XLSX will just cause compatibility hoopla.
Logged
Crystalline (SG)
Sigtext
Quote from: RedKing
It's known as the Oppai-Kaiju effect. The islands of Japan generate a sort anti-gravity field, which allows breasts to behave as if in microgravity. It's also what allows Godzilla and friends to become 50 stories tall, and lets ninjas run up the side of a skyscraper.

Thundercraft

  • Bay Watcher
    • View Profile
Re: [Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #311 on: June 21, 2011, 10:19:38 pm »

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.

This has a lot to do with personal preferences. Some players like to build vertically, so they'd prefer something like 10x10 or 15x15. But some players want room to expand horizontally or prefer to see a lot on the same level instead of changing levels constantly. They might prefer something like 20x20 or 30x30. Personally, I feel that 15x15 is too small, while I find 20x20 or 30x30 more appropriate. However, I don't always play the same and sometimes I go for small layouts.

That said, there are a number players (including myself) who feel strongly that most hallways should be at least 3 tiles wide. If they're anything less, then any areas with traffic will cause dwarves to run into each other and re-path constantly, causing a significant drop in FPS. (The only exception being low traffic areas, such as seldom-used corridors to isolated bedrooms.) But 3-tile wide corridors naturally suggests a cross pattern (North-South and East-West corridors) and that results in an odd number of tiles for dimensions. So instead of 20x20 or 30x30, it'd be more like 19x19 or 29x29. Some of us absolutely refuse to consider blueprints with corridors 1 or 2 tiles wide.

I'm just saying there are a number of players who are much more concerned about maintaining good FPS and having their dwarves finish hauling jobs and get to their destinations faster than worry about making Shift+<movement key> work well. Consider that FPS death is still a leading cause of fortress failure (for older, established forts) and that each new release of DF is larger and with more features (theoretically making FPS worse). Many of us cannot afford to buy a new computer every other year and ToadyOne is not likely to address these FPS issues for a long time yet, either.

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:
Spoiler (click to show/hide)
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.
BTW: I see nothing wrong with having, say, 30x30 or 40x40 size sleeping levels and smaller levels (such as 20x20) for all other levels... Well, except that any stairs near the corners would not line up with other floors, making a large central stairway important.

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

Anyway, it sounds like you did not even consider 3x3 staircases (to go with 3-tile wide corridors). I've looked at a lot of fortress maps, DF YouTube videos, and fort designs and a surprising number of them use a 3x3 central staircase. At least with recent DF versions, they seem more common than a 2x2 central staircase design.

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

As you said, the problem would be funneling that traffic through a 2x2 stairway to the surface. But this is less likely to be an issue with a 3x3 central staircase going all the way from the surface to the bottom. Even if it has 1x1 staircases in the corners, the 3x3 central staircase should be able to handle the traffic volume to and from the surface.

Another solution might be to have a completely enclosed (with roof) surface level with one or more bridges as the entrance(s). Depending on the design, the corner staircases could be functional as there might be a need to go to the roof, such as for marksdwarves to reach the fortifications in order to patrol them.

(BTW: Personally, I like the idea of using the central tile of a 3x3 staircase to build an automated waterfall system to keep dwarves happy.)

Edit: Oh, and another reason why I prefer odd-numbered dimensions (such as 19x19 or 29x29) in blueprints is it makes it easy to center it. For example, I like to use something like:
Code: [Select]
#dig start(4; 4; Center tile of a 7-tile square)
« Last Edit: June 22, 2011, 04:09:38 am by Thundercraft »
Logged

Root Infinity

  • Bay Watcher
  • Why?
    • View Profile
Re: [Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #312 on: June 22, 2011, 06:23:53 am »

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

Quote
If you upload the template at least I'd be more than happy to start making modules for it...
Why was it shelved anyways?
Couldn't decide on a template! :D

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

FAKEEDIT:
Why don't you do a 21x21 grid? That way you can simply overlap blueprints if you want to get 2x2 corridors (as one can assume that all edges are only corridors with stairs at the corners anyways)

Also, regarding the "funneling" problem - this is not so much of a problem if you do a ~4x4 grid of the 20x20s, with one central 3x3 staircase with the others being only 2x2 or 2x3/3x2.

Quote
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
Thanks again!
Logged
Classic Medieval sexist views are awesome when they work out in your favor.
Noone likes my witty comments enough to sig them.

Dr. Hieronymous Alloy

  • Bay Watcher
    • View Profile
Re: [Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #313 on: June 22, 2011, 06:47:12 am »

For modular blueprints, I've found that a 11x11 grid works best, i.e.,


Code: [Select]

X.........XX.........X
.#########..#########.
.#...#...#..#...#...#.
.#...#...#..#...#...#.
.#...#...#..#...#...#.
.#########..#########.
.#...#...#..#...#...#.
.#...#...#..#...#...#.
.#...#...#..#...#...#.
.#########..#########.
X.........XX.........X

It's a perfectly modular design, it's incredibly space-efficient, it has double-width corridors and lots of up down stairs for movement, and each 9x9 block can be subdivided however you want, whether into 3x3 workshop rooms, the center carved out for a 5x5 shop or kennel or whatever, or cut into parallel line sections for bedrooms. I don't use this design myself any more because it's boring, but it's the best overall modular design I'm aware of.

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.
« Last Edit: June 22, 2011, 07:15:50 am by Dr. Hieronymous Alloy »
Logged

Thundercraft

  • Bay Watcher
    • View Profile
Re: [Quickfort] Version 2.00 released! DF 31.25 compatible
« Reply #314 on: June 22, 2011, 01:15:01 pm »

For modular blueprints, I've found that a 11x11 grid works best, i.e.,

Spoiler (click to show/hide)
Now I understand what was meant by "modular".  :D

Interesting... I could envision a variation of designs like this with 2-tile wide corridors that would allow users to overlap them into either 2-tile wide, 3-tile wide, or 4-tile wide corridors, depending on preference. Still, the corridors along the periphery would remain 2-tile wide unless manually dug out further.

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.

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.

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.
« Last Edit: June 22, 2011, 01:31:09 pm by Thundercraft »
Logged
Pages: 1 ... 19 20 [21] 22 23 ... 42