On 1/24/2014 6:48 AM, a bug reporter wrote:
> The whistle in Nethack has no encyclopedia entry. I suggest for the next
> release something from the M. R. James ghost story 'Oh, Whistle, and I'll Come
> to You My Lad'.
>
Changes to be committed:
modified: doc/fixes35.0
modified: include/extern.h
modified: src/apply.c
modified: src/zap.c
On 3/23/2015 6:41 PM, a bug reporter wrote:
> When you're hiding under an item (e.g. via garter snake polyform), and
> that item gets polyshuddered into nonexistence, you continue hiding
> (under nothing).
This was addressed previously.
> (Incidentally, it's a bit weird that you use > to aim at items that are
> flavorwise above you at the time.)
This addresses the flavorwise concern.
On 3/23/2015 6:41 PM, a bug reporter wrote:
> When you're hiding under an item (e.g. via garter snake polyform), and
> that item gets polyshuddered into nonexistence, you continue hiding
> (under nothing).
This addresses the "hiding under nothing" bug, but does not
address this flavor comment also included in the report:
> (Incidentally, it's a bit weird that you use > to aim at items that are
> flavorwise above you at the time.)
On 3/23/2015 6:41 PM, a bug reporter wrote:
> If the game generates a graveyard, the graveyard places a normal
> demon, but all normal demons are extinct at the time, then morguemon (at
> mkroom.c line 423) indexes mons with NON_PM (the return value of
> ndemon() if it can't find a reference), which is an invalid pointer
> dereference. According to the testbench, this mostly seems to happen on
> dlvl 12.
This fixes the code violation, but the logic will now drop down to the
ghost/wraith/zombie code when that happens.
Is that desireable, or should something else happen (for variety)?
Here in branch paxed-new_lev_comp-B (branched
from paxed-new_lev_comp) is a simple fix
for the strcmpi issue.
The bottom section of lev_main.c has a bunch
of forced linkages to names from NetHack etc.
#ifdef STRICT_REF_DEF
bunch of stuff
#endif
This change to lev_main should make everything
work for those that don't supply a compiler
library version of strcmpi()
With this patch, those people can just
add a -DSTRICT_REF_DEF to their compile line
for lev_main.c.
This would close the issue in a simple way,
and doesn't require linking in anything new to
the level compiler, or modifying any port's Makefiles etc.
This old feature alert from 3.3.0 is pretty stale, so remove
if from the code because everybody has probably suppressed
it by now.
/* Because 'Q' used to be quit... */
if (flags.suppress_alert < FEATURE_NOTICE_VER(3,3,0))
pline("Note: Please use #quit if you wish to exit the game.");
With SYSCF, the SYSCF_FILE name was overwriting the
default config file name making it unavailable for
subsequent user config file options handling.
- Keep the name of the last config file successfully opened.
- Do it without orphaning the default config file name needed
for the next pass.
Since that line of code is used by a lot of different ports, I decided to
recant its removal and just add #ifdef to ensure it isn't compiled on WIN32.
I think other ports might encounter the same issue where the first pass with
filename set to 'sysconf', is then going to overwrite the hard-coded user
config file name, but I can't fix or test those so for those ports, it
will be now be back the way it was.
Whenever SYSCF was enabled on Windows, the option
processing would go bonkers with illegal options
at startup. I noticed it months ago, and Derek
had it happen the other evening.
It turns out, the hard-coded 'defaults.nh' setting
was being overwritten with the name sysconf on
the first SET_IN_SYS pass, so all subsequent passes
were re-opening the SYSC_FILE instead of the
user config file.
I opted to take it out as I couldn't ascertain
why it was there in the first place.
Things won't build for ports that first
define SYSCF.
This moves assure_syscf_file() from unixmain.c
to files.c and adjusts extern.h to get it
out from under #ifdef UNIX.
The call to assure_syscf_file() in options.c was
only #ifdef SYSCF, SYSCF_FILE and not UNIX,
so new ports #defining SYSCF would get an erro.
assure_syscf_file() will be utilized by mswin
when SYSCF is defined.
This is an enabling patch for upcoming work. It breaks
save/bones so editlevel is incremented.
I'd like to a second overloadable int field in struct obj,
instead of just the one that is typically overloaded - corpsenm.
The second one can be used for things that are being tallied
up as opposed to a static one time assignment for reference/linkage
purposes.
The differentiation will allow both uses to co-exist for the
same object.
There was actually a fixes35.0 entry further down that covered off
that particular entry already which I missed first time around.
> many instances of physical damage were not taking Half_physical_damage
> into account when reducing your hitpoints
This is catching up on some things that were changed
in development years ago that Dave C. suggested be
documented.
For the record:
-The things that were evaluated and ruled out
are now documented in include/youprop.h so they don't
come up again.
- The things that were evaluated and deemed to be susceptible
to the intrinsic and thus led to a modification in the code
are listed below in this commit message.
Modifications:
- A crystal ball exploding on being applied
- Artifacts' blasting
- Being a fish out of water
- Being hit by Mjollnir on the return
- Being thwacked by an iron ball chained to you
- Boiling/freezing potions
- Broken wands
- Bumping head on ceiling by cursed levitation
- Burning (un)holy water
- Chest/door/tin traps
- Dipping a lit lamp into a potion of oil
- Exploding rings and wands (under all circumstances)
- Exploding spellbooks
- Falling downstairs
- Falling into a (spiked) pit
- Falling off or failing to mount a steed
- Falling on a sink while levitating
- Getting squished in a pit under a boulder
- Hitting your foot with a bullwhip
- Hitting yourself with your pick-axe
- Hooking yourself with a grappling hook
- iron-ball-pulling yourself out of a bear trap
- Jumping/Newton's-Thirding into something solid
- Kicking something that makes you go "Ouch!"
- Land mine explosion
- Sitting in a spiked pit
- Stinking cloud damage
- Thrown potion (bottle)
- Zapping yourself with a wand, horn or spell
- Jumping yourself out of a bear trap
From ais523's recent list of bugs:
If a long worm tail is blocking the door, and you're blind and not
telepathic, attempting to close the door marks the position of its head.
From an email received in late September 2014 before the git conversion:
> I was trying to close a door, not noticing that there was a garter
> snake there, and this message resulted:
> The garter snake stands in the way!
> I haven't tried it with any other monsters without feet, but
> "stands in the way" appears to be the wrong way to describe
> this situation...
Both of the above were found in the same function in lock.c
Changes to be committed:
modified: src/do.c
From the email sent by ais523 earlier:
> You aren't charged for digging a pit below an unpaid boulder
> (causing the boulder to fill the pit).
Changes to be committed:
modified: src/pager.c
When the previous occurrence that triggered a segfault
was fixed, I didn't check for more of them. It turns out there
were more instances.
This also removes some dead code.
Changes to be committed:
modified: src/pager.c
Steps to reproduce the reported segfault:
Use / command, answer n, press space and enter
In do_look() variable glyph is only set to a proper
value if using the screen (from_screen) or the
mouse (clicklook).
On the code path that triggered the segfault,
glyph was being passed to mapglyph with a random
arbitrary value.
If glyph had been initialized at the start of
do_look(), it would have prevented the segfault,
but would have always displayed a giant ant or
something silly instead of the correct thing.
Don't use glyph except under
from_screen || clicklook.
On 3/1/2015 10:37 AM, coppro wrote:
> >> Sun SPARC based machine running SunOS 4.x, Solaris 2.x, or
> Solaris 7
>
> By release time, I should have access to a BSD flavour installed on a SPARC
> machine. Would out be helpful for me to do cursory tests?
On 3/1/2015 10:41 AM, lorimer wrote:
> I have access to a Borland environment too, so I'll be
> borrowing that at some point. [Just not soon.]
I didn't include the above, just in case they don't happen.
The README can, of course, be updated again once they have
been tried.
There was actually a fixes35.0 entry further down that covered off
that particular entry already which I missed first time around.
> many instances of physical damage were not taking Half_physical_damage
> into account when reducing your hitpoints
This is catching up on some things that were changed
in development years ago that Dave C. suggested be
documented.
For the record:
-The things that were evaluated and ruled out
are now documented in include/youprop.h so they don't
come up again.
- The things that were evaluated and deemed to be susceptible
to the intrinsic and thus led to a modification in the code
are listed below in this commit message.
Modifications:
- A crystal ball exploding on being applied
- Artifacts' blasting
- Being a fish out of water
- Being hit by Mjollnir on the return
- Being thwacked by an iron ball chained to you
- Boiling/freezing potions
- Broken wands
- Bumping head on ceiling by cursed levitation
- Burning (un)holy water
- Chest/door/tin traps
- Dipping a lit lamp into a potion of oil
- Exploding rings and wands (under all circumstances)
- Exploding spellbooks
- Falling downstairs
- Falling into a (spiked) pit
- Falling off or failing to mount a steed
- Falling on a sink while levitating
- Getting squished in a pit under a boulder
- Hitting your foot with a bullwhip
- Hitting yourself with your pick-axe
- Hooking yourself with a grappling hook
- iron-ball-pulling yourself out of a bear trap
- Jumping/Newton's-Thirding into something solid
- Kicking something that makes you go "Ouch!"
- Land mine explosion
- Sitting in a spiked pit
- Stinking cloud damage
- Thrown potion (bottle)
- Zapping yourself with a wand, horn or spell
- Jumping yourself out of a bear trap
From ais523's recent list of bugs:
If a long worm tail is blocking the door, and you're blind and not
telepathic, attempting to close the door marks the position of its head.
From an email received in late September 2014 before the git conversion:
> I was trying to close a door, not noticing that there was a garter
> snake there, and this message resulted:
> The garter snake stands in the way!
> I haven't tried it with any other monsters without feet, but
> "stands in the way" appears to be the wrong way to describe
> this situation...
Both of the above were found in the same function in lock.c
Changes to be committed:
modified: src/do.c
From the email sent by ais523 earlier:
> You aren't charged for digging a pit below an unpaid boulder
> (causing the boulder to fill the pit).
Changes to be committed:
modified: src/pager.c
When the previous occurrence that triggered a segfault
was fixed, I didn't check for more of them. It turns out there
were more instances.
This also removes some dead code.
Changes to be committed:
modified: src/pager.c
Steps to reproduce the reported segfault:
Use / command, answer n, press space and enter
In do_look() variable glyph is only set to a proper
value if using the screen (from_screen) or the
mouse (clicklook).
On the code path that triggered the segfault,
glyph was being passed to mapglyph with a random
arbitrary value.
If glyph had been initialized at the start of
do_look(), it would have prevented the segfault,
but would have always displayed a giant ant or
something silly instead of the correct thing.
Don't use glyph except under
from_screen || clicklook.
On 3/1/2015 10:37 AM, coppro wrote:
> >> Sun SPARC based machine running SunOS 4.x, Solaris 2.x, or
> Solaris 7
>
> By release time, I should have access to a BSD flavour installed on a SPARC
> machine. Would out be helpful for me to do cursory tests?
On 3/1/2015 10:41 AM, lorimer wrote:
> I have access to a Borland environment too, so I'll be
> borrowing that at some point. [Just not soon.]
I didn't include the above, just in case they don't happen.
The README can, of course, be updated again once they have
been tried.
nhmall