Print

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

[dorfdokamine]

The following is my proposal for a new menu, structurally similar to the [z]ones menu, designed to allow the user to copy select parts or all of the [d]esignation, [b]uilding, and [q]->[r]oom definition that goes into creating, say, a bedroom, a set of bedrooms, a z-level of exploratory mining, from an area that has already been turned into such a room or area, and gradually paste the [d]esignation etc. to another area, to greatly decrease the amount of user input required to create such a room or area.

The conflicts arising from, for instance, telling DF to designate a square for mining, smoothing, engraving and the construction of a bed all at once are dealt with below. I have tried to recycle as much _pseudocode as possible, and I'm getting rather carried away with the formatting.

I will distinguish between things like pig-tail socks, which can be moved from square to square, and things like constructed tables, which cannot, by referring to the latter as static.

To Magma Business!


How It Works:

• The user designates an area to act as a template via return in the menu.
  
• There is no limit to the x or y dimensions of the area, but it is restricted to 1 z-level.
  
• The user selects, using a multiple-toggle submenu similar to the [z]one submenu, what categories of designations they would like to export from the template area.
• The user presses something like shift+x to eXport the desired designations from the area.
• The fun begins. For the purposes of demonstration we assume the user chose to export everything about the area that they could.
• DF parses over the area, recording every tile feature that is included in one of the categories selected by the user, and its location relative to the (0,0) of the template area.
• DF converts the information it has collected about the tile features into information about how another tile might be made to have the same features. A [floor] tag(?) becomes [designate_for_digging].
• While doing so, DF ignores the particular qualities of built objects. So masterwork quality oaken bed no. 4072, created by Urist McCarpenter, defined as a bedroom containing the squares {(0,0),(1,0)...} relative to the bed, currently belonging to Urist McNotCarpenter, does not become a designation to build that bed, but a designation to build some bed, exactly as if the user had typed [b] -> [b] -> return, and a seperate definition of a bed as a room containing the squares {....}, relative to the location of the bed.
• Df takes several deep breaths to calm itself down, reflecting that DF now has an exact set of instructions for building the selected components of the template area. Feeling quite pleased at this, DF decides to show off by throwing up a brownscale image of the template area under the user's cursor, and might, if DF was feeling generous, be cajoled into reflecting the image through one or more axes.
• The user moves the brownscale image to wherever he actually wants to designate them, and hits return.
• DF takes another deep breath and dives at the instructions DF collected from the template area, ferociously sorting each tile's associated list of designations by an order of precedence such that no designation precedes any designation which it would render the completion of impossible, nor which it requires to have been completed before it itself can.
  In other words:
  {[build_a_bed],[designate_for_smoothing],[designate_for_digging]}
  becomes
  {[designate_for_digging],[designate_for_smoothing],[build_a_bed]}
  because you cannot build a bed and then smooth the floor beneath it (?) nor build a bed until you have dug the square out.
• DF looks in turn at each square in the region in which he is to designate the image from the template, and asks 'Is it possible do the the first thing in the list I associate with the corresponding tile in the image to this square?' If it is, he designates it to be done. If it is not, he checks the next thing on the list, and so on, for every square.
• What happens next depends on how what the user has done to the area he designates the image in previously. If it is not yet dug out, the dorfs dig it out. If it is dug out but not smoothed, they smooth. If it is dug, smoothed and engraved, DF adds the bed designation to the list of things to ask the user to specify the components for at the end, via a nicely re-hashed multiple-material selection tool he stole from the build -> Construction menu.
• The End.

[1] Just realized a hole in the order of precedence def. but it is fixable.

[aepurniet]

this could be done by recording the actions within a zone, rather than trying to figure out what the actions are. but it will take some more code to figure out when the next actions can be queued.

ie room is dug out, then smoothed. when does the paste template functionality designate the area for smoothing? obviously after it is dug out, but this will have to be coded. one solution would be to allow floors to be designated for smoothing before they are dug out. right now this is not possible. DF doesnt have a distinction between smoothing walls and floors. a square is marked to be smoothed and whatever is there is smoothed.

also what do you do about quality levels and materials in a template? lets say i only want masterwork pine beds that are decorated with cloth to be queued once the template is pasted. what about if i dont care about what kind of wood it is? what if i demand that the decorated cloth be exceptionally dyed?

unfortunately i dont see an easy way to specify these preferences within this template system.

[dorfdokamine]

Hi, thanks for reading.

Actions within a zone is an interesting idea, but seems to have a number of problems that working out the designations from a pre-completed area does not:

