Print

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

[Zarathustra30]

I think the tool problem is a bit exaggerated. It would only really be a problem if somebody forgot include a container. A dwarf would take whatever tool(s) necessary (e.g. hammer and tongs) to the proper furniture item for the job (e.g. anvil). As long as a dwarf prioritizes items already in the workshop, the tools should generate jobs to be put back where they were found, using the same code already in the hospital.

[Ops Fox]

I really like this idea.

I could see most new people in dwarf fortress just carving out a room with the constructed bits like furnaces in it and the associated tools like a hammer to create the metalworking shop. More advanced players could have workshop zones that intersect allowing some tools to be shared between jobs, improving efficiency. This would of course be like the other features of the military all you really need is a squad and the s key, overlapping workshops would be something veterens use to improve the overall efficiency of their forts.

[Pencil_Art]

The idea is very good and does a good deal of explanation as to how it works. PTW.

[Enchiridion]

wow I didnt expect a necro. Thanks! I kinda dropped the thread once I realized that this is what toady is already going for, kinda makes me happy to know that's something planned.

[Timeless Bob]

I really like how this all come together - it'd make fortress design more varied as well.

[NW_Kohaku]

wow I didnt expect a necro. Thanks! I kinda dropped the thread once I realized that this is what toady is already going for, kinda makes me happy to know that's something planned.

I remember there being a thread I had a long argument in before, however. 

I just hope that Toady takes what I said in that thread to heart, as well, and doesn't make a crazy overabundance of tools that have to be crafted and kept track of.  Making multiple types of tools per workshop means a blindingly long list of crap to keep track of.  (Although I'm sure SirHoneyBadger would love it, even he says that his mods aren't for everyone, and they'd absolutely murder new players trying to learn the game...)

[Salmeuk]

This was one of those threads where I get halfway through the OP before realizing just how old it is. "This guy is kinda out of the loop if he thinks these ideas aren't planned." hehe

There was a lot of work put into this suggestion, though - hats off!

[Enchiridion]

Thanks guys. I sort of stopped adding ideas eventually. I just sort of got that people got the idea and most of it is planned apparently(or most certainly IS now anyway) I know it would be a huge pain to re-programm though, and I can see why it might cause a lot of problems. anyway, thanks guys.

[Adrian]

Reading through Tarn's devlogs on taverns and stuff it seems he's committed to making new areas from zones as opposed to the old rooms-from-furniture approach.
Reworking existing rooms to use the same system would take a lot of time and effort and seems like a long term thing.

[Enchiridion]

Reading through Tarn's devlogs on taverns and stuff it seems he's committed to making new areas from zones as opposed to the old rooms-from-furniture approach.
Reworking existing rooms to use the same system would take a lot of time and effort and seems like a long term thing.

Yes, I'm very happy about that and I cant wait to see what it's like in-game.

[Tristan Alkai]

While I was reading through the suggestion, I ended up coming at it from the angle of reaction raws. 

Well as for the "necessary to produce" list, I think that's a great idea. Just a few notes - in order to create something, you will at most need is a workshop and three types of things: tools(chisels,hammers), construction(furnace, grinder) and resources(stone,wood, metal). As for the "level 2 workshop"(which you said to avoid, and I totally agree.), that idea becomes obsolete. All you need is just a workshop.

The current reaction raws provide tags to specify [REAGENT:?] and [PRODUCT:?].  This suggestion would also require tags for [TOOL:?] and [CONSTRUCTION:?]. 

On a related note, how does this system interact with the current [BUILDING:?] tag? 

If you can come up with a powerfully flexible way to scale the complexity with experience (by options) without resulting in two totally different gameplay experience, then it could work. Also, even for advanced players, as much as possible needs to be automated, which is a non trivial set of algorithms here.

I have an idea here, derived from the current stockpile give/take orders.  It also incorporates the current [AUTOMATIC] reaction tag, and calls for a new tag, tentatively called [INTERCHANGEABLE]. 

1. Workshops would need the same "take from anywhere/take from links only" option that stockpiles have. 
2. Alternately, give and take could have corresponding "exclusive" orders which block the workshop interacting with non-linked stockpiles (probably give-x and take-x).  By default, stockpile give and take orders would not block the workshop in this manner; the current blocking behavior would be a setting that can be turned on and off as needed. 

Auto fill
With a stockpile set to take from a workshop (exclusively or not) the "change stockpile settings" window (q, s) gets some new buttons.  In addition to the current allow/don't allow options, each item (that is allowed in the stockpile and can be produced in the linked workshop) would have an "auto-fill" setting.  If activated, this would cause the stockpile to attempt to queue production orders in the linked workshop until a certain minimum number of that item are present in the stockpile (this number would need to be adjustable by the player). 

