silver wands followup

There was code higher up that could destroy the obj,
so this eliminates any risk of trying to dereference a
bad pointer in the deferred silver message by saving
a copy of the name earlier on.

B01001 - bold menu_heading support
Not really a bug, but when TEXTCOLOR is defined, wintty can display menu
headings is bold upon request, but didn't.

silver wands

From the newsgroup:
> <email deleted> (<Someone>)
> Newsgroups: rec.games.roguelike.nethack
> Subject: Question: Why don't silver wands give silver damage?
> Date: 9 Nov 2003 09:18:50 -0800
> Organization: http://groups.google.com
> Lines: 7
> <email deleted>
>
> I had a character cornered by a werejackal the other day.  I'm not too
> bothered by the death but why didn't the silver wand he desperately
> wielded in his final moments do extra damage?  I mean, silver rings do
> so why not wands?  I realise this is a pretty minor problem since not
> that many people will be going around wielding wands, but still.
>
>  ~<Someone>

There was a code path for objects such as wands that avoided
all the silver checks. Now fixed.

flag adjustment followup (trunk only)

flag adjustments (trunk only)

Move all system or port specific flags to sysflags which is used only if
SYSFLAGS is defined, and leave everything else in flags unconditional.

Acknowledge Schroedinger's cat (trunk only)

Acknowledge Schroedinger's cat at end of game.
- determine cat's status:
      - give points for the animal which accompanied
        you.
     or
     - include dead cat in the box contents.

Schroedinger's cat is the only ordinary creature
that could actually ascend with you.

This patch doesn't deal with any supernatural creatures
including:
 - djinn in bottles
 - ghosts in bottles

POSIX compliance for get_saved_games().

mon name buffers

Follow suit with what <Someone> did for the object name buffers,
so that this sort of statement can work correctly:

pline("%s hits %s.", Monnam(mtmp), mon_nam(mtmp2));

U716 - trapped monster switching weapons
A trapped monster with one step between you and the monster (@.@) would
repeatedly switch between a ranged and hand-to-hand weapon if carrying both.
Since the monster switches each turn, it will not make ranged attacks.
Modified the test in dochug to prefer a ranged weapon in this case.

wiztele follow-up

U716 - trapped monster switching weapons
A trapped monster with one step between you and the monster (@.@) would
repeatedly switch between a ranged and hand-to-hand weapon if carrying both.
Since the monster switches each turn, it will not make ranged attacks.
Modified the test in dochug to prefer a ranged weapon in this case.

wizmode level teleport

<Someone> wrote:
> The new ^V wizmode menu is nice, but it is rather misleading; most of
> the levels it lists are "you can't get there from here". Would it be
> possible either to make it only list levels that can be reached
> directly, or alternatively to allow you to reach the ones you
> ordinarily couldn't (maybe by forcefully changing u.uz.dnum to yoink
> you into the right branch, and even summarily issuing you with an
> Amulet if you ask to teleport to the endgame).[...]; being able to bamf
> quickly to Minetown from DL 1, for example, would be damn useful in > testing stuff.

Allow fairly free roaming of the dungeon via the wizard mode teleport menu.

<Someone> wrote:
> The new ^V wizmode menu is nice, but it is rather misleading; most of
> the levels it lists are "you can't get there from here". Would it be
> possible either to make it only list levels that can be reached
> directly, or alternatively to allow you to reach the ones you
> ordinarily couldn't (maybe by forcefully changing u.uz.dnum to yoink
> you into the right branch, and even summarily issuing you with an
> Amulet if you ask to teleport to the endgame).[...]; being able to bamf
> quickly to Minetown from DL 1, for example, would be damn useful in > testing stuff.

Allow fairly free roaming of the dungeon via the wizard mode teleport menu.

win32tty hung NetHack fix

If a Key-down event didn't meet the expected criteria,
the event was ignored in the "peek" loop, but it was
never removed from the input queue either, so it
remained at the top of the queue.

It isn't clear if this fixes the dedicated arrow keys
hanging, but if those were resulting in strange
event values too, it just might.

B01001 fix: corpse grammar

<Someone> wrote:
> You start bashing monsters with your 2 cockatrice corpses.
> You hit the foo with the cockatrice corpse (note singular).
> The foo is slowing down. The foo turns to stone.
> Also: Your cockatrice corpses rots away.

