Print

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

[Kogut]

No, no, no - it is not needed. It may be nice to have smarter construction but it have (almost) nothing to do with this suggestion: solvable using 10 lines of code, without slowing down game.

[zilpin]

...It's a simple, trivial check to perform once one gets to the job site....
...It won't slow down pathfinding.

Simple, but take a look at the structures in DFHack to understand how tiles are stored.
It will slow down pathing.  Noticeably.  DF uses many vectors, many long memory calls.  As explained, this dramatically increases the number of memory fetches, which makes your CPU cache useless.  So much so that you may as well use Java instead of C++.

I don't see why we should go through the extra-tedious and boring job of manually designating the order of tile removal, when determining that kind of order is something computers are actually very good at. I'd rather have Toady automatize it than code yet another UI feature for this.

Technical reasons.
It's easier to implement for Toady, it is one stone that kills many birds, and it is has near-zero performance impact.
That's why.

The basic idea would be to use a flood-fill algorithm every time a channel or floor removal is designated, to identify the whole contiguous region of tiles to remove. Then, treat the connected region as a graph where each tile has 0 to 8 neighbours, and apply an algorithm to turn that into a tree....
...Performance-wise, the worst that could happen is a slight slowdown when designating if you designate half the map for channeling, but it shouldn't otherwise affect your fps.

Are you kidding?

How it can help? It is normal to have multiple tiles removed simultaneously.

True, but avoiding that would require a great deal of code.
My suggestion helps because it gives you some micro-management control over the order the tiles are removed by limiting access.
Yes, more tedious micro-management, but more importantly, it takes minimal effort to implement, has no performance impact, and solves other problems with dwarfs going where you don't want them going.


Not that any of that matters.
The suggestions board is just to let us placate ourselves.  Toady almost never reads them anyways.

Cheers.

[isitanos]

I don't see why we should go through the extra-tedious and boring job of manually designating the order of tile removal, when determining that kind of order is something computers are actually very good at. I'd rather have Toady automatize it than code yet another UI feature for this.

Technical reasons.
It's easier to implement for Toady, it is one stone that kills many birds, and it is has near-zero performance impact.
That's why.

You seem to believe that UI is somehow easy to code. Hint: it's not. Something the player interacts with is also more of a maintenance chore for the future.
As if the UI wasn't complicated enough already.

If you like tediousness you can designated your channeling one row at a time.

The basic idea would be to use a flood-fill algorithm every time a channel or floor removal is designated, to identify the whole contiguous region of tiles to remove. Then, treat the connected region as a graph where each tile has 0 to 8 neighbours, and apply an algorithm to turn that into a tree....
...Performance-wise, the worst that could happen is a slight slowdown when designating if you designate half the map for channeling, but it shouldn't otherwise affect your fps.

Are you kidding?

No. Are you?
Once the tree is computed, just pick the next child from the tree and send a dwarf there. Nothing changes except the way the tile to channel is picked.
The cpu-intensive part would be computing the tree, but by doing it during designation (where the game is paused anyways) it doesn't matter that much.

Besides regarding the other proposals, I don't buy your arguments about CPU cache. Even if you looked at the DFHack memory structures, which I didn't, you don't have the source code at hand and you don't know if DF manages to use the cache optimally when pathfinding. Toady may already make all kind of memory fetches straight in the middle of pathfinding, for all you know. Basically you're trying to do blindfolded backseat optimizing, which is rather useless and counter-productive.

[Jeoshua]

Woah, woah... let's not get all crazy, technical, and upset here.

The suggestion was that Dwarves not stand, working, in places that are designated for removal.  It's a simple hack, which need be performed only once the dwarf tries to get down to work (am I standing on a channel/designated-removal?).  It's simple, it would take 20 minutes to code AND debug combined, and it would make dwarves seem 10,000% less stupid.

Don't try to question my knowledge either.  I've seen alot of people basically telling each other off in this thread, trying to bully each other with their CompSci credentials.  Not necessary.  I am in school for this stuff.  So I'm not the best, but I'm not blowing smoke up your ass.  It would take 20 minutes, it's just been overlooked until now.

[isitanos]

Jeoshua, well there are two things here. One is your solution, which is simple, and second is the rather more comprehensive solution that I proposed.


I like your idea, but I'm not sure it has been discussed enough. The simplest implementation would presumably result in a dwarf cancelling his digging job if another starts digging under him. So, more message spam. I didn't do diagrams of anything to picture the worst-case situation, but it seems to me that in a cramped space and several miners it could result in an endless cycle of job cancellation.


I'm not sure either why my solution seems to scare some of you off as overly complicated... it's rather ordinary CompSci stuff, and it's much simpler that some things Toady does now. The particulars of DF's implementation could render it impractical, but there's no reason to dismiss it right off the bat.

[Jeoshua]

The simplest implementation would presumably result in a dwarf cancelling his digging job if another starts digging under him. So, more message spam. I didn't do diagrams of anything to picture the worst-case situation, but it seems to me that in a cramped space and several miners it could result in an endless cycle of job cancellation.

Diagram not necessary.  I get your meaning on that, and the situation you describe quite dire.  I'd think it better that they just skip over the job for the time being if they can't find a safe place to stand.  This might result in dwarves milling around stupidly if you designate a large or overly complicated area for channeling/removal, but wouldn't spam you.

I'm not sure either why my solution seems to scare some of you off as overly complicated... it's rather ordinary CompSci stuff, and it's much simpler that some things Toady does now. The particulars of DF's implementation could render it impractical, but there's no reason to dismiss it right off the bat.

A Flood-fill algorithm is much less complicated than A* pathfinding, as far as total calculations required is concerned... certainly.  But I only fear that it would require a bit more behind the scenes to even make it possible.  It doesn't appear to me that jobs are stored in any way except a out-and-out list of things to do.  There isn't much data attached to each job, either.