Example:
1. A "Finished Goods" stockpile is set to "take from" a clothier's workshop. 
2. In addition to simply accepting shirts, the stockpile can be set to "auto fill" to a minimum of (for example) 3 shirts.  If the stockpile has less than this, it will attempt to queue a "make shirt" job at the linked clothier's shop. 
3. These orders could be set for multiple items, such as 3 shirts, 3 trousers, 3 pairs of shoes, 3 pairs of socks, and 3 cloaks. 
4. These minimum settings for different items would be set independently, but I personally would set clothing items all to the same number (not necessarily 3, especially in a larger fort).

Auto use
The "give to" workshop would enable a similar set of buttons.  The stockpile would "auto empty" or "auto use."  The player sets a maximum, and, when that maximum is exceeded, the stockpile will attempt to queue a reaction that uses that item. 

However, queuing jobs based on reagents has some limits that did not apply when it was based on products.  For example, "use pig tails" will behave predictably, "use dimple cups" even more so, but "use cloth" or "use clay" will not.  In order to maintain sane behavior, "auto use" would only be allowed when there is specifically an [AUTOMATIC] reaction that uses the item.

The [AUTOMATIC] tag will behave appropriately on, at least, the following (not an exhaustive list):
> Tan a hide
> Brew drink from plant; Brew drink from fruit
> Process plants; Process plants (to barrel); Process plants (to bag); Process plants (to vial); Mill plants
> Mill seeds/nuts to paste; (make sure to set the maximum fairly high on that one)
> Weave thread into cloth; Dye thread; Dye cloth
> Most of the various kiln "glaze item" orders would probably work, although the corresponding kiln "make clay item" orders would not.  They would need to be set based on product. 

Some items make sense with both "auto fill" and "auto use," such as plant fiber thread.  This would attempt to queue both "process plants" and "weave plant fiber cloth" (or possibly "dye thread," depending on which workshops you linked that pile to).  There is, of course, nothing stopping you from setting an "auto use" maximum lower than the "auto fill" minimum.  They would also be able to independently set "interchangeable" commands (see below). 

[INTERCHANGEABLE]
Several of the above [AUTOMATIC] reactions also make sense with a new tag, tentatively called [INTERCHANGEABLE]. 

For example, one kind of booze is, at least for most purposes, nearly the same as any other kind.  This also applies to other goods like flour and plant fiber thread. 

Example:
1. A stockpile is set to give to a quern (or, in the suggestion above, a "milling zone" with a quern and millstone built in it), and contains cave wheat, purple amaranth, barley, longland grass, foxtail millet, and quinoa. 
2. Milling is an [AUTOMATIC] reaction (not currently, but it would be if this suggestion were implemented), and the cave wheat has an "auto-use" setting active, with a maximum of zero. 
3. Normally, this order would only use the cave wheat.  However, the [INTERCHANGEABLE] reaction tag enables an "interchangeable" setting on the "auto use" stockpile order. 
4. If activated, the "interchangeable" setting causes the stockpile to automatically queue a generic "mill plant" order, rather than a specific "mill cave wheat" order.  The dwarf would most likely still be constrained to take plants from that stockpile, but would not be constrained to cave wheat.  The dwarf would mill whichever plant he happens to grab. 
5. The stockpile for output cave wheat flour would then automatically have flour from the other millable plants mixed in, even though the other plants do not have their own "auto use" orders. 

The [INTERCHANGEABLE] tag would work with "auto fill" just as well as "auto use." 
For example:
1. A booze stockpile is set to "auto fill" with strawberry wine. 
2. However: plums, sand pears, blueberries, and blackberries are also available.  If the strawberry wine brewing is set to "interchangeable," these will also be brewed. 
3. Since the reaction being queued is "brew drink from fruit," this would not automatically produce dwarven wine, barley wine, whip wine, dwarven rum, or similar.  That would require a separate "auto fill" order on a drink that is brewed from plants. 

Frequency
To save on FPS, queuing an auto fill/auto use job would need to be an infrequent event.  It would be appropriate to check whether one is appropriate at most of the following events:
1. A dwarf just took an item off the stockpile. 
2. A dwarf just put an item on the stockpile. 
3. A previous auto job has just been completed. 
4. Every so often, perhaps once per game week. 

