Print

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

[Kogut]

You're pretending that you can't look at the map when trying to determine if something is "5 squares away."

Lets say this is our map.  * are the path, T is a Task Object.

.*......
.*......
.*..#...
.*..#T..
.*..#...
.*..#...
.*......
.*......

If we count diagonals as 1 space, then T is 5 away from the path (go around the wall on the top).  So we want this to be included, but we don't want to run an A* check on it (and by definition, every other task on the map).

What can we do?

Well, we do this: find every square adjacent to the path, and every square adjacent to that, etc. until we have 5 deep and note every task that falls inside that area.  Essentially we're doing a limited distance flood-fill.


1*12345.
1*12345.
1*12#45.
1*12#5..
1*12#5..
1*12#45.
1*12345.
1*12345.

Voila.  And if the object is in another room not direclty accessible, then the item isn't categorized:


1*12345.
1*12345.
1*12####
1*12#T..
1*12#...
1*12####
1*12345.
1*12345.

Now you have a list of every task that is inside some boundary distance of the dwarf's desired path.  Some tasks have a starting point and an ending point ("fetch quests" and for those you need to check the starting point and the ending point with the requirement that the start location is closer to the dwarf's starting location (and vice versa) which you can do through normal distance calculations (no need to do a path-find distance, as we already know that both points are within 5 of the existing path).

It is L*x, where L is length of path and x is maximum distance to find job (it is in fact BFS with found path as starting points with limited path length). It also will annihilate FPS.

[Kogut]

Alternately, it can actually look at the physical map around it, and search every tile for objects, then search those objects for jobs that take that object someplace, and then test to see if they are going the same place, and THEN search to see if they are actually "nearby" and don't have an obstruction between them. This causes problems to start with, since you have to search a lot of tiles for items to even start with, and then, if you have something horribly complex like a dump zone/quantum stockpile with 5,000 items in one of those tiles.  Preventing quantum stockpiles or putting limits on the number of items that can physically enter a tile (meaning dumping an item into a pit which already has 100 items in it will simply create a "solid wall" that prevents more items from entering it) will put some sanity check into that, but it's still going to be a problem.  This has a complexity of R^3 (O_p+O_q+O_d), where R is the radius of tiles around the object that you consider "nearby" (Alternately, you can only search for "nearby" as being on the same z-level - this means that objects on different portions of a ramp will never be tasked with one another, but it can cut out a lot of false positives where you assume that anything on another z-level is probably going to be very difficult to path a direct line to.  This means you only need R^2 complexity.)  while O_p are the number of items present in a given tile, O_q are the number of items with hauling jobs queued, and O_d are objects with nearby enough destinations.

Complexity is rather: n+m*pf, where:
n: number of items nearby start
m: number of items nearby start with nearby end
pf:cost of pathfinding from end to additional possible end

Problem is that worst case is sth like this:
{pile of dumped objects and sock}++++++++++++++corridor 1+++++++++++++++++++{socks stockpile}
+
++++++++++++++++++++++++++++++++++++++++corridor 2+++++++++++++++++++++{quantum dump}
In result every single dump-marked object must be processed before picking up sock to check is it possible to consolidate them in single job (with result: bad idea, pick only sock).

It would result in effects similar with ghosts (100 FPS - 0 FPS - 100 FPS). So without limiting number of objects on tile it is completely impossible.
@10 jobs for one dead dwarf. Better solution is to replace 2 shoes, 2 socks etc with single object "typical civilian clothing"

[NW_Kohaku]

Complexity is rather: n+m*pf, where:
n: number of items nearby start
m: number of items nearby start with nearby end
pf:cost of pathfinding from end to additional possible end

Problem is that worst case is sth like this:
{pile of dumped objects and sock}++++++++++++++corridor 1+++++++++++++++++++{socks stockpile}
+
++++++++++++++++++++++++++++++++++++++++corridor 2+++++++++++++++++++++{quantum dump}
In result every single dump-marked object must be processed before picking up sock to check is it possible to consolidate them in single job (with result: bad idea, pick only sock).

It would result in effects similar with ghosts (100 FPS - 0 FPS - 100 FPS). So without limiting number of objects on tile it is completely impossible.
@10 jobs for one dead dwarf. Better solution is to replace 2 shoes, 2 socks etc with single object "typical civilian clothing"

That doesn't make sense to me...

