Bay 12 Games Forum

From the dev log:

But plots can also be aimed toward adding another layer to the network. If a visiting agent has turned a fortress bookkeeper, the bookkeeper can attempt to compromise their friends, family and other position holders.

Another thing that a compromised fort resident can do besides trying to compromise other residents is spread rumors to weaken morale and make citizens doubt their loyalty, or to sow conflict and raise tensions.  This would require a fortress mode rumors mechanic to be added, so rumors can spread from dwarf to dwarf (but such a mechanic could be used for things besides villany).  Such a mechanic would also allow for agents pretending to be ordinary visitors to spread their influence without having to compromise anyone.

A compromised resident could prevent a rumor from being traced back to them by writing the rumor on a wall as graffiti. While catching a resident scrawling seditious graffitti could mean that they're compromised, it could also be a non-compromised dwarf spreading a rumor they genuinely believe.  On the other hand, a visitor caught scrawling seditious graffitti is almost certainly an agent.

It's be interesting if dwarfs other than the one involved in a strange mood would react to the mood and the artifact created.  Each of the various types of reactions would only have a chance of happening, both so that you don't have every dwarf in the fortress simultaneous react to each mood/artifact, and also so that each dwarf doesn't react the same to every mood/artifact.  For individual dwarfs types of reactions and probabilities would depend on their beliefs and personality.

Reactions to the strange moods themselves:

• Dwarfs close to the mooder could worry that the mooder won't be able to complete the artifact and thus go insane, feel somewhat relieved once the work starts, and completely relieved when the artifact is finished.
• Conversely, dwarfs who hate the mooder could hope that the mooder goes insane, and be disappointed when that doesn't happen.
• Dwarfs could feel a sense of awe or dread about strange moods.  This reaction might cause the dwarf to contemplate things at a library or go pray at a temple, with going to a temple especially likely if any of the deities they worship has a sphere related to moods/artifacts, like ART or CREATION.

Reactions to the creation of the artifact:

• Throw a party in celebration.
• Excitement that such an awesome thing exists and at the fortress (especially likely if the artifact's item type or base material are among the dwarf's preferences).
• Pride that the fortress has gained another artifact and/or another dwarf of legendary skill.
• Envy that someone else is getting attention for creating the artifact, that someone else got to create the artifact, and/or that someone else got the skill boost to legendary.
• For dwarfs who have themselves already created an artifact, melancholy that they'll never again create something so perfect and awesome.
• Worry that the artifact is going to attract thieves and/or invasions (more likely the more valuable the artifact).

I have backups of the linux DF itself, but it's still a major pain to get that system built again, as we've experienced in the past.

If you can save the drive you should get someone to clone it and keep the cloned drive safe, so when the old drive fails you can just swap in the cloned spare.

If you can't save the drive, then you should document exactly all the steps you need to take to get the Linux computer to the state where it can do a build.  That way when/if this happens again the recovery will be a lot easier and faster.

The problem is not really to write the code so things run in different threads, but to ensure they're not stepping on each others toes while doing so, i.e. protecting all the data stores involved so they handle parallel access from multiple threads, as well as ensuring things are not processed out of order

This is hard enough to do if a program is engineered from the ground up to be multi-threaded.  If you have a program which started out single-threaded and try to retrofit in multi-threading, it becomes even more difficult.

I ran worldgen again under valgrind, and all the warnings that came up during woldgen are gone (looks like no false positives due to -O2), but while saving the generated world it gave some warnings about uninitialized bytes:

Did you try code analysis tool in VS?

There's also various third-party C static code analysis tools, like PC-Lint/FlexeLint, Splint  and Clang.

To get it working under Fedora I simply removed the libstdc++.so.6 file from the libs directory; that took care of the "version `CXXABI_1.3.8' not found" problems.  I still had to deal with the bug 2688 problem.  That particular bug should be a quick-fix since several users have offered modifications to the df script which will automatically find the proper 32-bit libz file to use.

To the Linux users experiencing the 'libpng error: bad parameters to zlib'error, causing the game to be unable to read curses_640x300.png:

Edit the df script with a text editor, and add export LD_PRELOAD=/lib32/libz.so.1 somewhere in the middle of it.

Depending on the distribution, it might need to be export LD_PRELOAD=/lib/libz.so.1 instead. Replacing df with this script should make it work on most any distribution.  Or to copy-paste the script from right here: