Viewing Issue Advanced Details Jump to Notes ] Wiki ] View Simple ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007855 [DCSS] Bug Report minor have not tried 2013-12-12 03:39 2013-12-12 07:58
Reporter elliptic View Status public  
Assigned To neil
Priority normal Resolution done Local or Remote Remote
Status resolved   Operating System CSZO
Projection none   Console or Tiles Console
ETA none Fixed in Branch 0.13 ancient branch Product Branch 0.14 ancient branch
  Product Version
Summary 0007855: Autoexplore is stuck.
Description Autoexplore refuses to continue. I am on top of a stack of items, including some chunks that would burden me; it should be prompting me to continue exploring, but instead it is just printing "Partly explored, can't reach some items and places." (with no exclusions on the map). Savefile: [^]
Steps To Reproduce
Additional Information
Tags No tags attached.
Attached Files

- Relationships
has duplicate 0006386resolvedneil autoexplore gets stuck; maybe involving useless {=g} items 

-  Notes
neil (administrator)
2013-12-12 04:00
edited on: 2013-12-12 04:00

I get the same thing regardless of autosacrifice, but turning off pickup with ctrl-a does in fact "fix" it.

neil (administrator)
2013-12-12 04:43
edited on: 2013-12-12 05:27

Hmm... so in _explore_find_target square it chooses your pos as whereto (the next destination for explore) because of greed. That's fine, but pathfind has set the travel_point_distance to that square to 0. In fact, only four squares on the entire map have a nonzero distance: the ones to your NE, SW, SW twice, and SW then S.

In a game where this doesn't occur, the travel_point_distance to the player's position is 2. Likewise, if in your save I move one square NE then move back, the pathfind results look reasonable (and it comes unstuck).

Edit: it seems to have something to do with the unexplored cell two squares to the east. That causes path_examine_point to return true for the northeast cell, meaning it decides it has a destination before actually pathfinding to the player's location. But greedy_place is already set to the player's position by that point (and is closer than unexplored_place), so explore_target returns a cell with a travel_point_distance of 0 (unreached), which makes _explore_find_target square reject the location.

neil (administrator)
2013-12-12 05:53

I can reproduce this reliably with the following setup, where your position (@) has an autopickup item and the position marked ? is unexplored. It doesn't matter whether the item can be picked up, just that it hasn't yet been.
neil (administrator)
2013-12-12 06:11
edited on: 2013-12-12 07:59

Fixed in trunk (0.14-a0-1444-g21dc12d) and stable (0.13.1-16-g807a372).

- Issue History
Date Modified Username Field Change
2013-12-12 03:39 elliptic New Issue
2013-12-12 04:00 neil Note Added: 0024705
2013-12-12 04:00 neil Note Edited: 0024705
2013-12-12 04:43 neil Note Added: 0024706
2013-12-12 05:27 neil Note Edited: 0024706
2013-12-12 05:27 neil Note Edited: 0024706
2013-12-12 05:53 neil Note Added: 0024708
2013-12-12 06:11 neil Note Added: 0024711
2013-12-12 06:11 neil Status new => resolved
2013-12-12 06:11 neil Fixed in Branch => 0.14 development branch
2013-12-12 06:11 neil Resolution open => done
2013-12-12 06:11 neil Assigned To => neil
2013-12-12 07:03 neil Relationship added has duplicate 0006386
2013-12-12 07:58 neil Fixed in Branch 0.14 development branch => 0.13 stable branch
2013-12-12 07:59 neil Note Edited: 0024711

Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker