Bay 12 Games Forum

Quote from: Saiko Kila on November 21, 2018, 01:52:07 pm

Quote from: Kamamura on November 19, 2018, 09:25:38 pm

Hello, I was not really following the development process too closely during the recent say 3 years, can you please tell me:

1) How is the game scaling on modern CPUs? I have Core i5 8600K now, is the game still 32 bit single thread, or was there some effort to rewrite the code?

The faster single-threader, the faster the game. Scaling is almost 1:1 with the clock, and newer processors, which sometimes sacrifice clock speed for faster performance of newer commands (not used by DF at all), or for faster multithreading speed (more cores but slower), can suffer. This can be offset by faster memory controller or not, depends. Bigger cache also gives a boost, and faster memory too. You should have no problems with i5 8600 K at all, because it's one of the fastest single-threaders, unless you have low memory (you cannot really have SLOW memory).

So I suppose this site would be a help in choosing a CPU for a dwarf fortress player?
https://www.cpubenchmark.net/singleThread.html

I have an Intel i7-3770K which is at the 2,083 benchmark.  Since playing DF44.12 the game has been more stable and runs faster than any version of DF before.  Even with a 200+ dwarf fort on a 4x4 embark with a lot of livestock I was staying at 20FPS.  It would dip to 12FPS if one of those damnable buzzards spooked my livestock!

Last month I was actually messing around playing a fort in DF40.24 and I had performance issues and occasional crashes.

Yes, single-thread benchmarks are better than comparing clock speed, and the best kind of benchmark approximating performance in DF (apart from one specifically running DF) is single-thread integer tests. For example look at this comparison:
https://cpu.userbenchmark.com/Compare/Intel-Core-i7-3770K-vs-Intel-Core-i7-8700K/1317vs3937
At first 8700 K looks as if it was twice as fast, but scroll down to the Nice to Haves/SC Int (single-core integer speed), and 8700 K has only 23% lead there. Which would mean ~25 FPS over ~20 FPS. Which isn't that much, though of course every bit helps in bigger fortresses and in bigger worlds.

Technically DF also uses some floating point calculations, so you may look at mixed speed single core tests, but most of calculations are integers.

Number of dwarves and animals (plus visitors) is more important than overall size of the embark, but size starts to make difference when you dig deeper, and if you have more trees and such.

One note about the cpubenchmark (the one you quoted), the clocks they give is not the true clocks used in tests, but the ID string used by processor, which is rather base speed. Effective clock when using Turbo mode or similar would be higher. But the score stands.

As for crashing, the current version is better than these v.0.40xx, but still sometimes it can crash. Also sometimes I have issue in x64 version when there is a memory leak and all available memory is eaten (I have 16 GiB, so it's decidedly a leak), though it hasn't happened in the last few months.

The "mat" is an error: it should be "old_mat". There's another bug in the vicinity, however, causing the no part branch above to be incorrect as well.

Right.

Dorfs eat eggs from animal people, so why not milk/cheese? However, I agree that ought to be changed.

Because it's gross No, seriously I was more concerned that the item is described as camel's milk, but also because I don't see it can be obtained in any
meaningful way.

Vermin can be caught in vermin traps, and DF obviously generate preferences for eating vermin, but I haven't seen or heard of anyone catching and eating them except to stave off starvation. I don't know if dorfs with a preference for vermin can actually eat trapped vermin, though. If a dorf caught vermin to eat for a preference it shouldn't generate a bad thought though, as the dorf isn't forced to eat vermin.

There are vermin which can't be caught in traps, at least not in baited ones (there's a tag for it), and since some are in places not accessible to animal trappers, I think that these can't be really caught. An being non-fish, can't be bought.

The only vermin I know can be eaten "normally" is creepy crawler, which apparently can be slaughtered after being caught. I would expect that the non "fish" vermin that can be processed in other ways wouldn't leave any edible results, but I have never processed any.

I wonder what causes it. Maybe because it has no [NOT_BUTCHERABLE] tag.

I looked into the one humped camel man milk issue, and found it's common to all animal people that yield milk and cheese, namely that the product is named after the base creature, not the man variant. The bug tracker is unavailable at the moment, but I'll write a bug report later.

