POS: critical bugs.

[Guest]

Archived from groups: rec.games.roguelike.angband (More info?)

The first is really critical:
There is a segmentation fault when a store sells out its entire stock.
I was stocking up on !Hero and ?Blessing for the final battle with
Morgoth. Fortunately, I was running from inside the debugger, and was
able to force a save from inside the crashed program. (It restarts on
the store entrance.)
I haven't figured out what the bug is. After restocking,
display_inventory() fails with a bad pointer when attempting to display
the first restocked item. This doesn't make a lot of sense, since the
forced file save does work, and shows the new stock on recovery. (The
same thing happens independently of compiler options, so I don't think
it's a compiler bug. I'm running on OSX 10.3.9.)


The second is known: the de-materialization bug where monsters can't
attack you inside the wall (unless they are pass-wall or kill-wall).
This totally screws up game-play for characters with an
immaterialization escape. Either you have to fight from an ASC and
just use immaterialization as an escape, or you end up cheating if you
fight from inside a wall.

 

[Guest]

Archived from groups: rec.games.roguelike.angband (More info?)

On 16 Jul 2005 14:16:08 -0700, "pete mack" <pmac360@hotmail.com>
wrote:

>The first is really critical:
>There is a segmentation fault when a store sells out its entire stock.
>I was stocking up on !Hero and ?Blessing for the final battle with
>Morgoth. Fortunately, I was running from inside the debugger, and was
>able to force a save from inside the crashed program. (It restarts on
>the store entrance.)
>I haven't figured out what the bug is. After restocking,
>display_inventory() fails with a bad pointer when attempting to display
>the first restocked item. This doesn't make a lot of sense, since the
>forced file save does work, and shows the new stock on recovery. (The
>same thing happens independently of compiler options, so I don't think
>it's a compiler bug. I'm running on OSX 10.3.9.)
>
Looking at the code, the routine store_maint(store_num) sets (and
leaves) the static pointer st_ptr pointing to an object on the stack
which goes out of scope when store_maint() exits. When the code tries
to display the new inventory, it uses st_ptr which points to a reused
stack area. It needs to be reset to "&store[store_num]" before
calling display_inventory()

>
>The second is known: the de-materialization bug where monsters can't
>attack you inside the wall (unless they are pass-wall or kill-wall).
>This totally screws up game-play for characters with an
>immaterialization escape. Either you have to fight from an ASC and
>just use immaterialization as an escape, or you end up cheating if you
>fight from inside a wall.

Cam

 

[Guest]

Archived from groups: rec.games.roguelike.angband (More info?)

Cam Moore wrote:
> On 16 Jul 2005 14:16:08 -0700, "pete mack" <pmac360@hotmail.com>
> wrote:
>
> >The first is really critical:
> >There is a segmentation fault when a store sells out its entire stock.
> >I was stocking up on !Hero and ?Blessing for the final battle with
> >Morgoth. Fortunately, I was running from inside the debugger, and was
> >able to force a save from inside the crashed program. (It restarts on
> >the store entrance.)
> >I haven't figured out what the bug is. After restocking,
> >display_inventory() fails with a bad pointer when attempting to display
> >the first restocked item. This doesn't make a lot of sense, since the
> >forced file save does work, and shows the new stock on recovery. (The
> >same thing happens independently of compiler options, so I don't think
> >it's a compiler bug. I'm running on OSX 10.3.9.)
> >
> Looking at the code, the routine store_maint(store_num) sets (and
> leaves) the static pointer st_ptr pointing to an object on the stack
> which goes out of scope when store_maint() exits. When the code tries
> to display the new inventory, it uses st_ptr which points to a reused
> stack area. It needs to be reset to "&store[store_num]" before
> calling display_inventory()

Yep, you got it.