Allow migrated objects to break on arrival. Added code to obj_delivery to
cause this, along with a flag to keep breakage from occurring. The new
flag isn't used yet, because all the current object migration involve
objects that were moving/dropping. To help make this change, rloco now
returns whether the object was placed or not, so caller can know if an obj
pointer is still valid or not.
Making the breakage messages for MIGR_NEAR_PLAYER objects show up after the
new level is displayed required some effort (rather than while the old level
was still displayed, which was confusing), due to the needs of goto_level.
- obj_delivery now has 2 passes, one for before player arrives, another after,
allowing the two cases to be treated differently
- goto_level calls obj_delivery twice (run_timers is not called twice,
since the run required before the level is displayed will have already run
any timers on migrating object)
- kill_genocided_monsters now kills eggs on the migrating_objs list too
<email deleted> wrote:
> If more monsters fall through a trap door than can fit on the
> level below, when you go down the stairs, you get the following
> message:
> "Program in disorder - perhaps you'd better #quit.
> rloc(): couldn't relocate monster"
> This message seems to appear once for every monster-too-many that
> fell through the hole. I originally found this while
> intentionally completely filling a level with black puddings
> (there was a trap door I didn't know about). I also confirmed it
> in a wiz-mode test using gremlins and water.
[confirmed: moveloop -> deferred_goto -> goto_level ->
losedogs -> mon_arrive -> rloc -> impossible]
This patch:
- causes rloc() to return TRUE if successful,
or FALSE if it wasn't.
- adds code to mon_arrive() in dog.c to deal with
the failed rloc()
- allows the x,y parameters to mkcorpstat() to
be 0,0 in order to trigger random placement of the
corpse on the level
- if you define DEBUG_MIGRATING_MONS when you build cmd.c
then you'll have a debug-mode command #migratemons to
store the number of random monsters that you specify
on the migrating monsters chain.
>More worrying is the fact that applying a figurine over water lets
>the monster wait until its next move before it drowns (giving
>you time to teleport it to safety, or whatever) [...]
>Should there be a minliquid() check as part of make_familiar()?
Applying at the water location next to you was easy. But
applying it at your own location (triggering BY_YOU) could
end up placing the figurine at the far side of the level if
there was lots of water.
Correcting that required the ability to pass a flag from
make_familiar to makemon() telling it to not rule out
water locations as good positions. The flag had to
be passed on down to goodpos() and enexto().
The bulk of this patch is just adding an additional
argument to goodpos() in all of the callers.
If you level teleported while on a sleeping steed, a panic and possibly a
crash would occur. I believe the same would occur by digging a hole. This
was due to keepdogs avoiding keeping sleeping pets. In these cases, it
seems there's no reason for the sleeping steed to _not_ accompany you.
Since other ways of changing level (eg stairs) don't allow this, just added
a check to keepdogs to allow the steed to go with you.
Fix the reported problem of applying a figurine while swallowed
and getting a message about setting the figuring on the ground. Rather
than coming with special messages, just prevent it would activating if
you're swallowed at the time.
Also prevent figurines from creating the 4th erinys or 10th Nazgul.
I'm not sure whether to bother doing similar handling for stone-to-flesh
cast on statues.
The fact that a pet was starving to death got recorded with its
corpse; if that corpse was revived via undead turning, the resulting
monster would immediately starve again if it stayed tame. Similarly,
if one got petrified while nearly starved, reanimating the statue would
produce a starving pet. Make revival and reanimation use the same code
as life-saving, where hunger status gets reset.
Allow starving pets to consume items they wouldn't ordinarily
eat. Carnivores will eat fruits and vegetables--such as they are--
and herbivores will eat assorted rations. Even though eating such
rations doesn't violate vegetarian conduct for the character, horses
would never eat them.
This change should allow players to keep mundane steeds alive
much longer. The new behavior doesn't kick in until the pet has
been classified as starving though; it doesn't affect ones who are
merely hungry.
This also gives the reason why a starving pet has died instead
of just saying "<pet> dies" whenever it starved with hit points left.
Provide more control over message handling for monsters' use
of equipment. This fixes the statue revival problem (inappropriate
feedback when monster puts on speed boots) mentioned in the earlier
"intrinsics of dead monsters" patch.
Duuuh. Of course adding objects already changed the editlevel.
Anyway, here's the fix I was working on. It only matters in a very obscure
situation. (Also, the quest leader still speaks no matter what he's
polymorphed into.)
Incorporate a slightly cleaned up version of <Someone>'s patch to enable a
"pettype:none" startup option that allows one to start the game without a pet.
