Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - sphr

Pages: [1] 2 3
1
DF Modding / (request) stockpile utility
« on: June 27, 2010, 11:52:20 am »
Thank you for the attention, and now on with the topic...

let's face it, stockpile is one of the core elements in Dwarf mode gameplay and it is far from perfect.  Try creating a stockpile to accept only fat and not extract and you get what I mean.... LOL

Of course, stockpiles weren't the most serious problem.. Labor management is... or was, until the coming of Dwarf foreman/manager/Therapist.  I think that is an example of how a tool becomes integral to game play (no labor manager, no gameplay for me.... at least not without restricting total population to like 20...)  Now, I was hoping that stockpiles could be similarly tackled.

To start of, this is a modest list of features that could be helpful, other more advanced ones can be built on later...  Only the first point is essential at the moment.  The 2nd point onwards are just for ideas and Christmans wishes...

1) Copy/Paste/Import/Export stockpile settings.  Sometimes, after you've taken like 10 minutes like going through the list of "fat"s of a hundred creatures, you don't want to go through it again when you find you need to create another similar stockpile.  The custom stockpile is not really that useful for this.  It would be useful if we can just say point a cursor at a stockpile and copy the settings (export to external files if need be to be imported in later if we want) and then point at another stockpile and "paste" the settings.  I think that exact stockpile structure is only static per world-gen, but we can expect that users will only copy/paste/import/export within compatibles...  bonus if tool can persistently remember preset/previously-exported stockpile settings e.g. "Bins", "Barrels", "Masterwork Steel Weapons", "Artifacts-Only" etc.. a good library of stockpile settings is .... well, I'll leave it for you to judge how useful it could be to you.

2) Extend/Merge stockpile (and of lesser priority, reshaping/moving stockpile).  This is actually more of a convenience if the 1st point is already available.  Currently, to "extend" a stockpile.. we have to remove existing one and rezone another on top, then proceed to laborously copy the stockpile settings from human memory.  1) relieves the player memory part, by pasting in complex settings previously captured.  To take it even a step further, let player just indicate where to extend (or in general, reshape or even move the stockpile to another place entirely) with all the settings in-tact.

3) Potential advanced/dangerous options (Not likely to be feasible, but just for fun...)
Currently stockpile taking from other stockpile have the following limitations:

a) Each "giver" stockpile can be the source of only exactly one "taker" stockpile.  No "distribution".
b) There is no control over the quantity in the stockpile.

Without requiring new in-game features, we can make use of the stockpile's "take from" if we can somehow gain a list of items from within each the stockpile (help from mem hackers).  Then have the utility set up simple checking rules that activate periodically and changes the in-game "take-from" accordingly if conditions are satisfied.  e.g. A master "distributer" stockpile could me made to supply a number of "retailer" stockpile, where the retail stockpile that needs the goods most will "take from" the master stockpile.  (And if everybody have above at least some threshold number of items, the "take from" will be broken).

We can set up relationships like :
i) auto-balance across N stockpiles (e.g. for food/booze and ammo, or something like feeder stockpile for different workshops which are not close together). Goods are moved from high density area to low density area if difference exceeds a safety threshold (won't want to keep having the stockpiles take from each other non-stop, unless until hauler gains skill/attribute for hauling)
ii) distributor-retailer which is a special variant where goods are only taken from a master stockpile by the child stockpile with the greatest need.

hope I get the idea across...
Now, back to that never ending list of forgotten beast fat and extract...

2
DF Suggestions / Giant Trees (with integrated poll)
« on: April 09, 2010, 01:30:24 am »


Was somewhat inspired by "Animal Justice" that triggered a link to "Avatar the movie".

The idea is to shift the lime light away from the underground mining which is predominantly dwarven, to say allow either something like a colony of elves or just dwarves turned into tree-hugging hippies.



