Michael Meyer [Thu, 6 Oct 2022 02:19:52 +0000 (22:19 -0400)]
Make #attributes gold line match #showgold
The #showgold command now mentions (known) gold socked away in
containers in your inventory as of 706b1a9. Since the gold info in the
attributes display and dumplog matches the output of #showgold
otherwise, update it to do the same thing. Also refactored doprgold a
bit to be a little more compact, as opposed to enumerating all the
different combinations of gold/no gold in open inventory/containers.
This eliminated some string constants that were broken up into multiple
constants/lines (like "line 1 " "line 2"), which NetHack code style
seems to prefer to avoid.
PatR [Wed, 12 Oct 2022 20:47:12 +0000 (13:47 -0700)]
monk strength
Add a stack of 2 tins of spinach near the leader on the monk quest
start level and another stack of 2 blessed tins of spinach at a
random spot on the monk quest locate level, to compensate for the
inability to gain strength from giant corpses if they adhere to
vegan or vegetarian conduct. paxed supplied the 'tinplace' magic.
4 tins of spinach aren't nearly enough to get to 18/100, but by
uncursing the first pair, if necessary, and waiting until strength
is at least 18, they can be eaten to add 4..40 (average 22) points
of exceptional strength. (Players choosing either of those conducts
for other roles or foodless for any role are on their own as far as
boosting Str goes, same as before.)
The special level loader needed to be modified to handle tins of
spinach. It now accepts "spinach" as a fake monster type for an
object of type "tin". Also added support for empty tins since it
involved the same code, and use of fake monster type "empty" with
object type "egg" to be able to create generic (unhatchable) eggs.
(Wishing for "egg" produces those by default but it also accepts
explicit "empty egg" by coincidence.)
PatR [Wed, 12 Oct 2022 09:05:32 +0000 (02:05 -0700)]
more github issue #679 - orc strength
Handle alternate values for hero poly'd into a 'strongmonst' form
more thoroughly by propagating max values other than 18/100 to the
attribute manipulation routines.
ATTRMAX(A_STR), which used to be a relatively simple expression, now
contains a function call.
Along the way, change the races[] terminator's value for 'mnum' from
0 (giant ant) to NON_PM.
PatR [Tue, 11 Oct 2022 21:49:14 +0000 (14:49 -0700)]
PR #862 - try XLII
When strength loss is so big as to cause HP damage, but reduce
strength if the damage causes hero to revert to normal form. There's
no point in adjusting strength before rehumanization and not fair to
do so afterward.
Also, validate strength and its intended adjustment before doing
anything else. (Just paranoia; there's no reason to suspect that any
bad data ever gets passed in.)
PatR [Mon, 10 Oct 2022 23:46:33 +0000 (16:46 -0700)]
PR #892 - one more try...
Try again to make losestr() do what's intended. If it would take
strength below 3, it takes away HP and max HP instead. If hero is
poly'd, those come from the hero-as-monst values. If hero was
poly'd but isn't any more, hero-as-monst died and rehumanized as
previous self; leave max HP alone. If hero wasn't poly'd, take
HP and max HP from their usual values, but don't take max HP below
the threshold of minimum max HP (experience level times 1). The old
check for max HP going below minimum can't happen anymore, unless
hero was below that threshold already (which shouldn't happen; if it
does somehow, don't punish hero further).
If this still isn't right, I'll throw up my hands and my lunch.
PatR [Sun, 9 Oct 2022 23:57:06 +0000 (16:57 -0700)]
more PR #892 - strength lose due to poison
Refine pull request #802 by entrez. Applying damage within a loop
could potentially damage the hero multiple times, maybe using up
an amulet of life saving and then killing hero anyway, or causing
rehumanization and taking further HP from normal form, or both,
causing rehumanization and then using up amulet of life saving.
Accumulate the damage in the loop and then apply it as a unit.
nhmall [Sun, 9 Oct 2022 13:35:24 +0000 (09:35 -0400)]
warning fix in msdos build
../sys/msdos/font.c:24:12: warning: declaration of 'flags' shadows a global declaration [-Wshadow]
24 | uint32 flags;
| ^~~~~
In file included from ../include/hack.h:285,
from ../sys/msdos/font.c:3:
../include/flag.h:422:29: note: shadowed declaration is here
422 | extern NEARDATA struct flag flags;
| ^~~~~
make[2]: Entering directory '/home/nhmall/git/NHsource/util'
nhmall [Sun, 9 Oct 2022 13:11:56 +0000 (09:11 -0400)]
potentially uninitialized variable warnings
src/mkroom.c(1068) :
warning C4701: potentially uninitialized local variable 'insidex' used
src/mkroom.c(1070) :
warning C4701: potentially uninitialized local variable 'insidey' used
The warning is because the insidex and insidey variables only get
assigned a value conditionally within a for-loop, but contain random
values if that for-loop is not executed, and they are used unconditionaly
later on in the code.
Initializing them changes that from containing random values to containing
zeros, whether that is appropriate or not.
In this particular case, insidex and insidey look to be riding on the coat
tails of insidect and there is a check for invalid insidect in the code,
so that should catch the situation.
PatR [Sat, 8 Oct 2022 23:54:24 +0000 (16:54 -0700)]
pull request #888 - latent shop creation bug
Pull request from copperwater: if a theme room produced a room with
one door that effectively opened on a 'hallway' leading to the core
of that room, it would be considered to be eligible to become a shop.
But if the only spot available for the shopkeeper to move away from
the spot in front of the door was another spot in the hallway, there
would be no possibility to get out of the way, either to let someone
in, or if the hero arrived by teleport or trap, to let hero out.
| --
| ---..[rest
|##+12..of the
| ---..room]
| --
Shopkeeper would move back and forth between 1 and 2, always blocking
access between the door and the rest of the room.
Currently no rooms get generated with that shape. I haven't tried to
force one in order to verify the fix.
copperwater [Sat, 1 Oct 2022 15:21:50 +0000 (11:21 -0400)]
Fix: possible themed room shop where shopkeeper permanently blocks entry
Reported by every for xNetHack. This bug is latent in vanilla, but can
easily start to present itself if themed rooms of a certain shape are
added. Ultimately, it comes from an assumption that shops will always be
rectangles of at least size 2x2, and the shopkeeper will always be able
to step diagonally backwards from their normal position just inside the
door in order to get out of the player's way.
Themed rooms introduce the possibility of shops where the shopkeeper has
only 1 square adjacent to their normal position to move to -
effectively, the shop entrance is a narrow corridor. When this happens,
they have nowhere to go to allow the player to enter or leave the shop,
leaving it permanently blocked unless the hero teleports or falls in or
out.
This fixes that by adjusting the shop algorithm to detect when a shop
candidate room is set up like this, and excludes it from becoming a
shop.
PatR [Sat, 8 Oct 2022 23:44:17 +0000 (16:44 -0700)]
pull request #893 - prevent non-adjacent grabber
Pul request from entrez: in some circumstances a monster holding the
hero can move away and continue holding. Check for that sooner and
release hero is warranted.
Michael Meyer [Tue, 4 Oct 2022 23:13:11 +0000 (19:13 -0400)]
Fix: nonadjacent grabber after move
A monster which has grabbed you could move away without becoming unstuck
if it hit the "move and shoot" or "helpless" conditions in the dochug
MMOVE_MOVED case (since those lead to early return or break), leaving
the hero stuck to a monster which is no longer adjacent. Put the
'grabber moved away -> become unstuck' stuff at the top of the block so
that it will always be evaluated if a grabber has moved.
I would have liked to move the whole "grabber checks" block up, but I
think it'd change behavior to have the u.uswallow attack come before the
early return for a helpless monster, so I split it up instead.
PatR [Sat, 8 Oct 2022 23:33:43 +0000 (16:33 -0700)]
pull request #892 - strength loss effects
Pull request from entrez, with several commits: monster spell 'weaken'
didn't handle poly'd hero correctly, possibly continuing in poly'd
form with negative hit points. Make losing strength (which takes away
HP if Str would drop below 3) take care of applying damage too so that
several callers don't need to do that.
Michael Meyer [Tue, 4 Oct 2022 22:27:40 +0000 (18:27 -0400)]
Don't hardcode min Str in losestr
Min Str is typically 3 no matter the hero's race, but could be higher
(at least in theory?). Using ATTRMIN makes losestr respect the same
minimum as other kinds of attribute loss (I'm operating under the
assumption that this wasn't an intentional move to fix the minimum at 3
regardless of other factors).
Michael Meyer [Tue, 4 Oct 2022 21:52:01 +0000 (17:52 -0400)]
Use function for combined str/hp loss from poison
Since losestr and losehp calls go together most of the time, this feels
like it probably makes more sense than repeating the killer name/format
twice in a row all over the place.
Michael Meyer [Tue, 4 Oct 2022 21:37:35 +0000 (17:37 -0400)]
Don't make callers responsible for losestr death
Remove callers' responsibility to deal with possible hero death when
calling losestr. This is less fragile and error-prone than leaving it
in the caller's hands, but it means that death from the monster spell
'weaken target' no longer goes through done_in_by, and the death reason
is no longer "killed by <monster name>".
Michael Meyer [Tue, 4 Oct 2022 21:26:23 +0000 (17:26 -0400)]
Don't use boolean for losehp killer format type
Killer format isn't a boolean, since it has 3 possible values
(KILLED_BY_AN, KILLED_BY, NO_KILLER_PREFIX). It shouldn't make any
difference behind the scenes, but it's confusing to use 'boolean' for
it.
Michael Meyer [Tue, 4 Oct 2022 21:13:58 +0000 (17:13 -0400)]
Fix: 'weaken target' spell against poly'd hero...
...could leave hero in creature form with negative u.mh
losestr can subtract HP, but doesn't directly kill its target. The
caller is responsible for possibly killing the hero if losestr reduces
her HP to 0 or lower; most callers do this by combining losestr with a
losehp call, which can kill off the hero if necessary.
MGC_WEAKEN_YOU calls done_in_by if u.uhp < 1 after losestr, but didn't
handle the Upolyd u.mh case, so could leave a polymorphed hero with
negative health. Add a rehumanize call in that case.
This could also be done by changing losestr to call losehp itself for
the HP loss it deals out, but this would interfere with
cast_wizard_spell's use of done_in_by to generate the death reason:
either all strength loss is described one way ("terminal frailty" or
something -- not great) or else losestr must be passed a death reason
and is described a different way than other attack spells (because it
wouldn't go through done_in_by).
PatR [Sat, 8 Oct 2022 23:09:19 +0000 (16:09 -0700)]
fixes entry for PR #883 - digestion attack by hero
Pull request from entrez: poly'd hero who digests a creature has a
change to gain an intrinsic from it. I put the fixes entry in the
New Features section.
I was a bit concerned that g.afternmv might be cleared during the
turns the hero is busy digesting, leaving a stale value for
g.corpsenm_digested, but I don't think that that can happen.
Michael Meyer [Tue, 27 Sep 2022 01:22:49 +0000 (21:22 -0400)]
Digestion attack can grant hero intrinsics
Monster purple worms can now gain intrinsics from swallowing foes whole,
so maybe the hero should be able to do so too. Intrinsics aren't
granted immediately upon swallowing (that would probably have been
easier), but only once a corpse is created and then entirely digested.
I'm not sure if this is too powerful and was being avoided deliberately
for that reason, since it includes potential level gain from wraith
corpses in addition to other intrinsics. That's consistent with monster
purple worms but may be a bit too much in the hands of the hero, though
it is limited by needing the corpse creation roll to succeed.
Ray Chason [Sat, 8 Oct 2022 19:42:07 +0000 (15:42 -0400)]
Avoid null dereference in VESA initialization
If the VESA mode chooses a mode with 8 bit pixels, but the tile set
has too many colors for that, a null dereference can result when
trying to set up the nonexistent palette. Catch this condition and
refuse to set VESA mode instead.
PatR [Fri, 7 Oct 2022 08:07:43 +0000 (01:07 -0700)]
fix github issue #894 - guardian nagas can't grab
Issue reported by eakaye: for a 'hugs' attack to succeed, the
monster must have at least three attacks and the two preceding the
hug attack need to both hit. Guardian nagas had three attacks but
the first was melee 'bite' and the second was ranged 'spit'. Those
are mutually exclusive, so they would never both hit and nagas never
grabbed their prey.
Make the spit attack be first, the bite attack be second, insert a
touch attack for 0 damage third, and make the hug be fourth. Also,
change their hug damage type from 'phys' to 'wrap'. The first and
2nd+3rd+4th are still mutually exclusive.
The resulting message feedback left something to be desired and has
been tweaked.
The difficulty-level formula used by deprecated 'makedefs -m' now
generates 17 rather than 16 for guardian naga so I changed revised
monster to match. They are definitely more difficult now that their
constriction attack has a chance to hit.
nhmall [Fri, 7 Oct 2022 00:57:54 +0000 (20:57 -0400)]
warning fix
../win/curses/cursmain.c: In function 'curses_init_nhwindows':
../win/curses/cursmain.c:157:17: warning: unused variable 'pdc_font' [-Wunused-variable]
157 | static char pdc_font[BUFSZ] = "";
| ^~~~~~~~
../win/curses/cursmain.c: At top level:
../win/curses/cursmain.c:157:17: warning: 'pdc_font' defined but not used [-Wunused-variable]
PatR [Wed, 5 Oct 2022 10:40:35 +0000 (03:40 -0700)]
"no monster to remove" for steed knockback
Reported directly to devteam, mounted hero whose steed got hit
for knockback effect triggered impossible "no monster to remove".
In addition to fixing that, this makes a knockback attempt at a
hero who is stuck to a cursed saddle knock the hero and steed back
instead of knocking the hero out of the saddle.
mhurtle_step() should be able to use u.ux0,u.uy0 to update the
hero's old location after moving the hero in order to move the
steed, but the value was different from what was expected and the
map showed stale steed symbol when I used that. I'm not sure what
is going on there; saving u.ux,u.uy before moving the hero worked
as intended so I didn't pursue it.
nhmall [Tue, 4 Oct 2022 23:09:54 +0000 (19:09 -0400)]
latest Xcode build issue
An Xcode update has started causing the same problem that was experienced on
Linux with newer compiler or glibc a while back.
˜
In file included from monst.c:6:
In file included from ../include/config.h:670:
In file included from ../include/integer.h:54:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:32:
/Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:302:39: error: too few arguments provided to function-like macro invocation
^
1 error generated.
make[1]: *** [monst.o] Error 1
Please enter the commit message for your changes. Lines starting
PatR [Tue, 4 Oct 2022 22:21:04 +0000 (15:21 -0700)]
more PR #891 - build fix
More tty-specific hangup handling. There's still doubt about the
origiinal testing, but not about testing after "post bitrot repair",
if there was any. That wasn't useful because the new code was
accidentally suppressed by testing a misspelled macro. when deciding
whether to include it.
Pull request from entrez: the conditional hangup handling in
wintty.c hasn't been getting used because the HANGUPHANDLING macro
from the core was misspelled as HANGUP_HANDLING.
The old testing was probably invalid since it was most likely done
with the same misspelled #if. I haven't done any new testing so
since this should be considered potentially buggy.
Michael Meyer [Tue, 4 Oct 2022 17:20:12 +0000 (13:20 -0400)]
Fix HANGUPHANDLING ifdef for TTY
The SIGHUP handling for the TTY windowport added in 594cb5f was wrapped
in '#ifdef HANGUP_HANDLING', but the actual define is 'HANGUPHANDLING'
without the underscore.
PatR [Tue, 4 Oct 2022 22:03:35 +0000 (15:03 -0700)]
github issue #890 - hobbit #chat feedback
Issue reported by eakaye: the alternate hobbit chat message is a
complaint about dungeon conditions, given if its current HP is 10
or more less than its maximum HP. But since hobbits are level 1,
they will almost never have 10 HP so won't be alive to chat when
at max minus 10.
Keep the old behavior if maximum happens to be more than 10, but
give alternate feedback when less than max if max is 10 or less.
PatR [Mon, 3 Oct 2022 22:53:35 +0000 (15:53 -0700)]
getting knocked off flying steed
I was trying to reproduce the reported "no monster to remove" warning
from remove_monster() when a mounted hero was knocked off jabberwocky
steed but so far haven't been able to.
While trying, I came across a more minor bug. The hero got knocked
off a flying steed and got feedback of "you fly off" rather than
"you fall off". Flying capability came from the steed and dismount
feedback is aware of that but calls u_locomotion() which isn't. This
commit fixes that.
This adds some groundwork (DISMOUNT_KNOCKED) for better dismount
control. With a map fragment of
|....
|.Du.
|....
I got knocked off my steed by the attacking dragon and ended up with
|..@.
|.Du.
|....
It would be better to prefer spot 1, then the 2s, then 3s, then 4s
(not sure about farther spots if none of those are available)
|.432
|.D@1
|.432
when forced to dismount by knockback. This does _not_ implement that.
PatR [Sun, 2 Oct 2022 19:42:12 +0000 (12:42 -0700)]
fix wishing help for X11
Pass the wait-for-response arg when displaying the wishing help text
window. tty, curses, and Qt waited regardless, but X11 honors the
no-wait request. It was showing the text window then letting the
core immediately resume, resulting in reissuing the wish prompt on
top of the help window. Entering a successful wish then dismissed
the prompt but left the help on the screen, possibly obscuring the
map depending on placement.
PatR [Sun, 2 Oct 2022 01:14:59 +0000 (18:14 -0700)]
fix github issue #679 - orc strength
Reported by eakaye: orcish hero has maximum strength of 18/50 but
hero poly'd into an orc was given 18/100 strength. Also, a comment
from vultur-cadens pointed out that orcish heroes start with poison
resistance while monster orcs lack it.
Even though the boost to 18/100 is only temporary until the poly
times out, make orcs a special case where strongmonst from poly'ing
into them only gives 18/50 strength instead of 18/100. Adopt the
suggestion that Uruk-hai be an exception and continue to give hero
poly'd into them 18/100.
If any gnome becomes strongmonst (currently none are), treat them
as 18/50 too. Elvenking and elf-lord are strongmonst; treat their
forms as plain 18 though, matching the limit of elf heroes. Lesser
monster elves aren't strongmost.
While in there, add another special case so that hero poly'd into a
giant gets 19 strength. Monster giants are still plain strongmonst
so might warrant some sort of adjustment.
Give orcs poison resistance, but eating their corpses doesn't provide
an opportunity to confer it. Note goblins and hobgoblins still don't
have the resistance (to distinguish them from orcs a bit).
Take away strongmonst from orc shamans and give it to orc mummies.
Human mummies should have it too (at least according to movies) but
I didn't alter them becuase they're already pretty dangerous at the
point they start occurring. Take away strongmonst from plain 'elf'
placeholder.
New: when hero polymorphs into a form that lacks the strongmonst
attribute, take away any exceptional strength (drop 18/01 through
18/100 down to 18; as mentioned above, the drop is only temporary).
There's no attempt to set the maximum even lower for wimpy forms.
PatR [Sat, 1 Oct 2022 09:35:51 +0000 (02:35 -0700)]
use Norep() for searching while engulfed
Suggested by entrez: when you search while engulfed the feedback asks
whether you're looking for the exit, but the joke about the exit isn't
funny when repeated over and over which happens if the player waits to
be expelled by using 's','s',... rather than '.','.',....
PatR [Sat, 1 Oct 2022 09:34:28 +0000 (02:34 -0700)]
fix #K3739: engraving in dust mentions frost
[sic] should be "engraving in frost mentions dust"
Writing on ice with fingers is described as writing in frost, but if
you overwrite an existing engraving rather than add to it the game
said you wiped out the engraving in the dust (immediately followed
by writing in the frost).
Not mentioned in the report: finishing a multi-turn engraving on
ice had the same problem.
Pull request from entrez: X11's get-extended-command widget
allocated 1 extra byte for a couple of end-or-array terminators
and then wrote more than 1 byte to them when initializing its list
of extended commands.
Michael Meyer [Fri, 30 Sep 2022 00:22:00 +0000 (20:22 -0400)]
Fix: X11 extcmd menu heap buffer overflow
Instead of allocating space for ((n + 1) * size) (to make room for all
entries plus terminator), it allocated space for (n * size + 1).
init_extended_commands_popup would therefore write past the end of the
memory allocated for command_list and command_indx when trying to store
their respective terminator entries. This meant the X11 windowport
would crash when accessing the extended command menu, if NetHack had
been compiled with -fsanitize=address.
I also did some minor cleanup/refactoring to eliminate variables and
lines that were made redundant or useless by 9d64d13, which changed the
way the function worked and removed the need for things like tracking
indices in the source and destination arrays with separate variables.
A change to the curses interface from three years ago to make sure
that round-off didn't make the horizontal and vertical clipped map
indicators appear to not be clipped was using ROWNO for both instead
of COLNO for the horizontal one. For modest clipping the mistake
was unnoticeable; I don't know whether that remained true for more
extreme clipping.
[Not fixed: the curses scrollbar stuff ignores the fact that map
column 0 is unused.]
warning: for tile 250 (numbered 250) of objects.txt,
found 'huge chunk of meat' while expecting 'enormous meatball'
../win/share/objects.txt: 460 tiles
Make the prompt for single genocide be more precise
from: What monster do you want to genocide?
_to_: What type of monster do you want to genocide?
and the re-prompt for it be slightly more verbose
from: What... [type the name of a monster]
_to_: What... [enter the name of a type of monster]
Also, make the already verbose re-prompt for class genocide even
more verbose
from: What class... [type the symbol representing a class]
_to_: What class... [type the symbol or name representing a class]
Possibly should have changed 'type' to 'enter' on the last one to
keep them consistent but I left that as-is.
Pull request from entrez: genocide prompt has a short explanation
appended. Skip that on first try, and on all tries if 'cmd_assist'
option is Off.
For class genocide, don't retry an unlimited number of times if
player supplies an empty response. Any empty response will now
count toward the 5 chances available to supply a valid choice, as
it does with single genocide.
Michael Meyer [Wed, 28 Sep 2022 01:08:30 +0000 (21:08 -0400)]
Show genocide prompt help iff 'cmdassist' enabled
The "[type the name]" prompt seems appropriate for handling via
cmdassist, so experienced players who don't need the help can hide it.
I also added a corresponding help note for the class genocide prompt.
Michael Meyer [Wed, 28 Sep 2022 00:47:57 +0000 (20:47 -0400)]
Don't screen out empty input in class genocide
So that a blank line wouldn't use up one of the player's "tries" for
class genocide, the game would continue to prompt until the input was
non-blank (or the user hit <esc>), with a tight loop around the getlin
call that only exited when it got some non-empty input. This apparently
risked leaving the game endlessly looping under some worst-case-scenario
hangup conditions. It was also inconsistent with normal genocide, which
doesn't have special handling of blank lines. Make the class genocide
prompt behave like the normal genocide prompt by removing the "blank
input" loop (and consequently treating a blank line the same way as any
other attempt to write a name).
Pull request from chasonr: if the curses interface did a full screen
update while the game was ending, it could attempt to refresh windows
that had already been removed.
For #if PDCURSES, raw_print() could attempt to write to the message
window after it had been removed.
[Why is raw_print() using the message window at all? Isn't the main
point of it to bypass that?]
Ray Chason [Wed, 28 Sep 2022 00:57:09 +0000 (20:57 -0400)]
Fix undefined behavior when exiting Curses
* When saving: curses_exit_nhwindows calls curses_uncurse_terminal,
which calls endwin. curses_exit_nhwindows then calls raw_print,
which calls more Curses functions after endwin has been called.
Fix this by having curses_raw_print use puts if window_inited
is false.
* When dying, quitting, etc.: really_done opens the "Goodbye" window,
which refreshes the other windows when it closes. But the status
window (and possibly the map and message windows) are gone by that
point. The window pointers are properly NULLed, but the NULL is then
passed to touchwin. Fix this by checking window pointers for NULL.
Michael Meyer [Thu, 25 Aug 2022 01:38:56 +0000 (21:38 -0400)]
Fix: IS_SUBROOM_INDEX range
The macro (currently unused, I think) for checking whether a particular
index designates a subroom was off by one on the maximum allowable
value.
Because of the dedicated extra space for the g.rooms array terminator
flag (hx == -1), subroom indices in g.rooms are set out in the range
[MAXNROFROOMS+1, MAXNROFROOMS*2], inclusive.
Pull request from vultur-cadens: don't change unID'd gem prices
when source changes insert some new object before them or the game
gets rebuilt with different featues enabled such as MAIL.
This is more about keeping the spoiler table in the wiki accurate
than anything to do with game play. It definitely gives players
who use spoilers an advantage over ones who don't, but does so in
such an insignificant aspect of play that it likely doesn't matter.
I'm fairly sure that the remark that keeping the prices the same
is what the original implementor intended is not correct. I don't
recall who implemented this and the commit log for the first cvs
repository is long gone so it's moot.
Make the token selling prices for unidentified gems not depend on how
many items were defined before FIRST_GEM. Now the unidentified gem
selling prices will depend only on the number and defined order of the
types of gems, and won't inexplicably change when objects are added,
or depend on compile-time options such as MAIL.
Also don't do the regular item price reduction for unidentified gems,
since they are already not based on the actual value. This restores
the pre-3.6 behavior, allowing players to gain a bit more information
from the nominal selling prices of unidentified gems.
Whoever first introduced this special handling for gems probably
intended for players to be able to gain information from gem prices
this way, but probably nobody has been doing it since 3.6.
rename "huge chunk of meat" to "enormous meatball"
Pull request #607 by Vivit-R proposed renaming "huge chunk of meat"
to "giant meatball" to better reflect the similarity to meatball.
But an object name that contains a monster name prefix requires extra
work in the wishing code. I considered "huge meatball" which retains
more of the original name but decided to go with "enormous meatball"
becaues it seems more evocative.
> I'm not sure whether gcc 3 is really the right test for whether the
> returns_nonnull attribute setting is available.
The gcc.gnu.org website only goes back to 5.1, and searching the
documentation of that version for returns_nonnull finds it. I used
ftp to get gcc-core-3.0.0 and gcc-core-4.0.0 and their doc files don't
mention this attribute. It might have been added for some later 4.x
but that really doesn't matter for nethack's purposes.
Use __GNUC__ >= 5 instead of __GNUC__ >= 3 when testing whether
__attribute__(returns_nonnull) is available.
The menu to interactively set the windowborders option for curses
uses 'a'..'e' for choosing 0..4. Accept '0'..'4' (via unseen group
accellerator) too.
projects / nethack / log