First off, if a stockpile is full, you don't have to pathfind to it to see if it's full beforehand, the job itself can see whether or not the stockpile is full before it posts itself to see which stockpile the job wants the item in question to go to.

Secondly, you don't have to fully pathfind from the starting location to each destination to see whether they are going to the same place - you can do that by just having the job post is destination stockpile, and comparing coordinates.  You can do a quick and dirty calculation of distances by absolute distance from the starting location to each stockpile and from stockpile to other stockpile to get a very rough idea of which would be most efficient, and then stick with it, whether it was actually more efficient or not.  (Which is very similar to how dwarves choose the "closest" stockpile to pull stones from when they are choosing materials for workshops.)

Hence, the only way you'd reject a pathfinding to a stockpile would be if it turns out you can't pathfind to the stockpile at all.  The game should take a bias towards claiming jobs just to get them out of the way, even if that involves using the not quite most efficient way of hauling goods.  Remember, you would have to pathfind from where the dwarf starts to the goblin corpse to the stockpile back to the corpse back to the stockpile back to the corpse back to the stockpile already.  Consolidating this down to one big pathfinding crunch where you calculate from dwarf to corpse to stockpile A to stockpile B to stockpile C wouldn't actually cause that much of an average FPS dip.

You can combine this with some of the more advanced pahtfinding ideas, like storying paths from one stockpile or workshop to other stockpiles or workshops that are commonly used, and get a more accurate (less dirty, but still quick) pathfinding cost to use when deciding the closest distances.

Thirdly, I hate to think of any condition other than claiming a quantum stockpile where you would actually have a hundred or so jobs activate on top of a single tile that need to go to completely different stockpiles, but even if there were, so long as you aren't checking for a path to a blocked-off stockpile, those jobs should still be claimed by most dwarves who even bother to pathfind, anyway, unless they literally cannot pathfind from the quantum stockpile to the stockpile they want to go to, in which case that stockpile should just have some sort of "inaccessable" marking for a certain number of frames.

[Silverionmox]

Let's try out where a more naturalistic approach gets us.

- As a reminder, dwarves have a limited carrying capacity. They can only carry so much goblin shoes, depending on their force and containers. This will naturally limit the items we have to consider.

- Grouping jobs: instead of striving for maximum time and resource efficiency (every free dwarf must haul if there's an item to be hauled), strive for organizational efficiency: all hauling jobs for a group of items are grouped, and assigned to a dwarf. That dwarf goes over there, takes what he can carry (preferring items for the same stockpile(s)), goes to stockpile it (visiting several stockpiles in a row and dropping of items, if necessary), and returns to pick up more. When he goes to sleep somebody else can be assigned to continue the group of jobs.

- Ad hoc: a dwarf goes to an item to be hauled, picks it up and checks for a similar nearby item (using a limited floodfill like Draco suggested; the distance of the floodfill should be larger if the trip to the stockpile is longer (people think twice whether they have everything before leaving the store and driving back home, but if you're taking food out of the pantry it's not important if you have to return one more time)), if he finds one he picks it up and checks for more until his backpack is full and goes to the stockpile, if he doesn't he goes to the stockpile.

- Central depot stockpiles: for large quantities of diverse items (eg. battlefield remains) it makes sense to haul everything to a central location (inside your fortress, presumably) and sort it out later.
The way it could work is to flag a stockpile as central/depot: this stockpile would then get priority as a destination for non-stockpiled items. However, it would also be emptied ASAP by moving stuff to normal stockpiles. That way you could set up a central stockpile for everything to start, and later diversify with other central stockpiles when you don't want corpses to be brought into your central hall, or set up the ore processing facilities elsewhere.

[ikkonoishi]

One solution is searching the entire jobs list, and then looking at the "starting from" location to find the "nearby" ones. This causes problems when the jobs list becomes longer, because it means that every new job will have to make a search of every single job already put on the job queue to search its starting location. This basically has a complexity of O^2+O where O is the number of jobs being put into the jobs queue.  (Subgeometric complexity growth with number of tasks.)

I don't think it would be near that complex. You don't need to check the existing jobs at all. The empty slots in the stockpile generate the jobs after all. When the stockpile goes through the item list grabbing items to fill its slots it could create bundled item gather jobs instead of tons of single hauling jobs.

So instead of having

Code: [Select]

Item myitem
for each emptyslot in stockpile.emptyslots
{
   myitem = getUnstockpiledItem(stockpile.acceptableItems)
   CreateJob(Haul,myitem,emptyslot)
}
You would have

Code: [Select]

bulkhaulingjob[] myjobs
item myitem
for each emptyslot in stockpile.emptyslots
{
   myitem = getUnstockpiledItem(stockpile.acceptableItems)
   for each job in myjobs
   {
      if (job.items[0].location.getXYDist(myitem.location) < 2 && job.items < MAXBUNDLEDITEMS)
      {
         job.addHaul(myitem,emptyslot)
         break
      }
      elseif (job == myjobs.lastjob)
      {
         myjobs.add(CreateJob(BulkHaul,myitem,emptyslot))
         break
       }
    }
}
The code for the job itself would be.

Code: [Select]

goTo(items[0].location)
for each item in items
{ 
   if item.location.getXYDist(dwarf.location) < 2
   {
      pickup(item)
   }
   else
   {
      dwarf.complainAboutItemBeingMisplacedAndGoGetABeerOrSomething()
   }
}
for each destination in destinations
{
   goTo(destination)
   drop(items.firstitem)
}


With MAXBUNDLEDITEMS at 2 this would double hauling efficiency for 90% of the jobs that occur. Workshops are always full of items most of which will end up in the same place. Crafting, butchering, brewing, plant processing, elf murdering, ect... Forging usually needs metal and fuel both of which come from the bar stockpile, and could very well be in the same bin.

It considers only directly adjacent tiles to be acceptable for bundling which removes the need for additional path-finding at the pickup end. So long as the items are close enough you just teleport them to the dwarf's inventory. They don't even have to move.

The jobs are all generated by the same stockpile so any additional pathing on the delivery end is up to the player.

[Lungfish]

Most of the crap my dwarves swarm to pick up and carry back to the hoard can fit in bins, and the dwarves can carry bins full of stuff. Why, oh why, can't they just bring a bin with them? It could be automated - when 10+ binnable things are a certain distance from their target stockpile and in the same region, a dwarf on their way to haul them can pick up an empty bin and put the stuff in it like they would put bolts in a quiver. Or if they HAVE to put down a bin before putting something in it, maybe a spot could be designated just for bins - a temporary "anything" stockpile that accepts only items on adjacent tiles. Picking things up one at a time and putting it into a nearby bin wouldn't be as bad as having to go all the way to hell and back for every sock, helm, and amulet.

Or maybe it's a Dwarven Culture thing? Maybe they just love racing through battlefields in a great and infrequent Trinket Relay. Running in a crowd of 60 dwarves accross the map to scavenge an elven caravan that didn't survive a goblin ambush could generate invisible happy thoughts, and finding a more efficient way to haul things could make them sad without them even knowing about it!

[Granite26]

Nice, ikinoishi....

Krull has the main character reach into a stream of 'lava' to retrieve the magic shuriken needed to kill the final boss.  Basically it was a use case derived from a movie.

[NW_Kohaku]

- As a reminder, dwarves have a limited carrying capacity. They can only carry so much goblin shoes, depending on their force and containers. This will naturally limit the items we have to consider.

Oh, did I forget to mention that?  I meant to.  If you are only pathfinding once you have actually decided to try carrying something, then you don't need to pathfind any more items than you can actually carry.

- Grouping jobs: instead of striving for maximum time and resource efficiency (every free dwarf must haul if there's an item to be hauled), strive for organizational efficiency: all hauling jobs for a group of items are grouped, and assigned to a dwarf. That dwarf goes over there, takes what he can carry (preferring items for the same stockpile(s)), goes to stockpile it (visiting several stockpiles in a row and dropping of items, if necessary), and returns to pick up more. When he goes to sleep somebody else can be assigned to continue the group of jobs.

I was going to try to address Draco's post with this, but... I'm not sure if looking for things "on the way" is worth the pathfinding cost, actually.  Basically, we could just go by absolute job starting and ending point definitions of "nearby".  It means that maybe the haulers will go to a distant site, pick up half a wheelbarrow's worth of socks, and roll right over a sock on the way to the sock stockpile, but that at least prevents additional limited-range flood pathfinding along an already pathfound route. 

Basically, I'd think it would come down to how likely it is that you would save trips and jobs and extra full pathfinding tasks by doing so compared to the costs of doing so.  You'd have to test this with plenty of live forts to really get a sense of the average number of jobs you'd save for doing this.

If a goblin dies, and the stockpile for metal armor are clearly in another part of the map than the stockpile for fabric and leather clothing, then there should probably be completely different tasks for dwarves to jump for.  If there are a large enough number of items that the dwarf cannot claim all the hauling jobs for that pile of crap, then the jobs that he/she cannot claim should still be left up on the jobs queue for other haulers to try to take.

- Ad hoc: a dwarf goes to an item to be hauled, picks it up and checks for a similar nearby item (using a limited floodfill like Draco suggested; the distance of the floodfill should be larger if the trip to the stockpile is longer (people think twice whether they have everything before leaving the store and driving back home, but if you're taking food out of the pantry it's not important if you have to return one more time)), if he finds one he picks it up and checks for more until his backpack is full and goes to the stockpile, if he doesn't he goes to the stockpile.

Actually, if we're dealing with wheelbarrows or even mine carts that are "mobile stockpiles", then wheelbarrow-hauler dwarves should have a much larger "nearby" definition, so that a single guy with a wheelbarrow might try to take up every single goblin-corpse-clothing-looting job that he can physically cram into his wheelbarrow.  Provided that the siege goblins all died relatively near one another, you could set a ten or twenty-tile "nearby" radius or something similarly large, and use flood filling around the corpses to see a decent path between which corpses to visit.  The flood-fill would be costly, but it should only take one or two dwarves to even do the entire task, as opposed to the hundreds of trips you'd be saving in the long run.

- Central depot stockpiles: for large quantities of diverse items (eg. battlefield remains) it makes sense to haul everything to a central location (inside your fortress, presumably) and sort it out later.
The way it could work is to flag a stockpile as central/depot: this stockpile would then get priority as a destination for non-stockpiled items. However, it would also be emptied ASAP by moving stuff to normal stockpiles. That way you could set up a central stockpile for everything to start, and later diversify with other central stockpiles when you don't want corpses to be brought into your central hall, or set up the ore processing facilities elsewhere.

This makes a lot of sense, but may be tricky to get coded. 

Of course, this pretty much describes what the minecarts are supposed to be and do, anyway.  You make a minecart track to near where the hauling jobs are getting created (battlefield, mining quarry, farm, underground tree factory), and then shove the mining cart back to the central distribution area, where it can be distributed to the workshop resource stockpiles.


Ah, three ninja attacks... I'll post and sort that out later.

[NW_Kohaku]

I don't think it would be near that complex. You don't need to check the existing jobs at all. The empty slots in the stockpile generate the jobs after all. When the stockpile goes through the item list grabbing items to fill its slots it could create bundled item gather jobs instead of tons of single hauling jobs.

With MAXBUNDLEDITEMS at 2 this would double hauling efficiency for 90% of the jobs that occur. Workshops are always full of items most of which will end up in the same place. Crafting, butchering, brewing, plant processing, elf murdering, ect... Forging usually needs metal and fuel both of which come from the bar stockpile, and could very well be in the same bin.

It considers only directly adjacent tiles to be acceptable for bundling which removes the need for additional path-finding at the pickup end. So long as the items are close enough you just teleport them to the dwarf's inventory. They don't even have to move.

OK, I didn't know that the stockpile creates the job, not the item.  That changes how I have to consider the hauling jobs, then, although I have yet to think through all the ramifications... give me a bit. 

The limited attempt to go out of your way to collect more items unless it's a really easy calculation can make some sense, so I guess it's a matter of just trying to playtest this until it comes out being the best overall balance.  (Maybe some sort of init option for "nearby" definition so that the players can test this out, since we players can carry a lot more of the playtesting weight than Toady can?) 

We also need to have a way to use wheelbarrows, however, which would presumably be able to carry more items at once, so that you could stuff all the crap a goblin drops into the wheelbarrow if it's all going to the same stockpile, anyway.

Most of the crap my dwarves swarm to pick up and carry back to the hoard can fit in bins, and the dwarves can carry bins full of stuff. Why, oh why, can't they just bring a bin with them? It could be automated - when 10+ binnable things are a certain distance from their target stockpile and in the same region, a dwarf on their way to haul them can pick up an empty bin and put the stuff in it like they would put bolts in a quiver. Or if they HAVE to put down a bin before putting something in it, maybe a spot could be designated just for bins - a temporary "anything" stockpile that accepts only items on adjacent tiles. Picking things up one at a time and putting it into a nearby bin wouldn't be as bad as having to go all the way to hell and back for every sock, helm, and amulet.

This is exactly what wheelbarrows are for - they're just bins on a wheel and don't even weigh dwarves down.

[Granite26]

NW, check out the job priorities thread in my sig.  It's got a lot of job info in it.

[Silverionmox]

- Grouping jobs: instead of striving for maximum time and resource efficiency (every free dwarf must haul if there's an item to be hauled), strive for organizational efficiency: all hauling jobs for a group of items are grouped, and assigned to a dwarf. That dwarf goes over there, takes what he can carry (preferring items for the same stockpile(s)), goes to stockpile it (visiting several stockpiles in a row and dropping of items, if necessary), and returns to pick up more. When he goes to sleep somebody else can be assigned to continue the group of jobs.

I was going to try to address Draco's post with this, but... I'm not sure if looking for things "on the way" is worth the pathfinding cost, actually.  Basically, we could just go by absolute job starting and ending point definitions of "nearby".  It means that maybe the haulers will go to a distant site, pick up half a wheelbarrow's worth of socks, and roll right over a sock on the way to the sock stockpile, but that at least prevents additional limited-range flood pathfinding along an already pathfound route. 

Basically, I'd think it would come down to how likely it is that you would save trips and jobs and extra full pathfinding tasks by doing so compared to the costs of doing so.  You'd have to test this with plenty of live forts to really get a sense of the average number of jobs you'd save for doing this.

If a goblin dies, and the stockpile for metal armor are clearly in another part of the map than the stockpile for fabric and leather clothing, then there should probably be completely different tasks for dwarves to jump for.  If there are a large enough number of items that the dwarf cannot claim all the hauling jobs for that pile of crap, then the jobs that he/she cannot claim should still be left up on the jobs queue for other haulers to try to take.

Indeed, jobs on the way shouldn't be considered, because that inevitably requires computing "the way", i.e. pathfinding, adapting the path etc. What I meant was grouping jobs that are close together.

After his load is full, the dwarf is simply emptying his load. So he just needs to pathfind to the nearest stockpile, drop off what he can, and then he'll look for the closest stockpile out of all the stockpiles he needs to visit. Repeat until empty. Trying to find the ideal route between the stockpiles is not worth it, IMO. I don't care if the haulers are a bit dumb. They're normally safely inside the fortress at that point anyway.

a decent path between which corpses to visit

That's a travelling salesman problem. Might be tricky. What I meant was floodfilling until a hit, then picking that up, then floodfilling again from that position.

[ikkonoishi]

We also need to have a way to use wheelbarrows, however, which would presumably be able to carry more items at once, so that you could stuff all the crap a goblin drops into the wheelbarrow if it's all going to the same stockpile, anyway.

Just add a check to my pseudocode in the job section. If the number of items in the job is higher than, lets say, 5 the dwarves will grab a wheelbarrow or empty bin. If they can't find one then they can grab what they can, and maybe split the bulk haul job so another dwarf can help.

Or wheelbarrows could be creatures that can't move on their own. They have their own AI that looks for clusters of hauling tasks when they are idle, and claims them. Then they create a job for a dwarf to come move them to their destination and load them. If you don't have wheelbarrows then there would not be any extra checks for wheelbarrow usage. This would also allow for other creatures to be haulers with dwarven assistance and proper training. Train a bunch of hauling kangaroos, fill their pouches with items, and drag them around the fort!

Edit: After testing with stone stockpiles it seems that the stockpiles as a whole don't create the jobs because when I created 3 stone stockpiles instead of claiming items in the order of their creation they claimed them in a jumbled order. I think therefore that the individual stockpile tiles claim the items. More testing could determine the exact order, but I have to go to bed in 30 minutes so I won't be doing it anytime soon.

[NW_Kohaku]

NW, check out the job priorities thread in my sig.  It's got a lot of job info in it.

I did, it's actually got a lot in common with the dwarfbot discussion and some of my previous talks about job priorities.

That's a travelling salesman problem. Might be tricky. What I meant was floodfilling until a hit, then picking that up, then floodfilling again from that position.

If we do it that way, we can wind up "following a trail of breadcrumbs" away from a task we should be lumping in as a nearby task.  If there's a single item on the floor that by chance creates the first task on the job board, then there is another single item a single tile away to the north, but a pile of goods that needs to go to the stockpile two tiles to the south, and then when the flood search takes place from the single item that was to the north, it finds another item 2 more tiles to the north of that, then another item 4 more tiles to the north of that, then another 8 tiles to the north of that, then you've gone out of detection range for the whole pile of items to the south.

Depending on how many items a dwarf might be able to haul at once (with something like a wheelbarrow), then it might be useful to perform a full flood on the first item, then stop-on-hit floods for every successive item, with a full flood exception every 5 items or so if we have a really large hauling capacity.  Then, we could do a relatively quick and dirty absolute distance traveling salesman calculation, where we try to find the two items that are the furthest apart from one another to set start and end points in the collection task.

After his load is full, the dwarf is simply emptying his load. So he just needs to pathfind to the nearest stockpile, drop off what he can, and then he'll look for the closest stockpile out of all the stockpiles he needs to visit. Repeat until empty. Trying to find the ideal route between the stockpiles is not worth it, IMO. I don't care if the haulers are a bit dumb. They're normally safely inside the fortress at that point anyway.

Yes, it's going to be a really odd way of trying to balance performance with stupidity in terms of dwarfy pathfinding

Just add a check to my pseudocode in the job section. If the number of items in the job is higher than, lets say, 5 the dwarves will grab a wheelbarrow or empty bin. If they can't find one then they can grab what they can, and maybe split the bulk haul job so another dwarf can help.

Or wheelbarrows could be creatures that can't move on their own. They have their own AI that looks for clusters of hauling tasks when they are idle, and claims them. Then they create a job for a dwarf to come move them to their destination and load them. If you don't have wheelbarrows then there would not be any extra checks for wheelbarrow usage. This would also allow for other creatures to be haulers with dwarven assistance and proper training. Train a bunch of hauling kangaroos, fill their pouches with items, and drag them around the fort!

Edit: After testing with stone stockpiles it seems that the stockpiles as a whole don't create the jobs because when I created 3 stone stockpiles instead of claiming items in the order of their creation they claimed them in a jumbled order. I think therefore that the individual stockpile tiles claim the items. More testing could determine the exact order, but I have to go to bed in 30 minutes so I won't be doing it anytime soon.

Well, the wheelbarrow as a creature might make more sense when talking about minecarts, which are supposed to be mobile stockpiles.  Wheelbarrows I've seen as more just being backpacks or extra hands for a dwarf that they carry as "equipment" and up their maximum inventory hauling space.

Actually, having backpacks as some sort of hauling harness might be an amusing idea.  Haulers will become more specialized dwarves that have their own desirability based upon their ability to carry more items at once if this goes all the way.  You must protect your legendary haulers as they are precious resources necessary for maintaining the working order of your fortress.

As for stockpiles, I don't know if individual tiles claim stones, since they always seem to fill from the top left horizontally and then downward, which seems like it's just a "capacity" check.  Maybe your stockpiles were simply taking turns declaring jobs, or they were set to claim different kinds of stone, or distance calculations made different stockpiles become declared closer on a very odd basis.

[blizzerd]

add in this or something like it, because i feel its related:

http://www.bay12forums.com/smf/index.php?topic=78340.0

basically "demand when needed" in stead of "reserve until use" for constructions and the objects used to make them

basically in short, when you build a bed and select -tower cap bed- or [SPECIFIC ARTEFACT NAME HERE] as the object used to build it, df will not reserve any -tower cap bed- or [SPECIFIC ARTEFACT NAME HERE] until a dwarf has prepared the site for construction and is about to walk over to the reserved object to fetch it, this will prevent any constructions from suspending because a reserved object is placed on its location for construction even if the specified objects construction is also suspended and will also make it so the dwarves ALWAYS pick the closest object that fits the requirement from the moment they need it, meaning more will have to be worked with stockpiles but this would also enable one to for example build a giant structure with chalk blocks and start designating the walls and everything even if this person's fort has only have 1 actual block in stores at this moment, while the masons construct more and move it to the stockpile next to the construction

because the latter is far more inefficient when it comes to dwarven fortress mechanics

[Draco18s]

It is L*x, where L is length of path and x is maximum distance to find job (it is in fact BFS with found path as starting points with limited path length). It also will annihilate FPS.

So rather than countering the idea with a better idea all you did is tell me why it wouldn't be efficient enough.

And how efficient does the algorithm need to be in order to be good enough for you?