The idea, is to make giant trees, which are not like the normal trees which are just 1 tile entity, but have physical 3D structure in the terrain.  E.g. imagine a whole magma pipe turned into "wood" type of material (when "mined" ) and pull that whole thing half way above ground, (above ground is the tree trunk, those that remains underground are roots).  Then high up, we can have some vertical "branching, using the "wood" type material again, and end with leaves (which may not be visible, but would be interesting if it can become some some sort of semi-persistent farmables).  Those part that remains underground will also have "branches" which are roots. (i.e. the trees will have to be generated during the time stuff like magma pipes are generated)

As a kind of organic dynamics, giant trees lives forever even without water (they just become dormant without any leaves) When there are place to grow leaves and some root part is in contact with water, it will slowly ABSORB the water at the root, and "grow" leaves automatically.  Would be interesting if banches, trunk and root can grow too, but it can be taken that the growth of the giant trees are so slow that it is not detectable in the lifespan of a dwarf. (until the time where terrain changing dynamics like erupting volcano is done, then perhaps actual tree growing can use same dynamics).

What does it enable in-game?

  - Tree-colony style playing
  - When tree trunk/branch/root tiles designated to "mine", it will require "woodcutter" skill instead of "miner" and yields "log" (perhaps a raw kind of wooden block?) Perhaps smoothing/carving should require carpentry skill while engraving should require the "wood crafter" skill?
  - carve/"dig" rooms in large tree trunks (maybe not as large as underground, but you get many levels!), open platforms that extends of edge of tree trunk/branches, linking walkways that links between trees above ground (it is also possible the giant trees which are closeby and have large crowns will have branches that naturally "touch" each other forming natural linking walkways)
  - tree-huggers who are opposed to actually harming the wood can grow their colony by building AROUND the trunk (e.g. a spiral stairway consisting of up/down stairs and open walkway that spirals up the surface of the trunk, and have larger platforms with housing on the branch levels (which have more horizontal "terrain")
  - leaves can be seen as a kind of harvestable wild "plant" by itself, except that it cannot be planted and will always grow some the same region, tied to the tree's nutrition (water intake at the root)
  - Tree roots can be used as a natural water-sink that spans z-levels
  - shift of defense focus : from mainly against "OUTSIDE" and "ABOVE" to "SURFACE" and "BELOW"
  - Although a well hydrated giant tree is somewhat harder to burn, a dehydrated tree or persistent fire sources may become a bad, bad combination.  But since there are around for so long (at least as long as any race or megabeasts or even older), there must be some sort of natural counters.  Could add more to the fire dynamics (I'm out of idea here atm)  If not, the possibility setting the whole tree colony on fire could either provide some glee for some evil dwarf, or woe for some hippie elf (Avatar the movie?).
  - Elves could REALLY be the "natural" "white-cells" of the giant trees, evolved to get rid of the bad thingies that will try to harm the trees.
  - rope ladders? retractable staircase that spans z levels in open space, but can be "drawn up" as if a drawbridge. helps to keep non-flying enemies on the ground away from tree colony during invasion.
  - elevator ? like a bucket in a well, except that it can transport people.  fancy version of rope ladders that can span many more z levels.

Other story-drivens beyond usual dynamics:
  - special anti-tree invasions: e.g. enemies which includes some special task force to set fire at certain important sport: the defenders better get rid of them in time (hmmm.. it seems that I MAY be uncounsciously affected by Avatar the movie)
  - special underground raids that intends to harm important parts of the tree roots (more susceptible to dwarf fortress which digs to expose roots and joins up with surface or some underground carvern with possibility of invading nasties).  Or even let the players themselves harm the giant trees.  (though what is the exact effect of harming roots beyond lessening/limiting leaf growth is not decided atm... maybe won't have effect on anything except leaf growth... even when dying, the giant tree will take so long to die that it could still outlive a dwarvern generation or tree)
  - Giant Tree Spiders!!!!!!
  - more possibilities when magic arc comes in.  Giant Trees like this heavily modifies the "mana" concentration or flow or whatever magical crap.
  - monkey colonies? or giant tree-specific eco-culture (like similar before for carverns)

well, that's most of what I can rem off the top of my head atm. feel free to discuss, criticize, add on.  If we get Toady interested enough, it may come up in some future DF versions. :)

more idea images:

Spoiler (click to show/hide)

3
DF Modding / [minimod]: Gender names for domestic creatures
« on: September 03, 2008, 03:33:11 am »
Minimod: Gender names for domestic creatures

Summary
This tiny mod adds gender specific names to domestic animals to make managing them easier. It's so simple that any beginner modder can do this, but I thought I just provided mine as an easy reference.

The original file is based on DF ver 28.181.40c. (should be relatively unchanged from prev versions)

Content
Changes the following names where each row has the format:
(creature):   (male), (female)
dog: dog, bitch                             
cat: tomcat, queen (corrected)
donkey: jack, jennet                           
horse: stallion, mare                             
mule : (no changes as mules are non reproductive anyway)

Note that adjective is unchanged (still the original race name).  What this probably means in common game term is that you will still get donkey leather instead of jack leather or jennet leather.  But I could be wrong :)

Installation

  • Backup {dwarf fortress directory}/raw/objects/creature_domestic.txt.   You
    can restore this file if you want to remove this "mod".
  • Copy creature_domestic.txt from below and replace the content of creature_domestic.txt with it.
  • You need to restart the game for it to take effect!

Uninstall
Just restore creature_domestic.txt (You DID backed it up did you not?)

New content for creature_domestic.txt:
Spoiler (click to show/hide)

4
IMPORTANT: Ahem, first off, those misguided ascii-worshippers, please go elsewhere (back to your shrines perhaps).  I really don't have time for non-constructive stuff like telling you why you are misguided.  DF is great not because it is ascii. So, just ... go.  I'll even throw you a friendly wave.

EDIT::Clarification: This is not an ascii-bashing thread.  It is just to show that a complete graphical presentation which hides all trace of ascii origin is quite achievable.  And this is also not a "My char/gfx set is good" thread either.  It just shows that if I can do it, so can others (and can potentially do a better job)

Now the rest of the story...

After I finally got my hands dirty on character set starting from SL's tileset as a base (which is partially based on guybrush, which I as using, and Flying Mage), and added a bunch of tiles I like from Red Jack's Nintendo sprites, then tweak a lot of things to my liking, and even through in some new tiles (I wanted to make stockpile easier on the eye). 

I also grabbed one of the posted colour schemes on the wiki and just changed the glass colour to a lighter shade of blue.... and when I look at the final thing, I can say that it doesn't seem any bit like the ascii-based game it was... And this is done with the current limitations of hard-coded non-creature tiles and text/object sharing problems even when I used the Accent Removal instructions from the wiki utilities page.  (I tried to keep text disturbance to minimum... X gets an invisble shadow, 0 gets a funny frame ... and O was regretably mutilated to make it join nicely with walls..... and punctuations??? eh.. let's just forget about punctuations....).  Other than the language files, which can be easily reprocessed with each new version, I did not want to change any other raw data (like remapping tree/matgloss symbols) so I had to work with the limits.....

But enough words; a picture tells a thousand words....
http://mkv25.net/dfma/map-3330-steelfortress

EDIT:
in response to a later post:
Have uploaded a "Director's cut" of the gfx and char tileset files I'm actually using right now to DFFD here.  Consists of more than my own work (mainly DR). Manual installation is still required, but probably easier now.

5
DF Bug Reports / [39e] DIPLOMAT gfx tile problem
« on: August 09, 2008, 04:47:58 am »
I got a human diplomat visiting the fort.  For some reasons, it uses the default or standard human zombie tile I defined.  I've looked at the creature details and it only says that it is "human"

I've double checked my custom gfx tile stuff and found only 2 reference to that particular tile:

Code: [Select]
[DEFAULT:HUMANS:0:19:AS_IS:ZOMBIE]
[STANDARD:HUMANS:0:19:AS_IS:ZOMBIE]

I DO have the tile for human diplomat declared somewhere
Code: [Select]
[DIPLOMAT:HUMANS:8:3:AS_IS:DEFAULT]
I figured that either DEFAULT ignores modifier tags or there's something in the tile resolution that is either misunderstood by me or bugged?

What I did was I removed the line for [DEFAULT:HUMANS:0:19:AS_IS:ZOMBIE] and reloaded the game.
Now I see the diplomat as .... a Skeleton.

After fiddling and reloading the game many times, I realised that DEFAULT/STANDARD has special processing rules that I am not sure I understand.  So next I do, I removed all other DEFAULT/STANDARD tiles specifications for ZOMBIE and SKELETON.  Now, the DEFAULT:HUMANS tile is shown instead.  Still not the DIPLOMAT tile...

Anyways, the main question is : despite all the mess up with DEFAULT/STANDARD tile with subtype specified, why is DF not using the DIPLOMAT tile I defined?  could there be a possible spelling error (I rem copying the tag from the graphics_example.txt in the raw).  There are no reports in error log of an unrecognized tile token, so I guess DIPLOMAT is recognized.

In addition to the possible bug, will appreciate if anybody can clarify on the tile selection resolution scheme (based on Race,SkillType,SpecialAppointment,Subtype[guards, royal guards, zombie, skeleton) ? (well, best will be if Toady One has some free time to clarify).  this should be a nice addition to the wiki.

Links:
image on map archive : http://mkv25.net/dfma/poi-6585
human tilepage and tile text data I'm using : http://www.dwarffortresswiki.net/index.php/Image:Sphr_humans.png

6
DF Dwarf Mode Discussion / The incoming human diplomat's a .... Zombie
« on: August 08, 2008, 07:59:01 am »
This is strange.  I've got a message that says

"A human diplomat from Dur Er has arrived."

I zoomed to the creature and see.... a zombie.
I was pretty sure previous merchants don't look like zombies...
I tot it was a tileset problem, and did a thorough check on both bitmaps and tile data text.  Yup, only 2 instances of reference to that tile particular tile:

Code: [Select]
[DEFAULT:HUMANS:0:19:AS_IS:ZOMBIE]
[STANDARD:HUMANS:0:19:AS_IS:ZOMBIE]

I guess since diplomat is not specialized, it used the standard zombie tile...

But zombie?? Have I been trading with an undead kingdom all along??  *shocking discovery*

7
DF Suggestions / [suggest] See creatures 1 level down in empty space
« on: August 05, 2008, 10:58:14 am »
On maps with complex z terrain, it is especially hard to find creatures.  It would not solve, but would help a lot if there is some way of indicating a creature exists 1 z-level below an empty tile.  Sort of like how trees 1 z-level below are indicated in empty squares.  It can be some generic ascii character (creature type unknown, just indicate existence of creatures,  and have to go 1 z level below to see actual type) or some filtering of actual creature tile (e.g. a dither mask applied to actual creature tile to differentiate a creature on this level and a creature 1 z level below in an empty space tile)

In the future, may need some way of indicating things more than 1 z level below when presentation arc gets fleshed, but even 1 level is great now, if it can be easily done (like the trees being handled now)

8
DF Modding / [question] custom graphics for vermin
« on: December 30, 2007, 10:58:00 am »
Is it even possible now? I've tried to create an entry using a vermin's creature tag of which I had two in cages(item in stockpile, not building), but there doesn't seem to be any effects.

[ December 30, 2007: Message edited by: sphr ]


9
DF Modding / [gfx set: Sphr's Goblins v0.1]
« on: December 24, 2007, 01:34:00 am »
download/installation instructions/screenshots

Didn't actually want to do another gfx set so soon, but in my current game, the goblins invades, and I couldn't resist it...  Think what new gfx tiles I do next is very much decided by what things appear in the current game... LOL


10
DF Modding / [new gfx set: Sphr's Dwarves v0.9]
« on: December 21, 2007, 03:25:00 pm »
Only dwarves.  Made it for myself when playing in dwarf mode.

Sample screenshot:
  ;)

(edit: fixed wrong link for 12x12)
(edit: added status screen screenshots)

[ December 22, 2007: Message edited by: sphr ]


11
DF Modding / [memory hacking]: detecting binary version (take 2)
« on: December 10, 2007, 03:00:00 am »
ok, the last attempt at trying to find identity block (searching for a block where the block itself is the data wanted) in DF process VM was not really working out.  This is take two at known version detection:

This time round, I'm using a mixture of binary filesize and crc32 checking.  Crc32 provides the file signature.  Filesize is just an extra safety switch in case two versions ends up with the same crc32 by coincidence.

Here's what I gathered so far, from a quick program:

33a : (crc32:0x0d752a37,filesize:5226496)
33b : (crc32:0x54b3ed5d,filesize:5230592)
33c : (crc32:0x9acba447,filesize:5255168)
33d : (crc32:0xcec9022c,filesize:5259264)

The only short-coming here I guess is that checksum computation could be expensive, but given DF binary's small size, and that I'm using an assembly implementation I got off codeproject, I think it is acceptable (the delay is not really noticeable by human), if it is done only once at the entry point and once again at every re-entrance.

Any suggestions/criticisms/loop-holes?

edit:added values for 33a

[ December 10, 2007: Message edited by: sphr ]


12
DF Modding / [memory hacking] Identifying your own dwarves
« on: December 09, 2007, 04:50:00 am »
Background:
The creature race in creature structure (offset 0x008C in 33b) is used to identify the race of the creature.  0xA6 (unmodded) identifies a dwarf.

Problem:
When retrieving all dwarves with the race, it actually includes dwarves that do not belong to your settlement (e.g. merchants/guards).

1) Was wondering if there is another way to tell these entities apart from the other races?

2) Also, how can one distinguish the Child and babies?

3) How can one retrieve the last name and the active profession?


