> 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.
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.
<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.
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.
<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().
- 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
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.
<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.
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.
<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.
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.
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
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.
<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...
>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.
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.
- [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.
- [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
- [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!"
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.
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>
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>
<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.
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...
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()
<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.
> 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.
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.
<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.
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.
Opinions expressed:
> I actually like having "yes" consistently mean take a
> dangerous action, and "no" mean the safe route.
Also:
> I would classify the current behavior--where the "safe" answer
> is the opposite of the one for other prompts--as simply a bug.
[...]
change the dreaded "Stop eating?" prompt to "Continue eating?" with default "no"
<email deleted> wrote:
> [...] Vlad happened to be generated with a /WoDig and tried to
> make an escape hole during his last few moves. Shouldn't he
> know, that the floor in his own tower is undigable? So he lost
> valuable time with a pretty senseless action...
Zapping existing ice with cold wand/spell guaranties safe ice for
a minimum of MIN_ICE_TIME time.
Note that it could actually cause the ice to melt sooner than
it previously would have due to the randomization, but that's
an internal that the non-wizard-mode player would never
know anyway. The important thing from the hero's perspective
is that the ice should be safe for a while at least.
Also noticed and corrected a bug where the ice object effects
seem to have been getting initiated when solidifying lava in
zap.c
add a new melt_ice_away timer for ice created via zapping
a wand/spell of cold.
Some follow-up adjustments to the length of time before
the ice melts may be necessary. Ideally, I'd like to
have it so that the shorter the length of time since
the ice was created, the lesser the chance that it will
melt out from under you. Likewise, the longer it has
been, the more risky it will be to venture onto it.
At the moment, however, each spot of ice is just
getting a somewhat random time always greater
than 50, which is less than ideal.
> Not all objects say "Splash!" when they fall in the
> water. When levitating/flying and dropping things they
> don't, but when polymorphing and forced to drop items
> they do. [<email deleted>]
when floating over the water, things dropped always
make some sort of sound. Also fix up some messages
when Underwater that previously said things like
"feel what is lying on the water" by adjusting
surface() in that situation to return "bottom."
While looking into this, I noticed that if you
are polymorphed into a Flyer and you then polymorph
back into your normal form, you don't end up in
the water until you move, so this attempts to
correct that too.
> You cannot stop eating, transcribing, or removing armor, save
> the game, restore it, then expect to continue. These use
> static data structures which aren't saved.
1. Switch to low-level console routines for performance improvements.
2. Instead of moving the cursor around like a real tty, just track the
destination coordinates of where the cursor should be, and
defer the movement until user input is expected.
Credit to <Someone> for #2.
There was a great deal of inconsistency in
different menus on how headings were displayed.
This allows the user to select what they like best.
I was motivated to do this, because I wasn't satisfied
with the appearance of ATR_INVERSE in the menus
on win32tty, and several of them specified it.
On September 11, 2003 "<Someone>" wrote:
> When we're going to have a different save file format, could
> the last messages in the message history be saved as well, so
> ^P would work the same before and after saving (possibly
> including a few less messages to make room for the startup
> messages?).
This seemed like a reasonable request. This patch:
- adds the core support required.
- adds the tty supporting routines.
trunk and branch:
Do not limit role selection list by race/gender/alignment. The default.nh
selection will still be honored but the list itself will include every
possible role.
Some interface tweaks for main trunk:
- improved calculation of the size of the menu window
- made auto-arrange windows on/off option (it was reset automatically
which was unintuitive and in some cases annoying, IMO)
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
<Someone> wrote:
>> You're equally unlikely to be wishing for spellbooks by colour,
>> but I note that 'grey' for 'gray' only works for dragonscale and
>> stones, not the spellbook description.
>>
> I've just noticed that the fix for this only works for 'grey
> spellbook', not 'grey spell book'; 'spell book' works for wishing
> in other contexts, so it probably ought to here :-)
> Would it be possible to make autodig also dig downward
> when I press '>' while wielding an pick-axe? When digging for gold,
> after casting detect objects, this would be convenient for getting
> to buried gold and gems.
> [<Someone>]
> When I enter a desacrated temple, sometimes an enormous ghost
> appears next to me:
> You have an eerie feeling... An enormous ghost appears next to
> you!
> You are frightened to death, and unable to move.
> You regain your composure. When I don't have telepathy, and don a
> blindfold first, I get the same messages:
> You are now wearing a blindfold. You can't see any more.
> You have an eerie feeling... An enormous ghost appears next to
> you!
> You are frightened to death, and unable to move.
> You regain your composure. Why does the ghost scare me if I
> cannot even see it? How do I notice it appear?
> [<Someone>]
<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.
> NetHack feedback form submitted by
> <email deleted>
> on Tuesday, September 9, 2003 at 06:41:34
> Hi, Just thought I'd point out a sort of inappropriate word
> choice or typo that I came across in Juiblex's Swamp. I got this
> message, after pushing a boulder into the swamp: There is a large
> splash as the boulder falls into the moat. Obviously it's a swamp
> and not a moat so that sounds a bit wrong. It says the same sort
> of thing when I #dip a scroll in the swamp as well.
<Someone> submitted the following bug report:
> An object and a pit are occupying the same square. I try to kick
> the object out of the square, but "You can't kick something
> that's in a pit!"
>
> I step into the square and escape the pit, but I can pick up the
> object, so maybe it's not in the pit after all.
>
This patch does *not* address this part of the bug report:
> If it's in the pit and it's a cockatrice corpse, should I die
> from landing on it when I fall into the pit?
Bones loading was only checking to see if a
monster was marked extinct, it wasn't adding
up the born count of a species in the current
game with the number of that species on the
bones level being loaded. That made it possible
to exceed the correct number of nazgul and
erinys via bones.
This adds a common routine called propagate()
that makemon() and restmonchn(ghostly) share,
for incrementing the born count and checking for
extinction, etc.
When a bones level is loaded, restmonchn()
will flag an illegal monster (duplicated unique,
or too many of a species) by setting the
individual monster's mhpmax to the cookie
value DEFUNCT_MONSTER. Before getbones() finishes
loading the bones level, it will purge those
monsters from the chain.
Although the overlay stuff is destined to be
removed someday, this patch just makes the
use of STATIC_DCL, STATIC_OVL consistent
in the trunk.
[As a side pointless experiment, I was able
to build a working 8086 port of 3.4.2 after
this change that worked correctly in limited
testing right up until it came time to enter
Ft. Ludios., where it couldn't allocated the
required amount of memory.]