Bay 12 Games Forum

Couple of things from the wiki regarding foreground/background colour you may want to take into account for future versions
[...]

Edit 2: I've found a little bug - Quite often it's impossible to select the last row of a list!

Also because bright background colours are possible, RTS gets a bit confused when they are set in a raw file it loads.

I could not reproduce the end of list bug, although I remember it beeing there in an older version, but I'm right supposing you are using 1.0?
I added support for 16 background colors.

I know you've sort of written this project off,
but I would be eternally grateful if you'd pick it up
just one more time and switch it to true-type ouput
instead of using the tileset to display letters...

Because now that we've got ttfs, I went and took all the letters out of my tileset...

The project is not really written off, it's more on a hold. I'll try to keep it in a usable state.
I implemented a quick fix for the character display. A second tileset will be used for characters now, so you can work on tilesets without characters.

You can change the displayed background color for the whole tileset (when using png transparency) by pressing 't'.

It's probably a openGL driver problem, wouldn't be the first time that ati drivers are bugged. Maybe try 31.04 which can be downloaded here: http://www.bay12forums.com/smf/index.php?topic=57492.0. It has different graphics code and might work better for you. Otherwise try older graphics drivers for your card.
The majority of todays games use directx for graphics, so errors in the openGL drivers won't be visible there.

In what circumstances will dwarfes not return to a civilian life? From what I gathered they will stay always military after individual combat training. Is this true after fighting, too?
I upgraded the training dummy mod so civilian dwarfes can train all combat skills, it's much less hassle than getting them to train properly. What I wanted to achieve is a part time militia, dwarfes that are somewhat skilled in warfare and can be drafted in bad situations, then undrafted when the situation is resolved.
So, will this work or will they stay military after killing enemies?

A sidenote: the endless waiting for combat demonstrations seem only to appear when the minimum number of dwarfes for training is larger than the number of dwarfs in the squad. If it is equal or lower they will go through with the training, although without learning much.
If two equally skilled dwarfes are in a squad and set to train they will spar and become legendary fighters in a season - sadly this hardly ever works. I will try to get them to the same level with the training dummies and test if this improves the situation.

And I hardly think this thread is unnecessary. It's good to have one place for all military questions. And it is still unclear how much of the problems will be solved with .31.04 - or if new problems creep up.

Me again.

So I did some hand-modding of my files (added a sapling_tile to some trees) and the sapling_tile flag didn't read into the editor...
I'm not sure why that was the case. I think it works in-game, and it reads the colors fine, but it doesn't think there's a tile flag.

Just thought I'd bring it up. Even with that bug (which might be my own fault), this is still the coolest thing since peeled kittens.

Keep it up!

Did you add a tag for that tile in the definitions.txt ?
Should look somewhat like this, I suppose:

[TILEDATA:SAPLING_TILE:SAPLING_COLOR]

I suppose the trees wood foreground color ( DISPLAY_COLOR tag ) is used for the wood when it is available in plant_standard.txt. Otherwise the wood template color is used (brown). All the wood types that were described as colored in this thread do have a DISPLAY_COLOR entry in plant_standard.txt, the others don't. This can be modded then, too, to get wood of other colors.
Barrels are a bit special, for them the backgroundcolor is used for display instead of the foregroundcolor (the only tile that is treated that way). As there are just 8 backgroundcolors instead of the 16 foregroundcolors some colors are not available (as for example yellow for fungiwood is not), in this case another color is chosen by some method (that is unknown to me).

Edit: Actually the method to choose the color for barrels will be quite simple. First we give numbers to the colors. From 0 for black to 7 for light grey (which are available as foreground and background color) and 8 for dark grey to 15 for white (available as foreground colors only).
Woods that have a color value higher than 7, like towercap (white, color 15) or fungiwood (yellow, color 14) get the highest backgroundcolor value available (7, light grey). Bloodthorn has color 4, dark red, which is available as a backgroundcolor.

Another question is why fungiwood doors are displayed black, there the foreground color should be used. I remember the same problem with some stone doors in 40d (was ist granite?).

Toady has said some time ago that he uses a modified A*. The modification is that he divides a map into accesible areas, so if point A is in another area than point B, it means that there is no access from A to B, and no path in actually calculated. It saves a lot of performance in such situations, because otherwise the pathfinding will have to fill the whole area before deciding that there is no path.


As for my advice about fortress design:
-try to have as much straight paths as possible
-mark hallways which are frequently the best path as High Traffic
-mark dead-ends and areas your dwarves do not need to visit as Low Traffic

Thanks, thats great to know.
Further improving the method will probably be much harder for him then.

Traffic zones don't affect which stone he goes for though right? only how get gets to that particular stone.
Have I understood this correctly?

Right. Burrows will probably help when its about which stone will be selected.

Edit:
According to Rafal99s post later in this thread (http://www.bay12forums.com/smf/index.php?topic=56041.msg1224791#msg1224791) an improved A* ist used, so the following examples are not important for fortress planning.

I think I do remember 'newest first' being something I saw in 40d. It's been a long time though, and I don't know if it's in v31, since I've hardly touched that.

Do you maybe mean best first? That is a pretty old method from the late seventies. A* is a mixture of Dijsktra and best first (which is also called B*).
I dismissed the thought that he might be using such an inefficient method, assuming that he wrote the pathfinding some time in the last decade. But on the other hand it might not be that improbable, maybe he uses the pathfinding code from an older game and never had another look at it. It is of course more fun enabling more content, like 1000 year old puke monsters from the depths, than working on pathfinding...

So, lets have a look at B* (even if your post was not about it and I got that wrong) and what this would mean for fortress layout then:
I currently don't have the time to read up on the details of the algorithm, it's hard to find something on the net and visiting the library might be the better approach. But lets have a look at some examples, as the website linked in the op has that implemented, too.

Finding the path to a target in open space:

This is worse than Dijsktra, and much worse than A*. All surrounding tiles are checked iteratively until the target is found. So obviously open spaces are definitely not our friend then. High pathing costs would not stop the method from checking all those tiles, they would just influence which path is chosen afterwards, afaik. So setting traffic zones would probably not improve pathfinding speed.

Finding a path inside:

Much better, as there are less tiles that have to be checked...

And some obstacles:

Even better, as we have more walls there are even less tiles that have to be checked.

With unreachable items the situation doesn't change, it's just as bad:


So if this method is used I think your best fortress design would be quite different:
- Mine as little space as possible.
- Build as many walls and other obstacles as possible.
- Keep all ways short.
- Don't spend too much time on setting traffic zones.

If toady is using this method there are good news: Changing the algorithm should not take him too much time, a few hours in the best case or probably a few days in the worst. The speed improvements would be immense. Of course he has a lot on his hands for now, but if the method is this outdated he might have a look at it much sooner.

Actually, restricted zones are checked.  They just have a very high path cost.  The low/normal/high/restricted path costs default to 1/2/5/25.  It's explained in data\init\init.txt.

Yes, you are right, what I wrote is misleading (so let me change that). What I meant with that was that the high pathing costs of restricted tiles should result in many other tiles being checked first. So if there is another way (thats not too long) it will probably be found before a row of resticted tiles has even been looked at.

Edit:
I had a short look at the kobold quest source code, and to my understanding he is using a variant of B* there. But the existence of traffic zones in df shows that he did change his method and having different pathing costs would point towards A* (ruling out Dijkstra due to target selection). So the examples and conclusions in this post should be of little importance.