Print

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

[NeedsDF2GetThruWorkingDay]

if you're caching A -> B and B -> C, and the game notices that the two routes are often used together, it can make a new shortcut path for A -> C.  If dwarves then start pathing from C to a newly accessible point D, the game caches C -> D, and shortly after may cache A -> D.  So new paths can develop organically.

Is DOS capable of "noticing" things in the manner you describe? Does the game currently have any system where it tracks how frequently you do X? I think I know what you're talking about; when I text message on my phone, it for some reason prefers to spell out "neck", and I need to manually advance it to the next word until it displays "meal". But if I use the word "meal" frequently enough, that will start to be automatically displayed when I key in 6325.

Caching in general sounds like it would be efficient, with the right parameters, but when you start adding in threads/processes that are "watching" and "noticing" certain behaviors so that things can "develop organically", it starts to sound like the CPU will be just as busy.

[Impaler[WrG]]

Except that in a simulation there is no way of alterting the cache system that there is a new route, unless you did it EVERY time a tile was dug out.  There simply isn't a way to find new paths.

Actually the best way around that is to have a small probability that each time a stored route is used theirs a chance it is first updated, if a faster route is found it either replaces it or supplements in in such a way that traffic gradually shifts as is the case IRL.  The probability of updating should itself be dynamic and based off changes in the fort, say the probability is (X + 1)/ Y, X is incremented every time their is a construction or dig event in the fort and decremented every calendar month, Y is equal to the forts size probably a composite of population and mined out volume.  This sets up a system in which changing the layout stimulates more frequent updates to the routes allowing the old-obsolete routes to be replaced, yet doesn't waste time recalculating paths in a mature fort.

[ScreamingDoom]

Actually the best way around that is to have a small probability that each time a stored route is used theirs a chance it is first updated, if a faster route is found it either replaces it or supplements in in such a way that traffic gradually shifts as is the case IRL.  The probability of updating should itself be dynamic and based off changes in the fort, say the probability is (X + 1)/ Y, X is incremented every time their is a construction or dig event in the fort and decremented every calendar month, Y is equal to the forts size probably a composite of population and mined out volume.  This sets up a system in which changing the layout stimulates more frequent updates to the routes allowing the old-obsolete routes to be replaced, yet doesn't waste time recalculating paths in a mature fort.

Rather than having just a random probability, it'd be easier (and less error prone) to just have a timestamp attached to a route. Every time a route is found in the cache, see if timestamp is outside of some threshold. If it is, then recalculate the route. This allows for easy adjustment (you want routes updated more often, make the threshold smaller at the cost of more CPU usage) while not wasting time with seldom or one-use routes (since routes are only recalculated when there is a cache hit).

[scribbler]

I'd like to point out my earlier suggestion of having routes updated when the simulation's otherwise on pause, like when giving orders or trading.

(And I still say let players place waypoints to encourage traffic patterns.)

[Porpoisepower]

What if you kept track of "Doorways" or "Gaps" defined as either a gap between any 2 colinear walls or the gap between two ends of a non straight wall(exact definition to be deturmined).  Then set up tables with a starting and Ending "Doorway" where there is no additional "Doorway" between. Each Entry would also have a cost(or # of steps to get from one doorway to the other). 

The quickest routes could then be generated as lowest total "Doorway" cost.

I believe this if correctly defined, could limit # of "cached routes" while also minimizing route complexity.

[Footkerchief]

^^^ This might interest you.