stores in [O] [comp]

I ran into a strange thing with the stores in the current comp. I
dove directly [without leaving the stairs] down to, maybe, 850', then
stairscummed my way back to town. Most of the stores had lots of
repeats. E.g. the weapon shop had 3 spears 1d6 in two separate slots,
on different pages. Obviously, things were not sorted as usual.

Anyone else see anything like this?

I wasn't thinking, killed off the char, and overwrote the savefile.
Sorry about that Bahman. At the time, I thought it was some [O]
weirdness rather than a bug.


Eddie

Bahman Rabii <bahman.RemoveThis@oangband.com> writes:

> Thanks. This has been reported twice now, but I have not been able to
> reproduce it. Very odd.

I looked at the code, and found a possible bug, but I don't think it
is the problem. I am guessing some sort of pointer problem that
overwrote the store counters with random numbers. Then if 5 items got
deleted from the middle from a full store, the last 5 items from
overwriting the store count would be copies of the last 5 legitimate
items.

Anyway, here's what I saw that might be trouble:

In store.c, both home_carry and store_carry have

/* Check existing slots to see if we must "slide" */
for (slot = 0; slot < st_ptr->stock_num; slot++)
{
/* Get that object */
j_ptr = &st_ptr->stock[slot];

/* Objects sort by decreasing type */
if (o_ptr->tval > j_ptr->tval) break;
if (o_ptr->tval < j_ptr->tval) continue;

/* Objects sort by increasing sval */
if (o_ptr->sval < j_ptr->sval) break;
if (o_ptr->sval > j_ptr->sval) continue;

/* Evaluate that slot */
j_value = object_value(j_ptr);

/* Objects sort by decreasing value */
if (value > j_value) break;
if (value < j_value) continue;
}

That's actually pretty dangerous. The store is never sorted. It is
assumed that the items are in sorted order, and works to maintain the
order. The danger is that if things ever get out of order, there is
no re-sort to fix them. It would be better IMO to just add the new
item at the end [if it doesn't merge with an existing item] and
insertionSort. I believe in *guaranteeing* your invariants, even
allowing for the possibility of bugs elsewhere overwriting constant
values like tval or sval, but I digress.

Anyway, it seems that there is a problem with wand stacking. As I
understood it, object_value is usually based on one object, i.e. it
returns the same value for a stack of arrows as for a single arrow.
But for some reason it returns different values for wands/staves with
different numbers of charges. As such, if you have consecutive
entries with the same type of wand because of discounts, buying a wand
could leave the store's list out of order. That could still happen in
rare cases with values depending on the mean number of charges, since
2 wands with 3 charges averaging 1.5 would change to 1 wand with 1 or
2 charges, depending.

I don't see how that could lead to a problem in the alchemist's shop,
so there is probably something else causing trouble. OTOH, the fact
it hasn't been seen in [V] makes me think it might be a wand-stacking
phenomenon since that hasn't been in [V] very long.


Eddie