Print

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

[Sutremaine]

Exactly what is says on the tin. The exact number could be an init option, but 5 seems a reasonable number. While the code's there, there could also be an option for saplings (5) and plants (3) and tiles containing fire (25).

[NW_Kohaku]

If they can immediately tell what tiles have fire in them, why would they want to walk in them at all?  I would think they should be afraid of fire, and not walk through a fire, even if it was a really, really good shortcut.

Generally, I'm not sure about the way in which this all works at the lowest levels, but pathfinding is very, very CPU-intensive stuff, and if you make the pathfinding program start making checks on what tiles have certain stuffs in them, it will make the pathfinding code become even more bogged down in waiting for data fetching to see where all these little bumps on the map are.

Traffic designations are problematic as-is, but at least they aren't dynamic.  You stop the game to alter them, and a new pathfinding connection map can be built while you are paused with no real lag.  Sprouts and contaminants you can track need to be checked dynamically, however.

Again, I've not made myself an expert on the subject of pathfinding, but these are just some of the potential problems I can see off the top of my head.

[GreatWyrmGold]

If they can immediately tell what tiles have fire in them, why would they want to walk in them at all?  I would think they should be afraid of fire, and not walk through a fire, even if it was a really, really good shortcut.

Generally, I'm not sure about the way in which this all works at the lowest levels, but pathfinding is very, very CPU-intensive stuff, and if you make the pathfinding program start making checks on what tiles have certain stuffs in them, it will make the pathfinding code become even more bogged down in waiting for data fetching to see where all these little bumps on the map are.

Traffic designations are problematic as-is, but at least they aren't dynamic.  You stop the game to alter them, and a new pathfinding connection map can be built while you are paused with no real lag.  Sprouts and contaminants you can track need to be checked dynamically, however.

Again, I've not made myself an expert on the subject of pathfinding, but these are just some of the potential problems I can see off the top of my head.

...Woah. And I thought this sounded like a good idea at first...My fort's already running too slow.

[Sutremaine]

I'm not an expert on pathfinding either, but the map already dynamically checks for walls and other obstacles. Would it really add that much number-crunching to have it check for other things?

Good point on the fire though, I guess I'm too used to having them ignore it completely.

[Uristocrat]

Exactly what is says on the tin. The exact number could be an init option, but 5 seems a reasonable number. While the code's there, there could also be an option for saplings (5) and plants (3) and tiles containing fire (25).

I like this idea, so long as it can be done reasonably efficiently or is optional.

[thijser]

It's probable easier on your system if you add the path cost the moment a contaminant falls on the ground.

[Aramco]

If they can immediately tell what tiles have fire in them, why would they want to walk in them at all?  I would think they should be afraid of fire, and not walk through a fire, even if it was a really, really good shortcut.

Are you sure about that? I find myself taking shortcuts through fire quite regularly.

On topic- I like the idea and doubt it will cause notable issues. And, on the opposite end of the path-finding spectrum, I think that they should path-find towards things like booze and contaminate treating facilities(Like waterfalls.).

[robolee]

First of all creating a path based on what's in the way would make the dorfs seem psychic ("this is your god speaking, a fire broke out down that shortcut you were going to take, take the long way round my friend"... "nope wait, fires out, shortcuts free again"), secondly it would be much quicker to just create the shortest path to follow and have the dorf analyze each tile as it moves along the path and change it when it comes to the obstacles (or analyze the first 10 tiles and then after that a single tile every step, so it doesn't seem short sighted).

[Sunken]

If they can immediately tell what tiles have fire in them, why would they want to walk in them at all?  I would think they should be afraid of fire, and not walk through a fire, even if it was a really, really good shortcut.

Setting a high traffic cost for tiles that are on fire (etc) will incur some performance penalty. But entirely forbidding them will cause far greater problems for pathing. That would require a connectivity map update, which is a whole new level of expensive.

[NW_Kohaku]

If they can immediately tell what tiles have fire in them, why would they want to walk in them at all?  I would think they should be afraid of fire, and not walk through a fire, even if it was a really, really good shortcut.

Setting a high traffic cost for tiles that are on fire (etc) will incur some performance penalty. But entirely forbidding them will cause far greater problems for pathing. That would require a connectivity map update, which is a whole new level of expensive.

Regardless, the AI should not path into a fire, even if it is the only way to get from point A to point B.  So a mere cost spike would not be sufficient.

