Print

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

[soundandfury]

lessee...16*48 = 768 tiles wide maximum embark.
6*48=288 tiles wide standard embark. >,,>
Height...that's decent for most purposes. I know I have maps with 180Z to work with and some reportedly have more.

Well, it'll become more configurable when the allocation is properly dynamic (right now it just allocates 8MB of space and only uses what it needs).  In theory, the next version should be able to do as big a map as you can fit in your memory... assuming I get round to putting that into the next version.

If mechanical things(windmill, waterwheel, screwpump, mechanism, axles) aren't in, then they should be- it'd be a HUGE selling point for DF engineers if you managed to add some checks useful for that sort of thing. But that may be beyond the scope of this proyekt.

That... is an awesome idea; thank you!

[CobaltKobold]

I'm sure we'd forgive you for missing how windmills malfunction. But noticing whether it should be powering, and power requirements, are all easy things to determine (well, aside from "does site have wind and how much"-windmills are powered if Outside- which means nothing that blocks a fall is over it.

If you get to buildings, you'll want to start tracking what tiles are solid.

[Askot Bokbondeler]

maybe you couldn't say how much power is generated, but it wouldnt be much trouble to calculate and output how much power is required from a windmill

[CobaltKobold]

You only miss the 0/20/40ness of it. Whether a windmill will generate power beyond that is easily discerned.

So, make an option for windmills: "0/20/40" power.
Windmills: Generate (0, 20, or 40), require 0. Transmits power to square below center, e'en when blocked by floor.
Waterwheels: Generate 100, require 10. Transmits power...I dunno.
Screwpumps: Require 10. Transmits power in all (non-blocked) directions
(Millstones): Require 10. Transmits power in all nonblocked directions.
Gear assembly: Requires 5. Can be toggled in connectivity if lever hooked up to it. Transmits through all nonblocked.
Axles: Require 1/tile, transmits along the axis at least- can be in x/y/z directions.

[soundandfury]

0.10 adds dynamically allocated maps which can hence now be huge... up to 2048x2048x256 (that big enough for you?), a DF-TILES display mode (which uses a hacked-up version of one of Toady's curses font pngs, which means you can tweak the tileset if you like, maybe even make it look like Mayday tiles or whatever), and general bugfixes and improvements.
Link at top of thread.

[soundandfury]

0.11 adds colour rendering to DF-TILES mode, so now beds are brown, grass is green, and so on...
General tweaks and adjustments.

[Dakk]

Few quick questions, I realize this is a alpha, but here goes anyway:

How do I build contructed walls?

How do I (or can I) move between Z levels?

Can I have a bigger area to build in?

Also, it refuses to load the maps it came with, at least for me 

[soundandfury]

>How do I build contructed walls?
just use the 'r' tool (rock) - anything above ground level will be treated as a wall rather than rock

>How do I (or can I) move between Z levels?
use < and > (shift-comma and shift-fullstop)

>Can I have a bigger area to build in?
run with command line options - see the readme

the above questions also suggest another course of action: rtfm might be a good idea.  between them, the readme and the built-in help (press 'h') should tell you everything you need, including 2 of the 3 things you just asked.

>Also, it refuses to load the maps it came with, at least for me
they might have Unix line endings on.  If you're on Windows, try running them through a unix-to-dos converter; there are several in existence.  (I have not heard of others having this problem with the maps)
Also, check that you're loading the '.dfd' files, not the '.txt' files.  The '.txt' files are a human-readable representation exported with the 'x' command; they cannot be re-imported as some information is lost.

[[NO_THOUGHT]]

Does this have a way to take the exported plan and have it designated into DF or is it just* a planner?

*albiet the most amazing planner in existence!

[soundandfury]

Does this have a way to take the exported plan and have it designated into DF or is it just* a planner?

Just a planner.  Someone did suggest adding a way to export Quickfort .csv files, but somewhere along the line someone has to intelligently handle build order (eg. for towers); it's not feasible to automate that.

*albiet the most amazing planner in existence!

[dyze]

Just a planner.  Someone did suggest adding a way to export Quickfort .csv files, but somewhere along the line someone has to intelligently handle build order (eg. for towers); it's not feasible to automate that.

even an export that only handled a single z-slice would be nice.
one thing, why not just use SPACE to toggle between edit and iso mode? it feels a bit akward right now, having fingers constantly resting on 'i' and 'e'...
and how about some small graphic icons at the bottom for placing doors etc, in addition to the keyboard shortcuts?

anyways great app, some kind of export would make it golden! 

[Innominate]

I am bookmarking this thread.

I haven't looked at any of the DFHack headers, but would it be possible to have DF Designer optionally emulate a DF executive - i.e. occupying the appropriate memory space (obviously not simultaneously) - so that fortresses could be viewed in any visualiser that uses DFHack?

[soundandfury]

I haven't looked at any of the DFHack headers, but would it be possible to have DF Designer optionally emulate a DF executive - i.e. occupying the appropriate memory space (obviously not simultaneously) - so that fortresses could be viewed in any visualiser that uses DFHack?

Well, I'm afraid that would be, for all practical purposes, impossible; firstly, the data would need to be held in memory in the same format as in DF -- which it isn't.  Secondly, DFD would have to 'pretend' to be DF, so that the visualiser thinks it's looking at a DF executable -- which is quite difficult.  Thirdly, I gather DFHack-based apps are a Windows thing, and since it's only through a bit of random hackery that I can get a Windows exe at all, it would be decidedly nontrivial to get one with all the bits in the right places.

What we really need is a standard interface format or protocol for sending DF data.  (Well, no, what we really need is for such a protocol to be built into DF by Toady as well, so that interfaces/vizzers etc don't have to do memory hacking... but we know Toady is a little bit wary of 3rd-party interfaces, so I don't suppose that'll happen).
Then we'd simply be able to pass data from one DF tool to another, which at the moment we can't do. 

Each has its own file formats, data structures, etc.  Anyone want to formulate a standard?  We must have some budding RFC-hounds here?

[soundandfury]

New version 0.11.1 out (download in usual place, links at top of thread), only a minor update: applies dyze's suggested keybinding change: space now toggles between edit and iso modes.  The old use of space, jump to ground z-level, is now on '?'.

Been fairly busy of late so haven't had time to do much work on Designer.  (eg. recently open-sourced my web server 'httpico')

Re dyze: "even an export that only handled a single z-slice would be nice."
But you'd have the problem of inaccessible corner tiles not getting built.  My opinion is that this would make such a feature basically useless, but if anyone sends me a patch I'll be happy to merge it in.

"and how about some small graphic icons at the bottom for placing doors etc, in addition to the keyboard shortcuts?"
I am planning a proper GUI at some point (with actual menus and stuff), but right now the GUI code is very much a fugly hack, so it'll take a total rewrite of some fairly large sections of code.  Fear not though, I do plan to do this when I have time, and I promise you it'll look great.

[soundandfury]

Well, after some discussion on IRC, I decided to put in quickfort export, even though it's a bit buggy and you'll probably have to hand-hack the csv files to make 'em behave properly.  I can't test out the actual quickfort files produced, because I don't have quickfort or AHK installed, but I generated a couple of test files and they look about right.

So, here is DF Designer 0.12.  'y' to export .csv of current zslice, uses some of the cleverness from the floor-plan export code.  Builds for both Linux and W'doze available, in the usual place (see top of thread).

Patches to improve the handling of quickfort .csv export would be much appreciated.