Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: [40d] FPS crawls with 'item inacessible' spam  (Read 424 times)

Mephansteras

  • Bay Watcher
  • Forger of Civilizations
    • View Profile
[40d] FPS crawls with 'item inacessible' spam
« on: December 11, 2008, 03:26:50 pm »
I'd originally put this up in the suggestions forum, but since it might be better classified as a bug..

Whenever I have items designated for trade that are outside, and I then set orders for dwarves to stay inside, I get FPS killing spam about '[dwarf] cancels bring item to depot: item inacessible'. This can only be solved by going in and removing the items from the trade list, which can sometimes be time consuming when it isn't obvious which item is causing the problem.

The same thing happens when I have orders to pit/chain/cage/butcher animals that are outside. This can be a real problem when the butcher's shop is outdoors. The dwarf will take the animal up to the gate, cancel the butcher order, and then stand there trying to figure out what to do with a large animal in tow. Which results in lots of '[dwarf] cancels [job]: handling large animal' messages that also kill my FPS.

A good way to fix the first one would be to just remove those items from the trading list if they can't be gotten to. For the second, the animal order should also be canceled I think. If the dwarf has the animal, maybe return it to where ever it came from or release it (if tame)?
Logged
Civilization Forge Mod v2.80: Adding in new races, equipment, animals, plants, metals, etc. Now with Alchemy and Libraries! Variety to spice up DF! (For DF 0.34.10)
Come play Mafia with us!
"Let us maintain our chill composure." - Toady One

numerobis

  • Bay Watcher
    • View Profile
Re: [40d] FPS crawls with 'item inacessible' spam
« Reply #1 on: December 13, 2008, 05:57:05 pm »
The items are sorta-kinda accessible.  Animals have a similar problem that leads to them smashing their heads against the door. 

There's an optimization to not even try pathing to places that can't physically be reached because there's a wall or door or gaping chasm in the way.  There seems to be a (reasonable) assumption built in that if the optimization doesn't apply, then there's a path, and then you get spammed in red when the assumption fails.  I suspect the easiest fix would be as you describe, to path upon thinking of taking the job, and not taking it (but not cancelling either) if there's no path. 

Less easy but more elegant: a good data structure for representing the differing connected components for animals, civilians, military dwarves, and others.
Logged