• The zone is actively checking whether anything has been done to the room for the entire time. Hugely expensive compared to checking on copy and applying on paste, all while the game is paused.
• The user cannot re-use templates, eg. make 8 rooms, use that template to make the rest of the z-level of bedrooms, delete old template and make a new one over the whole z-level of bedrooms, use that to make another z-level, unless there is some system for allowing the template zones to overlap, which would be a huge coding effort and difference to every other zone/stockpile/building in the game.
• It requires the user to know about the template zone before they need it! The user cannot build rooms for his population of 20, get a migrant wave, find out about the template zone, and avoid building another 20 rooms manually.
• It would have to parse each action for the non-specific elements, as opposed to just the items. A huge list would have to be added to the list of things to filter in the tile_feature -> designation code, and be run every time any static object is created in the zone.
• What if the user defines a zone, builds a bed, decides he wants all the beds in that zone to be a certain colour, removes the bed, and builds a new bed? Does poor DF have to parse out any actions that are later reversed? Does DF have to try to designate two beds to be built? Can the dorfs have no temporary structures?
• blah blah

room is dug out, then smoothed. when does the paste template functionality designate the area for smoothing? obviously after it is dug out, but this will have to be coded. DF doesnt have a distinction between smoothing walls and floors. a square is marked to be smoothed and whatever is there is smoothed.

The last bit of my post is not particularly clear, because I had been bugging over it for a couple hours and was getting tired, but all this is sorted out. Digging and smoothing was one example of the error I mentioned in the precedence definition, but as DF would not actually be sorting by definition but by an order Toady created from such a definition, it would be no trouble to add the bits the definition did not cover.

The solution, and the bit I was particularly unclear upon, is that it doesn't actually queue anything when you paste a template, or designate the same square for more than one operation at any one time. The user pastes the template repeatedly over the designated target area, and each time DF designates the next "layer@, if you will, of designations. So...

For each square, it designates the first designation in the list that was sorted by order of precedence that that square is capable of receiving and then moves straight to the next square. It would never tell a room to be both dug out and smoothed. If the corresponding tile in the template was dug out and smoothed, and the tile it is pasting to is neither dug out nor smoothed, it will designate it for digging and then move on to the next square. It will designate the area for smoothing the next time the user pastes the template over the area.

So, for example, suppose that a square in a template is dug out, smoothed, engraved, and has a bed on it, and the template is pasted in a completely untouched square of rock.

• The user pastes the template on the rock. DF looks down the list and says 'can i dig here?', DF can, so it designates the area to be dug out and stops checking for things it could designate there. The dorfs dig it out.
• The user pastes the template again onto the same, now dug out, area, and DF says 'can i dig here?' DF cannot, DF asks 'can i smooth here?' and DF can, so DF stops checking the list for valid designations, and designates the area to be smoothed.
• User pastes again, DF does the same, cannot dig or smooth, designates engraving. User pastes again, DF cannot dig, smooth or engrave, so DF designates a bed to be built.

While it might seems cumbersome for the user to repeatedly paste the template, I think it is actually a good feature, because it means that a) the user can stagger the designations. He does not have to have his 80 beds before he can dig out the rooms they are to be built in, nor must he commit himself to 80*dig + 80*smooth + 80*engrave + 20*build_a_bed all in a row, in case he does not want to simultaneously occupy all his peons for the better part of a year. b) the user can also designate the latter "layers" by parts... not sure how to describe it, but suppose that you have designated a large area to be dug out via the template, and that your dwarves have currently dug the western half out. If you paste the template over the area again at this point, it will designate the next "layer" of designations, eg. smoothing, of the western half, without interfering with the as yet uncompleted digging designations of the eastern half. If you are in hurry to get the first 20 beds set up for your 20 current dwarves, but still want your dwarves to be working on the rest of the bedrooms, you can repaste the template over the target area again, and have the first 20 bedrooms completed before the rest are even dug out.

However, the paste selection view would almost certainly require some kind of snap-template-image-to-previously-targeted-area functionality, or people are going to accidentally print the template 1 square to the left of where they intended, and DF is going to designate their walls to be dug out.

You might make this even safer by creating a seperete export button in the template menu that exported only the dimensions of the template, and when pasted defined the target area of that paste as a potential target area for all subsequent pastes of that template, so the user could simply -/+ their way through the list of potential target areas, like they do when selecting which bridge to link a lever to, and be completely sure that they were not going to screw up their whole z-level of bedrooms... Come to think of it this is almost certainly better than the simple 'paste-anywhere' function described previously.

also what do you do about quality levels and materials in a template? lets say i only want masterwork pine beds that are decorated with cloth to be queued once the template is pasted. what about if i dont care about what kind of wood it is? what if i demand that the decorated cloth be exceptionally dyed?

This, again, I didn't really explain properly at all in the original post, but is thought of.
Recall that, while pasting...

If it is dug, smoothed and engraved, DF adds the bed designation to the list of things to ask the user to specify the components for at the end, via a nicely re-hashed multiple-material selection tool he stole from the build -> Construction menu.

The 'select multiple mechanisms to attach x to y' menu is actually a better example. The user is by default given a plain list of the mechanisms he has by material, and if he presses x the list is expanded to show quality and decoration, and gives the user the option to view the individual mechanism's description with v.

