Print

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

[NW_Kohaku]

We need that Hauling rewrite desperately. 

Ekhm. Why?

There are plenty of efficiency reasons for having stacking and hauling, so that dwarves can put a stack of 5 plump helmets together with another stack of 5 plump helmets in order to conserve space in the stockpiles, or having to go back and forth from the fields carrying each seed to and from the fields individually, or making looting the goblin corpses a matter of the entire fortress population each running out into the battlefield to pick up one sock each while the iron breastplates lie unclaimed until the next siege.

Aside from the obvious immediate uses of having dwarves capable of carrying and storing multiple items together, it is necessary in the long term to allow DF to break away from its materials rut of everything costing 1 wood, 1 stone, or 1 plant, or 1 metal.  Make a barrel out of wood?  That costs 1 wood.  Want to make a ceramic pot, instead?  The clay is free, but the fuel costs one wood.  Material cost-wise, it's all just 1 wood. 

Costs in stone are pointless, since they're so abundant as to be a benefit whenever you can get rid of the stuff.  Farming is so easy that plants like food and booze and cloth are functionally free, as well.

That makes metal and sometimes wood the only resources of any scarcity or value. 

The hauling rewrites are a prerequisite to almost any serious work on the industrial workings and economy of Dwarf Fortress, because it lets you finally start making one thing cost more materials than another thing without making that cost "3 metal for a table" when 1 free stone does just as well.

[Kogut]

I think that model "bed/barrel/fuel/craft: one log" is part of making simulation of entire world possible and making it playable.

I see that 'on your way' may be nice but I have no idea how to make efficient algorithm (n log n or better) to solve it.

Herbalists are begging for fix but it is not "desperately" thing - it is not game breaking/FPS annihilating/crashing/stupid more than cage traps, food for entire fort from 3 tiles/dodging or military training.

[Granite26]

Didn't metal bars get converted to 1000s and no one noticed?

[Kogut]

When? And is it possible to make things from part of bar?

[Granite26]

Same time it happened with threads.

And no, all that happened was a muliplier got added in some places for amounts.

[NW_Kohaku]

Same time it happened with threads.

And no, all that happened was a muliplier got added in some places for amounts.

Yeah, I remember seeing a message that I was "1000 units of thread" short on trying to make a bag or something, and thinking it must be a bug at first.

Plus, once I made some super-sized dwarves to experiment with something, and they wound up making axes and such that were 65 tons of steel, but only took one steel bar, and had values in the millions.  (And even though they were tremendously strong, they were weighed down by their 20-ton pig tail socks, and as such moved at a glacial pace unless I ordered them to go naked.)

The size of the raw material has nothing to do with what you create with it right now.  Hopefully, one day that will be fixed, and you will be able to use fractions of a bar of steel, but to do that, you need hauling and stacking fixed.

[Sowelu]

God.  Stacking and hauling.

See, here's my opinion.  It should be okay to lose some significant FPS for some major intelligence upgrades.  If the FPS drops by half, but your dwarves start combining four trips into one, then you've come out ahead.  If your miners stop being dumbasses that trip over each other in an OCD effort to make sure that each of six tunnels are always exactly the same length, no matter how far apart they are, and who dare not take two seconds to mine the stone that another dwarf across the fortress has claimed, then you've come out ahead.  Things would get done SO much faster.  You wouldn't notice the FPS drop most of the time, because in terms of REAL LIFE time, you would get results sooner.

[Kogut]

It is not "the FPS drops by half", it is "the FPS drops to 1/n of old FPS" where n is quantify of dwarves. (or even "the FPS drops to 1/(n*n) of old FPS")

[NW_Kohaku]

It is not "the FPS drops by half", it is "the FPS drops to 1/n of old FPS" where n is quantify of dwarves. (or even "the FPS drops to 1/(n*n) of old FPS")

I'm going to have to ask you to explain where you came up with those numbers.  The only way that sort of complexity would make sense is if the entire pathfinding routine would have to take place per every other pathfinding creature in the entire map, which makes absolutely no sense.

[Kogut]

It is not "the FPS drops by half", it is "the FPS drops to 1/n of old FPS" where n is quantify of dwarves. (or even "the FPS drops to 1/(n*n) of old FPS")

I'm going to have to ask you to explain where you came up with those numbers.  The only way that sort of complexity would make sense is if the entire pathfinding routine would have to take place per every other pathfinding creature in the entire map, which makes absolutely no sense.

