Sitting on a squeaky board wasn't triggering it even after the
handler for that type of trap allowed VIASITTING to override Flying.
The check_in_air() test for floor traps didn't have the same override,
so the squeaky board handler didn't get called.
This fixes that, which led to inconsistency with some other trap
types, and additional fixes for pits and bear traps. There might be
others that still behave oddly. For example, if flying over a hole,
using #sit yields
|You land. There's a gaping hole under you! You don't fall in.
I think that's a message phrasing issue rather than a falling trap
issue; if you want to go down, use '>' instead of #sit. On the other
hand, you do now fall into pit traps for #sit while flying over them.
If the hero deliberately sits on the floor while flying over a squeaky
board, then either they're trying to squeak it on purpose or they haven't
noticed it. Either way, sitting should trigger it.
Issue reported by vultur-cadens: tame monsters capable of using items
would pick up cursed ones and even wear cursed armor.
The report cites commit 6c9700ab25 but
I don't see any reason why it would be the cause. However, I was able
to reproduce the misbehavior and this commit seems to fix it.
Fixes#1072
Pull request from vultur-cadens: writing an unknown spellbook will
succeed if corresponding spell is well known (feasible via divine gift
in 3.7 or object amnesia in earlier versions). When nearing the point
of fading from memory, Luck is still required but non-wizards only
need the much lower wizard amount. If already forgotten, the chance
to write the book remains the same as if the spell wasn't known.
Closes#1069
Allow hero to write an unknown spellbook if the spell is freshly known
(from divine knowledge). If the spell is going stale, the chance of
successfully writing the spellbook depends on Luck, but only rnl(5)
(like a Wizard) instead of rnl(15). Forgotten spells do not help when
writing unknown spellbooks.
Pull request from entrez: pits created by breaking a wand of digging
or applying a drum of earthquake used to be able to destroy altars
but a change to prevent placing traps on 'furniture' unintentionally
caused that to stop working.
Closes#1057
Especially powerful magic is meant to be able to destroy altars
(breaking a wand of digging or using a drum of earthquake), but it was
being blocked by a check added to maketrap() in a7f6460 designed to
prevent wizard-mode trap wishing from overwriting stairs. The check was
refined in 6a3d82c to add an exception for digging up graves, but
continued to prevent the destruction of other types of
previously-destructible terrain.
Since this block was a side effect of an attempt to add some guard rails
to wizmode terrain wishes, and the code to explicitly permit the
destruction of other furniture with especially powerful magic is still
present, it doesn't seem like it was actually intended. Open up terrain
destruction by digging magic a bit more by excluding only
non-destructible terrain, not all furniture other than graves, from
being overwritten by pits and holes.
Also, use AM_SANCTUM to more precisely identify non-destructible high
altars in dig_check() rather than checking whether the hero is on the
Astral or Sanctum levels.
Pull request from entrez: when creating a detached theme room of type
"water-surrounded vault", make sure that one of the chests contains an
item that could be used to escape from the room in case hero arrives
via trap door or [level] teleportation.
Closes#1051
Water vaults are one of the few places that can/will generate completely
sealed off in a normal level. Other such spots are designed to provide
a guaranteed means of escape (vault guard, scrolls of teleportation in
niches, etc) -- water vaults were an exception that didn't do this, so a
hero who fell into one from above could have ended up in a position
where she had no choice but to wait to starve to death or #quit. Provide
an escape item in one of the vault's chests to give a hero more options
in that position.
Also fix a minor mistake (I'm pretty sure, though I'm not a Lua expert
enough to be certain) in an nhlib.c comment describing how to use
obj.addcontent() -- when called as box.addcontent(contents) as the
comment suggested it produces an error, but works OK when called as
box:addcontent(contents) or obj.addcontent(box, contents).
Issue reported by vultur-cadens: arriving on the Mine Town level
via falling or level teleport won't register the "entered Minetown"
achievement if hero doesn't arrive inside a room.
Reorder some code in check_special_room() so that town entry will be
tested before the early return if no room entry has occurred. This
adds 'level.flags.has_town' to make the town test be cheaper when
the hero hasn't attained the achievement yet and is wandering around
the mines.
Fixes#1070
Pull request from entrez: the legend for wizard mode #terrain wasn't
updated to include terrain type "lava wall", so the entries for it
and everything that followed were inaccurate.
I've expanded the comment about level type codes in rm.h.
Closes#1052
The "temporary?" levltyp[] array became desynchronized from the level
types enum with the addition of lava walls. This caused all level types
past that to be given the wrong description when it was used.
Add an explicit length to the array so that future additions to the enum
should produce a compiler warning if it's not updated at the same time.
The correct plural of "Cyclops" is "Cyclopes", not "Cyclopses". I don't
know if anyone would actually use that as a fruitname, but it wouldn't
hurt to add it -- especially since a Cyclops does appear in the game.
Pull request from copperwater: if a special level's lua file
specified invalid coordinates for some things, the code in sp_lev.c
might use them instead of rejecting them. This could lead to severe
problems. Presumeably the existing special levels aren't affected
by this.
Closes#1034
Revealed this bug when testing the previous commit:
Themed room generation with a randomly placed map involves picking a
single random point on the map at which to plop it down, and then
declaring the themed room failed and exiting if it would go beyond the
map bounds or overlaps with an existing room. In the process,
xstart/ystart/xsize/ysize have been modified, but weren't getting reset.
(They would get reset if the map successfully got placed and it had a
contents function, as of commit 4af086b, but there wasn't handling for
the failure to place it.)
I traced a memory corruption bug in xNetHack to a themed room that
looked something like this:
function()
des.room({ type="themed", contents = function()
des.feature({ type='sink' })
...
end })
end
Placing a feature at a random spot within a room or region is a
reasonable thing for the parser to handle, but the code was not equipped
to handle it, and so the unspecified x and y set as -1 got passed
directly to SP_COORD_PACK, ending up as coordinates way off the map.
Since sel_set_feature does not do an isok() check, this ended up writing
data to unrelated memory.
This commit does the following things:
- Enables des.feature() with no coordinates specified, both via a table
with 'type' set, and as the single string argument. When no
coordinates are specified, it will pick a random normal-floor spot
within the enclosing room or region if there is one, or anywhere
on the level if there isn't.
- Prevents sel_set_feature from corrupting memory outside
g.level.locations. Additionally, if EXTRA_SANITY_CHECKS is defined and
this gets attempted, it causes an impossible.
- Guards the existing "door coord not ok" Lua error with an immediate
return from lspo_door.
- Adds similar "coord not ok" errors to all the other locations in
sp_lev.c which did not already check for a unspecified/invalid
coordinate and for which a random coordinate is nonsensical:
des.terrain(), des.drawbridge(), and des.mazewalk().
The FIXME comment noted that builds_up would return an incorrect false
value for a dungeon branch that builds upwards but is only 1 level, but
that this is a latent problem because no such branch exists in NetHack.
Such a branch does exist in xNetHack, and it causes the debug fuzzer to
crash ("mon_arrive: no corresponding portal" because it can't find the
correct-direction stairs), so I figured I might as well fix it upstream.
Pull request from copperwater: accept 'true' or 'false' (also 'yes'
or 'no') in des.object specification for 'trapped'.
After resolving a merge conflict one diff band of this went away, but
the settings of otmp->otrapped from o->trapped and otmp->greased from
o->greased without it look ok to me.
Closes#1032
I thought there were more object fields that currently only accept ints
but ought to accept booleans, but when I checked I found that most of
them do already, and the ones that take ints are the ones that the
number carries meaning (spe, recharged, etc).
Except for trapped. In struct obj, otrapped is a 1-bit flag, so there's no
good reason for the level parser to treat it as a type error if someone
intuitively makes a des.object call with trapped=true or trapped=false.
Change it to an optional boolean argument, like the other boolean flags
(locked, greased, etc).
Note that get_table_boolean_opt still accepts ints, so existing uses of
trapped=0 or trapped=1 won't be affected.
Something that's reasonable to expect to see in Lua files is something
like:
local sel4 = sel1 - sel2 - sel3
or more generally, producing a selection from subtraction that will then
be used in subsequent selection math.
I discovered this wasn't actually working correctly, and that it also
applied to the xor operation. The reason behind this is that
l_selection_sub and l_selection_xor create a new selection from nothing,
which by default has "lower" bounds of COLNO, ROWNO and "upper" bounds
of 0,0. Iterating across the intersecting rectangle of both selections
does not reliably set the bounds of the resulting selection properly,
since the first selection_setpoint with a value of 0 will cause the
selection's bounds_dirty flag to be set, at which point they will cease
to change as more points are added.
Then this selection with its incorrect boundaries is pushed back onto
the Lua stack, and becomes the first operand of the next subtraction
(i.e. selr in the first l_selection_sub becomes sela in the second
l_selection_sub). Depending on how broken the bounding box is, results
may vary, but if the bounding box is still (COLNO,ROWNO,0,0), the
resulting selection will have no points selected at all.
This fixes this problem by forcibly recalculating the bounds of the
result selection, so any subsequent operations on it will be valid.
I was looking to see what the impact of converting glyph_to_cmap() to
a function might have and noticed a couple of places where the macro
edition is passed a non-trivial argument. Since it evaluates that
argument many times, there is hidden overhead. Fetch the glyph once
and pass that to glyph_to_cmap().
This will no longer be very useful--but won't need to be reverted--if
PR #1022 gets incorporated.
do_positionbar() has bugs (only matters for MS-DOS).
Pull request from NulCGT: make statues created for statue traps be
5 to 10 points higher in difficulty than the default would be.
5 to 10 points of difficulty higher is already used for figurines.
The pull request chose the same amount but I've reduced it to 3 to 6.
Partly so that they won't be the same, partly so that they won't be
too hard when activated, and partly so that the creature won't be
quite as obvious a give away that the statue is a trap.
Closes#1009
Pull request from NulCGT: when a doppelganger is choosing to become
a fake player, get role from an entry in the high scores file. Use
that entry's name too if the doppelganger is within view at the time.
I'm not sure how well this will work for a single user score file if
the player always runs the same role and name. I've given it a small
chance (1/13) to ignore the topten and stay with random role instead.
Closes#1008
I saw this in the YANI archive, and I think it's fairly interesting.
Doppelgangers are known for commiting identity theft, but in NetHack
they function as just another shapeshifter. This commit makes them
a bit more interesting, I think.
Original YANI by aosdict and Andrio.
Pull request #1005 introduced some code that needed minor reformatting.
This goes beyond that, splitting the livelog/#chronicle handling and
the vampire unshifting code out of mondead() into separate routines.
The livelog phrasing for death of a unique monster always assumed that
the hero was directly responsible:
"killed|destroyed <unique mon|shk+details> (Nth time)."
If it dies while monsters are moving, switch to:
"<unique mon|shk+details> has been killed|destroyed (Nth time)."
It isn't phrased as if the hero is responsible if the monster dies due
to passive counter-attack against poly'd hero but that isn't blatantly
wrong and doesn't seem worth worrying about.
The livelog message includes the shopkeeper's shop type, since the
livelog for stealing also mentions the shop type.
Only the first kill per shopkeeper is logged.
The command name is expected to be short and the menu description is
expected to be short, but use a bigger buffer for the combination of
the two just in case.
In the paranoid_confirm submenu for 'm O', dynamically substitute the
correct key into the description of the 'swim' choice if #reqmenu is
bound to something other than 'm'.
Issue reported by ostrosablin (and mentioned previously but I still
I haven't remembered where): loading a roguesymset removes any utf8
data that has been set up for primary symset. The curses interface
explicitly initializes roguesymset to the default set and if config
file has specified OPTIONS=symset:Enhanced1 (or some other uft8 set
if someone adds such), that stays the active set but no longer gets
rendered with the intended symbols.
I have no idea whether having symset and roguesymset both use uft8
with different symbols and/or colors works at all and if so whether
it will still work after this revision, but this prevents loading one
set with non-utf8 while the other still uses utf8 from clearing out
the cached utf8 data.
Closes#1026
