Allow wishing for secret doors and secret corridors. It's a bit
more strict about where the wish is performed than wishing for
furniture. Implemented in order to test drum of earthquake effects.
I spent a lot of time figuring out SDOOR details that somebody
already knew at some point but evidently didn't document--you can't
specify D_CLOSED for them or the display code will issue impossible
warnings about wall mode angles.
When a drum of earthquake targets a secret door, reveal it (which
is always followed by collapsing the door), and when it targets a
secret corridor, reveal that corridor. Both situations also place
a pit at the location.
Drum of earthquake can try to destroy fountains, thrones, altars,
sinks, and graves but it wouldn't do so because maketrap() had been
changed to prevent clobbering furniture with traps. So you might get
"the throne falls into a chasm" but the throne would remain intact.
Change furniture to be floor before trying to create a pit. The gist
of the patch is the 'if' after 'do_pit:' and also some changes to the
revealing of hidden monsters. The rest is reformatting.
Don't allow dual-wielding if either wielded or alternate weapon
(or both) is a launcher: bow, crossbow, or sling. (I thought that
this had been addressed ages ago.)
Refine the "can't twoweapon" feedback. The message for having
either or both hands empty is the same, but sentence construction
is different. The not-a-weapon feedback is slightly different, now
mentioning whether it's the wielded or alternate weapon which isn't
allowed. The case where neither are acceptable still just reports
uwep; mentioning both it and uswapwep would be too verbose.
Make more things be described as "(wielded)" instead of "(weapon in
hand)". It was just stacks with quantity more than 1. That's now
joined by ammo and missiles (any stack size, but in reality just 1
since greater was already being caught here) and any quantity of
non-weapon, non-weptool. It's overridden if dual-wielding so that
right/left stay matched.
When dual-wielding, list primary as "(wielded in right hand)" and
secondary as "(wielded in left hand)" instead of "(weapon in hand)"
and "(wielded in other hand)". The vaguer wording was better for
bows since they're held in the off hand but now that they can't be
dual-wielded that doesn't matter. (Single-wielding a bow is still
"(weapon in hand)".)
When not dual-wielding, the item in the alternate weapon slot is
still described as "(alternate weapon; not wielded)" even if it's
not actually a weapon. I couldn't think of better phrasing.
Applying a spellbook allows the player to flip through the pages, providing an
indication of how many reads it has left before turning blank.
Originally from UnNetHack but code almost completely refactored and updated
for post 3.4 changes like deafness and novels.
When GOLDOBJ was activated unconditionally, several texts started referencing
"money" instead of "gold".
As we don't have the intention to introduce a complex coin system with
different denominations, change it back and also some other places that
reference "money".
The test for whether a migrating object generated as plundered
mine-town loot should be delivered to any orc created and then giving
that orc a bandit name was kicking in for orc mummies and orc zombies
as well as for regular orcs.
Also, the loot could include tins or eggs and their species would
get clobbered by the overloading of obj->corpsenm. During delivery
when the overloading was reset they would become giant ant eggs/tins.
(Not seen in actual play.)
Meat rings were causing increased hunger even though they don't do
anything. Not mentioned in the report, but cheap plastic imitation
amulets increased hunger too and they don't do anything either.
Trickier to fix, +0 rings of protection were excluded from hunger
on the grounds that +0 rings don't do anything, but since 3.6.0
+0 protection provides +1 to magic cancellation if protection isn't
coming from anywhere else. Two +0 rings of protection are trickier
still since only one of them provides the MC bonus.
Fixes#272
After the "make 'w' parallel with 'Q'" patch, wielding bare hands
was erroneously treating object id 0 as a split of zeroobj. That
isn't in inventory so seems 'lost'. Fixed by testing for nonzero.
There was another bug: you could wield a partial stack even if your
current weapon was cursed. Fixed by reordering if/else-if/end-if.
Change the composition of worm tooth from none-of-the-above to bone
and crysknife from mineral to bone, same as is used for unicorn horn.
I think the only significant difference will be that worm teeth used
up during polypiling will produce skeletons rather than flesh golems.
Fixes#268
Originally requested by one of the hardfought admins
Adjust all active window ports (tty, curses, win32, Qt, X11) to store
the itemflags that they receive with each item.
Also, make those active window ports understand the new
MENU_ITEMFLAGS_SKIPINVERT flag by skipping any menu items with that
setting during invert_all and invert_page operations.
Build testing and rudimentary functionality testing was carried out
on each of the window ports listed above.
The code was also modified on some non-active window ports (Qt3, gem,
gnome) but it was not tested for build or function there.
The desired functionality expressed was to be able to select a
single object category, and use the @ "invert all" function to
exclude that one and select all the others.
The "invert all" function's behavior of also including things
like "select all" and BUCX menu items made the feature unuseful
for that purpose.
Subtracting one dungeon depth value from another had the subtraction
backwards and that yielded a negative value where a positive one is
expected. If NH_RELEASE_STATUS were to be set to NH_STATUS_RELEASED
then this was at risk of crashing (if the bad subtraction yields -2,
rn2(diff+2) would divide by 0) since rn2()'s argument isn't validated
for released version.
fixes37.0 was confused, listing a couple of things that aren't bugs
in 3.6 as general fixes. I suspect that the DLB one was fixed before
being exposed via git, so shouldn't be there at all.
If you're wielding a stack of N items, issuing the command to quiver
them asks whether you want to quiver N-1 of them (implicitly leaving
one wielded). If you answer no then you're asked whether to quiver
all of them. You could also give a count when picking the item to be
quivered and the stack would be split based on that.
However, if you have a stack of N items quivered, issuing the command
to wield them just did so, leaving the quiver empty. And picking an
item ignored any count, so even explicitly asking for 1 (out of N)
wielded the whole stack. Change 'w' to parallel 'Q'; if you try to
wield a quivered stack, you'll be asked whether to wield just 1 of
them. For no, ask whether to wield the whole stack. Or you can give
an explicit count when picking any stack in inventory to wield.
Both 'w' and 'Q' probably ought to handle the alternate/secondary
weapon similarly when it contains a stack. This doesn't address that.
Bite the bullet and add a special purpose boolean option to control
game behavior for random clairvoyance. When objects or monsters are
discovered, it normally issues "you sense your surroundings" and
performs a getpos() operation which allows the player to browse the
map by moving the cursor around and getting 'autodescribe' feedback.
But there have been complaints that once the hero has the Amulet
(which triggers random clairvoyance even though hero isn't flagged
as having that attribute) the message and pause-to-browse become too
intrusive.
This was initially combined with the 'timed clairvoyance' fix because
they both bump EDITLEVEL to invalidate existing save files, but their
details don't interact so I separated them.
When the hero has random clairvoyance, the code used
| (moves % 15) == 0 && rn2(2) != 0
(where 'moves' is actually the turn number) to decide when it would
kick in and show a portion of the map. If the hero was fast enough
to get an extra move when the turn value met the (moves % 15) == 0
condition then clairvoyance could happen twice (or more if poly'd)
on the same turn.
The changes (one new field, reordering a few others) in 'struct
context' invalidate existing 3.7.0-x save files.
Fixes#266
It's a minor annoyance when you forget you can't do this in vanilla and
then get relocated somewhere random on the level. Since it's not a
harmful "trap", just allow the adventurer to teleport directly onto it.
Something I noticed in the hardfought diff what looked interesting.
Unfortunately the most interesting bit turns out to be unuseable.
Display high altars (Moloch's Sanctum and the Astral Plane) in
bright-magenta and unaligned altars (aside from the Sanctum one) in
red. Hardfought's code also uses white for lawful, gray for neutral,
and black for chaotic, matching the unicorn colors associated with
the alignments. But those colors don't render in a reliable fashion
(see the comment in mapglyph.c) and become confusing about why they're
used for altars of particular alignments.
When picking up from floor or removing from container fails because
there aren't any inventory slots available, pickup/take-out stops.
But the message
|Your knapsack can't accomodate any more items.
is inaccurate if there is gold beyond the stopping point. Actually
continuing in order to pickup/take-out gold would require substantial
changes, but varying the message to be
|Your knapsack can't accomodate any more items (except gold).
when stopping is a one line fix. The parenthesized remark is only
added if there is actually some gold after the current object and is
given regardless of whether autopickup happens to be targetting it.
Fixes#246
github pull request #228 commentary follows:
This adds a boolean option, autounlock, defaulting to true. When this is
set to TRUE, messages stating that some door or container is locked are
automatically followed by a prompt asking if you would like to unlock
it, if you are carrying an unlocking tool (key, lock pick, or credit
card).
Architecturally, this extends the pick_lock function to take three
additional arguments (door coordinates or a box on the ground you are
autounlocking).
Because this adds a new field to struct flag, this is not a
save-compatible change. I have not adjusted EDITLEVEL or
VERSION_COMPATIBILITY, though.
The code that selects an unlocking tool will always look first for a
skeleton key, then a lock pick, then a credit card. Since curses, rust,
and other attributes don't really have an effect on the viability of the
unlocking device, it didn't seem to warrant making a more complex
function for that.
closes#228
Add "Gateway to Moloch's Sanctum" to the vibrating square level if you
step on the square or detect/magic map it as a pseudo-trap, an extra
hint for players who manage to get that far but then don't know what
to do next. (I think I may also add a randomly placed floor engraving
along the lines of "For a good time, consult the Oracle of Delphi."
as a gag variant of "For a good time, call <name> at <phone number>."
Not very thematic for Gehennom but could conceivably nudge someone in
the right direction. But it could give away the level for experienced
players who haven't located the vibrating square yet.)
The annotation sticks until the one for "Moloch's Sanctum" gets added.
That happens when the temple on the sanctum level is entered or the
altar there has become mapped (in view or via magic mapping).
Could break existing 3.7.0- save files (but probably won't, since
at least two bits were available unless using an ancient 'Bitfield()
allocates whole bytes' configuration). That's the reason I didn't
put this into 3.6.2+.
