Print

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

[Amostubal]

I'm having major issues with "Drop off inaccessible" spam for no apparent reason. I simply cannot norrow down the cause.

I'm not using burrows at all, in fact, its cropping up before I've even mined my first z-level. It spams so much that it seems like my dwarves end up doing nothing, presumably because they are getting confused.

I'm getting errors in Dfhack, but I'm not using it manually for anything:

Code: [Select]

stack traceback:
        ...3)\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:116: in function 'getitemType'
        ...3)\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:126: in function 'handler'
        ...3)\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:166: in function 'equipHandler'
        ...3)\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:175: in function <...3)\Dwarf Fortress/hack/scripts/modtools/item-trigger.lua:169>
Whenever I get these drop-off spams, I get this message spammed in Dfhack console.

I've no idea what's causing it. The spam is bad enough. but it feels like there's something more, since it seems to kill off my dwarves ability to perform new jobs. I also have no idea what it is they could be searching for.

I have a theory that it's caused by building wooden floors with the "standardised wood" setting turned on that turns all wood into generic rough logs, but it occurs frequently even when I haven't built any floors.

Its rendered the game unplayable and it's a shame because I really wanted to try this mod.

I would say probably not picroft. that mod has been in use for years without that error.  item-trigger complaint tells me your probably on on masterwork 1.23 on DF version 43.03 its the one that is listed at the top of this page.   That error was fixed in to 1.24b, you will find a post on the masterwork forum, we're at 1.24c now.  If it is masterwork 1.24b or c version you can upload you save folder and I'll investigate the error.  but I'm fairly certain its fixed in 1.24b and beyond (I wrote the fix to that script and sent it to the dfhack crew and was thanked).  the error was simply an attempt to identify an item that has been picked up and either the item was immediately dropped or used up in an interaction, was plant material, or instantly consumed by the unit as food.   Anyways, invalid ramps/drop offs spam usually comes from misaligned ramps.  Ramp areas where the ramp say goes up with a wall to the north, but the only valid floor above the ramp is east, south, or west.  I'm guessing that wherever you had embarked you have an error in the map data near where the units want to move.  it causes them to cancel their jobs.  if you checked your errorlog, it should have a pathing failed line that identifies the unit and the xyz of the location the unit was trying to get to and coming from... if I remember right the from location will be the location the unit failed to find a path which should tell you where they are hitting a drop off inaccessible point.