13
DF Modding / discuss: Future Proofing of (memory hacking)Utilities
« on: December 04, 2007, 11:21:00 pm »
(edit: reformatted some stuff due to code section not being wrapped and causing a wider-than screen-width page)
Not really a modding post,  and more of a tools/utilties post.  But since there are not tools/utilities subforum, and tool/utility topics seem to end up here, so this is where I'll drop it.

BEFORE YOU CARRY ON:
This is meant for present/potential tools/utility developers only  Think that nobody else will be interested.  So save yourself the pain of reading a long post with gibberish-like codes.

==(Limited) Future Proofing of (memory hacking)Utilities==

I am just getting started with re-learning the memory hacking all over again.

One problem I find with trying to create a utility is the rapidly changing version and the need to keep things updated, recompile and upload.

On the user end, they have to deal with multiple versions of the same tool that works for one version of dwarf fortress (I don't know about others, but I keep my previous versions around, in case there are insurmountable bugs in the lastest versions etc etc.)

What I'm thinking of is, instead of hard-coding/static-compiling all the memory offsets into the binary, why not add an optional means of loading a new "Memory Map" from a text file?  If there is any latest updates to the memory map in the latest version, the "config" file could be edited into wiki and people can just copy and paste the config data to make their tools work with latest version if the attributes the tools used are defined.

To make the same config works across different tools, perhaps we can develop a library that accepts well-known attribute names defined by the community.  E.g. Instead of assuming that nick name of a creature is 0x001C from the starting address of a known creature struct data, users of library uses the defined attribute name "first_name" instead.  The actual resolving of the name to actual address offset is handled by the library.  In the ideal case, the library should also provide wrappers to work with these offsets such that the tool developer don't ever have to deal with the address after binding the main dward fortress process.  Or even the process binding part could be part of the library.

====A hopefully motivating example====
This is a mockup of a partial input file that helps define the memory maps for a particular dwarf fortress version

code:

<!--
 The following defines a memory map called  "creature_ptr" which "specializes"
 from a primitve type "pointer" and value_type denotes the memory map
 name of pointed data.
-->

<defmap id="creature_ptr" type="type "pointer" value_type="creature"/>

<!--  
   The following defines a memory map called  "creature_vector" which
   "specializes" from "vector" type.
   A type-specific attribute "value_type" optionally denotes the contained
   type.  If this type does not have a size which is statically known, the
   vector cannot use indexed retrieval and falls back to just being a block
   of bytes
-->
<defmap>

<!--  
   The following defines a memory map called  "creature" which "specializes"
   from a primitive "complex" type.   Complex maps are the only ones that
   can have submaps.
-->
<defmap>
 <submap>
 <submap>
 <submap>
 <submap>
 <other>
</defmap>

<!--
 this defines a memory map called  "main" which "specializes" from "complex"
 type.  Specialized data are contained as children.
-->
<defmap>
 <submap>
 <other>
</defmap>



Code-wise, say after the memory maps are loaded and placed in a registry (and can be retrieved by name), we can then create "memory objects" which is just a particular binding of a specific address/process handle to a memory map. The following is just rough work that doesn't fully make use of all the meta data available in the mock data earlier.


e.g. (c++ on windows platform assumed)

code:

 HANDLE handleDF;
 // proceed to find and retrieve handle for dwarf fortress process and detect
 // version and load correct memory map definitions etc)

 /* for the rest of mock code, assume:
   suffix of Sptr to be shared/smart ptr.
   ??MemMap to be a memory map instance
   ??Object is like a io formatter for a memory address and a particular map

   In short, ??MemMap just denotes where the offsets to certain known
   attributes are, ??Object is the one that tries to interpret a memory
   location as the speicified ??.
 */

   // Optional phase to verify that all things we are going to use are
   // defined.  If not, should probably terminate the application with
   // error messages where appropriate.

   // start of testing.
     MemMapBaseConstSptr mmap;
     ComplexMemoryObjectSptr temp;

     // **** verify main process map ****
     // verify required memmap exists
     mmap = MemMapRegistry::GetMap("main");
     ASSERT(mmap)

     // verify required memmap attributes exists
     ASSERT( mmap->GetMapping("main_creature_vector_loc") );


     // **** verify creature struct map ****

     // verify required memmap exists
     mmap = MemMapRegistry::GetMap("creature");
     ASSERT(mmap)

     // verify required memmap attributes exists
     ASSERT( mmap->GetMapping("first_name") );
     ASSERT( mmap->GetMapping("nick_name") );

   // end of testing

 /*
     Note that each tool applciation does not need to verify the whole memory
     structure.  It only have to verify those that it uses.  For example,
     foreman.exe uses labour settings and professions.  It does not need to
     verify things like inventory or health.
 */


 // call to registry to return shared ptr to a memory map called "main"
 MemMapSpr spDFMemMap = MemMapRegistry::GetMap("main") ;

 if( spDFMemMap == NULL )
 {
   // report error.  memory map not found.
   // redundant if testing is done before
 }
 else
 {

   ComplexMemoryObjectSptr  spMainDF =
     ComplexMemoryObject::New(   0     // no offset address
                               , handleDF  // process handle of dwarfort.exe
                               , spDFMemMap
                             );

   ASSERT( spMainDF != NULL ); // assume no prob

   VectorObjectSptr creature_vector = VectorObject::New(
         spMainDF->GetSubObject("main_creature_vector_loc")
       , MemMapRegistry::GetMap("pointer") ) ;
       // need to specify a map with known size to make vector iterable.

   ASSERT( creature_vector  != NULL ); // assume no prob

   // iterate through creature vector
   for( VectorObject::Iterator it = creature_vector->Begin()
       ; it != creature_vector->End()
       ; ++ it )
   {
     ComplexMemoryObjectSptr creature =
            ComplexMemoryObject::New( PtrObject(*it).Dereference()
                                   ,  MemMapRegistry::GetMap("creature")
                                   );

     ASSERT( creature  != NULL ); // assume no prob

     // retrieve first and nick names
     std::string first_name =
       StringObject(creature->GetSubObject("first_name")).GetValue();

     // declare var for nick name instead to allow easier write back
     StringObject nick =
       StringObject(creature->GetSubObject("nick_name"));

     std::string nick_name = nick.GetValue();

     // change nickname and rewrite it back.  Note that if new string is
     // longer than existing string capacity, it gets truncated.  I don't
     // think it is feasible to try to do cross-process string reallocation.

     nick_name = "Newbie";

     nick.SetValue(nick_name);
     // note: should throw exception if in exception enabled and failed.
   }
 }


The above mockup end-coder code is entire independent on any address/offsets perculiar to a process.

It does still have this shortcoming:
Library user have to know type of attributes... e.g. first_name and nick_name are strings.  ComplexMemoryObject::GetSubObject just retrieve the address.  Currently, application have to interpret that (e.g. as strings) to get the data properly.  If say ToadyOne decides that instead of std::string, first and nicknames are now stored using ICU's UnicodeString.... Bam... broken app.  As a possible extension, notice that "type" is actually placed into the mock up xml data, which is unused atm.  It could be used to switch between how to intrepret the offset address instead of simply assuming it right now...


Feasibility:
Coding-wise, not much problem.  Although I use mockup code in the above, I think they can be turned into real code without much changes as the concepts behind are almost fully thought out.  The most trouble-some part I find will just be the serializing to and from xml/some other text file (labour-wise, rather than design-wise).  The only thing left is that enough tool makers (eh.. at least 2?) have to support this to make the effort worthwhile both to dev the library as well as preparing a new "config file" for each new version.

Anybody game for it?

[ December 04, 2007: Message edited by: sphr ]


14
DF Dwarf Mode Discussion / Tutorial : Stone Organization
« on: November 29, 2007, 09:35:00 pm »
Tutorial : Stone Organization aka How to make your mason use the right stone.

This is something that I feel may be useful to some new/learning players, so I thought I'll share this and also to see if there's any improvements that can be made.

Problem :
===============
1. You got stones everywhere.  Stones piling in newly dug rooms and corridors.  And stones of all kind.  It seems that no matter how big a stone stockpile you make, it overflows too quickly.  Besides, a room cleared of stones looks much nicer.

2. You want to make high quality obsidian furniture.  But due to shortest absolute distance search used by Mason's workshop, you need to maintian a stockpile of the required stone nearest to your mason.  But you will probably want a way to easily swap the "active" stone type easily without any long distance hauling.


The Solution?
===============
What I managed to came up with is a mixture use of stockpile take-orders, garbage zones and haulers.  It is a system that potentially has the following benefits:

1. makes dumping stone somewhat easier (instead of hunting all over the place to dump stone, you always dump and re-claim stone in the same area)
2. makes it easier to switch "active" material for mason's Workshop.

The basic setup:
===============
with a sample 9x9 room size.  feel free to adjust size yourself, also the level order can be reversed.

level z : Mason's Workshop (Or Mechanic's workshop if you want to)

