Reported by paxed 8 years ago: if a bones file contains a
doppelganger imitating a unique monster, when it gets loaded
that monster ends up being marked as having been created. The
doppelganger itself will shapechange to other forms, but the
unique monster won't be created when it should be because it has
become extinct.
Report involved creating a statue of a unique monster which
yields a doppelganger in that monster's shape, then using stone
to flesh to animate the statue, dying before it changes to some
other shape, and having bones be saved.
Pull request from copperwater: don't give "flash of light" feedback
when activating a level teleporter because it's too much like one of
the outcomes of a magic trap.
This doesn't use the suggested commit. Getting the "you feel
disoriented" feedback before being asked for destination level (when
having teleport control) seemed contradictory. This gives different
feedback and does so after the actual teleport.
Supersedes #850
and since nhcopier doesn't seem to understand "supersede"
Closes #850
Mark alloc()--also dupstr() and re_alloc()--for gcc and clang as
always returning non-Null. This should silence some of the static
analysis complaints.
Almost all the monster and object naming functions (anything that
returns an mbuf or an obuf) should be marked this way too but I'll
leave that for somebody else to deal with.
I didn't attempt to mark alloc() with the 'malloc' attribute because
macro definitions could end up causing trouble. Specifying its
deallocator would probably be useful but is at even bigger risk of
macro interference.
I'm not sure whether gcc 3 is really the right test for whether the
returns_nonnull attribute setting is available.
Year old issue from copperwater: 'open' directed at a non-door told
player that there isn't a door and took no time unless character was
blind and learned what type of terrain it is, applying a key gave
the same message but used a turn and didn't update map to reflect any
terrain discovery.
Attempting to open an adjacent door or applying a key to one while in
a pit had a similar issue: they produced the same "you can't reach
it from here" but had different time vs no-time outcome.
Noticed that an attempted terrain replacement wasn't taking hold even
though 'w' is supposed to mean "match any stone or wall"; this was
because w converts into non-terrain-type MATCH_WALL and replace_terrain
was doing a simple comparison on whether the potentially replaced
terrain matches that type. Add a special check here for w so it will
match the terrain types it's supposed to.
Note that using replace_terrain with 'w' now WILL match stone, since
this is the documented behavior of w, to match IS_STWALL rather than
just IS_WALL. If a level designer really wants to exclude stone, they
can work around this by either making a selection and filter out stone
terrain, or doing two replace_terrains with '-' and '|'.
Pull request from copperwater: the random traps specified by the
special level definitions of the tourist locate and goal levels could
be placed inside the shops present on those levels.
copperwater [Sun, 14 Aug 2022 00:04:25 +0000 (20:04 -0400)]
Fix: prevent traps in shops in the Tourist quest
The Tourist locate and goal levels have 2 shops each, and also have
various traps randomly placed on the level. Unfortunately, this does not
account for placing them in the shops, so it was possible to wind up
with a magic trap or falling rock trap or whatever inside the shop,
which the shopkeeper would not clean up.
This commit makes selections that exclude the shop areas, and picks the
traps from those selections, keeping the shop floors trap-free as their
customers expect.
Someone asked whether the 'magr' argument to artifact_hit() can be
Null or not since the code sometimes checks whether it is Null and
other times uses it unconditonally. The answer is "it depends."
Can't reply to asker due to forced anonymity when the contact form
was submitted.
Michael Meyer [Thu, 22 Sep 2022 02:19:42 +0000 (22:19 -0400)]
Prevent impossible fall dmg if falling up
The way hole destinations work now theoretically allows for a
cross-branch hole or trap door to move you across branches in a way that
decreases your overall depth. If this happened, it would cause an
impossible when the negative result of (depth(new) - depth(old)) was
used to calculate fall damage. Limit fall damage to 1d6 if dist <= 0.
Michael Meyer [Thu, 22 Sep 2022 01:25:25 +0000 (21:25 -0400)]
Apply trap door destination restrictions in dodown
Missed this way to use the trap door (in a block added in 05761ba) in
previous commits, though I'm a little confused about whether that block
in dodown is even reachable given how various trap scenarios are handled
with dotrap earlier in the function.
Michael Meyer [Thu, 22 Sep 2022 00:06:35 +0000 (20:06 -0400)]
Refine attempt to clamp trap door fall destination
This should prevent anyone from exploiting falling into the sanctum (by
taking advantage of a trap door in a bones file from a differently
laid-out dungeon, as described in the previous commit) to bypass the
invocation, in addition to falling past the actual end of the dungeon.
Michael Meyer [Wed, 21 Sep 2022 23:55:04 +0000 (19:55 -0400)]
Prevent hero from falling past end of dungeon
Similar story with saved trap door destinations: if a bones file near
the end of the dungeon came from a longer dungeon (i.e. with a
lower-depth castle) than the one the bones file is loaded into, the
trap door destination could be past the dungeon end. Clamp the
destination so it won't be lower than the bottom level of the dungeon.
Michael Meyer [Wed, 21 Sep 2022 23:44:27 +0000 (19:44 -0400)]
Have monsters' hole destination match the hero's
The fixed destination of a hole or trap door was being used for the hero
but not for monsters. Make everyone land in the same place, so you can
chase a monster into a hole and actually find it.
Michael Meyer [Wed, 21 Sep 2022 23:41:45 +0000 (19:41 -0400)]
Fix: antigravity trap doors
Trap doors saved their destinations as an absolute level, rather than a
relative one, so if you loaded bones from a special level their
destinations would reflect the dungeon layout from the bones player's
game. For example, die on the Oracle level, on dlvl5, with a trap door
that goes to dlvl6. Another player gets those bones on their Oracle
level, which is dlvl8... the trap door would still go to dlvl6. Pretty
amazing trap door -- something you might see in a funhouse!
Include relative rather than absolute destinations in save and bones
files, much like stairs do, to avoid this problem.
I bumped EDITLEVEL because although this won't break save files in an
obvious way, it will interpret the (absolute) destinations in existing
save and bones files as relative, leading to some crazy long falls. :)
Pull request from argrath nearly a year ago: an 'if' and corresponding
'else' have the same code so there's no point in testing for if/else.
I'm still not convinced that simply removing the if/else is the right
fix here but nothing else is going on. I've put part of the removed
code back inside '#if 0' in case it needs to be resurrected someday.
Pull request from entrez: the check for whether a pet in desperate
straits will eat a corpse that will cause it to polymorph used bad
logic. The suspect code was added post-3.6.
Michael Meyer [Tue, 20 Sep 2022 01:59:34 +0000 (21:59 -0400)]
Fix: starving herbivore pet vs polymorphing corpse
The special handling of polymorphing corpses included an "is acceptable
food if starving" rule which ignored the pet's other food preferences,
so a starving herbivorous pet would become willing to eat a
non-vegetarian corpse iff the corpse would polymorph it when eaten.
Along the same lines but latent: if there were a vegan polymorphing
corpse, a carnivorous pet would eat it not only if starving, but also if
maltreated and on the verge of becoming feral.
Instead of trying to fix this by reimplementing all the herbi vs carni
rules specifically for polymorphing corpses, just have a "don't eat
polymorphing corpses if neither starving nor almost untame" rule, and
fall back to the normal palatable corpses tests once it's been
determined that the pet is willing to eat even a polymorphing corpse.
I rephrased the comment just to make it negative (about avoiding
polymorph, rather than polymorph being OK under certain circumstances)
to match the new form of the rule.
Michael Meyer [Wed, 24 Aug 2022 17:08:46 +0000 (13:08 -0400)]
Describe engulf attacks a bit more consistently
Use verbiage for mon vs mon and hero (mostly hero) engulf attacks that
matches recent changes to monster vs hero engulf attacks more closely
(e.g. "swallows whole" instead of "engulfs" for purple worm, other
changes in b07fe59...). Also ensure non-AD_DGST engulf attacks
(e.g. from revamped trapper or lurker above polyforms) aren't treated as
"eating" (or as involving "debris").
Also change the enfolds and digests macros so they produce booleans
rather than attack pointers (I got a compiler warning about casting
struct attack * to boolean when I did 'boolean b = digests(ptr);').
fixes entry and tweaks for PR #871 - revive corpse
Pull requet from entrez: give better feedback than "it" when hero
observes a corpse reviving into a monster that can't be seen.
Tweak reviving from a container which was coded as if the container
was optional. That can lead to confusion when someone reads the
code so make the situation more explicit.
Michael Meyer [Sat, 10 Sep 2022 03:07:57 +0000 (23:07 -0400)]
Improve description of invisible mon revival
An invisible monster reviving would be called "it" (as in, "It rises
from the dead!"). Improve on this a bit by instead saying that "the
troll corpse disappears!" (similar to the messaging used when undead
turning is used on an invisible monster's corpse), or calling the
revived monster "something" (as in "something escapes from a sack!")
instead of "it". Distinguish between the original location of the
corpse and the location of the revived monster when describing seeing
things that have happened to the corpse, since revival may not place it
on the corpse's location.
Pull requet from vultur-cadens: use space instead of hyphen in
enlightenment and end-of-game feedback.
All the other resistances already use space. The inappropriate
hyphen in "disintegration-resistance" seems to have been present
since enlightenment was added (in 3.0; back then the relevant code
was in cmd.c; current insight.c didn't exist until 3.6).
when splitting a stack of named, shop-owned objects
Pull request from entrez: when perm_invent is on, splitting an unpaid
stack would issue impossible "unpaid_cost: object wasn't on any bill"
while cloning the new stack's name from the old stack.
Michael Meyer [Sat, 17 Sep 2022 02:50:39 +0000 (22:50 -0400)]
Fix: impossible from splitting named stack on bill
Trying to split an unpaid stack of named items in a shop, with
perm_invent enabled, would cause an impossible 'unpaid_cost: object
wasn't on any bill' because copy_oextra -> oname triggered an inventory
update while the newly created split stack was marked unpaid but before
the billing information had been split to match. Defer the copy_oextra
call until the billing info has already been split.
Change the handling for windowing system specific files so that
when building for more than one set, each gets compiled as a set
instead of some being interspersed among rival window systems.
Put differently, handle tile.o specially so that there's no need
for the hints to sort the WINOBJ list in order to avoid tile.o
duplication.
So the order of compilation is
common source files
unix-specific files
tty files
curses files
X11 files
Qt files
tile.c (if applicable), version.c, date.c
Previously, some of the X11 files were scattered around among the
others because of the spelling of their file names.
Only matters if you're watching the progress of a build.
Pasi Kallinen [Sun, 18 Sep 2022 09:35:30 +0000 (12:35 +0300)]
Themerooms: Engraving hints the location of buried treasure
Add two new themeroom functions that are called when generating
the level: pre_themerooms_generate and post_themerooms_generate,
calles before and after themerooms_generate.
Allow the buried treasure -themeroom to put down an engraving
anywhere on the level, hinting at the location of the treasure.
des.object contents function now gets the generated object passed
to it as a parameter.
options.c: In function ‘option_help’:
options.c:8820:55: warning: ‘%s’ directive writing up to 255 bytes into a region of size 220 [-Wformat-overflow=]
8820 | Sprintf(buf, "Set options as OPTIONS=<options> in %s", configfile);
| ^~ ~~~~~~~~~~
This reverts commit 94945a719afc0aa08eaff9aa1e0e2fbf159bf388.
It was too intrusive and can be handled by the 'onefile' script
by compiling isaac64.c before any source file that includes hack.h.
Issue reported by k2: tipping a wand of cancellation, bag of
holding, or bag of tricks from a non-magic container into a bag of
holding causes the bag of holding to explode but it wasn't dealing
out explosion damage nor being logged for livelog/chronicle the way
putting the item directly into a bag of holding is handled.
This fixes the described issues but bones handling leaves a lot to
be desired.
Reported by Umbire:
|You kill SpaceMannSpiff! SpaceMannSpiff puts on a dwarvish cloak.
|SpaceMannSpiff puts on a dwarvish iron helm.
|The seemingly dead SpaceMannSpiff suddenly transforms and rises as
| a Vampire.
This was tough to reproduce but I finally managed it. The issue
text mentions that it was fixed by copperwater in xNetHack with
commit 8c4af50f0aa3e72522f3eb98df039ff25c2a1ea0 to the repository
for that variant. My attempt to cherry-pick that failed--I'm not
even sure whether it should have been expected to work--and some of
the code has been impinged upon by changes, so I ended up applying
the contents of that commit manually.
The commit changes how/when monsters put on new armor rather than
anything directly related to vampires. Circumstances similar to
the example above now yield:
|You kill SpaceMannSpiff!
|The seemingly dead SpaceMannSpiff suddenly transforms and rises as
| a Vampire.
on one turn, then on the next turn the revived vampire produces:
|SpaceMannSpiff puts on a dwarvish cloak.
My test case only had one item of interest; I assume that the second
item of armor gets worn on a subsequent turn rather than at the same
time as the first one.
Require a free hand when tipping a container into another container.
Presumeably you need to open the destination container and possibly
keep holding it open.
If you try to tip a carried container into an unknown bag of tricks,
apply the bag (once) instead of performing the tip. (To 'open' the
destination as above.) Possibly slightly confusing if bag is empty.
When tipping a container, always ask for the destination instead of
doing that only when carrying other containers. Confirming floor
as destination can be annoying but having to do that sometimes and
skipping that sometimes is aggravating because it is error prone.
And floor is preselected so can be chosen with space or return.
(I wanted to change the selector letter for floor from '-' to '.'
and then keep '-' as an unseen group accelerator, but the latter
doesn't work for PICK_ONE so I've left '-' as-is.)
Don't display "monsters appear" after tipping a bag of tricks.
Monster creation gives feedback these days. (Comparable to recent
"summon nasties" fix.)
Pasi Kallinen [Thu, 15 Sep 2022 15:08:32 +0000 (18:08 +0300)]
Split themeroom shape from themeroom contents
Previously, the tetris-shaped rooms were always either
normal rooms, or turned into shops or other special rooms
in NetHack core. Now, the themed room lua code first picks
the themed room (which can be a themed or shaped), and some
of those will then pick a random filling (eg. ice floor,
traps, corpses, 3 altars).
Adds a new lua binding to create a selection picking locations
in current room.
The content-function in special level regions now get passed
the room data as a parameter.
For tipping purposes, a horn of plenty is treated like a container.
But using one as the source container in a container-to-container tip
wasn't supported. Implement that.
Also, #tip was offering carried bags of tricks as candidate containers
to tip some other carried container into. Only do that for ones which
aren't known to be bags of tricks (so when type not discovered yet, or
specific bag not seen yet due to blindness).
Ray Chason [Tue, 13 Sep 2022 23:49:56 +0000 (19:49 -0400)]
Sundry fixes for DOS 16-color VGA mode
To test 16-color mode, specify OPTIONS=video:vga explicitly;
autodetect will choose a VESA mode if it can.
* Draw tiles correctly when redrawing from panning or from changing
the map mode among text, tiles and overview. Previously, this would
draw everything with the tile at the hero's position.
* Draw corridor walls with the stone tile.
* Map the statue colors to the nearest neutral tone among the main
16 colors. This mainly affects altars and female cats.
* Fix the code that shows statues as the generic statue tile. This
code could be deleted, but the statues don't draw with the full
range of gray tones.
When tipping a magic-bag exploder from a sack or box into a bag of
holding, the choice of whether to call useup() or useupf() was
backwards. But nothing bad happened which is fishy.
Reported by k2: tipping one container's contents directly into
another container allowed transferring a wand of cancellation (not
mentioned: or a bag of holding or a bag of tricks) into a bag of
holding without blowing it up.
That's now fixed. There are other issues that this doesn't touch:
I think it's odd that you can transfer stuff from one carried
container to another but not from a carried container to a floor
container nor from one floor container to another one at same spot.
I didn't test shop billing so an not sure what happens when #tip
blows up a bag of holding and there are some unpaid items involved.
Using #tip on horn of plenty treats it like a container, but doing
that when it's carried doesn't offer the chance to tip its contents
directly into a carried container.
Tipping a carried container does not require free hands or even
limbs (for playability) but tipping such into another container
should require at least one free hand.
Renaming got_from_config[] (something that was done in the past)
to set_in_config[] (something to do in the future) is sufficient to
remove any confusion about why it is being set from 'O'. Since that
is the name of an enum value, use opt_set_in_config[] instead.
The definition of enc_stat[] got changed by a pull request nearly a
year ago ('const char *enc_stat[]' -> 'const char *const enc_stat[]')
but the separate declarations for it weren't changed to match.
Make the same change for hu_stat[]. Not sure why the pull request
didn't include it since the old declaration and the usage are same.
Reported seven and a half years ago: if you are in a vault but not
carrying any gold and the guard arrives, you're told "Follow me."
Then if you pick up gold while the guard is still in the wall breach
rather than out in the corridor, you would be told "I repeat, drop
that gold and follow me!" "Repeat" refers to the follow part but
sounds as if it refers to the drop-gold part which isn't actually
being repeated. Keep track of whether the guard has issued a drop
gold demand and use that to vary the wording of subsequent "I repeat"
message.
Modifies monst->mextra->egd so save and bones files are invalidated.
Pasi Kallinen [Fri, 9 Sep 2022 09:03:08 +0000 (12:03 +0300)]
Fix traps generated inside walls
When fuzzing, noticed a trap generated inside a wall. Culprit
was one of the themed rooms that generates a rectangular room and then
puts freestanding wall columns inside. Note in somexy that it can
return a non-accessible location, and change the places that used
it and absolutely needed a space to somexyspace.
For a compound option's value that uses getlin(), cancelling with
ESC wasn't dismissing the menu and could eventually result in a
"No window slots!" panic. Clean up properly after ESC.
doset() and doset_simple() were sharing a format string but those
weren't the same if the longest option name differed. Stop sharing.
doset_simple() didn't support menu_tab_sep. Now it does. (Tested
with Qt; really needs to be tested with WinGUI. Enabling that is
expected to produce strange looking results with tty or curses.)
While testing the secret door message handling, I wanted to phaze
through solid rock to get near some secret corridors. Instead of
polymorphing into a xorn, I used #wizintrinsic to get temporary pass
through walls. That let me move orthogonally through rock but not
diagonally. Polymorph to xorn did allow diagonal movement. I think
the difference was gaining 18/100 strength in that form.
Have wall phazing override narrow diagonal checks.
When zapping a wand of secret door detection or casting spell of
detect unseem instead of displaying
|You reveal secret doors.
|You reveal a secret corridor.
|You reveal traps.
|You reveal a hidden monster.
show
|You reveal 2 secret doors, a secret corridor, 3 traps, and a hidden monster.
as a single message.
Detecting invisible monsters is still a separate message; those get
re-mapped as "remembered, unseen monster" but not actually revealed.
The pull request included some changes that were neither accidental nor
unintentional, so only a subset of the changes from pull request #869
submitted by klorpa were manually applied.
Move the guts of doset_simple() into a separate routine. Initially
that was just to avoid having to increase indentation when replacing
'goto' with 'do { ... } until ()'. It ends up making the flow of
control easier to see.
doset() and doset_simple() each had their own static flag indicating
whether 'fmtstr_doset' had been assigned a value. Redundant
assignment produced the same value so it wasn't an actual problem.
doset_simple() probably needs to add menu_tab_sep support for WinGUI.
Qt is able to get by without it, but that's because it forces use of
fixed-width font when any line in a menu or text window has 4 or more
consecutive spaces. I don't think WinGUI does that.
The menu for #herecmdmenu includes "look at map symbol" but if you
choose that it auto-picks the hero's location. Looking at your own
'@' isn't particularly useful so only include that menu option if
the symbol or tile being displayed isn't the normal one.
My /usr/include/curses.h has various A_attribute macros but A_ITALIC
isn't one of them. Compiling cursmisc.c failed because one of the
uses of that wasn't guarded by #ifdef A_ITALIC. Instead of adding the
ommitted #if, substitute A_UNDERLINE for A_ITALIC when that's missing.
The select attribute menu when adding a menu color or a status hilite
now shows an entry for italic that's underlined (as expected) but the
underline entry itself does not display any sort of attribute. I
didn't pursue that.
projects / nethack / log