If we are dealing with certain conditions changing the weight of a path, then perhaps you could just pass some sort of value into the weight that triggers a flag that automatically fails that path, as though it hit a dead end?  You wouldn't have to update the connectivity path, it would just fail any path through that tile until the condition that triggers it is gone.

[Sunken]

I'm not entirely sure exactly what you mean, but...

If you generate paths as usual, but fail any resulting paths that lead through a forbidden tile, then:
You'll have dwarfs failing to find paths even though there are valid detours (say, a one-tile detour).

If you up the traffic cost for fire tiles first, and then if the path found is still taking you through fire you reject that path... that might work in many cases. Though it will be a costly path search - say there's a fire in the only doorway into a room and you make the cost really high; the dwarf might then potentially try every tile in the map outside that room before deciding to path through the fire. Then the path is failed and quite likely the dwarf will do the whole thing over again next frame...
It's not impossible but requires some thought to keep it from really bogging the game down.

Or maybe you meant something different.

Anyway, as for avoiding contaminants, not fire, the rejection approach doesn't seem as reasonable there. Raised traffic cost makes sense in that case.

[Thundercraft]

I think NW_Kohaku made some very good points in reply #1.

Pathfinding is very CPU intensive and it seems far too risky to ask Toady to have the game check for more things. Maybe sometime down the road when your average home computer is faster and some of the existing bugs and FPS bottlenecks have be resolved, it can be considered. But, considering how inevitable FPS death is for old forts, maintaining a decent FPS for a longer duration seems more important than the issues being addressing.

[NW_Kohaku]

I'm not entirely sure exactly what you mean, but...

If you generate paths as usual, but fail any resulting paths that lead through a forbidden tile, then:
You'll have dwarfs failing to find paths even though there are valid detours (say, a one-tile detour).

If you up the traffic cost for fire tiles first, and then if the path found is still taking you through fire you reject that path... that might work in many cases. Though it will be a costly path search - say there's a fire in the only doorway into a room and you make the cost really high; the dwarf might then potentially try every tile in the map outside that room before deciding to path through the fire. Then the path is failed and quite likely the dwarf will do the whole thing over again next frame...
It's not impossible but requires some thought to keep it from really bogging the game down.

Or maybe you meant something different.

Anyway, as for avoiding contaminants, not fire, the rejection approach doesn't seem as reasonable there. Raised traffic cost makes sense in that case.

Well, in the case of having a dwarf walk through a fire, and potentially causing the whole fortress to crumble, then it's one case where players would probably really rather have a slower frame rate rather than sub-optimal pathing.  Ultimately, the "keep bashing your head against a door" problem of that second option is exactly what pets facing pet-impassible doors currently faces.

What I was really meaning was the first of those options, though.  Honestly, I think preventing dwarves from making a one-tile detour around a fire looks reasonable.  How much space would you give a raging wildfire?  I guess a problem is, however, that I'm not familiar with A* specifically, so I'm not sure how many tiles back the algorith would potentially fail.  If we are already creating a special exception on passing some certain value, though, we could potentially go ahead and create an exception on how the failure of the path is handled, as well.  It gets a little more cluncky with having multiple functions doing the same thing, but "don't walk into a fire, dumbass" may just be worth it.

[Sunken]

What I was really meaning was the first of those options, though.  Honestly, I think preventing dwarves from making a one-tile detour around a fire looks reasonable.  How much space would you give a raging wildfire?  I guess a problem is, however, that I'm not familiar with A* specifically, so I'm not sure how many tiles back the algorith would potentially fail.  If we are already creating a special exception on passing some certain value, though, we could potentially go ahead and create an exception on how the failure of the path is handled, as well.  It gets a little more cluncky with having multiple functions doing the same thing, but "don't walk into a fire, dumbass" may just be worth it.

Then I misunderstood you. I thought you were talking about rejecting the path after A* was done.
If you mean rejecting a tile during A* - well, this is the same as forbidding a tile and has the same problem of violating the connected component system. Once we have some way of dealing with that, we can do what you propose. But we can't right now, AFAIK.

[NW_Kohaku]

I was trying to think of a way to workaround the idea that the entire connectivity map would need to be rebuilt, yes.

But again, while I don't know the exact mechanics of A*, I thought Toady was using a customized version of A*, so why is it not possible to force the A* to just try to find another path when it tries to path into a tile covered in fire?

(In fact, don't we already have this with water and magma?  They block pathways, and are dynamic, as well.)