It appears that vtense() has a problem recognizing "corpses"
as plural.  This doesn't fix that, it just switches to using
otense() in this particular case.

sleeping shopkeeper
Pat verified something I had wondered about, that various tests of mcanmove
in shk.c should have also been testing mcanmove.  There may well be other
tests of mcanmove in other files that need fixing.

debug mode monster creation [trunk only]

Allow '*' with control-g to create a random monster species,
or several different monster species if a multi count was specified
on the control-g command.

sleeping monster responding to attacks
when msleeping is set, mcanmove is not cleared.  mcanmove applies only to
mfrozen.  So, mattackm needs to test both mcanmove and msleeping.
mattackm will not wake the defender if the attack misses.

U719:  grayswandir and exploding black lights

<email deleted> wrote:
> When wielding greyswander and a black light explodes, the
> message is still "You are freaked by a blast of kaleidoscopic
> light!" giving no indication that you are immune to
> hallucination. Maybe something like "You see a blast of color,
> but seem unaffected" would be more appropriate?

return the changed status back to the caller from
make_hallucinated().

healer follow-up bit (trunk only)

There is a new Deaf attrib to consider in the trunk.

ce fix (from <Someone>)

set interject() and interject_assistance() to NOP for Windows CE port.

display bit for spellbook gift (trunk only)

     From the newsgroup:  when invisible and unable to see invisible,
