Noticed with recent looting patch: QBUFSZ is not big enough
to reliably hold formatted object names. (I haven't looked through
any other source files for similar problems.)
The recent change to include increased damage and increased
chance to hit in all enlightenment feedback instead of just at end
of game feels too specific compared to most of the other feedback.
Instead of giving exact plus/minus values, give a generalized
categorization of the amount. The exact value is given at game end
as in existing 3.4.0 behavior, and also given when in wizard mode.
> I'm working on a Nethack port, and one of the header files a
> library uses has a structure with a member named "red". Since
> includes/decl.h #defines red to something, this totally loses.
>
> Attached is a patch which fixes the color defines.
Newsgroups: rec.games.roguelike.nethack
Subject: Re: YANI - empty containers interface
<email deleted>
On Mon, 2 Sep 2002 12:13:49 +0300, <email deleted> wrote:
> I find the behaviour when trying to put something in an empty container
> quite irritating. Let's remind it:
> #loot
> "The <container> is empty. Do you want to put something in it? (y/n)"
> This means I have to read the message and to press 'y' or to cancel via
> Esc.
> For comparison, non-empty containers behave like this - please forgive
> me that I've forgotten the exact words:
> #loot
> "Do what?
> o - take out
> i - put in
> b - both of the above"
> So my suggestion is to change the behaviour of empty containers to be
> the same as non-empty ones. That is:
> #loot
> "Do what?
> i - put in"
> This way, I don't have to look at the container. If I want to put
> something in, pressing 'i' will lead to the same results in both cases.
This part of the suggestion was not implemented, however:
> If I want to take something out, then pressing 'o' or 'b' - although
> they are not in the list of choices - will display a message "This
><container> is empty" and end the #loot-ing session.
This uses pmatch() as a default pattern matcher,
and #defines USER_SOUNDS_REGEX for Qt
to enable the code for regular expressions.
This is enabled for win32tty and win32gui.
Forwarded from the newsgroup as noting that dropping a chameleon corpse
into a purple worm did not cause polymorph nor will the digestion attack.
Added code to dropy and mdamagem to include special corpse effects like
those in dog_eat and meatobj.
> In my final attributes;
> "You had +1 bonus to hit."
> Surely "You had a ..." ?
Also moves the hit and damage bonus feedback from the "troubles"
section to the "physical attributes" section and delivers it for
every enlightenment rather than just after the game is over.
Your quest leader would tell you to return later, even after you
were converted, which would be futile, and could mislead new
players.
This patch:
1. Causes the quest leader to banish you the first time you
encounter him/her following a conversion, since you cannot ever
complete the quest anyway in the current game.
2. Adds a new general QT_BANISHED message to be delivered, in
which you are told that you won't be able to get the Amulet without
the Bell now.
This helps resolve the complaint about not knowing that your game
cannot be won.
Someone posted in the newsgroup about using stone-to-flesh
to reanimate a petrified pet and having it come back to life with
boosted speed intact. When the character gets petrified, stripping
speed is one of the first things which happens, so now do that for
monsters too. I decided not to make monsters who have normal speed
become slow; there isn't any analogous case for the player.
Possible bug: while testing this, I zapped a wand of probing
at a hill orc which had just eaten a lizard corpse to save itself
from stoning. The feedback said "eating" but the orc immediately
hit and killed me as if it wasn't affected by any movement delay.
Mounting a steed would work even when done diagonally at a doorway,
such as a shop door. Use test_move to check for all such moves and disallow
the mount in this case.
<email deleted> wrote in the newsgroup:
> "You've attracted the tree's former occupants!"
> (nothing happens)
>
> Yes, it's _zero_ to four bees, depending on your luck. I think it's meant
> to be one to five, though.
>
Possible fix for B10001.
When the code went into case 3 in cursed_book(),
the game hung in an endless loop in take_gold().
The call stack was:
take_gold() line 22 + 10 bytes
cursed_book(int 2) line 124
study_book(obj * 0x00968860) line 421 + 19 bytes
doread() line 130 + 9 bytes
rhack(char * 0x005b8eac in_line) line 1813 + 3 bytes
moveloop() line 405 + 7 bytes
main(int 3, char * * 0x00962ac0) line 93
ohitmon was incorrectly using location visibility in a couple places where
monster visibility was more appropriate. I'm still not sure about the
canspotmon check for destroy vs killed. Similar checks do no appear
elsewhere in the code. But at least now the 'destroyed' won't be shown
for a seen, living monster.
Pat added some error information to create_levelfile.
This does the same for create_bonesfile, but the
only place it is logged is in the paniclog, unless
you're in wizard mode. If bones file creation is
silently failing for someone and they aren't getting
bones files, this provides a way to diagnose why.
(from <Someone>):
I guess that this:
mcam += iflags.wc_scroll_amount;
should be his:
mcam += iflags.wc_scroll_amount - 1;
In words: If scroll amount is 1, the behaviour should be as it was
before the option existed, which means: no addition to mcam.
Update the other trickery situation. I don't know how I managed
to miss this. The disadvantage of suppressing extern.h from normal
dependencies I guess.
1) consolidate all core usage of `errno' in files.c;
2) give more feedback for any failure by create_levelfile or open_levelfile,
similar to what was being done for problems during level change;
3) include trickery info in paniclog (many instances of "trickery" seem to
be due to disk or quota problems rather than user misbehavior...).
The create_levelfile call in pcmain probably ought to be changed to use
error feedback, but in the meantime this should continue working.
Perhaps error() should be modified to update paniclog too, but I didn't
want to go through all its port-specific incarnations making changes.
Fix part of the buglist entry regarding hitting and mhurtle. Flag if
mhurtle already killed the monster, and don't call killed again in this case.
One of the new checks for this already_killed flag is just futureproofing.
> - I'd like to see another option added: scroll_amount. In
> combination with scroll_margin, this would control the amount
> of squares the screen is scrolled when the scroll_margin is
> reached (currently, this amount is 1, but if I recall
> correctly, it used to be more). For example, if both were 5,
> when you came within 5 spaces of the left screen border, the
> screen would shift 5 spaces to the right).
Prevent the pardoning of trickery in wizard mode from attempting
to continue when there's no longer any current level. Also prevent
the ZEROCOMP configuration from trying to read from file descriptor -1
in case there're any other places which still let that slip through.
And fix an oddity in the VMS port's error() routine which has gone
unnoticed for years.
A monster hit by Stormbringer could take less damage to current
HP than it took to max HP if attacker had sufficient penalties, so
end up being healthier than its new maximum. This only applies to
attacks by the player; attacks by monsters don't include the sorts of
modifiers that can trigger it.
From the newsgroup: taking a shop-owned pick-axe out of a
container inside a shop gave a misleading message telling the
player to take the pick-axe out of the shop. It was caused by
using the object's `unpaid' field before addtobill() had set it.
Implement a check in make_hallucinated similar to the check in make_blinded
to handle the case where your hallucination is cured but Grayswandir is
suppressing its effects anyway.
- Breaking wand of digging dug through rock which should be undiggable.
Checks assumed pits would never show up in solid rock.
- Breaking wand of digging near shop walls wouldn't anger the shopkeeper
Checks assumed pits would never show up in walls, also, added a special
case to pay_for_damage to handle the case where you're falling thru and
can't be asked to pay.
- Shop walls wouldn't be restored if there are pits in the way.
Checks assumed pits would never show up in walls.
- If there was a hole outside the shop, you could kick stuff out of the
door into the hole without shopkeeper noticing. Added the missing check.
Reported to the newsgroup, the code in study_book for the effect of
confusion on studying a book was never reached. The study_book code
didn't completely handle continuing to read a book when you got confused
after getting interrupted.
Reported to the newsgroup, the code in study_book for the effect of
confusion on studying a book was never reached. Removed the deprecated
check from read.c
Do vision_recalc immediately when blasting a door so that all the
subsequent messages for the same blast hitting other things are all
evaluated with the same vision in effect.
The link is no longer valid. I found another
link, http://tultw.com/bios/latin.htm
but this doesn't seem like something we
want to direct maintenance effort towards.
So this removes the link altogether.
<Someone> wrote:
> Linux, Redhat 7.1 nethack 3.4.0
>
>Please see attached patch file.
>
>I'm attempting to move more stuff into the "read-only" area, in
>preparation for a port to another OS.
- when testing travel locations, don't treat diagonal moves thru closed
doors as possible, unless player can go/dig thru door
- treat closed doors and boulders as expensive for travel, preferring open paths
<email deleted> on Sunday, August 18, 2002 at 15:28:18
> comments: player is blind, and not hallucinating (initially). On #loot:
>
> You trigger a trap!
> A cloud of ultraviolet gas billows from the large box.
> You stagger and get dizzy...
# ifdef WIN32
#define SAVESIZE (PL_NSIZ + 40) /* username-player.NetHack-saved-game */
files.c had:
# if defined(WIN32)
#define SAVESIZE (PL_NSIZ + 60) /* username-player.NetHack-saved-game */
It has to be 40 for savefile compatibility with 3.4.0.
From a bug report, a rolling boulder
trap could report that the boulder had fallen into the pit with you
and then let it keep rolling. flooreffects() only returns true
when it uses up the object being manipulated but it doesn't use up
boulders that hit pits which hold monsters or the hero. Its caller
needs to handle the cases where the boulder ends up sharing the pit
with a monster.
