Bay 12 Games Forum

Now that skins have more uses than just becoming leather it starts to be a regular thing to turn off the AutoTan. However, most of the time I want it on since I am really only interested in vellum. This leads me to think that it might make sense to have a screen somewhat like the kitchen screen that controls how some materials should be used.

Also the biggest irritation in any fort is having to constantly watch the food production. A few small changes to kitchen screen and a little name change and it can become a screen that allows the user to set how they want plants handled automatically. The options should be cook, brew, process, extract, mash, and any other reaction the raws declare for handling of plants. The automation screen for skins would have options for tanning and parchment.

There have been many suggestions for automation in the past, but they were often complex. This only requires adding jobs to a workshop when an item is created (already done elsewhere), creating a list of reactions for use in the new screen or screens (new code), and leveraging an existing screen to connect the user with the task list (mixed bag). I think this would provide one of the simplest solutions for one of the bigger user time sinks in the game and could be a template for future automation screens.

Along with this I also think that the screen should list items in a slightly complex order. First all items that might be available to the user should be in the list, for example if there is or ever was a cow in the fortress (initial embark availability should count as available in the fortress) then cow skin is available to be set regardless of whether a cow skin currently exists. I think this same rule should be applied to the current kitchen screen; I can not count the number of times I have wanted to adjust cook settings to prevent something being used but can't because my dwarves just used the last of that item. Second alphabetical order makes it easier to find things and should be used almost everywhere that there is a lengthy list. The existing kitchen screens meats section can become a horrible mess because prepared llama brain is in the middle of turkey eggs and goose eggs.

Under the Fortress Mode: Status->Stone menu
1. Alphabetically sort the lists to make it easier for players to find things.
2. Mark the magma safe stones with something.

Under the Fortress Mode: Status->Kitchen menu
1. Separate seeds and plants into sub-menus as is done with stone (Economic/Other).
2. Sort alphabetically.
3. Use "discovered==true" instead of "quantity>=1" as the determinant for displaying the cook and brew controls for a plant.

Under the Fortress Mode: Trade with Merchant interface
1. Provide some indication about the cook/brew/eat capabilities of a given plant/seeds. This could be considered as part of the merchant's sales pitch.

This is a very different solution to the current perceived pathfinding slowdown.  Please don't bother bringing up other techniques that have been discussed before.  To understand this you should have a basic idea of how A* works; if you don't have that knowledge please get it before commenting.

Throughout this post I will use XD, YD, ZD for where the dwarf is; X, Y, Z for the target object location; and XW, YW, ZW for where that object needs to go.

---

The basic premise is that most jobs currently use a Pythagorian calcluation on the Cartesian coordinates to determine which object to use.  This involves looping through all objects, calculating the 'distance' for each that is applicable to the job.  Then targetting the location of the one found to be 'closest' for pathfinding.  The 'distance' above results in a single precise calculation for the initial H factor in the A* alogarithm.  That number then is recalculated with each step to determine if movement was in the correct direction.

---

The first question is always, "Should we calculate a path?"  This seems to already be handled in a very quick fashion for all types of jobs.  Perhaps it could be made faster, but it is very difficult to guess.  I will skip past this question.

---

The next question is, "Where should the path go?"  In the case of a workshop job it needs to go to the object closest to the workshop.  A dumping job has mostly the same answer, we want an appropiate object closest to the dump site.  The answer to which object is closest can only be accurately calculated by pathing, an obvious conundrum.

In order to solve this catch22, sort the objects based on the Z axis as they are checked for appropiateness.  Then compute the 'distance' only for those that have a Z=ZW.  If this results in no values being computed then the pathing will have an H factor of MAXINT initially.  I will also suggest that the 'distance' calculation be simplified at this step.  The simple form used is D=abs(X-XW)+abs(Y-YW), then the lowest value calculated is used as the H.

With an initial H value decided we can begin pathing.  Each step of the path should check for 2 things.
1: We are at an appropiate object.  By indexing the start and end points in the Z sorted list of objects the testing loop can be kept small.  To make the looping even smaller it only needs to be checked when the H factor of the destination tile is 0.  The H value for each step in the path would be the previous tile's H minus 1 (2 when the step was a diagonal).  If the H goes negative or reaches 0 then the tile is checked for a match.  If an object isn't there then 'distances' are computed based on that location and the correct H is set for that tile.