I noticed after changes that I had three dwarves with three different one-humped camel milk requirements. One of these was normal, another was from giant version, and third was from animal man, despite the same name. Talk about fussy eaters.

I tried to get the script to replace vermin, but ran into an unexpected problem: Not all the vermin fish that are edible according to the wiki Vermin page have the VERMIN_FISH flag set. The set of any_vermin and CASTE_MUST_BREATH_WATER includes Moon Snail but excludes Lungfish and Pond Turtle.

It think the [FISHITEM] is what causes vermin to be available both in stocks category (as fish), and in trade. It is available in caste flags, I'm not sure if also in general race flags. Since this tag is related specifically to their edibility, I would say it is a good choice for tests. Quite possible it's also the tag which creates this general (no specific part) food preference in the dwarves.

Sad fate of Olon the Scholar.

 About a year and half earlier, a human decided to visit my fortress. After a few steps he changed his plan and form to that of a weresheep. It passed the gates before they were closed, so I ordered a squad to take care of it. Ultimately only one soldier was interested in handling the foe, the rest of them took position that one is more than enough. The beast was near entrance when a civilian engaged it, a naturalised elf dancer. Before my soldier arrived, the civilian was cruelly dismembered and strangled. My soldier, formally a wrestler, but really a very pissed miner, pursued the sheep, and was exchanging blows, blocking or dodging his way, and hacking the monster to pieces. Slowly. When the beast was near death one dwarf scholar named Olon decided to help, gods know why. And he ultimately stole the kill, by punching it right before it bled to death. I wasn't happy, my soldier probably too. Of course, the scholar was bit by the weresheep, but shortly after the incident he decided to leave the premises. I took a note of him, expecting to hear more in the future.

 This came 15 months later, when the werebeast showed up. It was a weresheep, so seemed familiar - it was indeed Olon the Scholar. He was too close to the gates to be closed in time I thought but I didn't even try, knowing that the dog will occupy it for a while, and ordered a squad to attack. Again, they were too blasé for pack hunting and designated only one representative. This time it was a legendary mace lord with a bronze morningstar who caught the beast still near the gate (actually beyond) because it decided to pursue some human visitor, so I could just really close it if I wanted. Also, the fight was much shorter. Two or three from the morningstar shots maybe? The werebeast was able to kill the pursued human before that, so I can't say it was completely victim-less victory.

 I have checked if Olon had other kills in the meantime. No, he had only two to his account - the human bard now, and the same weresheep monster who gave him the curse to begin with, 15 months before. Kind of ironic, but that's how these curses work. Now, if I could ask him one question it would be "Was it worth it"? I mean the kill steal incident. It probably gave him a short lived fame, but was it really worth it?


On a side note, I made an archive save for some tests and repeats when the test come, and concluded that the silver vulnerability of this beast means not much - legendary silver warhammer was just scratching it, and it would be hard to say that it was supposedly 20x stronger than blows from other weapons.

No goblins at all? That means some genocide. I wonder who did it - humans or elves.

Anyway, the most dangerous goblins are those past their expiration date. They may still be there somewhere.

Hello, I was not really following the development process too closely during the recent say 3 years, can you please tell me:

1) How is the game scaling on modern CPUs? I have Core i5 8600K now, is the game still 32 bit single thread, or was there some effort to rewrite the code?

The faster single-threader, the faster the game. Scaling is almost 1:1 with the clock, and newer processors, which sometimes sacrifice clock speed for faster performance of newer commands (not used by DF at all), or for faster multithreading speed (more cores but slower), can suffer. This can be offset by faster memory controller or not, depends. Bigger cache also gives a boost, and faster memory too. You should have no problems with i5 8600 K at all, because it's one of the fastest single-threaders, unless you have low memory (you cannot really have SLOW memory).

Regarding the first script, the one http://www.bay12forums.com/smf/index.php?topic=172335.msg7888383#msg7888383
I've spent more time with testing it. First technical, the script is a quote not a "code", needs to be copied, and since some lines are too long for my web browserI had to edit it to prevent related errors. Not a big deal if someone knows Lua commenting style, but there it is. Second technical was I had to change
because new_str is treated as userdata data type, not as a string and it throws an error.
Third technical was I had to change lines
I suppose this is how it was intended, but I note it in case it causes some funny things.

