Print

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

[Granite26]

Im a big fan of slower mining, and reforming walls makes a lot of sense(not as living stone, but maybe as 'granite conglomerate' that is looks the same as living granite.), esp. For processor speed.

I don't think 1 walls worth of granite should make one walls worth of G.C. though.

Also,  makes for more interesting veins if a square can contain 1-7 units of ore.  Makes them easier to follow too.

_________
As for carts, I know they are planned, I know they are popular, I just think they are a bad idea.  I wasn't trting to 'replace carts function with barrrows', because I didn't think thqt was carts job to begin with.

[Symmetry]

I completely agree they're a bad idea with the way the game works right now.  About the most use I'd get out of them is running over goblins in some kind of nightmare frogger clone.

[NW_Kohaku]

Well, lifts might be either a positively fantastic masterstroke of coding that Toady performs that allows for extremely brilliant automation of logistics, or it will simply be another manually-operated thing that requires very careful construction of pressure plate mechanisms to be able to move large pieces of fortress around in a big steampunky way.

If dwarves know how to use lifts themselves without your input, you can make those minecarts become something very special, with multiple floors of tracks and the lift acting as a sort of terminal.  You can ferry out minecarts to the mining veins, dump all the slag and worthless stone in one cart that gets automatically ferried off into the dumping grounds, while the useful ores and gems and stones get put into the other cart that goes to the central distribution center.

If I can actually design and manage a fully automated minecart logistics model in future DF, I would be beside myself in euphoria. 

Unfortunately, I don't think this is going to be coming very soon if at all, and I doubt heavily the "coming at all" part, as well.  I think we're more likely to see the "you have to move the lifts by manually ordering the pulling of a lever" type of mechanics.

[Symmetry]

If they're both manually operated then they're going to need to carry a huge amount of rock to justify the overhead of operating them, let alone the overhead of building them and their tracks.  (sidenote, I think some mines used grooves carved in the floor which might work better)
Moving water or magma around might possibly be another use?  If you can move large amounts at once it would help stop evaporation problems, and it would be worth the overhead compared to building a pump network in some cases.

I am looking forward to sections of the fortress moving though, if only for a "Transformers: Fortresses in Disguise" thread.

[Granite26]

If they're both manually operated then they're going to need to carry a huge amount of rock to justify the overhead of operating them, let alone the overhead of building them and their tracks.  (sidenote, I think some mines used grooves carved in the floor which might work better)
Moving water or magma around might possibly be another use?  If you can move large amounts at once it would help stop evaporation problems, and it would be worth the overhead compared to building a pump network in some cases.

Wow, nice... grooves could make the whole shebang work.

[NW_Kohaku]

If they're both manually operated then they're going to need to carry a huge amount of rock to justify the overhead of operating them, let alone the overhead of building them and their tracks.  (sidenote, I think some mines used grooves carved in the floor which might work better)
Moving water or magma around might possibly be another use?  If you can move large amounts at once it would help stop evaporation problems, and it would be worth the overhead compared to building a pump network in some cases.

I am looking forward to sections of the fortress moving though, if only for a "Transformers: Fortresses in Disguise" thread.

Yes, I have no doubt that the first thing everyone will do upon the instant a version of DF with moving fortress parts is released is to build a horde of giant spider walkers that vomit magma at attacking goblins.  I look forward to the arms race.  (I also wonder if "improved sieging" will include goblin spider walkers with magma, just as part of that arms race - SURPRISE, SUCKERS! Remember that child the goblins kidnapped 4 years ago?  Now goblins have the secrets of magma-spewing spider-walkers, too!)

Anyway, I think that stone tracks would be by far the most preferred method of running a minecart, and could probably just be designated to be carved into the floor as you go.  Maybe it would be slower than a metal track, but it's a world less annoying than actually using a metal bar to extend a minecart track to the next set of iron ore that you are going to convert into the steel that you will only use extending the mine cart tracks.  Even if one steel bar made 10 tiles of track, you're asking a lot, and I expect it would only be really useful in the truly important areas where additional speed in movement would be worth almost any material price.