anyways, try it on 1.24c if you are still getting issues such as that holler at us again, with an uploaded save, I can usually find these odd map points (I've had several).  or you can try I think its "deramp" in the dfhack console, it kills invalid ramps, I may have the command wrong, I'm not where I can go and look it up right now.

[PiCroft]

I would say probably not picroft. that mod has been in use for years without that error.  item-trigger complaint tells me your probably on on masterwork 1.23 on DF version 43.03 its the one that is listed at the top of this page.   That error was fixed in to 1.24b, you will find a post on the masterwork forum, we're at 1.24c now.  If it is masterwork 1.24b or c version you can upload you save folder and I'll investigate the error.  but I'm fairly certain its fixed in 1.24b and beyond (I wrote the fix to that script and sent it to the dfhack crew and was thanked).  the error was simply an attempt to identify an item that has been picked up and either the item was immediately dropped or used up in an interaction, was plant material, or instantly consumed by the unit as food.   Anyways, invalid ramps/drop offs spam usually comes from misaligned ramps.  Ramp areas where the ramp say goes up with a wall to the north, but the only valid floor above the ramp is east, south, or west.  I'm guessing that wherever you had embarked you have an error in the map data near where the units want to move.  it causes them to cancel their jobs.  if you checked your errorlog, it should have a pathing failed line that identifies the unit and the xyz of the location the unit was trying to get to and coming from... if I remember right the from location will be the location the unit failed to find a path which should tell you where they are hitting a drop off inaccessible point.

anyways, try it on 1.24c if you are still getting issues such as that holler at us again, with an uploaded save, I can usually find these odd map points (I've had several).  or you can try I think its "deramp" in the dfhack console, it kills invalid ramps, I may have the command wrong, I'm not where I can go and look it up right now.

Thanks, downloaded 1.24c.

I gave it another go, but it seems to persist (although the drop-off spam seems to be lessened somewhat). Now, however, dwarfs seem to randomly disregard certain jobs and refuse to perform certain tasks. In this case, I've started a new map and cut down some trees and there's a ton of wood about. My dwarfs seem to have just decided to forget about it and now sit about not touching any of the wood.

In addition, after digging downwards with a 2x2 stairway, my miners have now decided that they don't want to do anything else to do with mining.

I also placed a stockpile for wood, but no-one will drag wood to it and a nearby carpenters complains that there's no logs, despite the map having about a billion logs about after a clear-cut in the local area, and I even drew a wood stockpile over a bunch of logs so the stockpile had some logs to start with. No joy I'm afraid.

There doesn't seem to be any errors in the DFhack log. It feels like after a very brief time, the dwarves AI seems to get very confused and then just dies on its backside and doesn't recover (occasionally, dwarves will pick up a task I queued up, but wether they do or not is entirely at random and very very rare). There's no specific reason for why they don't perform jobs as their labours for these tasks are definitely turned on and they do perform them them at first.

How do I go about uploading the save? There doesn't appear to be appear to attach to posts and while I can share via dropbox I need a specifc person to share with.

e: Here's a link: https://www.dropbox.com/s/plwyrqvh3qtdg6o/save.zip?dl=0

[Amostubal]

I'm downloading it now.  I generally push a lot of stuff on DFFD, it persists forever.

[Amostubal]

@picroft - the ramp issues seem to stem from the stream... build a bridge or cancel all the jobs for the far side of the river.  the river has so many bends in it, it can't move the water fast enough to the far edge, which is causing the water level to be low enough that the jobs are the far side are being picked up as available for path but then later are immediately canceled when the water level in one of the path squares gets above 3.  a bridge and it seems to level out and the dwarves run across the river to do the jobs there.

the other guys having issues, were some ramps by the place you dug into the cliff face, they have no back wall so they are unusuable for travel down or up.  and a wood cutter who treed himself.

I couldn't test it out fully, but there really wasn't that many inaccessible drop off reports to look at.  the map is WAY too big for my system to run at a decent pace.  on top of that I would suggest you create a new world, not reuse old world saves.  the scripts have been updated since 1.23.  Have fun!

[Amostubal]

spoilers on new entity file appearance.

I just finished up modding the entity_good_dwarf.txt file, its sleak its fast, its smaller, with better feature handling, easier to read, easier to understand, and in the end just looks better.  In current tests all buildings and reactions exist as they should with no loss.  15% file reduction, removal of several duplicate lines and unnecessary "noise" in the file.  take a look, comment please.

[ANickel]

spoilers on new entity file appearance.

I just finished up modding the entity_good_dwarf.txt file, its sleak its fast, its smaller, with better feature handling, easier to read, easier to understand, and in the end just looks better.  In current tests all buildings and reactions exist as they should with no loss.  15% file reduction, removal of several duplicate lines and unnecessary "noise" in the file.  take a look, comment please.

Looks much better than before!  Now what brave soul will volunteer to do a similar clean-up on all of the files? 

[Amostubal]

I made it through orc entity-  it already was pretty, but there was basically 3 to 5 people's notes on changes, and a lot of dead end noise, its interesting a way a person writes is like a fingerprint.  some people tag themselves in their writings others are like ghosts, but something as simple as .... , comma usage, or an interesting arty arrow (=>) is almost as good as signing your full name to every line.

Kobold entity.... that was the most "cobbled" together piece of work.... it has less than half the "reactions" and basic information that dwarf entity had.... but it took almost 6 hours, longer than dwarf entity...  basically only a handful of reactions were even close to their buildings. It seems every time someone made a change to the file they just tacked on a few reactions wherever and then assigned them to buildings.

Human entity will take longer.  I have the first part pulled out.  I reassigned their modest mod based brews to a modest file (which I may reverse... originally they were designed to be shut off by the modest mod selector on the mod page.... I may reverse it's location back to the human reaction file and remove the modest mod tags from it all together, its about all that one guild building does....).  Like dwarves there is a buy/sell reactions, but its really confusing what exactly they are for, which means a ton more look ups.

The next target after I get the human entity cleaned up is to start the process of modifying building files, I'm going to make names more obvious.   Same with reactions.

If a building is say human only its going to be labeled HUMAN_XXXXXX. If a reaction is a human only reaction its going to be labeled HUMAN_XXXXXXX.
If a building is a part of a certain mod it will be named with the mod.  If a building is used by multiple groups its going to labeled MWDF (for masterwork DF) so we know that its just a "vanilla" masterwork building.  most of us know the tags for vanilla buildings.  Reactions will also have their building name appended to them so say the pottery building from the dwarfs that is only used by dwarfs will be DWARF_POTTERY_CLAYSHAPER and the reactions since they are used in 3 different buildings by 3 different races will be labeled MWDF_CLAYSHAPER_XXXX, the other buildings will be called KOBOLD_XXXX_CLAYSHAPER and HUMAN_XXXX_CLAYSHAPER.

I'm trying to decide if that should be changed to HMN, DWF, KBD, ORC, SUC, STD(instead of MWDF) etc. 

Of course this is all just ideas running at 5 in the morning, whatever I end up doing, I want it to be readable and understandable.

clarity is important, currently there's at least 5 styles of writing through out the raws. Which makes it hard to read.  I'm moving the files to a one tag a line format, stepping in 1 tab when the tag refers to what is in the line in front of it so its:
reaction
tab->name
tab->building
tab->description
tab->reagent
tab->tab->things about the reagent
tab->product
tab->tab->things about the product
tab->{[fuel]}

considering that there's all kind of spacing, all kinds of writing, copy and pasting, minor errors that are being compounded by copy and paste.   I'm hoping the end all be all will be more transparent, easier to modify, etc.
 

[Rekov]

I just saw on Meph's twitter that his tour ended. Looking forward to getting him back around here!

[Amostubal]

WOOT!  I'm ready for his return too!  look like hes already back home!

besides... I'm tired.  Its his turn to answer questions around here.

[Harem-Rose]

I am having an issue with several of my visitors. Various races end up visiting and I am guessing that they have "building destroyer" as they actively travel through my fortress flipping stuff over. One one occasion, one of them walked into my trade room and destroyed the depot, splattering everything it had in it on the floor.

I have to constantly check my notifications for visitors of these races (Jotuness, Great Spider Fiend, and one other I can't remember) and immediately dispatch my military to deal with them.
Is this behavior of rude guests working as intended, or a bug?
I've also had a couple of "necromancer" race visitors who spend a couple minutes at the tavern before necromancing a few corpses to attack my people.

Is there a way to prevent members of certain species from visiting your tavern (or other locations) short of just preventing visitors all together?

[Amostubal]

I am having an issue with several of my visitors. Various races end up visiting and I am guessing that they have "building destroyer" as they actively travel through my fortress flipping stuff over. One one occasion, one of them walked into my trade room and destroyed the depot, splattering everything it had in it on the floor.

I have to constantly check my notifications for visitors of these races (Jotuness, Great Spider Fiend, and one other I can't remember) and immediately dispatch my military to deal with them.
Is this behavior of rude guests working as intended, or a bug?
I've also had a couple of "necromancer" race visitors who spend a couple minutes at the tavern before necromancing a few corpses to attack my people.

Is there a way to prevent members of certain species from visiting your tavern (or other locations) short of just preventing visitors all together?

yep those guys are working as usual... I think its annoying that "friendly" races still will knock things over, perform necromancy, etc. your options are:

1. don't set them as active civs, this stops them from appearing as far as I can tell.
2. set their alignments to something else.  I do this with elfs all the time.  I hate those dirty little tree huggers dislike their political driven agenda to get pissy over a few fallen trees stop me from strip mining an embark of all its resources.
3. place all visitor buildings outside of your fortress, set internal meeting zones to citizens only, and then use up ramps with a hatch to stop outsiders from entering the base (not sure why that works... but it works).
4. make sure that in one of those outside buildings, you place an artifact structure (door, statue, hatch, !grate!, etc)  these guys will stand at the artifact and attempt to knock it down till they die of thirst/hunger.
5. Another thing is to place a single door entry to those buildings. get a unit to walk across the doorway while carrying any object (stone, sand bag, etc doesn't matter). Pause while the unit is in the doorway and forbid the item they are carrying, which will force them to drop it.  when they walk away the forbidden item will still be in the doorway, keeping the door wide open, normal units will be allowed to cross the doorway with no problems... world destroyers will sit there staring at the door, waiting for it to close....

4 and 5 works actually against dragons, giants, collossus, titan, megabeast, HFS demons.... personally, I prefer if they go after these buildings.  Put archer towers in range that can only be accessed from inside the base and take them down.  I've used the artifact construction many times to keep these types just outside of a base and shoot them... exploit, but its not my fault they are so obsessed with destroying what can't be destroyed.

basically if they can knock things over, they will find things to knock over, and destroy them if its possible. I've had them knock over glass windows, slabs, coffins, chairs, tables....
If they can raise the dead.... well they raise the dead when they see dead bodies.
Want to see something interesting, set the vampires and werebeasts to active societies, same alignment as your own, set them showing up as early, cut out most the other civs, so they have the ability to flourish (they usually wont, but cross your fingers).... Yeah! you will get vampire and werebeast caravans, diplomats, and visitors! a werebeast caravan is guaranteed to transform while they are sitting at the trade depot, and attack anyone in the area...  visiting vampires will randomly decide to feed.... now you got a fort of vampires!

[Harem-Rose]

Thank you,

If it's working as intended I will just kill them as they enter the map. It's good practice for my military anyway. Although the giant fiend spiders are way too fast. Sometimes it takes my military a month to catch up to them to kill them.

I only brought it up because if it's a bug I felt it should be reported. I don't mind playing along with the rules. I appreciate you tackling my question as well as my issue on the other thread.

[SQman]

I've been wondering if it's possible to disable the seasonal palette change. It may work well with Meph's tileset or Phoebus, but Duerer looks like trash in those colors. Would I need to fiddle around in the files, or is there a command for this?

[Rydel]

I think you just need to go to the .\Dwarf Fortress\raw folder and delete all the color_<season>.txt files

[Mundus]

Not sure if this is still an issue, but been playing Humans in the 0.42 version and have found that they never gather/collect objects for dumping. Stuff like food is stockpiled but just about everything else is abandoned in a rapidly growing pile across the map. Even if a required object is next to a Human/person they will cancel the job, saying that it is unavailable. Made sure all orders were set and nothing was forbidden, still a bug. Will be happy to upload a save for investigation if this is still an issue.