2: We have reached a stair/ramp.  When this occurs it is time to compute more 'distances'.  In this case we are looking at the Z level that is being led to, and calculating an H value for the outlet of the stair/ramp based on objects in that level.  The list of objects is already sorted, and we have an index that is 1 away from anything on that level.  If the calculated H for objects on the new Z level is less than the H of our current stair tile then we put that calculated H+1 at our stair location.  This will result in the up/down step having the correct H.

Let's take a moment to consider the obvious implications of this change to the alogarithm.  The A* method uses the H factor to determine if it is searching in the correct direction.  So far the change is completely breaking that, and making the path calculation more of a flood fill method.  When we consider that most fortress layouts already cause the H value of A* to work against us this doesn't seem like a bad thing.

---

The result we have so far is a path from XW, YW, ZW to the object X, Y, Z.  We actually need a path from XD, YD, ZD to X, Y, Z and a path from X, Y, Z to XW, YW, ZW.  The second path is just a matter of reversing all the directions in the path we currently have.  The first path is no longer looking for an object it is looking for a specific location and might need to be calculated.

We have to return to that first question, "Should we calculate a path?"  The reason to ask this again is because the dwarf might already be at the workshop. This would mean we have a perfect path already.  If that is the case the workload has been cut by more than half.

Assuming it is not the case we are back to calculating a path.  The second question, "Where should the path go," seems to be answered; in reality it isn't answered.  We already computed a path to the object, and it is very likely that some portion of that path will be valid for this new path.  The object we are trying to path to in this case is a point in our existing path.  We can use the exact same alogarithm described above by looking at the locations that first path went through as possible destinations.  Once the new path connects with the one we already have determined, the 2 paths can be assembled into a single one.

---

Next we need to look at what happens when the dwarf decides to get a drink in the middle of the job.  They aren't cancelling the job.  It makes the most sense to keep the path from the object to the workshop, and keep that object tasked to the job.  This does present a problem for things that can rot.  In order to handle this the object's original location should be kept available until the object has been changed and multiple taskings  should be able to be set on each object.  When the cook drops something in the middle of bringing it to a kitchen it would be tasked to be brought back to the stockpile and tasked to be cooked in the kitchen.  The return to stockpile would be putting it back exactly where it was and would use the part of the path to the kitchen  that the object had travelled.  The cook returning to duty before the object made it back to the stockpile would cancel the return job and could then path to the point the object is dropped at, and we would already have path from that point to the kitchen.

---

We should also look at some other types of things dwarfs like to walk to.

Mining, detailing, and woodcutting are the first to come to mind.  Here the object we use is the designation, and the workshop location is actually the dwarf.  This eliminates the top-left scanning currently used with these jobs.  The path is always computed based on what is closest to the dwarf.

Another one to examine is getting a drink.  The objects in this case are available barrels containing drinks.  Again we find that the change in method is an improvement in dwarven intelligence.

---

The real question is does this method make anything faster.  To answer that we have to compare what is already being done with the changed alogarithm.
1: Accumulating a list of viable targets.  Done in both.
2: Calculating 'distances' to targets.  Done once in A* for all targets.  Done repeatedly as needed in the new method; which could be slower.  Reduction of precision in the new method and restricting calculations by Z should result in speed equality.
3: Examining tiles in the wrong direction.  This can occur with both methods because of layouts.  I can't determine any clear difference in quality on this point.
4: Walking past a viable object.  A* does this all the time because of the 'distance' calculation determining a fixed destination.  The object based method changes the destination as needed to home in on what is closest.  This should frequently result in shorter paths.

I believe that last statement is what will result in faster pathfinding while improving dwarven intelligence.

It has been said many times that the learning curve for DF is quite steep.  The wiki and forums provide a source of help for many users.  The in game help could use significant work though.

This suggestion is not how to directly improve the in game help.  I would instead suggest moving the in game help into files that are player edittable.  There are many people in the player community that like helping others and it is very likely that the help would be sorted out and improved by us.  It should even be possible that the changes made by the community could become part of official releases.

I set all all my dwarves to hunting. Since I have no wildlife on my map they never hunt, but my goal was to armor all of them.  Hunting of course causes the dwarf to just lay down and sleep where ever they are, which was fine by me.

When a dwarf sleeps on a trap it causes it to activate.  I would hazard a guess that it is just the laying down that does it and this is why some injured animals trigger traps.

