Recipe to reproduce the bug:
- 1) on a level with a least one neighbor, add a crate and a bloor door, in that
order (be sure that there are not on-going combats on the level, so that oil or
blood stains are not added *after* the door)
- 2) destroy the crate
- 3) walk to the neighbor level, far away to be sure that the modified level is
no more visible.
- 4) save
- 5) walk back to the modified level
- 6) save - KABOOM
Fixed in svn r5367.
Here is the commit log, that shortly explains the bug:
----------------------------------------------------------
Do not restrain dirty_animated_obstacle_lists() to visible levels only.
This fixes a bug that leads to create and save obstacles with negative index in
a very specific case:
defrag_obstacle_array() is called when a game is saved, and a destroyed object
can be replaced by an animated door. In that case, the type of the element that
was containing the door is set to -1. If the defragged level is a non-visible
neighbor of the current level, then it's animated obstacle list is not dirty and
so the door's old index (whose type is now -1) is used by animate_door() which
can decrement the value of the obstacle type.
----------------------------------------------------------
Also added a protection in animate_door() to avoid to decrement an obstacle if
it's type is not a door type, in svn r5368
|