Print

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

[Paragon99]

It might be useful to have direction of travel traffic designations. It could be considered a low traffic zone in one direction and a restricted traffic zone from the others.
It would be helpful to be able to designate entrances and exits in this way which in turn could go along way to toward reducing traffic congestion, slightly decreasing the amount of time it takes your dwarf to get to the beer he's leaving a party to drink, so he can sleep it off sooner such that he might finally get to the trading post before they depart.... In some cases.

[Bumber]

I don't know if it's feasible with the way pathing weights work.

Perhaps you could do it with clever layout (i.e. using quirks of pathing algorithm) or with pressure plates and doors/hatches.

[Dirst]

I don't know if it's feasible with the way pathing weights work.

Perhaps you could do it with clever layout (i.e. using quirks of pathing algorithm) or with pressure plates and doors/hatches.

Well, the pressure plates wouldn't fix the pathing issues because a dwarf wouldn't path through an obstruction.

I'm not an expert in the A* algorithm, but it doesn't categorically exclude differing costs in different directions.  The devil is in the details, in how exactly nodes (rooms) are defined and how creatures path across the tiles within a room.

[MeMyselfAndI]

A* is a general graph pathfinding algorithm. You certainly can have asymmetrical path costs, as long as you don't have nonpositive-sum-cost loops.

Although you can kind of simulate this already.

If you have a pressure plate in front of a hatch, it acts as (almost) a one-way door. Dwarves will still path to the wrong path, but as soon as they step onto the pressure plate and the hatch opens they will repath to the correct one. A little ineffecient though, as a dwarf can bounce around several times depending on how many other dwarves are using it.

Remember: dwarves only repath when they can't walk on the next step in the path.

[Bumber]

If you have a pressure plate in front of a hatch, it acts as (almost) a one-way door. Dwarves will still path to the wrong path, but as soon as they step onto the pressure plate and the hatch opens they will repath to the correct one. A little ineffecient though, as a dwarf can bounce around several times depending on how many other dwarves are using it.

Yes, something like that.

As for just using layout, I had pictured maybe something like this:

Code: [Select]

###############
++++++++++++++#
#+###########+#
#++++++++++++++
###############I would suspect they'd choose a specific route based on which side they entered.

[Paragon99]

Actually, in terms of the path finding algorithm, the interesting thing isn't that the weight assigned a tile is variable (we already have that with traffic zones) but that there is an entirely new variable required, namely the direction. Even so, the direction can be calculated at the same time a weight is requested so providing the information shouldn't be difficult.

[Reelya]

This is from an old version, so I don't know if pathing still works the same:

http://dwarffortresswiki.org/index.php/40d:One-way

[Paragon99]

That's ingenious

[Larix]

Nope, that one's been fixed. Walls/ramps built like that are usable in both directions in the current version.

[Reelya]

I made a note of that on the wiki page to make it clear.

[TBeholder]

I would like more uses for sets of waypoints - as in, routes used not only for patrols.
So that one would create a route:
1) pick two waypoints,
2) assign traffic types (just like with tiles, but separate for A->B and B->A),
whether it's waypoints-only for pathing (so no climbing onto the bridge just because it's high-traffic), width (mostly should be automatic), for which purpose it's used  (e.g.: specific labors, military, "guests") and something like "keep passable". The last 3 would be of great use for wagons - if your road is not all readily passable over its set width 3 for merchant carts, this would be immediately visible in its properties.

Since the pathing algorithm works with graphs, a route would simply add a pre-existing connection with known total cost when pathing reaches it, possibly saving time. And yes, it's easy to make those costs anisotropic. If waypoints are either always (including intermediate ones) connected explicitly or collected in route groups rather than piled all together, thee will be no pointless bloating of N^2 arrays.

A combination of waypoints and random walk could also perform most things animals do, saving a lot of resources.
E.g. a herd of grazers usually needs pasture activity zone and path to water source, that's it. Each animal doesn't need full clairvoyant pathing every time it goes to water, until the existing path is disrupted.
Would make pets less prone to door-humping, too. 

[TBeholder]

As to existing pathing, it's not so simple.

As for just using layout, I had pictured maybe something like this:

Code: [Select]

###############
++++++++++++++#
#+###########+#
#++++++++++++++
###############I would suspect they'd choose a specific route based on which side they entered.

Probably would be the same if diagonal steps won't make AD cheaper than AB, because straight step-distances of BG and DG would be equal.

Code: [Select]

###############
A+B++++++++++C#
#D###########E#
#+++++++++++F+G
############### But since diagonal steps are pathed, it depends on how exactly they are compensated for (to avoid "strafe run" thing) and how this works for the specific map fragment.
So let's try a symmetrical case:

Code: [Select]

###############
#+B+++++++++C+#
+A###########F+
#+D+++++++++E+#
############### We know that A* is best-first. Does this mean that traffic costs of the nearest tiles is everything, while traffic costs of a no-choice corridor don't matter after one step in? Yeah, A* is anisotropic due to short-sightedness - it's very visible in FreeCol (which is A* too). The question is whether DF flavour works the same way.
If it's like that, you only need to set a few tiles: high-cost B and low-cost D will always prefer D when pathing from A to F, but for pathing from G to A it will be just an "open path" for lack of local alternatives. And the opposite for low-cost C and high-cost E will give us consistent right-side walking.
I have seen more of the opposite, so maybe pathing goes from the destination to the dwarf.
Also, this example assumes that A and F are origins and destinations. It's not the case, so the calculated distances between tiles one step north or south of them and target to north of south of the line will not be equal just because we see that there are two bottlenecks.