Now about the workings, the actual working and changes to dwarves. During first pass it caused some changes, for instance
  IMPOSSIBLE bumblebee mead [bumblebee]
  to
  dwarven milk [purring maggot]
You may say that it's changing something impossible to something theoretically possible, so it's theoretically fine, but it also does change alcohol into non-alcohol. Now I don't know if it at all matters to the dwarf to have one alcohol, but sans the one hillock generated imigrant (which was created by the game de novo, like seven initital dwarves) all people do have one alcohol preference, and sometimes (often, I would say) it's the only food preference they have. So I think it would be good after change to still have one alcohol (or two).

Another change was
  TOO SMALL desert tortoise gizzard tissue [desert tortoise]
  to
  donkey stomach tissue [donkey]
which was OK, but after I ran the script second time (because there were still two impossible foods) this happened
  donkey stomach tissue [donkey]
  to
  giant slug liver tissue
Hm. Only reason I can think of is some residual cache of Lua, a problem which I also run into sometimes with my scripts, when they can reuse a variable between different runs (instead of having it reinitialised/cleared). So in this cases the variable needs to be cleared explicitly or something. Not that big deal overall, but something which can surprise an user.

However, third weird change I noticed was harder to explain:
  cow cheese [cow]
  to
  UNAVAILABLE roc muscle [roc]
It was on the first run. This was changed again in the second run:
  UNAVAILABLE roc muscle [roc]
  to
  hippo heart tissue
Which is OK. But why change the perfectly fine cheese to roc meat in the first place?

There was similar issue with other dwarf:
  penguin muscle [penguin]
  to
  UNAVAILABLE giant damselfly stomach tissue [giant damselfly]
which in second run was repaired with this change:
  UNAVAILABLE giant damselfly stomach tissue [giant damselfly]
  to
  giant hedgehog pancreatic tissue
There were of course many other changes (I ran it on fortress of 160 people), but these struck me as somewhat strange. You may keep an eye on cases like this.

----------

Regarding the second script, the booze cooker, this is first time I ran it, so I didn't fully know what to expect. First a technical: it throws an error (or rather warning) of "take_stock encountered unexpected LIQUID_MISC material mode: inorganic          0       33", which is caused by milk of lime. I added lines         elseif i == "liquid_misc" and
               material.mode == "inorganic" then in appropriate place, and the error disappeared.
      
            
As for the working, it seems it is working. I'm not quite accustomed to reading scripts of other people, this is the third dfhack script I read (other than mine own), so I don't fully understand what it is doing yet, but apart from one error once (it was expecting integer in line "job.job_items [l].item_type = df.item_type [vector [categor_iterator]]", I don't know why it wasn't getting an integer), it creates up to three jobs per kitchen, with seemingly preference for powder (flour) in the first three, but maybe it's because they are the freshest thing.

Next time save the game the necromancer is still there, or better when the siege is just announced, someone will look at the save.

There are two kinds of necromancers, even from the same tower - one is associated with sieges, the other (sneaking about) is formally not. These two kinds can come at the same time. Since changing siege ID of besieging unit to ID of former sieges forces it to abandon the siege, and necromancers are already known to have wonky siege IDs it is possible that the game assigns ID wrongly, which forces the unit to break siege and flee immediately after showing up. If the breaking unit is a leader of some other units (like often a troll leads several other trolls, or a gobbo officer leads a pack of other gobbos), then all these units also break the siege. In a small siege it is possible that only one leader is there, and he can break the whole siege on himself.

So it would be interesting to see if the problem is with the siege proper, or with the units and their siege ID, or something else.

^ does this mean a very large dwarf, or maybe a human, can serve as an indefinit food supply for my vamp fort?

Not practically, because there are no humans big enough. When a vampire drinks, it usually takes somewhere between 5 and 15 litres of blood equivalent (if possible, i.e. the victim is still alive). If it takes close to the low bound of this range, the dwarf or human survives (except children and already bled ones, who have not enough blood). But next time the victim may be not so lucky and the vampire wants more than the victim holds. Also blood is refilled quite slowly, so if you have two vampires, the victim may survive first, but not the second.

Vampire doesn't need as much blood (it requires about 4.2 litres to sate every 3 months, unless hasn't feed for more than 3 months), but is just wasteful.