Take the example of beds again.
User pastes a template over a large area.
Each time DF finds that a square has been dug out, smoothed, engraved and has not been built upon, and that the corresponding tile in the image contains instructions for a bed to be built. It records the location in which it is to build this bed, adds {bed;<location>} to the list of things to ask the user to specify materials for at the end, and moves to the next square.
DF comes to the end of Df's examination of the area. DF sorts the buildings by building type. eg. bed/door/constructed_wall/chest etc. DF looks down the list of types of buildings that DF is to designate for construction. He finds a list of 10 bed designations, and asks the user to specify a bed for each of the bed designations in turn, snapping the view to each designations target tile as he does so, and thus giving the user exactly the same menu by which he would choose a bed manually(!!!), only all in a row, without moving the cursor between them or having to press b -> b for each one.


So that, I hope, is a slightly more thorough explanation of how it would work, and all that remains is a a justification of why I think it should be implemented.

First off, it is obviously and immensely powerful. It reduces the time it takes to build complex sets of structures logarithmically, and the designation of these complex structures is, in my experience, the most time consuming, least challenging, most monotonous and most predictable part of the user input in the whole game for which there exists a real need and no work around. It would be save alot of time, and get alot of the boring, predictable part of the game out of the way, so the user can spend more time creating beautiful inventive structures. Nuff said.

I think the main thing that actually takes some arguing is that it would be relatively easy to code, as I claimed in the title of the post. Not least because I have obviously not seen source code of DF, wouldn't be able to even read it if I had, and can thus only estimate that, as I claimed in post 1 para 1, much of the code for it could be recycled from pre-existing menus and designations.

Nevertheless, the following is a list of parts of the code required for this menu which appear to already exist, parts of the interface that the user is already at least analagously familiar with, and ways in which this code itself could be easily recycled or updated for future use.

• Copy/paste is one of the most ubiquitous functions in everyday computing, no user would find the idea strange.
• The multi-toggle, choose-what-categories-of-tile-features-to-export feature is visually identical to the zones menu. The choose-multiple-construction-materials-or-items is used in various relatively commonly frequented places throughout the game.
• While the order of precedence which is required to ensure that each designation is designated at the right time is not generally implied by the phrase 'copypasta', it goes on almost entirely unbeknownst to the user, who has only to hit return a few times, and the part of the ordering the user can see is very similar to, say, the designation to chop down trees, where although the area selected by the user is a large rectangle, only the squares to which the designations are legally applicable, in this case all those that contain adult trees, are actually designated. Or the designation to dig, which is only applied to non-empty squares. Or numerous others.
• Furthermore, although it seems unlikely that there is currently no single ordering of precedence of player made constructions anywhere in the source code, it certainly exists in parts, because DF has to check if the square that the player is trying to designate for digging/building/anything-at-all is capable of receiving that designation every time the player designates anything, and a single ordering of precedence is possibly even something Toady would consider worth having in its own right anyway, if only for reference.
• The use of a copy/paste is such a commonplace and useful idea that it would almost certainly be implemented in some form at some point anyway. If this framework for a copy/paste function is easily extended and updated as new content is added, then there is a rather strong and obvious argument for not leaving it till later for a massive write up of every building and designation type at once, even if we ignore the facts that starting it earlier would allow the user input from <earlier> till <later> to be multiplied, by the efficiency of the function, into more beautiful designs, instead of just that input put in after <later>, and that users would have from <earlier> till <later> to get used to the function, instead of just after <later>.
• I could not honestly attest whether or not this framework would be easily extended or updated, but I will guess that it is at least relatively so, based on the seemingly generic nature of the processes that make up the majority of the function as a whole. The precedences, the various material selections, the parsing of tile features etc.   It seems to be really only their order that is changed.
• The ability to copy and paste even a very select, introductory group (I'm talking just digging, stairs, channelling) of the tile features that are described here would save an immense amount of user time and be warmly welcomed, I think. And seeing as most of the slightly complicated bits come in with the inclusion of more varied items, this on its own could be easily coded, while itself serving as a framework and bug-testing module for later additions to the categories of tile features that could be exported from a template area.
• The method of reverse engineering the designations for a room from a pre-completed room, instead of a set of designations, is certainly contestable. Personally, I think it wins out because it does not require any code to hold multiple designations for a tile, something that is certainly(?) not in the game at the moment. And while significantly later versions are probably envisaged as having some sort of ghost-module entirely seperate to one's embark, specifically designed to contain templates which one can paste, I still think people are going to want to be able to copy templates from existing forts, and I think rightly so.

Okay I have just written wayyyyyyyyy too much and I am going to stop... NOW.

Thanks for reading if you actually got here!
Please tell Toad to reads it!
I think it would tickle his pickle!

Thanks!