There are a few options I see for fixing this:
1. Laying down on a trapped location should not trigger it.
2. Hunting looks at the location for safety before actually laying down.
3. Give us a new DANGER designation.  All outside tiles are initially set to maximum danger at embark. This designation could be used for the stay indoors order, by having different danger levels allowed for civilians and soldiers, we would simply have to change the danger levels.  Areas marked with any danger level also should disallow the dwarf from being On Break, loitering with no job, taking a nap, etc in that spot.

I think at least one of the first 2 is needed to fix the bug.  Having the third option implemented solves this particular problem by making it a user issue, and also fixes issues with the stay indoors order.  However the third option doesn't actualy fix the bug, since animals might still trigger traps.

I am finally getting around to trying out and working with the adventurer mode.  In fact I largely hadn't even been reading this forum.

I decided to make a spear dwarf, and with spears being all pointy they keep getting stuck in the wounds.  Now my thinking after seeing the dwarf twist the spear around in a some kobolds head is that there should be new brain damage.  Nope.

Alright, so I figured out I could get more options in the wrestling screen.  None to pull the spear out, and none to push it deeper.  Nothing to wiggle or waggle either.  So I try grabbing the spear with my shield.  There is no new damage caused!  As I see it the dwarf just slammed a shield wearing hand onto that spear, it would have waggled!

After a bit longer I figure out that moving will pull the spear out.  Still no damage from yanking it out.  That is just plain wrong.  There is also a chance the grip is lost, which makes sense; but that means there is only downside.  I am imagining a spear that is about 4' shaft 1/2' blade shaped like a long version of a broadhead arrow.  Shove in, twist and try to yank out and bone may be solidly in the way.  If the dwarf is strong enough the opponent should be yanked or more bones broken.

Another thing that really got me was some skill gain issues.  No skills are gained from twisting the spear about.  No skills are gain from bashing with a shield either.

In fact using a shield as a weapon seems like a minus.  It doesn't pay attention to any skills.  You can have a weapon held in the same hand it will hit with the shield instead.  I am again imagining a shield that could be used a little more agressively.  Kind of a V shape with a wider angle V at the top.  This allows the spear to be rested on top of the shield as part of the attack stance.  The grip points on the shield and the size allows that the lower point chould be raised for a slashing attack.  A slight bevel and serration on both long sides serves as blades and sword breakers.

Basically what I see as needed so far is: shield as weapon should use skill, possibility of shield to be better designed for pierce and slash damage, damage for twisting weapons in wounds, damage for pulling stuckins out, wrestling moves added for interracting with a stuckin.

For that last one, say you fire 10 arrows at something, 5 stick and they still close to melee range.  You should be able to grab those stuck arrows and then twist, yank, wiggle, shove, and waggle them.  All of those maneuvers should cause obvious damage.  In fact just grabbing them should cause some damage, the motion to grab would be at full speed and wouldn't complete until the reaction to contact by grabbing part was complete, meaning the stuckin gets wiggled about some.  Misses could actually have the chance of shoving the stuckin deeper, the angle was just wrong.

Basically I am saying you made an amazing level of realism, so far, on the combat engine and I would love to see it completed.  Defintely looking forward to it.

Too bad this version doesn't seem to actually burn elephants, wood, trees, and some other stuff with flooding lava.

Anyhow, the world is nicely burnt now.

Time to butcher my elephants.

Not actually a bug, just an irritation.  It is an irritation nearly everyone complains about when they notice a miner walk half way around the world to stand next to his target when all he needed to do was take 1 step.

I am posting this more as a suggestion, and posting it here because the behavior does qualify as a bug under the concept of "not the intended result".

The logic is actually very simple.  We can not path from the dwarf to his mining target because the mining target is not an available place to step.  We do not want to path from the dwarf to each square around the mining target because that takes too long and does not actually assure that the target is reachable from that location.

What can be done is reverse logic.  Path from the mining target to the dwarf.  This gives use a shortest route and ensures reachability.  Then remove the first step and reverse the path.  This provides a route for the dwarf to travel and the final location to stand.

This particular logic design works with a dwarf just finished mining a tile and his new target tile selected him, as well as mining a new channel.  It can work with workshops and picking up items, those require standing on instead of standing next to and would not remove the first step prior to path reversal.