if successful prayer results in being given a spellbook you'll get the
message "an object appears at your feet" but the spellbook won't show on
the map.  Add a newsym() to force its location to be updated.  (I didn't
try to figure out why spellbooks use place_object() when all other divine
gifts use dropy() but that's why only this case has the display glitch.)

     This also fixes up the message vs map update sequencing for a couple
of other "at your feet" cases so that all of them use the same ordering:
first the message is given, then the object drops.

[Timing is the only reason not to put this simple change into 3.4.3.]

tin variety followup 2 (trunk only)

tin variety followup (trunk only)

tin variety (trunk only)

- store the variety of tin at tin creation time
  rather than at tin-opening time (as a negative
  value in spe just as homemade was; spinach
   is still spe 1)

Allow wishing for a particular variety of tin
from the tin variety list:
"deep fried", "boiled","broiled","candied"
"dried", "french fried", "homemade"
"pickled", "pureed", "rotten", "sauteed"
"smoked", "soup made from", "stir fried",
"szechuan"
Example: "tin of soup made from orc"

non-debug player could randomly fail on the
variety specification 1 in 4 times

win32tty: fix extended commands

The autocompletion was working, but you couldn't tell
because the text was overwritten with blanks.  This was
a recent glitch created during fix for other cursor problems.

crash on hangup following
restore the exit_nhwindows call, but in the right place.  without this,
the window inteface doesn't get a chance o shut down.

crash on hangup
the message history saver needs the windows to stick around until save
is completed.  This usually the case, but end_of_input() was calling
exit_nhwindows prematurely.  This is actually an old bug (calling it early,
but wasn't harmful until other recent changes).

saving msg history glitch (trunk only)

<Someone> discovered that it is possible to
have wins[WIN_MESSAGE] be null during
a hangup, not sure why yet.

Put a guard in to prevent de-referencing a null pointer.

more win32tty clean-up

This brings things much closer to correct operation (I hope).
- The shift to only moving the cursor on input (<Someone>'s
changes) had a lot of complications, among them was
that sometimes, there is no more input. When the program was
exiting, or bombing the cursor synch never got done, so the
final messages could end up strewn any place the cursor
happened to be dwelling.

- There were two competing output systems in use: the
wintty stuff for the game, and the msmsg and error stuff
used by the sys/share/pcsys, sys/share/pctty, and
sys/share/pcunix routines.  Those were meant to mimic
output to stdout, where stuff just got sent to a sequential
display.  Over time, there were calls mixed in that depended
on the cursor tracked stuff from the core game, so you
really couldn't be sure where things were going to display.
It wasn't as much of an issue before, because the cursor
really did get moved around as expected. Everything
now ends up in the same output system.

- I even found a use of the real putchar() because
sys/share/pcunix didn't #include wintty.h the same
as the other files, and the macro never got defined.
Who knows where that character was being put -
the game certainly couldn't track it.

While everything I knew to be wrong yesterday is
now working, there may be some other glitches
lurking that I haven't discovered yet.

Please: test, test, test.

patchevel.h comment

class differentiation followup

> Healers pick up on the fact that a wand of undead turning
> revived a creature.
...if a vital piece of code isn't accidentally left out

class differentiation bit (trunk only)

Healers pick up on the fact that a wand of undead turning
revived a creature.

changing level workaround (C341-13)
Use a new flush_screen(-1) call to toggle 3rd screen update in goto_level.
This keeps the 3rd screen state unchanged, no matter what happens at higher
levels, ensures the map window cursor stays on the hero, ensures the
hero's showrace colors remains bright white, and so on.

handheld lockfile left around fix (from <Someone>)

patchlevel.h sync between branch and core

win32gui build fix (from <Someone>)

<Someone> wrote:
> Using the MCVS IDE I couldn't compile NetHack any longer, due to a
> misplaced #endif and a library not included in the DSP file.
> Here's a patch for both problems for 3.5.0.
> The 3.4.x verison only suffered from the first problem. Patch also
> attached.

more win32tty fixes

There were still some significant startup message problems
with win32tty.

I've spent a lot of time in the debugger tracing through them all.
I think I've got them all worked out now, certainly the ones that
I was aware of.  There may be some I haven't discovered.
Testing welcomed of course!

This patch also attempts to diagnose the error where someone tries
to execute NetHack directly out of a zip file, and provide
them with a (hopefully) helpful message similar to what we
might end up telling them if they wrote in.  If you want
to test that part, you can comment out the line in the
Makefile that adds "dungeon" to nhdat, and delete the nhdat
in your binary and src directories, and "make install".
Then add the value of your TEMP environment variable as a
DATADIR statement in defaults.nh (here's mine):
DATADIR=C:\DOCUME~1\ALLISO~1\LOCALS~1\Temp
The diagnostic code engages if the game fails to open
dungeon. It then checks to see if it the game dir is the
TEMP directory for your system, and if so it prints the
message.

fixes catchup

win32tty: startup msg cleanup

the win32 cursor restriction stuff messed up any
messages displayed during abnormal start conditions
where the window system never got initialized properly.
among them:
- messages relating to lock files or games in progress
- dungeon errors
- early panic messages

starting pet identification
make it possible for the code to recognize your starting pet throughout the
game via is_starting_pet(mon) macro.

were followup

"Rat's appear" -> "Rats appear"
Use makeplural rather than s_suffix.

starting pet identification

Make it possible to identify your starting pet throughout the game
via is_starting_pet(mon) macro.

cvsfix

My cvs tree had the correct code. When I did a cvs update
it didn't pull anything down. When I deleted the include/extern.h
file from my cvs tree, and did an update with the "get the clean copy"
switch, it pulled down an extern.h that was indeed missing the
prototype.  In all cases my local cvs reported that it was 1.130.
I applied the prototype change to the cvs copy, did a cvs diff
to ensure nothing else was out of sync and re-committed.

stone to flesh bit
<Someone> suggested and I agree (mostly, if you're a Monk poly'd to a
strict carnivore, I think it should still smell delicious):
> "You smell the odor of meat." (if herbivorous)
> "You smell a delicious smell." (otherwise)
> I think that if your character is a monk or still veg(itari)an, you should
> also get the first message. Even if you're not intentionally vegitarian,
> the first message is still appropriate.

another conflict abuse
Reported a really long time ago (June 2001) by <Someone>:
 - stand on the upstairs and engrave Elbereth with a /oFire
 - create Demogorgon and e.g. a tame dragon
 - cause conflict
 - Dragon will kill Demogorgon and Demogorgon will never ever attack Dragon.
All monsters could still attack Demogorgon without response via fightm().
Modified fightm() to include a bit of code in m_move and dog_move, allowing
response to an attack.  Testing this in action, Demogorgon still usually
did things detrimental to the player, mostly summoning nasty monsters.

buglist: polymorphed into quantum mechanic
<email deleted> wrote:
- When polymorphed into a quantum mechanic, it is possible to jump in
  the water on a no teleport level and instinctively teleport.
- When an engulfing monster is teleported away on a no teleport level
  when the hero is polymorphed into a quantum mechanic, there is no
  message displayed like "You are no longer engulfed!" because
  u_teleport_mon is passed FALSE for give feedback. But maybe this is
  for a good reason...

<Someone>'s were_summon rules

>Hemmed in by one invisible wererat?
><Someone>: Should I feel hemmed in if I can see that a wererat summons
>zero rats? Can the invisible wererat hem me in all by itself? And
>even if it had summoned anything, wouldn't a different message had
>been clearer (for isntance, "Rats appear around you!"); after all,
>I could see *what* was hemming me in.
>I agree that the current messages (and even the ones aspired to by the
>comment) are non-ideal.

<Someone>'s suggested set-up:
Seen summoner, seen help    : "The wererat summons help!"
Seen summoner, unseen help: "The wererat summons help! You feel hemmed in."
Seen summoner, no help: "The wererat summons help! But none comes."
Unseen summoner, seen help: "(A rat appears|Rats appear) from
nowhere!"
Unseen summoner, unseen help: "You feel hemmed in."
Unseen summoner, no help: No message.

charging tweak

     Some newsgroup discussion recently pointed out that source comments
for scrolls of charging didn't match the actual charge increase performed
by that magic.  This bumps the values a little bit
 (uncursed: comment said 5 to 15, actual amount was 10 to 14, now 10 to 20;
  blessed: comment said 10 to 25, actual amount was 16 to 25, now 15 to 30)
and adjusts the comments to match the code.

weapon skill tweak

     Barbarians start with either a two-handed sword and an ordinary axe
or a battle-axe and a short sword.  The latter combination was the only
one among all the roles where the player couldn't enhance skills for
starting weapons to expert.  Fix that by allowing barbarians to become
expert in short swords; reduce potential capability with pick-axe/mattock
from expert down to skilled to compensate for the increase.

     This also addresses an earlier complaint that monks are no better in
martial arts than samurai even though the latter have lots of choices for
good weapon skills.  Reduce the martial arts limit on samurai from grand
master to just master; likewise with bare-handed combat for barbarians
and cavemen.  In this case there didn't seem to be any need to bump the
limit on anything else as compensation.

     I still think non-rogues shouldn't be allowed to become expert in
daggers (which means that ranger and valkyrie starting gear would need
to change slightly) due to how powerful throwing them is, but I haven't
included that change here.

     For the skills which have lower upper limits than before, existing
characters who have #enhanced their skills high enough with the previous
code will retain their higher-than-max skill ranking with the new code.
Characters who have exercised enough to advance to the old max but
haven't done so yet will be limited to the new max.

inappropriate lit_corridor check
To reproduce: disable lit_corridor, enter a corridor, read a scroll of
light, then read a cursed scroll of light.  The corridor won't darken again.
A test of flags.lit_corridor in newsym was at fault.  I'm guessing this was
never noticed because lit_corridor is on by default on Windows and the
default lit and unlit corridor symbols are the same on most other platforms.

lex update

     This is a case where a one-line change to the scanner source produces
a large diff in the generated C code.

Half_physical_damage 08

missed a spot

support engraving in blood in special level files
the file format and sp_lev.c supported it, but the level parser didn't

buglist: cutting Shopkeeper the long worm
Cutting a shopkeeper poly'd as a long worm would generate strange messages
and could result in a crash.  cutworm didn't deal with all the intricacies
of duplicating a monster.   Fixed by changing cutworm() to use clone_mon()
to do most of its dirty work.  It seems to me that without this change,
cutting a tame long worm could also have similar bad effects.
Other side effects of this change:
- clone_mon now takes x,y coordinates, 0,0 results in previous behavior
- clone_mon no longer always makes cloned monsters tame/peaceful if player
  caused the clone, using the same formula previously in cutworm.  Someone
  else may wish to tweak this for gremlins.
- clone_mon will christen the new mon with the old shopkeeper's name, even
  though clones are never shopkeepers (game can't handle 2 for a shop)
- cutworm can now be called during conflict or pet combat, although I
  added no such calls (yet)

extra control characters in panic messages
I noticed a few panic messages contained newlines, and one included a naked
carriage return.  panic() adds a newline itself, and also generally ensures
the message will be on a new line (the initial "oops" ensures the message
itself will be on a new lines).  This patch removes the unneeded characters.

gcc warning bit

Half_physical_damage 07

It is not physical damage if:
1. it already qualifies for some other special type of damage
   for which a special resistance already exists in the game
   including: cold, fire, shock, and acid. Note that fire is
   extended to include all forms of burning, even boiling water
   since that is already dealt with by fire resistance, and in
   most or all cases is caused by fire.
2. it doesn't leave a mark. Marks include destruction of, or
   damage to, an internal organ (including the brain),
   lacerations, bruises, crushed body parts, bleeding.

Current exceptions to the rule (already existing):
- holy water burning chaotic ("it burns like acid") is physical damage.
- unholy water burning lawful is physical damage.

Half_physical_damage 06

- [fixed in trunk] Alchemical explosion
- [fixed in trunk] Artifacts' blasting
- [fixed in trunk] Boiling/freezing potions
- [fixed in trunk] Chest/door/tin traps
- [fixed in trunk] Falling rocks/boulders (trap, digging, scroll of earth)
- [fixed in trunk] Mixing water and acid
- [fixed in trunk] Thrown potion (acid)

This is my last patch on this today.

Half_physical_damage 05

- [fixed in trunk] Jumping/Newton's-Thirding into something solid
- [fixed in trunk] Being hit by Mjollnir on the return
- [fixed in trunk] Contaminated or boiling water from a sink
- [fixed in trunk] Falling on a sink while levitating
- [fixed in trunk, fire only] Any passive attack
- [fixed in trunk] Zapping yourself with a wand, horn or spell
- [fixed in trunk] Burning (un)holy water
- [fixed in trunk] Thrown potion (bottle)
- [fixed in trunk] Bumping head on ceiling by cursed levitation
- [fixed in trunk] Exploding rings and wands (under all circumstances)
- [fixed in trunk] Stinking cloud damage
- [fixed in trunk] Sitting in a spiked pit, in lava
- [fixed in trunk] Exploding spellbooks
- [fixed in trunk] Falling off or failing to mount a steed
- [fixed in trunk] Falling into a (spiked) pit
- [fixed in trunk] Land mine explosion
- [fixed in trunk] Fire traps

Half_physical_damage 04

- [fixed in trunk] iron-ball-pulling yourself out of a bear trap
- [fixed in trunk] Hitting your foot with a bullwhip
- [fixed in trunk] Hooking yourself with a grappling hook
- [fixed in trunk] Being thwacked by an iron ball chained to you
- [fixed in trunk] A crystal ball exploding on being applied
- [fixed in trunk] Hitting yourself with your pick-axe
- [fixed in trunk] Molten lava (entering or being splashed)
- [fixed in trunk] Getting squished in a pit under a boulder
- [fixed in trunk] Kicking something that makes you go "Ouch!"

Half_physical_damage 03

- fish out of water

pets getting "stuck" trying to reach inaccessible objects
Incorporate a slightly modified version of a patch submitted by <Someone> back in June.  The basic problem, which I noticed again this past
weekend, is that pets with a high apport value can still try to get to
objects when there's no path to the object.  The patch extends the
can_reach_food function to be used for any object, renaming it to
can_reach_location, and adds a could_reach_item function for doing point
checks.  This also removes any chance of a pet dragon, for example, eating
something underwater.

Half_physical_damage 2

Another batch of missing Half_physical_damage checks
from the list provided by <Someone>:
- Scrolls of fire (!confused)
- Broken wands
- Splattered burning oil from thrown potion
- Dipping a lit lamp into a potion of oil
- Scrolls of fire (confused, didn't bother with non-confused)
- Being caught in a fireball

Adds a macro Maybe_Half_Phys to assist.

U704 - creating unappropriate hell random monsters
When changing levels, the state of rndmonst() is reset, causing the monster
choices to be recalculated.  However, the frequency counts for initial
uncommon() monsters were never cleared.  Thus, if the first non-extinct
monster were a hell monster, and you returned to the main dungeon, the hell
monster will remain in the list and could be selected.

win32tty hangs if you ^C at "Who are you?"

From Newsgroups: rec.games.roguelike.nethack :
> <email deleted>
> Subject: question for windows tty users
>
> I am trying to hunt down a bug, and want to know if I have
> encountered another one of those bizarre "features" that only
> occur on my computer (I seem to get a lot of them).
>
> I can reproduce this bug, or whatever it is, in the official
> Windows binary like this: Start the tty version of NetHack by
> double clicking on the program. You won't see the bug if you
> start it from the command line. When the game asks, "Who are
> you?" press ^C. NetHack will respond with "^C abort. Hit
> <Enter> to end," and then it hangs. Pressing Enter does
> nothing, and the program does not end.
>
> Can anybody else reproduce this behaviour? Thanks in advance.
>
> -- <Someone>

win32tty hangs if you ^C at "Who are you?"

From Newsgroups: rec.games.roguelike.nethack :
> <email deleted>
> Subject: question for windows tty users
>
> I am trying to hunt down a bug, and want to know if I have
> encountered another one of those bizarre "features" that only
> occur on my computer (I seem to get a lot of them).
>
> I can reproduce this bug, or whatever it is, in the official
> Windows binary like this: Start the tty version of NetHack by
> double clicking on the program. You won't see the bug if you
> start it from the command line. When the game asks, "Who are
> you?" press ^C. NetHack will respond with "^C abort. Hit
> <Enter> to end," and then it hangs. Pressing Enter does
> nothing, and the program does not end.
>
> Can anybody else reproduce this behaviour? Thanks in advance.
>
> -- <Someone>

win32 acknowledgement bit

win32 dep

some lint cleanup

     Using
gcc -Wall -Wshadow -Wpointer-arith -Wwrite-strings \
    -Wmissing-braces -Wmissing-prototypes
with an old version of gcc.

mhitu.c: In function `hitmu':
mhitu.c:1176: warning: declaration of `buf' shadows previous local
options.c: In function `special_handling':
options.c:2712: warning: initialization discards `const' from pointer target type
options.c:2745: warning: initialization discards `const' from pointer target typ
trap.c: In function `dotrap':
trap.c:1111: warning: `saddle' might be used uninitialized in this function

The first one is no longer present in the trunk code.  The last one is
bogus as its wishy-washy wording suggests.

old bug report: unchanging iron golem still rehumanizes
Calling rehumanize directly when u.mh > 0 doesn't consider Unchanging
(perhaps it should?).  But, it's probably better to call losehp anyway.
Also, part of a buglist item: .5PD didn't affect rust trap damage on iron golem

vms catchup

1) filename manipulation during restore
2) hangup handling in low level input routine
3) Makefile dependencies
4) version number update

U453 and buglist item - travel command updates
I wrote to the devteam early last week:
> Given my understanding of travel, it's supposed to be somewhat intelligent,
> and "convenient", and should, therefore avoid walking into water, lava,
> traps, or other things that distant movement would avoid, even if you're
> right next it.  Unless...  the travel destination is the "bad" location
> next to you when the travel starts.
To that end...
- add a context (iflags in 3.4.3 to maintain savefile compat) flag to
differenciate the first travel step from later steps, to allow the
detection of the final sentence, above.
- several changes to set/reset the travel1 flag as needed
- add code to findtravelpath to treat the first step specially if it's
the only step, allowing forced travel into a "bad" location
- correct the "don't travel over traps" code, which was getting confused
because hero's starting location was being avoided
- add code to avoid traveling into water and lava, duplicating
checks used for non-travel running
- fix some strange "guess" travel behavior: avoid zigzag paths when there's
a more direct path (even though the number of moves is the same)
- trunk change adds a new DISP_ALL tmp_at type, and uses it in some debug
code for travel, debug changes not added to the 3.4.3 branch

3.4.3 update
update the linux README

unix depend update
trunk needs a new dependency on context.h

unix depend update
update the unix 'make depend' output in both branches.

gnome does not like ^C
This hack simply causes ^C to be ignored completely by the gnome interface.
Gnome really cannot handle interrupts, and the window port interface does
not currently provide a way for the gnome interface to just quit.  Allowing
the gnome interface to prompt would require a complete overhall to the the
way window ports work.

another bit

follow-up to previous bit

more buglist crystal ball detection

<Someone> wrote:
- If I set the 'boulder' option, shouldn't I be able to give the
  symbol I define for them at the crystal ball "object or
  monster symbol" prompt and have it work?
- Could ']' be added as a synonym for 'm', as with genocide?
- set boulder symbol to '3'; use '/' or ';' to examine a
  boulder. Result is "unknown creature causing you disquiet
  co-located with a boulder" even though there's no warning
  glyph '3' there.

bit

triggered from newsgroup post:
> ""For you , esteemed lady; only 10 for this large shield." k - a
> large shield (unpaid, 10 zorkmids).
> To what level do you want to teleport? 0
> Go to Nowhere. Are you sure? [ynq] (q) y
> You scream in agony as your body begins to warp... You cease to
> exist.
> Die? [yn] (n) y
> Bayburt comes and takes all your possessions."
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> How? He teleported to Nowhere?

Leave no doubt that your possessions did not go with you...

crystal balls and space key

Another buglist entry.

<Someone> wrote:
- There appears to be no way to detect ghosts-and-shades; the
  space key just "Never mind"s. (Not that they'd be particularly
  visible on the resulting screen under ASCII, unless you've
  changed the 'monsters' option.)

Allow space; display results in inverse using detected_mon_to_glyph()

crystal balls and '~'

<Someone> wrote:
- You currently appear to be able to specify '~' and have it try
  to detect monsters (though it won't detect any long worms)

Show the entire worm when specifying either '~' or 'w' now.

breaking migrated objects
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

> - When polymorphed into a flying creature and being grabbed
> over the water, then polymorphed into a non-flying creature
> leaves you standing on the water (you can kill the creature
> too and you're still on the water when you shouldn't be).
> - When floating from levitation over water and being held and
> removing levitation, you will fall into the water and drown or
> crawl back onto land. If you crawl back onto land you're no
> longer being held.
> The first situation seems to be a bug, the second a possible
> exploit. Both situations don't seem very correct, if you're
> being held it seems you should not fall into the water/lava
> until you are no longer being held. [patch contributed] It
> will keep the hero held up on over the water until released if
> his size is smaller than or equal to the size of the monster
> holding him. [<email deleted>, patch
> supplied]
>

A recent patch ensured that you ended up in the water when
polymorphed.

This patch is less ambitious than <Someone>'s
contribution, where he actually had the monster hold you up.
Perhaps that can be tackled for the trunk later.

buglist: Vlad can turn to flee and be paralyzed at the same time

This is a cop-out in that it just suppresses the message.

debian bug #23229 - save file permissions
Use fqname buffer 1 for restoring the save file (just like save does when
creating it) so the value won't change out from under the code in unixmain.
- Also moved a tty-specific hack in docompress_file that was causing
the 'y' response to the "keep the save file" prompt to be echoed twice.

from <Someone>'s list: destroy wand of digging

20000922    Water should flow into pits from broken WoD, or DoE.

This addresses the Wand of Digging part, but does not
do anything about Drum of Earthquake.

eating amulet of unchanging redux
To keep this from growing beyond this targeted change, make eating an
amulet of unchanging "un"change you, unless you're also wearing one.

trunk compilation followup to iron changes

more patch cleanup

dipping non-weapon iron in fountain follow-up patch correction

dipping non-weapon iron in fountain

<email deleted> wrote:
> Non-weapon iron items don't appear to rust if #dipped in a fountain.

Fixed. If something does get rusted, its a 50/50 chance whether other
fountain effects take place on the item afterwards.

win32tty color fix

fix by <Someone>, updated by <Someone> on r.g.r.n.

changes the colours of the windows tty port so that blue and
bright blue, and cyan and bright cyan are distinguishable. The chief
benefit of this is that floating eyes no longer look like shocking
spheres.

debian bug #154629 followup
further testing found a trivial bug

debian bug #154629 - extended commands in gnome front end
Not all of the extended commands worked in the gnome interface because
'#' just caused the next character to be treated as a meta character (this
was a hack I added a while back when none of the extended commands worked).
Resolved by finally adding an extended command menu to the gnome interface.
- updated some formatting so I could read the code
- fixed startup player selection menus so accelerators work
- added necessary calls to make sure selected menu item is visible
- also removed some dead code

additional gnome SAFERHANGUP changes
Found more places where gnome interface wasn't cleaning up.

ice followup

Ensure that we don't start a timer on ice that
the player or a monster didn't create when
zapping existing ice.

newline

additional X11 SAFERHANGUP changes
While messing around with window closure events, I found that some such
events during startup were being ignored as a result a SAFERHANGUP changes.

debian #184911 - quitting while tty mode inventory is displayed
The tty menu code wasn't totally reentrant, causing it to free memory
that wasn't on the heap if you had your inventory displayed, ^C then
ask to see the inventory again.  Solved this by converting the buffer used
by process_menu_window to be heap-allocated.  If the Quit code could return at
this point, this would still be very bad, but since it doesn't, this is OK.