Miscellaneous
With these established, I have a few other interface settings that I would like:
1. Enable all items that have an auto fill option. 
2. Enable all items that have an auto use option. 
3. Even if the auto settings themselves don't get used, allowing (for example) all brewable plants and fruits (and only brewable plants and fruits) on a stockpile set to give to the still, at the press of a single button, would still be an enormous time-saver. 
4. Buttons to exclude all items that have an auto fill/auto use option would be less intuitive to use effectively, but could be used, in combination with tactical re-arrangement of give/take orders, to (for example) keep flour plants (most of which can also be brewed for beer) out of my brew pile (which reserves them for flour), while permitting plants with little other use but brewing, such as plump helmets and fisher berries.   

[StagnantSoul]

Am I seriously the only person who likes the current building system? It's so much easier to manage and would look a lot better and easier to mod than this system. Still, it's an interesting idea.

[NW_Kohaku]

Am I seriously the only person who likes the current building system? It's so much easier to manage and would look a lot better and easier to mod than this system. Still, it's an interesting idea.

I've never seen the big appeal to it, myself, but I don't think it would be harmful, if done properly. 

Hypothetically, Toady CAN let us mod it, and that means it would be easier to at least visually differentiate different workshops by their tools.  (I.E. not just a set of solid blocks and a [ for a workshop.)

[Enchiridion]

The current reaction raws provide tags to specify [REAGENT:?] and [PRODUCT:?].  This suggestion would also require tags for [TOOL:?] and [CONSTRUCTION:?]. 

Well, I suppose so, yes. Ultimately that's what the goal is. Perhaps some tasks could require no tool(such as making something out of a lump of clay. You don't really need tools).

As far as I understand(I have only some experience with modding DF) the current reaction raw is :

Code: [Select]

[REACTION:<identifier>]
     [NAME:<name>]
     [BUILDING:<BUILDING NAME>:<BUILDING KEY>]
     [REAGENT:A:150:BAR:NONE:POTASH:NONE]
     [PRODUCT:100:1:BAR:NONE:PEARLASH:NONE][PRODUCT_DIMENSION:150]
     [FUEL]
     [SKILL:<SKILL TOKEN>]
     [AUTOMATIC]
     [ADVENTURE_MODE_ENABLED]
Whereas this would perhaps look something more like this (this is all pseudo code. Not really that familiar with reaction raws. I know its missing things like automatic and fuel.)

Code: [Select]

[REACTION ID]
[NAME]
[NECESSARY INGREDIENT]
[NECESSARY TOOL]
[NECESSARY SKILL]
[ZONE WHERE TASK CAN BE PREFORMED]
[OUTPUT]

Bur perhaps there should be options to produce macros. So you have reactions that utilize reactions in and of themselves. For instance, making a clay pot or something may utilize a lower reaction to first get clay out of a clay boulder. I suppose, anyway. It's technically all within possibility.

[Tristan Alkai]

The current reaction raws provide tags to specify [REAGENT:?] and [PRODUCT:?].  This suggestion would also require tags for [TOOL:?] and [CONSTRUCTION:?]. 

Well, I suppose so, yes. Ultimately that's what the goal is. Perhaps some tasks could require no tool(such as making something out of a lump of clay. You don't really need tools).

As far as I understand(I have only some experience with modding DF) the current reaction raw is :

Code: [Select]

[REACTION:<identifier>]
     [NAME:<name>]
     [BUILDING:<BUILDING NAME>:<BUILDING KEY>]
     [REAGENT:A:150:BAR:NONE:POTASH:NONE]
     [PRODUCT:100:1:BAR:NONE:PEARLASH:NONE][PRODUCT_DIMENSION:150]
     [FUEL]
     [SKILL:<SKILL TOKEN>]
     [AUTOMATIC]
     [ADVENTURE_MODE_ENABLED]
Whereas this would perhaps look something more like this (this is all pseudo code. Not really that familiar with reaction raws. I know its missing things like automatic and fuel.)

Code: [Select]

[REACTION ID]
[NAME]
[NECESSARY INGREDIENT]
[NECESSARY TOOL]
[NECESSARY SKILL]
[ZONE WHERE TASK CAN BE PREFORMED]
[OUTPUT]
Bur perhaps there should be options to produce macros. So you have reactions that utilize reactions in and of themselves. For instance, making a clay pot or something may utilize a lower reaction to first get clay out of a clay boulder. I suppose, anyway. It's technically all within possibility.

The wiki has an article on reactions with the information you would need for this. 

I've been thinking about this a bit more, and spotted a few things I missed the first time through.  I see the following necessary tags:

