From: "Ken Arromdee" :
> My point is that you should be allowed to take vengeance on thieving
> nymphs too. The reasoning "a real knight wouldn't kill a nymph for stealing"
> doesn't make sense because the things a real knight would do instead (like
> arresting) aren't part of the game.
This is a compromise. This doesn't allow vengeance when you were
told "you gladly hand over ...", but does for most other cases, and for
leprechauns.
Can't push boulders through iron bars; traps can't roll such through either;
likewise for objects thrown by monsters.
Thrown objects susceptible to breaking might do so when they hit iron bars.
Assorted monsters can pass through iron bars; ditto for polymorphed character.
Attempting to dig iron bars will wake nearby monsters instead of yielding
"you swing your pick-axe through thin air".
Autodig won't accept iron bars as candidate location.
<email deleted>
> Since Priests' knowledge of the buc-status of an object only
> kicks in when the name is being looked at for the first time,
> they get an "X" option when taking items out of a newly-looted
> container, but B, U, and C thereafter; could their ability be
> pre-applied to the container's contents when constructing the
> menu, to avoid this anomaly?
>
moveloop() sets a flag when a were/poly change should occur, but it
delays this change if the hero is Unchanging or cannot be interrupted (e.g.
praying). However, by the time the change can be applied, the reason
may no longer be valid. Reset the change indicator when this is the case.
Avoids possible strange polymorphs and were crashes.
Implement a fix for the problem From a bug report:
if the destination position on the Plane of Fire has a randomly
placed trap on it, you'd get an impossibility warning of "couldn't
place lregion type 5" (and then arrive successfully at the target
spot anyway). As his investigation indicated, the code to remove
such traps wasn't being reached because the `bad_location' check
yields true for trapped spots.
This throttles insect creation through monster spell casting. Especially
insects. It was creating m_lev worth of insects--for a 25th level priest,
that means every batch of insects was size 25!
I also lowered the range for nasties creation for similar reasons.
Add "travel" boolean option to enable/disable travel command.
Add "mouse_support" wincap option to enable/disable mouse.
- When running the win32 tty version full-screen, some people
complained about the square mouse cursor.
Newsgroups: rec.games.roguelike.nethack
Subject: Re: Getting rid of the cursor?
<email deleted> <email deleted>
Followup-To:
On Thu, 04 Apr 2002 00:20:06 <email deleted> wrote:
> Ok, let me be more specific: when playing the windows non-GUI version, is
> there a way to get rid of the large rectangular white cursor?
>
> <email deleted> wrote in message
> <email deleted>
>> Can you get rid of the cursor in the windows version? I really hate that
>> thing.
>>
<email deleted>
>Newsgroups: rec.games.roguelike.nethack
>Subject: Disabling Mouse Input
>
>I purchased an older P120 laptop to be able to play Nethack at the hotel.
>I find that I rest my thumbs on the mouse touch pad all too often and my
>@ moves unexpectedly at times. I took a peruse through defaults.nh, but
>came up empty.
>
>Anyone know if mouse input can be disabled?
>
>MRSisson
- this is brute force, always update the status line each time you
insert something into a container. If you look closely, you may still
see the Burdened message disappears momentarily doe to the many possible
messages between the freeinv() call and the point where the object is
actually put into the container.
Another fatal bug in win32 graphical interface
"Too many "dead" NHW_TEXT windows around. Repeating #? 15 times will produce
the same result."
>Wizard, wearing gray dragon scale mail and wielding Magicbane. The
>Dark One teleports next to me and I get the message "The Dark One
>casts a spell at you! A field of force surrounds you!". Then I get
>3 windows popping up: "Oops." "The dungeon collapses." "ERROR: No
>windows available..." and the game exits.
> I wish I could reproduce this reliably. Here's the method I've been using
> to do it:
>
> - Equip character (+4 gdsm, Magicbane, unicorn horn, see invisible,
> telepathy, key, "gain ability" potions to max out, enhance dagger skill
> to max, level change to 14)
> - Teleport down to the portal entrance. Go through the portal, get
> permission to go down to see the Dark One.
> - Go down to the Dark One's level, teleport over, open up his door, and
> basically just try to head back to the entrance and kill him.
>
> Two different things have happened while doing this so far. (I've been
> able to get errors something like 5 times out of many tries, and I haven't
> been about to do it at all in the TTY version - only the windows
> one.) Either I get the above message I mentioned to you, which seems to
> happen at a random time, or I get a slightly different result - "Oops,
> program initialization failed, ERROR: No windows available". This second
> result happened once _after_ I had killed the Dark One and was trying to
> #quit.
>
- the "Burdened" message could disappear from the status line if it was
updated partway thru in_container, clearing the bot flags. Re-order
message so it comes after add_to_container, as in 3.3.1.
- It was possible for hmon_hitmon to call mhurtle to move a monster into a
hole or other trap, causing it to migrate. Then, hmon_hitmon would
subtract hp, and could mark the monster as dead. Later, dmonsfree would
notice the monster wasn't on the level anymore, causing the impossible.
Avoid the problem by just not hurtling the monster if it's going to die.
It's possible it will get lifesaved after not hurtling. Technically, if it
does die, the corpse should be hurtled, but won't be.
- treat jousting similarly
- if you're polymorphed into an eel, you were able to drown things like xorns
- also, fix the tombstone message when an eel drowns you, it was basing the
message on your location, not the eel's location
Fixing some iron ball/teleds stuff:
-- If the player can pass through walls, ignore all checks for walls, or else
things will behave weirdly.
-- Instead of using the kludge "if the distance is >2 it must be a teleport",
pass a parameter indicating whether they crawled or teleported onto the new
space. This fixes a special case, where the player moved one space and the
ball didn't move, but the chain moved through solid rock. This is acceptable
if teleporting and unacceptable if dragging.
This also required some rearrangement of teleds() so that u.ux,u.uy
are set after placing the ball, not before. I'm still not sure the pit
filling line is in the right place; anyone know?
-- add some comments so I can look at the code in a month and still know what
I did.
Most of this patch is just adding the new parameter.
statement that could be followed by ';' anywhere. However, with the goto
there, my compiler complains every time it's used:
"ball.c", line 402: warning: statement not reached
"ball.c", line 434: warning: statement not reached
"ball.c", line 442: warning: statement not reached
"ball.c", line 449: warning: statement not reached
"ball.c", line 452: warning: statement not reached
"ball.c", line 457: warning: statement not reached
"ball.c", line 479: warning: statement not reached
"ball.c", line 498: warning: statement not reached
None of the current uses care about an excess statement, but is there a
way to satisfy both desires?
- the response field of the pop-up dialog was getting smaller by a few
pixels each time it was used. This was because the width calculation
was effectively stripping off the margins (4 pixels total) each time.
Don't do that.
Replace "feature_toggle" implementation with an easier-to-understand
boolean option called "lootabc".
Provide "showrace", an option to display the hero by race glyph rather
than by role glyph.
Document the above.
Remove some obsolete Mac options.
- make the code in apply.c and zap.c consistent
- use the "drops away from you" case whenever the location type does not
lend itself to using the word "floor"
