serf IdleInStock in castle when he is supposed to be holder to a building
tlongstretch opened this issue · comments
stonecutter-at-58967-wrong-pos.save.gz
the stonecutter at pos 58967 (in his hut) never comes out to work. Upon investigation, he is in state IdleInStock, with an unexpected animation and counter. If I burn his hut and log his status, he invisibly goes into Escaping Building, Lost, and walks back to castle VERY QUICKLY while still being totally invisible. I think he somehow ended up in wrong state and/or wrong animation/counter which explains why he isn't drawn and moves so quickly (invisibly) back to the castle.
looking at other serfs.. it seems perfectly valid to have animation state 40, counter ~140, and state 1 IdleInStock. I am guessing he issue is this StoneCutter was not placed into StatePlanningStoneCutting and instead was placed in IdleInStock when he entered his hut???
OH, his pos is the CASTLE POS! So the Serf object has pos castle pos, but the Map him in his building. So when the hut is burnt, the map does gets_serfs_related_to pos and sets him to that pos and state?
[serf 13]
animation = 40
counter = 138
owner = 0
pos = 86,234
state = 1
state.inventory = 0
tick = 46068
type = 7
yes, here is his building, it says holder serf index 13
[building 8]
active = 0
burning = 0
constructing = 0
flag = 10
holder = 1
level = 8
military_state = 0
owner = 0
playing_sfx = 0
pos = 87,230
progress = 0
serf_index = 13
serf_request_failed = 0
serf_requested = 0
stock[0].available = 0
stock[0].maximum = 0
stock[0].prio = 0
stock[0].requested = 0
stock[0].type = -1
stock[1].available = 0
stock[1].maximum = 0
stock[1].prio = 0
stock[1].requested = 0
stock[1].type = -1
type = 4
need to add a corruption check to detect if a serf is listed as being at a pos, or holder to a building, that does not match his internal pos
okay the detection works, unfortunately I can't go back in time to see what caused it, maybe it will happen again
saw this again today with a fisherman, when I burnt his hut a generic non-fisherman serf came out. Starting to think this might be a bug where serf index/pointers getting mixed up
saw twice with Foresters. Wondering if it might be related to new pathfinder_freewalking_serf checks. Adding more debugging to track holders
again with a Forester... getting closer...
I think I found the cause and can reproduce at will. see freeserf#521
I think I have a fix in place now in unstable
fixed