It seems surpristing that no one has noticed this since the code that
is responsible has been present for six months. Inventory list at
end of game included bogus "? - (list likely candidates)".
Grimtooth is now permanently poisoned, protects the wielder from
poison, and can be invoked to throw poison.
Permapoison code comes from xNetHack by copperwater <aosdict@gmail.com>.
Pull request from copperwater: reorganize the theme rooms data so
that a room or a fill can be chosen by name, and when in wizard mode,
consult environment variables THEMERM and THEMERMFILL during level
creation to provide control over which theme rooms/room fills to
generate.
I reverted a commit that did a bunch of reformatting to themerms.lua
because to caused substantial merge conflicts. I will redo at least
part of it.
Closes#1384
If user has changed the stone glyph to something other than a space
(or uses a tileset), Sokoban levels showed the unreachable stone outside
the map area. Prevent marking those areas as seen, so the stone
glyphs aren't shown.
Disarming a chest trap was setting obj->tknown = 0 even though the
hero just discovered that it isn't trapped.
Triggering a chest trap behaved similarly. Since there are no
repeating chest traps, hero should know that the chest whose trap
just went off is no longer trapped.
chest_trap() didn't document its return value but was clearly meant
to return True if the chest was destroyed. It didn't handle that
correctly when the chest was being carried. However, none of the
callers actually use the return value. [This fix tracks whether the
chest gets deleted; a better fix would be to destroy an exploding
chest even when it is being carried.]
We've had reports of a couple of issues building against musl libc.
Issues reported:
- build procedures utilize col for Guidebook-creation, and col
is deprecated in distros that use musl libc
- some of the CRASHREPORT code is using library functions that
are not available in the musl libc environment. The reported
functions were backtrace() and backtrace_symbols(), which use
header file /usr/include/execinfo.h.
So we'll try to accommodate this. Since we don't have a means of
autodetecting the musl libc situation during the build (as of yet), the
builder will have to specify 'make musl=1' on the make command line.
Specifying 'musl=1' on the make command line will:
1. ensure that NOCRASHREPORT gets defined in the C preprocessor.
2. set COLCMD to be '../util/stripbs' instead of 'col -bx'.
Related to GitHub #1393
Issue reported by elunna: Using the 'F' prefix against a displacer
beast prevented swapping places.
This doesn't use the suggested fix. It is quite short but there is
a large diff due to change in indentation and reformatting several
comments because of that.
Attacking a displacer beast either with or without 'F' might miss,
hit, or swap places. It won't "harmlessly attack thin air."
Fixes#1377
It wasn't clear to me how selection.room() handles room edges and
unusual terrain in the room, so I looked at the code and wrote down how
it behaves for posterity.
I don't believe the one room currently capable of getting a random fill
while already containing some odd terrain, "Blocked center", actually
has unusual terrain in the room fill. This is because filler_region
creates an irregular region (i.e. a room containing the ROOM points in a
square ring around the blocked center). The points in the middle don't
share the same roomno, so they won't be returned in the selection
created by selection.room(). But there's no reason a room couldn't be
added in the future which does specify some nonstandard terrain and then
a themeroom fill.
Reported by k21971: applying an axe toward a location that contained
both a tree and a boulder (or statue) would use the axe to break the
boulder/statue rather than chop down the tree.
Different code is used to finish the dig/chop than is used to decide
whether the tool is appropriate for its target.
Fixes#1383
Issue reported by elunna: the definition of the Mitre of Holiness
specifies that carrying it should confer fire resistance but that
didn't work.
The Mitre's definition (added in 3.1.0) has always included that,
but such a capability had never been implemented. Wearing it didn't
confer fire resistance either--its definition doesn't bother to
specify a 'defend' attribute since the 'carry' one should cover that.
This adds carrying capability for damage types fire, cold, sleep,
disintegration, electrity, poison, acid, and petrification. Fire is
still specified by the Mitre; none of the others are currently used.
Fixes#1362
makemon() has a 1% chance to bestow a worn saddle when creating any
rideable monster. If that chance kicked in on a knight's starting
pony, an extra saddle would end up being created but not worn nor
in inventory nor on floor so not be freed when the game ended.
That 1% chance also overrode saddle suppression for pauper knights.
There wouldn't be any extra saddle but their pony could start with
one, against intent.
Have makedog() (which is only used for starting pet) tell makemon()
to suppress inventory when creating the initial pet.
Sanity checking was complaining about a no_charge obj in untended shop.
Angry shopkeeper was accepting thrown items as no_charge objects:
To reproduce the impossible, kick down the shop door angering
the shopkeeper. While the shopkeeper is still in their shop,
throw an item they don't want into the shop. Wait for the shopkeeper
to get out of the shop.
Move the anger checking before the sell auto-accept code,
so the shopkeeper will charge for the object.
Remove start_screen() and end_screen() from the
Window-port interface.
They were only ever used by tty, and there was a comment
carried to several window-ports about how they "really
should go away. They are tty-specific"
term_start_screen() and term_end_screen() are part of
terminal/NO_TERMS supporting routines now.
Issue reported by ostrosablin: having Kick enabled as one of the
values for the 'autounlock' option succeeded it prompting "kick it?"
when walking into a locked closed door, but answering "yes" behaved
the same as answering "no".
There's bound to be a better way of fixing this, but this works.
Fixes#1360
If water walking boots haven't been discovered yet and underwater
hero rises to the surface when putting a pair on, discover them.
(Sinking while removing such on water already discovers them.)
This originated with a bug in NerfHack in which the developer specified
an inventory for a quest nemesis, but neglected to include the Bell of
Opening in it. Since monsters' inventory contents from makemon() were
tossed out completely, this caused a situation where the Bell was
deleted and the game was unwinnable. The first part of this change is
guarding against that by adding mdrop_special_objs before discarding the
inventory. This does create a possibility where if the programmer *does*
specify a nemesis get the Bell item in their inventory, while neglecting
to remove its special case generation in makemon.c, it would generate
twice - but two Bells is better than none.
Working on that fix led me to think about a limitation of the current
sp_lev.c behavior. You could either have a monster generate with its
species-typical inventory by not specifying an inventory for it, or you
could have it generate with custom inventory but then have to use that
to clumsily reproduce the normal inventory's complex chances and
conditionals in mongets(). So the remainder of this commit implements
another flag for des.monster(), keep_default_invent, that allows for
more flexibility in two ways:
1. When des.monster() contains an inventory function and
keep_default_invent is true, the monster will retain everything it
gets from makemon() and the objects in the inventory function are in
ADDITION to those. This is useful for augmenting a monster's default
kit with something to make them more threatening, or just more loot.
2. When des.monster contains no inventory function and
keep_default_invent is false, the monster will get NO inventory even
if its species is normally supposed to. I'm not sure where exactly
this would be used, but it doesn't hurt to have it available.
When keep_default_invent is not specified at all, the behavior remains
the same as it is now - if inventory is provided, default items are
discarded, and if not, they are kept.
Remove the XP gain for tourist seeing a new type of monster
nearby, as it apparently made tourists a bit harder by forcing
early level gains.
Monsters next to hero are still marked as seen close-up, but
fix the code so it doesn't count undetected monsters.
Tourists still gain XP from "taking photos" of new types of monsters,
but only if they haven't seen the monster close up before.
(No actual photos are taken.)
Content:
* Document that the command has a default file list.
* Demote "COMMANDS" section to "Operations" subsection. The former term
is (1) too easily confused with Unix commands and (2) not a widely
used section heading in man pages.
Style:
* Italicize command names.
* Italicize file names.
* Use idiomatic man page cross references.
* Present operation and option letters in alphabetical order.
* Render option descriptions as full sentences.
* Set bug list as a bulleted list.
Markup:
* Break input lines at sentence boundaries.
* Favor use of man(7) font selection and alternation macros over roff(7)
font selection escape sequences.
* Drop numerous extraneous paragraphing macro calls. See subsection
"Horizontal and vertical spacing" of groff_man(7).
* Replace use of *roff requests to break lines and vertically space with
calls of paragraphing macros, which is what they're for. Two things
the page author didn't know: `.sp 1` already implies a break, so the
preceding `.br` was redundant. `.sp 1` without an argument already
means to vertically space by 1 vee; that is, the "1" argument was
superfluous. It was a bad idea anyway because the default
inter-paragraph spacing in man(7) is not one vee, but 0.4v--this
matters when typesetting. It has also been the case since 1979.
* Use `RS` and `RE` macros instead of a literal tab to achieve a
relative inset. Use of the macros is more idiomatic.
* Use `EX` and `EE` to attempt to set the examples in a monospaced font
family. These are extensions and are silently ignored by formatters
that don't support them.
groff_man(7):
.EX
.EE Begin and end example. After .EX, filling is disabled and a
constant‐width (monospaced) font is selected. Calling .EE
enables filling and restores the previous font.
.EX and .EE are extensions introduced in Ninth Edition Unix.
Documenter’s Workbench, Heirloom Doctools, and Plan 9
troffs, and mandoc (since 1.12.2) also support them.
Solaris troff does not. See subsection “Use of extensions”
in groff_man_style(7).
* Kill off useless trailing space on input line.
Follow Unix idioms and the guidelines presented in groff_man_style(7).[1]
* Present multiple synopses since the command has multiple operation
modes accessed via mutually inexpressible command letters. See the
POSIX standard for copious precedent.
* Stop implying that file name arguments are accepted alongside the `I`
option; see line 236 of util/dlb_main.c.
* Stop spacing around synopsis punctuation where unnecessary.
* Set metasyntactic variables (parameters) in italics, not roman or
bold.
* Spell ellipsis idiomatically for pleasant typesetting.
* Use `\c` escape sequence to force adjacency of tar-like option letters
to the mandatory operation letter.
* Use singular, not plural, for repeatable argument. The ellipsis does
the grammatical work of pluralization for us.
[1] Full disclosure: I wrote much of (the current form of) that man page.
Portions of these man pages seem at one time to have been dynamically
selected, but the mechanism for doing so appears to be commented out in
the source tree: see "NHGREP" in sys/{unix,vms}/Makefile.doc.
Wrap them in *roff "ignore blocks" to keep their noise from cluttering
the man page actually seen by the users.
Issue reported by ars3niy: with the relatively new container
handling, buying multiple items when some were inside a container
sometimes triggered impossible "unpaid_cost: object wasn't on any
bill" warnings and not buy all intended items. Once that occurred,
subsequent inventory display would repeat the warning.
A couple weeks back, I managed to produce a save file which would
reproduce the problem when 'p' was issued, but failed to figure
out why that was happening. I accidentally deleted that save file
and it took quite a lot of further attempts to get another one.
I still don't understand why this fix is needed, but with it in
place the save file no longer triggers any problems. I'm marking
the issue fixed but that could be premature.
Fixes#1339