Shipping magma by minecart seems both crazy and dwarfy, if not quite as dwarfy as the utterly insane magma piston.  I can't wait for mechanics that include making a minecart going down a ramp speed the cart up, and make turns along the track "slosh out" some of the magma onto unsuspecting dwarves, or runaway minecarts create Frogger-style !!Fun!! for your miners or maybe some goblins.  OK, so maybe not a big utility to the average player, but it is some sadistic fun.  Plus, I still have fond memories of designing roller coasters in some old theme park simulator games, where you had to keep the actual physics of how fast your roller coaster was going in mind.  That seems like the sort of fun and/or Fun that DF is made for.

... with all that said, I think we've sailed waaaay off topic in the past couple pages.  Weren't we talking about ways to optimize pathfinding before?

Or is there nothing left to talk about regarding how to make gathering as many items as possible into the most efficient task processor-wise possible?

Darn my lengthy posts and tendency to get ninjad for it...

Wow, nice... grooves could make the whole shebang work.

Yeah, I think the best way to handle carts would be just designating mining tracks as you carve through the rock, and designating certain "stops" by hand if need be, although just having the dwarves automatically know where best to place their minecart would be the ideal solution, if one that might take some fancy (if fortunately infrequent) pathfinding decisions.

[Silverionmox]

Mine carts on rails would really only be justified for the continuous mining of huge deposits of ore and coal. While I'm not against crossing the tech border in specific cases, there's a reason mine carts didn't really turn up before the industrial revolution and mass production: too much trouble for those relatively small quantities of goods. So I suspect that mine carts will only see much use for the future huge, concentrated deposits that will be mined for years: only there the distance from the items to the mine cart will always be small.

[NW_Kohaku]

Mine carts on rails would really only be justified for the continuous mining of huge deposits of ore and coal. While I'm not against crossing the tech border in specific cases, there's a reason mine carts didn't really turn up before the industrial revolution and mass production: too much trouble for those relatively small quantities of goods. So I suspect that mine carts will only see much use for the future huge, concentrated deposits that will be mined for years: only there the distance from the items to the mine cart will always be small.

There are several cases I can think of for routine bulk hauling jobs in DF, though - first is wood dumping down a pit to the furnaces for conversion to charcoal.  The wood would have to be collected manually, but the central pit could be de-forbidden routinely by the player, and have a minecart pick up large loads of wood to carry it to the furnaces.  In an ideal world, you could have that dump site just dump wood directly into the minecart waiting at the bottom, and that whole process would be automated.

Next is sending a minecart up to your "killzone" to carry down all the goblin armor for melting.  Preferably protecting the cart's pathway with a drawbridge that has a rail track on it.

Finally, a path from a central "finished goods" stockpile to the trading depot.  Just shove it all on the cart, and dump the cart onto the depot.

There's also just designating the stone rails to be built along the mine veins instead of simply creating normal floors, which would mean that as you dig, the minecart's reach extends along with the vein.

[Granite26]

Yes, I have no doubt that the first thing everyone will do upon the instant a version of DF with moving fortress parts is released is to build a horde of giant spider walkers that vomit magma at attacking goblins.  I look forward to the arms race.  (I also wonder if "improved sieging" will include goblin spider walkers with magma, just as part of that arms race - SURPRISE, SUCKERS! Remember that child the goblins kidnapped 4 years ago?  Now goblins have the secrets of magma-spewing spider-walkers, too!)

spat coke....

[NW_Kohaku]

I'm already concieving of ways to build a "spider walker" - assuming they cannot rotate, they would need two sets of legs, one to move north/south, and another to move east/west, and you could basically put a ring of fortifications at the top, and a ring of fortifications near the bottom, sticking out as a downward bubble, and have marksdwarves staff the walker. 

Then, if goblins come with walkers of their own, we could have marksdwarves launch bolts at the rival walkers, and then try to launch a gangplank to board the enemy walkers.

Basically, land-naval battles.

[Symmetry]

... with all that said, I think we've sailed waaaay off topic in the past couple pages.  Weren't we talking about ways to optimize pathfinding before?

Or is there nothing left to talk about regarding how to make gathering as many items as possible into the most efficient task processor-wise possible?

There is but it's hard to think of an efficient algorithm to solve a problem we don't understand.  If we accept that the only use of minecarts (And related lifts, etc.) is to move things from one or two specific locations or stockpiles, to a few other specific locations, and we think manual control is tolerable, then that sets some fairly easy limits on what the algorithm is actually expected to cope with.  In this case we don't really have to change the algorithm at all, we just have a minecart that create store jobs like a stockpile.

Similarly for multiple hauling problems we really care about cleaning out workshops, stacking rocks (possibly into minecarts) and perhaps one or two jobs that need two ingredients (brewing with a barrel and plump helmet for example). 
The cases where the items are next to each other, or in the same place, are the easiest here as already discussed.  Multiple ingredients is harder, though as we're only trying to improve on the time spent running around and calculating at the moment the dwarf could go for the lightest item first (obv.), then when they get it look for the other item it would get if it was at the workshop (normal rubbish 3D cartesian distance, which needs fixing too but that's a different problem), then path to the new item directly, and then back to the workshop.

This is three pathfinds rather than four, although in the worst case it's possible they will cover the same number of tiles as currently.

If Toady does try and fix the 3D cartesian distance item lookup too then there are a lot of possibilities, but they involve so much work I think it might be best left for him to deal with.  Too many tradeoffs based around what he's comfortable with coding and maintaining.

Also it seems to me the wheelbarrow problem discussed earlier is identical to the current situation with water buckets.  They do make a mess of my hospital.
I don't have anything more useful to say on that except people wearing wheelbarrows makes it much simpler

[Maklak]

I'd also like to see an improvement to stockpiles: one pointer for taking items from another stockpile and one for giving to another stockpile. While not a true n:m relationship, it would still be more versatile than the current system, where a stockpile can be given items by many stockpiles, but one stockpile can give items to only one stockpile. With my suggestion giving and taking are functionally similar, but distinct. Any stockpile could give items to one stockpile and take items from one stockpile. That way you could have 1:n and n:1 in various combinations, and m:n would require a "relay" stockpile in the middle (m:n could be formed by m:1 and 1:n). It would ofc require coding various borderline cases (Can stockpile A take from B, while B gives to A? etc)

I'm not sure I follow you on this one...

Each stockpile can take from any number of other stockpiles, but can only have one stockpile taking from it in turn. This limit applies even if the two stockpiles you want it to feed into don't share a single material that can be stored in both of them. Additionally, you can't make two stockpiles feed into each other, although larger loops (e.g. 3 stockpiles that feed into each other in a circle) are allowed.

I'm suggesting, that apart from "take from a pile" we get "give to a pile". Each workhop would only get one "take from a pile", and one "give to a pile", but a stockpile could have multiple stockpiles taking from it, and giving to it. It is kinda confusing, as taking and giving are not the same, yet work similar (items get moved).

"Give to a pile" could be used for making a central stockpile 'sink' items from other stockpiles, pretty much like we can do with the current system.

"Take from a pile" could be used to make multiple small stockpiles (workshops input, prison cell foodstores, etc) take from one central stockpile.

For this to work each stockpile would only need two pointers: one to from where it takes and one to where it gives items. At each iteration of stockpiles looking for items, these two pointers would be checked for each stockpile. Things like stockpile item count, and tasking items to be moved are already in the code, so it probaly wouldn't be difficult to implement (and easier than n stocpiles taking from m stockpiles), and it would geve players more options with logistisc, which this thread is about. 

[Draco18s]

Just like to point out that both of those do the same thing.  I'm all in favor of adding another UI option, but mechanically those are identical.

[Granite26]

I wrote up a proposal for stockpiles that didn't want to be filled (only craftsmen used them to save from walking.), Ones that did want to be filled(stocking multiple dining rooms) and ones thqt don't care.(warehouses).

If you get your restrictions right, everything works from there.

[Maklak]

Just like to point out that both of those do the same thing.  I'm all in favor of adding another UI option, but mechanically those are identical.

They are identical in that weather A takes from B or B gives to A, items get moved from A to B. They are not identical in how they are implemented, as "take from another stockpile" fills *this stockpile, and "give to another stockpile" empties *this stockpile. This suggestion is also different from what we have now in that multiple stockpiles could take from one stockpile as well as one stockpile could be given by many stockpiles. In the current system (unless wiki is wrong) a stockpile can take from multiple stockpiles, but any stockpiles can be taken from by only one stockpile.

If I still haven't made this celar, lets just drop it, faster hauling of multiple items is more important anyway.