code:

WWWWWWWWWWW
Wmmm......W
Wmmm......W
Wmmm......W
W...W+W...W
W...+X+...W
W...W+W...W
W.........W
W.........W
W.........W
WWWWWWWWWWW


W = wall
m = mason's workshop
+ = door
. = floor
X = up/down stairs

level z-1 : "Active" stone stockpile.

code:

WWWWWWWWWWW
Wsss......W
Wsss......W
Wsss......W
W...W+W...W
W...+X+...W
W...W+W...W
W.........W
W.........W
W.........W
WWWWWWWWWWW


s = "active" stone stockpile.  (don't need to be too big.  but if your mason work faster than you hauler, you should increase the size).  Set this stockpile to reject all stone types for now.


level z-2 : "Reserve stone stockpiles"
This sample stores unlimited number of 4 stone types.  You can use smaller or larger stockpiles depending on the stone type mix of your region.  You can create more reserve stockpile levels below this one to store even more stone types.

code:

WWWWWWWWWWW
Wa11111b22W
W111111222W
W111111222W
Wc33W+W222W
W333+X+222W
W333W+W222W
W333d44444W
W333444444W
W333444444W
WWWWWWWWWWW

1 = stone stockpile 1.  Set to only store a particular type of stone (or types of stone that you don't want to distinguish between).  (Note that this is not a rectangle.  It excludes the top left square)
2 = stone stockpile 2.  similar to 1, but for another stone type.
3 = stone stockpile 3.  similar to 1, but for another stone type.
4 = stone stockpile 4  similar to 1, but for another stone type.
a = 1 square zone acting as "stack", set to active + nothing for now.  Not that this is NOT part of stone stockpile 1.
b = 1 square zone acting as "stack", set to active + nothing.  Not that this is NOT part of stone stockpile 2.
c = 1 square zone acting as "stack", set to active + nothing.  Not that this is NOT part of stone stockpile 3.
d = 1 square zone acting as "stack", set to active + nothing.  Not that this is NOT part of stone stockpile 4.

For each reserve stockpile, set the "active" stockpile from the previous level to "take from" it.  (recall that a stockpile can take from many other stockpiles but each stockpile can only be taken from one other stockpile).  At the end of the day, the "active" stockpile should have a "take from" entry to all "reserve" stockpiles.

note: The "stack" square associated with each stockpile is where we will "stack" stones of that type when the reserve stockpile is overflowing.

The operation
===============
1. As you discover new stone types, set one of the reserve stockpiles to collect that stone type.
2. When a reserve stockpile is overflowing/full, change the zone type of the associated "stack" square to garbage (and make sure you have no other active garbage zones/normal dumping jobs going on!).  Then just dump the stones in the associated stock pile (which should be easy since they are laid out in a nice grid).  You can turn this on for the most abundant stone type in you latest digging operation.
3. Remember to turn "off" the "stack" square's garbage state when you no longer need it.

Check Point: so far, we have a way of collecting stones and laying them out in an organized fashion.  Each "reserve" stone stockpile act as a ready source of the chosen stone type.  If a stockpile is almost empty, just reclaim several stones from the associated "stack" square.  If it is getting full, activate the associated "stack" square's garbage status and start dumping stones from the stock pile.  There is no need to dump stones elsewhere as if there's empty space on the stockpile, the haulers will haul the stones to it eventually.

4.  Now, to choose the active type of the stone for your mason's workshop, just set the "active" stockpile's accepted rock type(s) to one of the "reserve" stockpiles' rock type(s).  As soon as you do, haulers should start filling the active stockpile.  As long as active stockpile is not empty, your mason should only use the stones there (provided there are no closer source of stones elsewhere/above the workshop).

5. Changing the active type of stone is as easy as setting the accepted rock types to some other type.  Give it some time to allow haulers move the now unneeded stones back to reserve stockpiles (remember to ensure there;s enough empty space for them!) and to move the now wanted stone types to the "active" stockpile.  After that, you can resume operations in your mason's workshop.


==end of tutorial===

Hope this is useful to somebody.
Feel free to comment on/criticize any shortcomings.

regards

(edit: forgot to put in the code tags to make the plans use monospaced font)

[ November 29, 2007: Message edited by: sphr ]


15
DF Dwarf Mode Discussion / does "ballista-tower" works?
« on: November 24, 2007, 10:26:00 pm »
thinking of building remote siege towers surrounded by moat and inaccessible from outside when draw bridge is drawn (accessible only from underground passage way leading straight back to fortress).  The ballista are supposed to be placed on a cross shaped top level platform so that 3 of them can case any of the compass direction as needed.

code:

  BBB
  BBB
  BBB
BBB...BBB
BBB.>.BBB
BBB...BBB
  BBB
  BBB
  BBB


where each 3x3 B represents a ballista.
stock pile of ammo will be stored in lower levels and underground, where an extra siege-workshop which is normally idle could be made to work to produce ammo right at the spot during attacks.

There can be extra platforms at lower levels for mark dwarves to station as well.

But have a few questions:

1) what effects does z-levels have on siege weapons (different for ballista and catapults?)

2) how does enemy scare siege-operators work?  by physical distance or does a fortification/enclosed room made the siege-operator feel more safe and continue to fire across the moat/from higher ground even if the enemy is close in terms of horizontal distance?

3) Any improvements/criticisms for the design?  

maybe I'll put up a 3D diagram in the "useful plans" thread after I actually built and tested it...  :)


Pages: [1] 2 3