With 3.7+ aspirations of improving savefile interoperability between 32-bit
and 64-bit builds, as well as between platforms, it is better to not have
the underlying struct/array content be conditional.
This splits off some of the MAIL code into MAIL_STRUCTURES code. In theory,
since MAIL_STRUCTURES is unconditionally included, the macro could
just go away and leave that code unconditional, but this commit doesn't
go that far.
Mimic-as-slime_mold needs to keep track of the fruit index the same
way that mimic-as-corpse keeps track of corpse's monster type. The
mimic description was changing (for '/' and ';' feedback) whenever
the player assiged a new fruit name.
That wasn't noticeable when applying a stethoscope because
mimic-as-slime_mold always yielded "that fruit is really a mimic".
Change it to report the fruit's type instead of generic "fruit".
If mksobj() was told to initialize the object it's creating and the
object class was something it didn't understand, it would issue a
warning and return Null. But an unknown object class is a severe
internal error and very few callers were prepared to deal with a
Null result, so change mksobj() to panic instead. Also eliminate the
few attempts to deal with Null result that are present in mkobj.c;
I didn't go looking elsewhere.
Sword given to angels used obj->spe = max(obj->spe, rn2(4)) [except
using a temporary to sanely work with max() macro]. But the obj was
explicitly created as no-init, so obj->spe was always 0 and the max()
was pointless. Shield given to angels was manipulating bless/curse
state directly instead of using the functions intended for that, a
no-no and also pointless to be clearing 'cursed' for a no-init item.
Mace for priests had useless handling for object creation failure.
Object creation failure could only happen if the mksobj() call had a
valid entry in objects[] (or out of bounds access that didn't crash)
for an object class that it doesn't know how to handle. That can't
happen unless somebody screws up big time. If it ever did happen,
it would have produced a memory leak.
Report #H9243 misinterpreted W_WEAPON as W_WEP and attributed a
hypothetical ball and chain sanity checking problem to that.
Rename the former to W_WEAPONS to emphasize that it includes
alternate/secondary weapon and quivered stack as well as wielded
weapon.
Another one which has been around for a while. When merging two
globs, the result is partly eaten if either (or both) of them was
partly eaten, not just when the one that's going to stick around as
the combined glob already was.
Changing an inventory item's bknown flag wasn't followed by a call to
update_inventory() in many circumstances, so information which should
have appeared wasn't showing up until some other event triggered an
update.
Verify that objects with the globby bit set are actually glob objects,
that their quantity is 1, and that their weight at least superficially
makes sense.
When place_object() puts a non-boulder underneath a boulder, make it
put the non-boulder under all the boulders there rather than just under
the topmost one. Otherwise the map display will show the non-boulder
rather than the 2nd boulder if the top boulder gets moved away by some
means other than pushing. (Pushing explicitly brings lower boulder to
top of pile in order to try to push it next.)
Reproduce by: wish for boulder--it will drop. Drop something else--
the something-else will end up under the boulder. Repeat. The second
boulder will be on top but the second something-else will be next in
the pile, above the first boulder. Now polymorph into a giant and pick
up the first boulder, then move away from that spot. Map will show
second something-else instead of the remaining boulder.
This fairly simple fix should work reliably on new games since boulders
will end up being consecutive on the top of piles. For old games,
boulders after the topmost could be anywhere and still yield a display
glitch, but since that's all the problem is (I hope...), we ought to
be able to live with that until old games eventually go away.
[A map display glitch doesn't explain a corrupted 'uball' so this fix
doesn't solve that.]
Lock context wasn't being cleared if it was for a container and that
container got destroyed. Case discovered was forcelock() ->
breakchestlock() -> delobj() (sometimes the container is destroyed
rather than just breaking its lock) followed by #wizmakemap (replace
current level) and maybe_reset_pick() trying to check whether
xlock.box was being carried. But being interrupted, destroying the
container or dropping it down a hole to ship it to another level, then
attempting to resume picking the lock would also find a stale pointer.
'struct obj' contains a union of mutually exclusive pointers, but
removing an obj from a list wasn't clearing whichever one had been
in use. If something is removed from a monster's inventory, clear
the object's pointer back to that monster; if something is removed
from a container, clear the object's pointer back to that container;
and whenever something is removed from the floor, clear the pointer
to the object which followed it at that floor location.
I misread part of the original code and the revision introduced a bug
based on that. obj->o_id price variations are used for all types of
non-IDed items, not just non-glass gems.
Player came across a stack of 2 gray stones in a shop and kicked one.
That one ended up with a different (in his case, lower) price once it
was separate. This behavior only applies to non-glass gems which add
a price variation derived from internal ID (obj->o_id) number. Make
splitting stacks always yield the same price per item in the new stack
as was being charged in the old stack by choosing a similar o_id. Do
it for all splits (that can vary price by ID, so just non-glass gems),
not just ones performed inside shops.
He picked up the lower priced one and dropped it back on the original
higher priced one; the combined stack took on the lower price. That
will no longer happen if they come from splitting a stack, but this
fix doesn't address merging with different prices when they start out
as separate stacks. (Unpaid items won't merge in inventory if prices
are different, but shop-owned items will merge on floor.)
Dropping an existing fragile item while levitating will usually
break it. Getting a new wished-for fragile item and dropping it
because of fumbling or overfull inventory never would.
Some callers of hold_another_object() held on to its return value,
others discarded that. That return value was unsafe if the item
was dropped and fell down a hole (or broke [after this change]).
Return Null if we can't be sure of the value, and make sure all
callers are prepared to deal with Null.