New Reaction Template:
[REACTION:<identifier>] The same tag that the current game uses.  The <identifier> is a string that serves as a unique identifier for the reaction. 
[NAME:<display>] The same tag that the current game uses.  The <display> is a string that is displayed in-game on workshop menus, representing the reaction when you order it. 
[BUILDING:<building name>:<building key>] The same tag that the current game uses.  I believe that it is not necessary to re-name this tag to reflect the fact that we are now working from some variant of "activity zone" in which workshop types can be enabled.  The <building name> is the kind of workshop zone permission required for the reaction, and the <building key> is a shortcut or hotkey to make frequently used reactions more convenient. 
[BUILDING:<building name>:<building menu>:<building key>] A potential alias for the above.  For example, the glass furnace starts with a menu to select green, clear, or crystal glass; then you select an item from the resulting menu.  The clothier's workshop has something similar with plant cloth, yarn, and silk.  This starting menu would probably need to be declared somehow in the raws for the building.  A complete token might read something like this:
BUILDING:CLOTHIER:MENU_PLANT:CUSTOM_B.  ("Make plant fiber cloth bag.")
BUILDING:GLASS:MENU_GREEN:CUSTOM_D.  ("Make green glass portal.")
[CONSTRUCTION:<name>] Many reactions will require some sort of prepared work site within the workshop zone.  Each construction can support only one reaction at a time, but there can be several such sites within a workshop zone.  These "constructions" will require their own set of tags, which would be specified on a separate page of the raws.  I will get to those later. 
[TOOL:<name>] Each workshop zone can have "tools" assigned to it.  Each TOOL can be used in only one reaction at a time, but the zone could have several tools of the same type assigned to it.  Unused tools would probably be left at the work site; stockpiles would be for tools that are not assigned to a work zone. 
[CONTAINER:<name>] Containers would have a list of "modifiers" that can be specified within the reaction, just like reagents and products do now.  I will get to those later. 
[REAGENT:?] The same tag that the current game uses.  Most of this uses the current set of tags, caveats covered below. 
[PRODUCT:?] The same tag that the current game uses.  Most of this uses the current set of tags, caveats covered in various locations below (particularly the container section). 
[IMPROVEMENT:?] The same tag that the current game uses.  Used in place of PRODUCT, with a slightly different set of permitted arguments and tokens. 
[COMBINATION:?] Tentative name for another alternative to PRODUCT.  The current game feature I have in mind is prepared meals.  Modders could also use it for things like pickling.  Combinations incorporate multiple stacks of reagents into a single stack of products.  The product acknowledges the exact list of ingredients, and the product stack size is equal to the sum of input stack sizes.  Combinations would not be messed up by reagent stacks of different sizes (I understand that PRODUCT would take the smallest stack size among them, though I have not properly tested this).  Combinations might necessitate a review of the list of REAGENT modifiers, but I think I need to simply leave that open to be debated. 
[SKILL:<name>] The same tag that the current game uses. 
Miscellaneous tags:
[AUTOMATIC] The same tag that the current game uses. 
[INTERCHANGEABLE] Covered in my earlier post. 
[ADVENTURE_MODE_ENABLED] The same tag that the current game uses. 
Note that (FUEL) is not in this reaction template.  It is a Construction tag. 

Container Modifiers:
[CONTAINER_SUBSTITUTE:<name>] For example, brewing would have (CONTAINER:BARREL) and (CONTAINER_SUBSTITUTE:POT).  Barrels would be preferred when available, but the substitute tag allows large pots to be used in their place.  I assume that the current stockpile give and take orders will have some successor in the new system, and these would be able to force all brewing to be into large pots, just like they can now. 
[CONTAINS_REAGENT:<name>] A replacement for the current reagent modifier (CONTAINS:?), which is necessary because containers are currently listed as reagents, rather than their own distinct category. 
[CONTAINS_PRODUCT:<name>] A replacement for the current product modifier (PRODUCT_TO_CONTAINER:?), which is necessary because containers are currently listed as reagents, rather than their own distinct category.  It would be possible to specify CONTAINS_REAGENT and CONTAINS_PRODUCT for the same container. 
[EMPTY] The same tag that the current game uses. 
[EMPTY_OR_CONTAINS_PRODUCT:?] For example, a dwarf could make more lye using a bucket that already contains some. 
[POUR:?] Only makes sense with CONTAINS_PRODUCT.  The hauler carrying this container and product to a stockpile will attempt to empty the hauled container into a container of this type so the original container can be returned to the workshop zone.  Used for buckets of milk and lye, which are supposed to be emptied into barrels.  Can be specified more than once, making each container type acceptable. 

Construction Template:
1. The current raws ("building_custom," which describes the screw press and soap maker) contain what appear to be display instructions, and I don't understand enough about those to comment on them. 
2. Since most "buildings" other than workshops are 1x1 (as are the quern and millstone) I will assume that most of these "constructions" will also be 1x1 unless somehow specified otherwise. 
3. It might also be relevant to bring up GavJ's thread on long term unattended reactions.  I like the idea (among other things, it might be the best way to fire or glaze several pottery items at a time), but I'm not sure exactly how to integrate it. 

