Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - PatrikLundell

Pages: 1 ... 4 5 [6] 7 8 ... 13
76
Acting on Toady's info in the FotF, a couple of dead civ related scripts have been made:
- slabciv: Kills off controllable civs (i.e. dwarven ones) if they haven't shows any sign of life for 100 years (arbitrary duration).
- permit_dead: Adds dead controllable civs to the pre embark civ selection list.

slabciv.lua
Spoiler (click to show/hide)

permit_dead.lua:
Spoiler (click to show/hide)

slabciv is started before generating a world and acts in the background during world gen, while permit_dead is run while on the pre embark screen to extend the civ selection list.

A quirk with permit_dead is that a if you have embarked and abandoned (and presumably also retired) a fortress that civ is neither picked up by DF nor by permit_dead for subsequent embarks.

The scripts are stored in a "text" file as<DF>\hack\scripts\<script name.lua> and are invoked from the DFHack console by typing the script name without the .lua suffix.

Edit: Updated to handle changed field names.
Edit2: Inserted permit_dead, which was missing, for some reason.
Edit 3: For some reason one of the indices was missing (line 159) from slabciv, which has been corrected.

77
These scripts select everything in the broker trade list for trade but exclude the bins (for reuse) and unworn underwear (since dwarves rely on 'import' for these, and thus aren't available in the usual dwarven masterworks quality).
The 'elf' version also removes items made out of wood and items containing wooden improvements. I suspect this will also remove fruit (from trees) and tree fruit based booze (although I haven't checked). It does not check for ash in its various forms, though (apart from the tree, of course).
The scripts set the trade flags for all items, so you'd start with running the appropriate script and then modify the list manually if you want to fine tune the selection.

allbutbins:
Spoiler (click to show/hide)

allbutbinelf:
Spoiler (click to show/hide)

To use the scripts, copy the script code into "text" files named allbutbins.lua and allbutbinelf.lua in the <DF>\hack\scripts folder respectively and invoke them by typing "allbutbins" or "allbutbinelf" into the DFHack console.

78
Utilities and 3rd Party Applications / DFHack script: unblockmeetings
« on: July 19, 2017, 07:03:03 am »
I think I've finally found a way to unblock stalled meetings (due to position holder replacements) without killing or driving away petitioners.

unblockmeetings.lua
Code: [Select]
--  Work around for blocked meetings where a change of position holder causes the meeting activities to
--  stall. The somewhat heavy handed approch wipes all meeting activities from the participants and the
--  internal store and relies on DF's ability to rebuild the ones that should actually be there.
--
function unblockmeetings ()
  if not dfhack.isWorldLoaded () or not dfhack.isMapLoaded () then
    dfhack.printerr ("Error: This script requires an embark to be loaded.")
return
  end

  dfhack.println ("Deleting " .. tostring (#df.global.ui.meeting_requests) .. " meeting requests")
  for i = #df.global.ui.meeting_requests - 1, 0, -1 do
    df.global.ui.meeting_requests:erase (i)
  end
 
  dfhack.println ("Deleting " .. tostring (#df.global.ui.activities) .. " activities")
  for i = #df.global.ui.activities - 1, 0, -1 do
    for k = #df.global.ui.activities [i].unit_actor.specific_refs - 1, 0, -1 do
  if df.global.ui.activities [i].unit_actor.specific_refs [k].type == 4 then  -- ACTIVITY
    dfhack.println ("Removing actor ACTIVITY from " .. dfhack.TranslateName (df.global.ui.activities [i].unit_actor.name, true))
    df.global.ui.activities [i].unit_actor.specific_refs:erase (k)
  end
end

    for k = #df.global.ui.activities [i].unit_noble.specific_refs - 1, 0, -1 do
  if df.global.ui.activities [i].unit_noble.specific_refs [k].type == 4 then  -- ACTIVITY
    dfhack.println ("Removing noble ACTIVITY from " .. dfhack.TranslateName (df.global.ui.activities [i].unit_noble.name, true))
    df.global.ui.activities [i].unit_noble.specific_refs:erase (k)
  end
end

df.global.ui.activities:erase (i)
  end
end

unblockmeetings ()

The script has only been tested to a limited extent (I've had a petitioner on route to a meeting, swapped out the expedition leader, ran the script, verified that the visitor did petition, dismissed the petitioner, waited until another petitioner showed up on the petitioner screen). I haven't tried it with diplomats. It may possibly remove things that should be retained in the data structures (I didn't have anything extra in my test case), but I don't know if there are other things that can show up there.

The code is stored in a "text" file called unblockmeetings.lua in the <DF>\hacks\scripts folder and is invoked by typing "unblockmeetings" in the DFHack command console.

79
DF provides an aquifer indicator pre embark, which indicates DF "knows" where aquifers should appear without actually generating the embark. Is it known what criteria DF uses to determine this?
The follow on question is how DF determines at which depth to place an aquifer. The bottom is obviously determined by "just" flooding the volume below the top of the aquifer to wherever the aquifer can propagate to an aquifer supporting layer (stopping at biome boundaries), but what about the top? Material properties specify whether the material supports an aquifer, so the flood filling part is just an application of the aquifer to to the geo biome makeup.
And can the aquifer reach the very top, so that any digging into the ground results in hitting the aquifer (I've heard rumors that it can happen in swamps, but have never seen it)?
Summary:
1. How does DF determine at which locations to place aquifers?
2. How does DF determine at which level below ground the aquifer starts?
3. Can an aquifer start at the very top soil level?

80
I've been trying to find out how plant selection for an embark works, and believe I've found parts of it, but there are pieces missing.

What I think I know:
1. World tiles refer to biome regions that list plants (and animals) available in that region.
2. World tiles control areas of the embark in terms of biome, etc., and an embark can contain multiple biomes, each controlled by a world region that's either the one of the embark or one of the 8 surrounding ones.
3. At embark, a 7*7 world region grid centered on the embark's world tile is drawn from to populate the df.global.world.populations list. This list contains entries from the surface as well as each underground level, organized per world tile. I don't know how complete this list is, i.e. whether it contains everything in the biome regions, only things legal to the world tile, or possibly contains an RNG selection of entries.
4. For the surface, only plants/animals legal to an actual biome show up, i.e. temperate/tropical/good/evil/savage restrictions are upheld for the embark, even when the region biome contains things that are not legal (since a region biome can span multiple biomes of the same broad type. In addition to that, it's possible to add inappropriate things through hacking).
5. The underground biomes do not seem to perform a legality check: hacking water dependent plants into Underground Chasm regions prior to embark cause those to show up on embark, so it seems DF relies on the population of the underground regions perform the check. Hacking surface plants into underground biomes prior to embark has resulted in surface plants being present in the caverns at embark. I don't know if new surface plants would sprout there after embark, but suspect the light check would prevent it.
6. For some reason, grasses seem to have been given a special treatment. The df.global.world.unk_59dc4 structure seems to contain "grasses" organized into world tiles and levels, with each level containing a list of "grasses". Adding a grass here causes the grass to start appearing on the embark, even if not legal (eyeball on a good embark, for instance). Hacking the df.global.world.populations structure has not given any effect at all regarding grasses: it seems unk_59dc4 has taken over completely.
7. Underground Chasm regions do not follow the normal pattern of providing "grasses" to unk_59dc4 from their population list (which does not contain any "grasses" [or other plants except possibly blood thorn] at all). Despite that unk_59dc4 gets both cavern moss and floor fungi for these regions, and removing the mud and pre existing ground cover with magma shows the grasses do regrow. Removing "grasses" from Underground Water regions (the normal caverns, i.e. not mud covered) prior to embark causes those caverns to be covered by generic grass, although I haven't verified that the corresponding unk_59dc4 list is empty.
8. Hacking df.global.world.populations to replace the plant reference in an entry to refer to a different plant of the same (Bush/Tree) type causes the embark to start providing the new type instead of the old one, even if the reference to the biome region's population still refers to an entry for the original type. I speculate that this back link is only used for animals for which there is a need to keep track of their numbers.
9. Hacking df.global.world.populations to insert new non grass plant entries seems to have no effect, even if properly linked up to hacked new entries in the region biome's population, even when the new entry has been inserted in between existing ones.
10. River creature populations are available in the feature_map's river feature entries on an embark tile level. Where that population is drawn from is currently unknown (educated guesses can be made, but I've made no investigations).

Things I know I don't know:
1. How does DF select which bush/tree to place when it's time to generate one? Presumably an RNG number is used to select from some kind of list, but where is that list located, and can it be manipulated? 8 & 9 above leads me to guess there is a list of pointers to the actual entries in the df.global.populations list (rather than a list of indices for the entries) somewhere.
2. Is the bush/tree "list" DF uses complete, i.e. does it contain every legal entry from the region biome's population list, or is there a further RNG based selection (on top of the one that led to the generation of the region biome population list contents)? Put a different way: does presence in the region biome's population list guarantee that you have a chance to get that plant on your embark (assuming it fulfills the local legality criteria regarding actual biome, etc.)? Experience indicates you may miss out on some, but it may just be bad luck.

So, do others have additional insights or knowledge proving/indicating things above are incorrect?

Edit: Added point 10 above.

81
It's a bit silly that spores released from caverns can result in corresponding plants everywhere except the caverns above. As long as the corresponding plants have their growth requirements met (such as savagery/evil/good, none of which currently affect vanilla subterranean plants) they ought to settle in the caverns above their native one as well.
There is currently a water access requirement for all underground trees except blood thorn, but if the drifting water vapors within a fortress is sufficient to support those on muddied rock everywhere, that ought to be sufficient for upper cavern growth as well.

82
This tool allows you to manipulate region biomes during world gen and pre embark:
- Change the Evilness of the biome (all world tiles included in the take on the entered value). Evil/Good plants and creatures no longer supported are removed from the population list. Evil weather is likewise removed if an evil region ceases to be evil.
- Add/remove plants and creatures on a per region basis. A toggle allows you to add things that doesn't belong (such as titans...) with largely unknown effects. Use at your own risk.
- Edit population counts for creatures.
- Flora/Fauna-diversity orders: set all regions to contain all plants and creatures respectively supported by each region. The toggle mentioned above does not affect these orders.
- The flora/fauna manipulations can be performed both on surface, cavern, and magma sea biome regions.
- Allows changing of cavern water, openness min/max, and passage density min/max parameters. Changing the water one
  can change the cavern biome type (Subterranean Chasm <-> Subterranean Water).
- Allows adding/removing/replacement of evil weather to regions regardless of actual region evilness, but no weather editing.
- Allows modifications of Geo Biomes, i.e. which minerals are present at different world tiles.
- Allows manipulation of world tile parameters, moving world tiles between regions, and creation of new regions.
- Allows manipulation of rivers, although their spaghetti course makes it a pain to do so.

The latest biomemanipulator.lua version can be downloaded from https://www.dropbox.com/s/bc7gxkmkk3mz1t6/biomemanipulator.lua?dl=0
It can also be found here:https://github.com/PatrikLundell/scripts/blob/own_scripts/biomemanipulator.lua (Note: it's a web page with the script on it, not the script itself, so don't try to save the page as a lua file).

To "install", copy the downloaded file into <DF>\hack\scripts and invoke it from the DFHack console with the command "biomemanipulator".

The author intends to update this first post without explicit change notes to reflect any changes in functionality. A change log should also be updated.

Change log:
0.44 2022-01-23: Dealt with unmapped creature_interaction_effect_type values.
0.43 2021-10-15: Fixed bug when veins occur in the first geo layer.
0.42 2021-08-15: Adapted to the identification of the plant_raw index field. Should be backwards compatible.
0.40 2020-03-04: Adapted to changed creature flag names. Should be backwards compatible.
0.39 2020-01-13: Fixed crashing when used with modded interactions.
0.38 2020-01-12: Updated to handle corrected field name when used during world gen.
0.37 2019-12-12: Fixed numerous bugs affecting biome generation.
0.36 2018-07-29: Fixed incorrect widget usage, causing text matching to fail.
0.35 2018-07-29: Fixed bug in the geo morph command that caused it to do nothing.
0.34 2018-01-15: Adapted to naming of the dead_percentage field.
0.33 2018-01-11: Corrected bug in evil weather reanimation detection causing reanimation to be reported where it isn't.
0.32 2017-12-27: Added new Geo Manipulation commands to assign all legal minerals to a layer, geo biome, or all geo biomes.
0.31 2017-12-25: Added beta and gamma DFHack version detection.
0.30 2017-12-22: Fixed geo biome panning.
0.29 2017-12-19: Fixed forwards compatibility bug in setting of whole region evilness.
0.28 2017-12-10: Modified new region creation to support 0.43.03. Fixed bug causing that to probably fail in 0.44.02.
0.27 2017-12-10: Added mostly untested support for 0.43.03, but river manipulation couldn't make it.
0.26 2017-12-09: Added printing help screens to the DFHack window to work around tile set illegibility.
0.25 2017-12-08: Adapted to DFHack changes in 0.44.02. It should be backwards compatible, though.
0.24 2017-11-25: Adapted to updated DFHack river structure. Remains compatible with the older DFHack version.
0.23 2017-11-24: Fixed region wide evilness changes and new region creation to set a region evilness field, allowing changes
                        during world gen to affect civ placement.
0.22 2017-11-18: Fixed display bug causing river sinks to be marked as disconnected erroneously. Also, DF doesn't seem to
                         recognize new rivers for unknown reasons, so avoid using that function.
0.21 2017-11-13: Added manipulation of rivers, added resizing of "maps", added fast movement keys.
0.20 2017-11-07: Added new page to allow manipulation of world tile parameters, shifting world tile region affiliation, and
                        creation of new regions from world tiles.
0.19 2017-09-24: Corrected geo manipulation "morph" logic that crashed on DF 64 bit Windows.
0.18 2017-09-10: Undone 0.17 as that was due do an incorrect understanding and updated the help text to describe the
                         current understanding of how the Cavern Water parameter works.
0.17 2017-09-08: Changed Cavern Water parameter to Cavern Muddiness due to better understanding of the parameter.
0.16 2017-09-03: Fixed display issue where "maps" are painted on top of the frame.
0.15 2017-07-30:
- No visible changes. It turned out I'd completely misunderstood the 'r' and 'b' parameters for "frames" in the API. Changed to use the 'w' and 'h' parameters instead, as well as correcting the internal "Grid" widget.
0.14 2017-07-25:
- Added Geo Biome manipulation.
- Restructured the help into several pages, as my rambling didn't fit on one...
0.13 2017-07-17:
- Fixed bug causing plant list not to be populated. It was caused by performance optimization that was done incorrectly.
- Shuffled the evil weather effects a bit to compress it while making it clearer (hopefully). No functionality change though.
- Implemented variant execution depending on whether the DFHack version is r2 or newer to use a newly identified field. More of an exercise than of any measurable benefit, though.
0.12 2017-07-16:
- Fixed biome profile calculation. The wrong parameter profile was passed in, so it's surprising that part seemed to work at all.
- Suppressed output of Evil Weather Probability when 100% (which seems to be always for generated weather).
0.11 2017-07-15:
- Expanded the evil weather info into an info dump (far from complete, though).
0.10 2017-07-10:
- Change region interaction identification from using string matching to using interaction source type = REGION. Only has an effect if you are creating your own region interaction raws.
0.9 2017-07-10:
- Fixed evil weather manipulation bug. I was able to assign the first one, but the second one didn't take. An incorrectly assigned variable caused the subsequent weather settings to be considered replacements (not sure why the first one worked at all...).
0.8 2017-07-06:
- Added addition/removal/replacement of evil weather for all regions. No weather editing is provided, as changes aren't saved. A
  crude indication of what the existing weather effects are is provided, however.
0.7 2017-07-05:
- Fixed design flaw casing it to fail to work with a reduced set of caverns. As I was in the middle of implementing some minor region interaction manipulation it's possible to bring up a partially implemented page on which you can do nothing (but nor break anything, I hope).
0.6 2017-06-30:
- Removed the minor hurdles to run the script during world gen. Only tested to a limited extent, though.
- Removed undocumented ability to pass a region parameter on startup. It will now start on region 0's first tile (0, 0) most probably) if started during world gen and at the current world tile if started pre embark (as before).
- Fixed an inevitable performance improvement bug causing animal/plant counts not to be updated on movement.
0.5 2017-06-29:
- Improved performance by not regenerating unchanged information all the time.
0.4 2017-06-29:
- Added cavern parameter editing.
0.3 2017-06-29:
- Replaced hotkeys for "map" display selection in favor of <TAB>/shift-<TAB> cycling
- Added an additional dimension by allowing manipulation of underground regions (the three caverns and the Magma Sea. HFS has been skipped intentionally [and is boring from this perspective anyway]).
0.2 2017-06-28:
- Added support for changing Evilness and Savagery of individual world tiles.
- Corrected initial panning bug, where the "map" didn't "center" on the selected world tile at startup.
0.1 2017-06-26: First version

83
I've tried to figure out why meetings get blocked, and how to get them going again. The number of samples so far is a single save from DFFD. What I've found from that save is as follows:

- A visitor identified by the save provider is blocking visitor meetings. As expected, that visitor displays an interest in joining the fortress.
- Killing the visitor gets meetings going again.
- The visitor's meeting field shows that she wants to conduct a meeting with the fortress. This is normal for all petitioners.
- The visitor's "specific_refs" list is odd, though. She's first scheduled to meet one dorf (presumably the former mayor), and then the current mayor. Both of those dorfs have one entry each in their specific_refs lists, which is a pointer to their respective meeting pointed to by the visitor's list.
- Appointing a third dorf as the mayor gets meetings going, up to a point. That point is when the stalling visitor gets scheduled for a meeting, which shows up as a third entry in her list, and one in the new mayor's. She doesn't attend that meeting either, so the meetings stall again.
- Appointing the former mayor as mayor again (suggested as a solution on the forum) did nothing. The stalling visitor didn't go to her first meeting either. A guess is that some internal state causes her to never consider the first meeting again, possibly when the second one was added (which probably is where DF goes wrong: the first meeting should have been removed from the lists of both participants on the election of a new mayor).
- Using DFHack to remove the meeting entries from the 3 dorfs in question did nothing on its own. I've tried various (probably all sensible) combinations.
- However, removing all the bugged meetings from all the participants AND appointing a third mayor sort of did the trick: meetings resumed, and the stalling visitor was processed properly. Sort of, however, means both of the (now) former mayors remain bugged: they would not perform any meetings when instated into office.
- Killing and reviving the stalling visitor seems to work, though. Somehow the cleanup following the death of the stalling visitor cleans out the specific_ref entries as well as whatever it is that blocks the mayor and former mayor from conducting meetings. When revived, the stalling visitor eventually went to a petition meeting with the elected mayor.
- The stalling situation seems to be easily reproduced: just replace the expedition leader/mayor as a visitor is to attend a meeting (as shows by the unit screen).
- If you don't want the stalling visitor to join, I've successfully unblocked the meetings by inducing the visitor to "head for the forest" as a (hopefully) less disruptive alternative to death-and-resurrection.
- Later development showed there were additional structures involved in df.global.ui. The latest version of the unblockmeetings script doesn't kill anyone.

I've created a couple of scripts that are useful in the situation examined, but they have limitations: I've failed to get the kill/revive script to return the possessions to the inventory of the stalling visitor (DF crashes when I try), so the possessions lie in a pile on the ground, together with a corpse I haven't tried to dispose of. The kill/revive script is based on exterminate.rb, and should thus work on vampires, but I haven't had any to test it with.

Script findmeetingblockers.lua
Spoiler (click to show/hide)
This script is run on the embark to try to find who the blocker is. It will list everyone with entries in the specific_ref list, in particular the mayor(s), and I haven't done anything to try to remove legitimate causes for entries in that list (I don't know what they are).

Script unblockmeetings.lua
Spoiler (click to show/hide)
This script is executed when a unit is selected in the unit list or with 'v' and kills and revives the unit. Due to the need for DF to run to perform the kill cleanup before the unit is revived, DF will have to run for 3 ticks for the script to finish, so you run the script, deselect the unit, and then either single step DF thrice, or just resume it.

getlost.lua
Spoiler (click to show/hide)
This script tells the selected unit to head for the forest. Unfortunately, it doesn't override the socializing done by over staying visitors, but bugged ones, such as a visitor who's gotten the petition foiled don't do any socializing, and seem to be subject to the suggestion to get lost. As usual, I have no idea if this script has side effects.

Caveat emptor: Limited testing of the scripts, and no knowledge of what side effects the unblockmeetings script may have.

Edit: Updated with the latest (non lethal) version of unblockmeetings, as well as added an additional point on the known info list.

84
This tool allows you to manipulate 3 region level features pre embark:
- Elevation (change region tile elevation)
- Biome (change region tile biome to any of the neighboring 9, including the local one)
- Change river course, elevation, and width. Elevation allows creation of aqueducts, gorges, and water falls.
- Change whether a river is a brook or a stream.
- Control the amount of water in the caverns. Only tested to a limited extent. This functionality also depends on other parameters
  having compatible values elsewhere, plus the RNG.
- Manipulation of Features (Adamantine Spires, Volcanoes, Magma Pools, Passages, and Pits). The set of manipulations is limited to what the author finds reasonable. Limited testing has shown that adding Passages and Pits can result in cave-ins and draining of cavern lakes.

Note: all of these manipulations, except the brook/river one, are temporary. They are lost when another region is brought into focus, and they are likewise lost when embarking again in the same region as a previous fortress. However, the manipulations in effect when a fortress is created get "frozen" onto the fortress. This presumably can cause issues for adventure mode.
Also, changing river courses is messy, and only vaguely understood by the author, but some spectacular things can be generated.
https://www.dropbox.com/s/lap5tapg8if9p62/regionmanipulator.lua?dl=0 Version 0.15 2020-02-15.
The script can also be found here:https://github.com/PatrikLundell/scripts/tree/own_scripts

The tool is a Lua script that's intended to be stored in <DF folder>\hack\scripts and then invoked from the DFHack console by typing "regionmanipulator" into the console.

Change log:
0.15: Updated for 0.47.01 changes. Should be backwards compatible.
0.14: Fixed bug in river editing.
0.13: Reworked the UI and added manipulation of Features.
0.12: Added printing of help screen to DFHack console.
0.11: Added display of river entry/exit directions.
0.10: Replaced control scheme with command keys instead of tabbing through edit fields. Added mask to help screen to mask DF UI.
0.9: Added cursor starting on embark rectangle and "see through" view of the native DF region underneath the UI.
0.8: Added control of cavern water. This functionality is tested to a very limited extent.
0.7: Added description of the Biome reference coding DF uses to the help screen.
0.6: Fixed edit fields being one character too small.
0.5: Added ability to change a brook to a stream and vice versa.
0.4: No functionality change, just a better widget implementation internally.
0.3: Changed the UI to resemble a form with fields.
0.2: Allowed elevations to be negative down to -999.

85
This tools is no longer supported, as the functionality has been rolled into the larger Biome Manipulator http://www.bay12forums.com/smf/index.php?topic=164658.0
This tool allows you to replace the geo biome of a world tile at a time with one of your making. It has to be used during the pre embark phase and does only change geological layers and their veins/clusters, but does not allow manipulation of the region's thickness or cavern placement. If an intended embark covers ground belonging to different world tile biomes, you have to edit each of those world tiles' geo biomes in turn to control the embark layers throughout the embark.

Why edit at all?
- You can ensure the presence of desired materials, either with desired traits (such as ores, gypsum, and the like) or colors.
- You can ensure the absence of "contaminants" in blocks of rock to ensure your fortress part of the embark is nicely uniform in color.

Note that there is no support regarding material properties, uses, or which ones may be present inside of each layer apart from the population of the corresponding lists. You'll have to look to the wiki for that. The tool attempts to follow the rules defined by the raws for which veins/clusters are found where.

You save the code into a file called geomanipulator.lua and store it in <DF directory>\hack\scripts and it is the invoked by calling "geomanipulator" from the DFHack console.

Spoiler (click to show/hide)

Edit: Thanks lethosor, I fixed the wrapping. I accidentally used quote instead of code...

Change log:
Version 0.3 2017-09-24: Corrected correction. I had to ensure nothing in done on empty lists, rather than trying to remove a non existent element.
Version 0.2 2017-09-24: Replaced misused  :delete() operations that kill DF on 64 bit Windows with iteration over erase(). This problem caused the "morph" operation to be lethal.

86
DF Dwarf Mode Discussion / Can statues be climbed?
« on: December 14, 2016, 12:58:43 pm »
If statues cannot be climbed at all, they should be a better alternative than stone blocks to line e.g. retracting bridges in areas where natural stone isn't available, provided you can ensure you won't have any building destroyers there.

87
I want to make a system that detects vampire visitors only, without witch trial murdering of others. However everything I've tried has failed for one reason or another.
My latest attempt was to use reanimated parts to scare non vampires away from the direct route, but that turned out to fail because mercs apparently also ignore undead. Thus, it seems I'd need something to distinguish vampires from mercs.
What I really am after is a way to let mercs and regular visitors through, but catch/kill vampires. If necros and weres are detected as well it's a bonus.

So far I've found that all visitors seem to go directly to the location they're visiting. If they're petitioning they'll then immediately go from there to petition. In a previous attempt I tried to make a visitor only tavern well away from the fortress itself by having a restricted tavern inside the fortress itself, but the blasted dorfs still insisted on running back and forth to the visitor tavern rather than the much shorter distance to their own tavern, so the attempt to make a passage used only by vampires out for a snack failed (I thought petitioners would go directly to petition, rather than go via their target location). I can separate citizens from visitors using travel restrictions (which I used in my latest failure to keep from scaring my dorfs), but I still need to separate vampires from petitioners.

88
DF Dwarf Mode Discussion / What is the visitor range, if there is one?
« on: November 16, 2016, 06:18:35 am »
I have problems getting visitors in most of my worlds. However, in the current one I do get a fair flow of visitors, but all of them (except 1, over 10 years or so) have been humans, despite the world having slightly more elves than humans (and both are much more numerous than goblins, which I don't expect to see many of, since I'm at war with their only civ), and a large elven civ being my trading partner.

Thus, is it known if there is a range for how far visitors are prepared to travel (or some kind of formula) and if so, what is it?

89
I'm having trouble with the elves considering the leather armor to be made of wood and refuse to trade. It's not the first time the elves have been pissed off even though I'm fairly sure I've deselected every bin there is, but this is the first time I've whittled it down to a single object and which definitely should NOT be made out of wood (there might be more of them: I haven't checked).
Is it a known bug (I fail to find it on the bug tracker)?
My save isn't really fit for a bug report since I've tried to do some hacking to handle the unavailable lost caravan bug items.
The armor probably belonged to one of the hordes of human mercs who insist on getting themselves killed while my fortress is under siege by goblins.

90
I suffer from periodic birdsplosions in my fortresses because the dorfs just ignore egg collection. I've put that up to overworking and egg collection being a low priority task, but currently my fortress is trying to have an R&R season, so half of the dorfs are socializing (green). The wiki claims egg collection is a food hauling task, but a lot of my socializers have food hauling enabled and haven't moved their lazy butts to collect those eggs for quite some time. I haven't quite managed to stop work completely, as there's still item hauling going on to clean up after the mess the latest goblin invasion caused (slaughtering a dozen or so mercs, leaving their gear to be hauled off).

Edit: I tired of waiting, so I ordered the eggs dumped, at which dorfs swarmed into the animal pen to sweep up the eggs. As soon as they'd been dumped I unforbid them, but they're ignored, as are the new batches of eggs laid. And I've reached the stage where nobody is working, so it's not for a lack of workers. I've rechecked the settings on the food stockpile, and it does indeed specify eggs as one of the permitted categories.

Edit2: A new check showed the food stockpile somehow was set to take from links only...

Pages: 1 ... 4 5 [6] 7 8 ... 13