We have route from A to B. [for example single sock moved from A [battlefield] to B [trade depot]]

We want to detect routes likes A->X->Y->B, without huge additional cost.
To find routes like this it is required to make pathfinding A->B and A->X->Y->B for every possible pair of X->Y. [sock moved from X1 [battlefield] to Y1 [trade depot], sock moved from X2 [battlefield] to Y2 [trade depot], seed moved from X3 table to Y3 stockpile etc]

So with n jobs, single planned results in pathfinder running n times instead of one check.
Result: pathfinding running n^2 times for n jobs, instead of n times.
[I assumed that number of jobs is liner vs number of dwarves, but "where n is quantify of dwarves" can be changed to "where n is quantify of jobs"]

[Granite26]

so... n isn't 'quantify' of dwarves, it's the number of tasks?  Yes, that's correct, it's O^2 for tasks, and that's just for taking stuff on your way.  Collecting an armload of stuff would be hell.

____

I did think that there's often a stack of craftdwarf output at the craft workshop, all going to a single stockpile, so there's a freeish optimization there.

EDIT: Not O^2, it's more O= n*pathfinding cost which is... hard to pin down

[Silverionmox]

- Just change the job definition: instead of focusing on placing the items, define the job as clearing an area of items. It could be split up as
1. collect the items (choosing a point, preferably central or somewhere where already are multiple items.
2. restack; group similar items (eg. gems, food); fill containers
3. haul the new stacks

Alternatively, let a player designate an area (as a kind of traffic designation; or as a kind of stockpile, either general or per category) as central depot, where all stuff outside burrows is hauled to first, before further distribution to workshops or stockpiles. That would make cleaning up after a siege, storing the stuff of the latest caravan and hauling ore all easier.

[Draco18s]

Result: pathfinding running n^2 times for n jobs, instead of n times.
[I assumed that number of jobs is liner vs number of dwarves, but "where n is quantify of dwarves" can be changed to "where n is quantify of jobs"]

You didn't even try to optimize.  You're checking every dwarf and every task, rather than being able to exclude some tasks based on criteria (say, "only tasks within 5 horizontal tiles of the A->B path").  You're trying to imply that this new functionality would be performed in the least efficient and most brute force way imaginable.

[Granite26]

Result: pathfinding running n^2 times for n jobs, instead of n times.
[I assumed that number of jobs is liner vs number of dwarves, but "where n is quantify of dwarves" can be changed to "where n is quantify of jobs"]

You didn't even try to optimize.  You're checking every dwarf and every task, rather than being able to exclude some tasks based on criteria (say, "only tasks within 5 horizontal tiles of the A->B path").  You're trying to imply that this new functionality would be performed in the least efficient and most brute force way imaginable.

I don't think there's an optimization that'll make an order of magnitude difference.  Even culling on distance is still going to send you pathfinding through the fort.  Say what, you pathfind to where you're going, then look everywhere within X (ACTUAL) spaces of where you're going for an object that's to within X squares of the path further on?  Then you've got to check to make sure you can get there only going 5-10 steps out of your way?  (no walls, etc)  Then you've got to redo that every few steps, just to make sure your plan still works?

Yeah, ugly, even with optimizations.

[Draco18s]

Result: pathfinding running n^2 times for n jobs, instead of n times.
[I assumed that number of jobs is liner vs number of dwarves, but "where n is quantify of dwarves" can be changed to "where n is quantify of jobs"]

You didn't even try to optimize.  You're checking every dwarf and every task, rather than being able to exclude some tasks based on criteria (say, "only tasks within 5 horizontal tiles of the A->B path").  You're trying to imply that this new functionality would be performed in the least efficient and most brute force way imaginable.

I don't think there's an optimization that'll make an order of magnitude difference.  Even culling on distance is still going to send you pathfinding through the fort.  Say what, you pathfind to where you're going, then look everywhere within X (ACTUAL) spaces of where you're going for an object that's to within X squares of the path further on?  Then you've got to check to make sure you can get there only going 5-10 steps out of your way?  (no walls, etc)  Then you've got to redo that every few steps, just to make sure your plan still works?

Yeah, ugly, even with optimizations.

You don't check through walls...
....You know what, never mind.
I'm not even going to try debating this with you, as clearly any solution is not good enough in your eyes.