[BUILDING:<name>] The current raws both say BUILDING_WORKSHOP, which I believe places them in the "workshops" sub-menu (in which case I also recommend BUILDING_FURNITURE, to keep that menu slightly more organized).  I envision tables and chairs being commonly used, and BUILDING_WORKSHOP seems slightly inappropriate for them.  As noted above in REACTION, this would need to be unique. 
[NAME:<name>] The same tag that the current game uses.  This is the displayed name for the building. 
[NAME_COLOR:<foreground>:<background>:<brightness>] Specified for both "custom" workshops, though I have not investigated enough to know what situations acknowledge this tag. 
[BUILD_LABOR:?] The same tag that the current game uses. 
[BUILD_KEY:?] The same tag that the current game uses. 
[BUILD_ITEM:?] The same tag that the current game uses.  Can be specified multiple times. 
[WORK_LOCATION] The current raws use this tag to specify that the worker is in the center of the building.  I envision this being redundant with most such constructions being 1x1.  Here, it simply specifies that the worker will stand or sit at this location while performing reactions. 
[WORK_ADJACENT] The worker will stand or sit next to this construction while performing reactions; direction is left up to the individual worker (unless the reaction also specifies a WORK_LOCATION).  Cannot be combined with WORK_LOCATION. 
[FUEL] Reactions that use this construction also need one bar of REACTION_CLASS:FUEL.  Used for conventional furnaces.  Replaces the current FUEL reaction token. 
[ADD_REAGENT:?] A generalization from FUEL above that can be used to specify other materials.  Works like any other REAGENT, and accepts all the same arguments and modifiers.
[SIDE_REACTION] Begins declaring a reaction that occurs each time this construction is used (separate from, and in addition to, the ordered reaction that is using the construction).  The side reaction is elaborated using tags "nested" under this one.  At a minimum, it will need to accept REAGENT and PRODUCT, along with all of their arguments and modifiers.  It probably won't need to accept a SKILL token most of the time (that's what the main reaction is for).  For example, I would put something like the following under a conventional (non-magma) forge:
(REAGENT:fuel:150:BAR:NONE:NONE:NONE)(REACTION_CLASS:FUEL)
(PRODUCT:12:1:BAR:NONE:ASH:NONE)(PRODUCT_DIMENSION:150)
This will cause the forge to demand one unit of "fuel" (either charcoal or coke) each time it is used.  It also has a 12% chance (1/8 is 12.5%) to produce ash from the burnt charcoal.  This "cleanup" will be somewhat irregular, but that's probably realistic.  It also means I can avoid the somewhat trickier proposition of figuring out how to tell the reaction to produce 1/8 (or 1/10) of a bar of ash every time.  A separate issue with partial bars is covered on the wiki under "melt item": the interface does not actually display partial bars, so I would rather avoid producing any if possible. 
[POWER:<number>] This building cannot be used for reactions unless it is supplied with at least this many units of mechanical power.  Used for the millstone (POWER:10). 
[FLUID:<material>:<distance>:<minimum depth>] The construction can only perform reactions if it has access to the specified fluid within the specified distance.  Magma furnaces would replicate current behavior with FLUID:MAGMA:1:4.  Wells would have FLUID:WATER:NONE:3. 
[SUBSTITUTE:?] Reactions that call for the current construction can use this other construction instead.  Can be specified multiple times.  Also accepts NONE and NOTHING, both of which indicate that reactions which benefit from this piece of infrastructure can be performed without it (such as a potter's wheel).
    [PENALTY_SPEED:<number>] Reactions using the substitute will take longer than normal, to a degree specified by the number (I don't know enough about the current math to say exactly how).  For example, the wiki specifies that "millstones process plants much faster than querns."  Milling reactions would call for a millstone, and the millstone would have SUBSTITUTE:QUERN and a PENALTY_SPEED tag. 
    [PENALTY_QUALITY:<number>] Reactions using this substitute produce goods of lower quality than normal.  How much lower is specified by the number (again, I don't know enough about the current math to say exactly how it should work).  I remember reading somewhere on the forum about stone blocks being a potential substitute for a proper anvil, which might involve this tag.
    [CAP_QUALITY:<number>] Reactions using this substitute cannot produce products above the specified quality level. 
[PREFERRED:?] Alias for SUBSTITUTE, with the distinction that workers will seek out this construction in preference to the original one.  Used for magma versions of furnaces.