Pull request from NullCGT: applying gold from inventory will flip
one coin and report "heads" or "tails". If impaired, that coin will
be dropped, otherwise it will remain part of the stack in inventory.
Can be done via 'a $' or with context-senstive item action via 'i $ a'.
I've used 'git merge --squash' and 'git commit -C <commit#>' to
flatten four commits into one and it seems to have accomplished what
I wanted, including retaining the log message from <commit#>.
I also changed
|You flip a gold piece. The gold pieces slips between your fingers.
to
|You flip a gold piece. It slips between your fingers.
when impaired and applying one from a stack.
Closes#1107
Applying one or more gold pieces now flips one of them, which will
cause it to come up heads or tails. This is NetHack, so there are
special cases for flipping a coin underwater or while fumbling or
greasy.
I've tried to future-proof this commit so that the code will not
need to be modified if other items are eventually added to the
coin class.
If memory serves, there was a patch for this on the bilious patch
database, but I was unable to locate it or who the original author
was. In any case, the code is entirely original.
Reported by entrez: it was possible for #overview to show a line of
just "." if a temple was known and its altar was unknown and no other
features such as thrones or fountains were known on the level.
It now lists "M temples and N altars" when both are present and the
case that yielded "." becomes "a temple". That's an improvement but
there might be edge cases it gets wrong. A listing of "a temple and
an altar" is ambiguous because there isn't any way to tell whether the
altar it mentions is inside the temple. That seems acceptable to me.
I think it should include more alignment information about temples and
altars, instead of just adding "to <your god>" when all known altars
are of hero's alignment, but this doesn't attempt to address that.
From a comment w/ diff in the pull request by entrez, combine the
show-full-map flag (available in wizard mode and explore mode) with
the bitmask for map-only, map-and-traps, map-and-traps-and-objects
flags for #terrain mode (and getpos() help) instead of passing that
as a separate argument. No change in behavior unless I messed up.
Only show the '/' menu choice for context-sensitive inventory item
action if data.base look up for the item will find something. Lack
of '/' is as informative as "you don't know anything about that".
Harder to implement than expected but seems to be working ok.
This also changes the menu for the '/' command, replacing cryptic /^
and /" with /t and /T so that listing near traps or all traps is more
like listing near|all objects|monsters. I put caret and double-quote
in as group accelerators; double-quote works on tty, caret gets
intercepted as "menu first page" so doesn't. I didn't check other
interfaces since supporting that doesn't seem to be worth the bother.
Also a little bit of reformatting.
Adds an option to the inventory item menu which allows a user to
look up an item in the database. This uses the existing whatis
command.
A minor secondary change is switching the failed database lookup
message to second person. The use of a first person pronoun here
has always been very strange, and switching to second person centers
the player in the action.
Rest of 'not PR #1102'. Resizing the terminal while getpos was in
operation recalculated the map from scratch instead of redrawing what
the core considers to already be shown. And it was always operating
while an asynchronous signal was excuting which could potentially
clobber whatever was running at the time the signal arrived.
This uses same redrawing as the prior '^R during getpos()' fix. It
also only performs the resize while tty_nhgetch() is waiting for
input. If that is the situation at the time that the signal arrives
then it will resize immediately (while in the asynchronous signal
handler); if not, it will set a flag and tty_nhgetch() will do the
resize the next time it gets called.
This builds with TTY_PERM_INVENT enabled and doesn't seem to be any
worse than before, but there are bugs with that. The only way I could
get perminv to appear was to save and restore, then perm_invent was
honored for both RC file and mO command. And once I managed to get it
to display, moving an item from a lower case slot to slot 'A', made
that item vanish; nothing appeared in the invent's right hand panel.
Both of those misbehaviors already happen prior to this commit. I
also saw an abort+panictrace if I resized while at the "Dump core?"
prompt when running the pre-commit code and didn't see that with the
post-commit code (although the prompt wasn't shown so I couldn't tell
that it was waiting for an answer). The abort probably sounds scarier
than it warrants; I suspect that the pre-commit code just treated the
resize as answering 'y' for some reason, possibly a stale value in the
variable it uses.
This fixes the part of pull request #1102 by entrez dealing with the
map refresh side of things. It was pulled out of a much larger patch
that also deals with terminal window resize for tty.
Using ^R when getpos() is in operation, whether actually picking a
position for something or browsing the map during #terrain or post
detection magic, it was reconstructing the known map and positioning
the cursor on the hero instead redrawing the selected terrain subset
or detected objects/monsters/whatever. There's already a routine to
redraw the current view of the map without recalculating it, but it
wasn't being used for ^R during getpos operation.
Wand of make invisible doesn't make you permanently invisible,
just for a short duration. Potion of invisibility makes you
invisible for much longer period, or if blessed, has a small
chance of giving permanent invisibility.
This makes the wand actually useful, and improves the spell
too.
Skeletons are extremely rare, and not generated at random,
and bone devils are basically just a speed bump when they appear.
Make both more interesting.
Idea by copperwater <aosdict@gmail.com>
Reported 11 years ago, the level definition for the Samurai quest
home level specifies a throne room and entering it gives the "opulent
throne room" message, but there isn't any throne.
Initially I was going to add a throne but decided that its lack is
probably intentional. The throne room designation is used to give
periodic atomspheric messages. That's my guess anyway.
Alter the room entry message there to omit "throne" from "you enter
an opulent throne room". Add a no-throne comment to Sam-strt level
definition.
While in there, make Lord Sato's katana and splint mail explicitly
rustproof and either blessed or uncursed. (The mail was already
implicitly rustproof because splint mail created on the Sam quest
home level always is, like for a Samurai's initial inventory.)
This was causing a really annoying to track down bug where
the fuzzer threw the attached iron ball and it could end up
anywhere on the level, emitting a sanity check error.
b_trapped was treating 0 as a null value for its bodypart parameter, but
0 is actually the value of ARM, so b_trapped(..., ARM) would be treated
as intending no A_CON abuse. Add NO_PART = -1 to the bodypart_types
enum, and use that instead of 0 as the "no body part" value in
b_trapped, so that ARM can be passed to it without any ambiguity.
aosdict identified this issue in xNetHack and handled it differently; he
added NO_PART with a value of 0, incremented the existing bodypart_types
values, and padded the body part arrays so the actual body parts would
start at index 1. I think using NO_PART = -1 is simpler, but that's an
alternative approach that can be used instead -- it is advantageous in
that it automatically fixes any other places where 0 is assumed to be a
non-body-part value that I may have overlooked.
The other suggestion from Pat about potential extensions to bda0b3b. I
think it's interesting from a story perspective, and hopefully nobody
will run into this by mistake when they hoped to use the Candelabra as a
light source later! The specific language used by the leader could be
changed if someone has a better idea (as could the code itself, for that
matter).
If the hero throws an unidentified fake Amulet of Yendor at the quest
leader, the leader will identify it and toss it back, similar to the
behavior for the real Amulet.
This was one of Pat's suggestions for continuing in the same key as
bda0b3b; I think this makes a lot of sense, especially now that people
may be encouraged to throw things called "Amulet of Yendor" at the quest
leader. Arguable about whether a _known_ fake Amulet should still anger
the leader and quest helpers; as I have it in this commit, it will, but
I'm somewhat ambivalent about what makes more sense.
If there were outdated savefiles encountered during
startup, each individual one was getting a wait_synch
that required a <return> even though a message window
wasn't being used at that point.
Allow suppression of the individual per-file wait_synch()
calls on Windows, so that a single one can be done once
the selectsave processing is overwith.
This was a little messy because an indicator had to flow
down through validate(), uptodate(), etc.
There shouldn't be any change in how things behave on
any non-Windows platforms.
Reported by a hardfought user, a ceiling_hider monster hid on the
Astral level, triggering a sanity check warning that gets repeated
each move until the hider comes out of hiding. Normally sanity_check
can only be set in wizard mode, but hardfought must force it on for
to-be-3.7.
I was able to reproduce it before this fix and unable to do so
afterward, but there is a random factor involved hence no guarantees.
I think that lack of ceiling for Astral is recent, but this could
have happened on other levels which lack a ceiling. I didn't try to
figure out whether it might happen with 3.6.x, just put the fixes
entry in the "exposed by git" (found in code not yet released, that
is) section.
Pull request from entrez: if hero throws (or kicks) an invocation
item or the Amulet at the quest leader, identify it and give it back
instead of treating the throw (or kicked item) as an attack.
In addition to the fixes entry I've made several tweaks to related
code, mostly to refer to the leader as "Someone" rather than "It" if
unseen.
Closes#1093
It's been possible for a while to throw your quest artifact to your
quest leader, completing the quest (he will then throw the object back
to you). The quest leader will also react to being brought the Amulet
of Yendor (i.e. having it in inventory when you approach or #chat), but
tossing it over like the quest artifact was treated as a hostile act and
would cause the quest leader and guardians to become hostile and attack
the hero.
Make throwing the Amulet of Yendor at the quest leader work like
throwing the quest artifact, and treat the invocation items similarly
just in case people try throwing those (maybe because they are lost,
unsure what to do, and have already seen their quest leader catch and
react to the quest artifact -- regardless of the reason, throwing over
the Book of the Dead is almost certainly not intended to be an attack).
Doing so for invocation items will ID them but not do much more than
that. The Amulet of Yendor triggers the existing quest pager message.
Wielding one or more rocks while other rocks were quivered and casting
stone-to-flesh at self wasn't subject to the "null obj after quiver
merge" panic but it did result in a combined stack of meatballs that
was neither wielded nor quivered. Keep inventory items that turn into
meat and are wielded/alt-wep/quivered separate and still wielded/&c.
Using apply to unlight a lit potion of oil makes it unlit, removes
it from inventory, and then re-adds it to try to force it to merge
with other potions of oil. If it was wielded and the other potions
were quivered, the game would panic. When merging, they get forced
into the weapon slot in preference to the quiver slot.
Unwearing it before freeinv+addinv would solve this but also leave
the hero with nothing wielded, even if it didn't merge with another
stack. Instead, don't try to merge if the potion being unlit happens
to be worn.
3.6.x was subject to this too and the fix is small+isolated but the
situation is so uncommon that I haven't bothered backporting it.
Applying a lump of royal jelly and then not picking anything to rub
it on had a similar problem. It also panicked if the applied lump
was wielded and other lumps were quivered. The fix is different
because the stack it gets split from during apply is known. This one
doesn't impact 3.6.x; applying jelly to eggs wasn't implemented yet.
For Autoselect-all confirmation, accept yes|n|q (or yes|no|quit)
rather than just yes|n (or yes|no). An extra query routine is needed
to support it, but the existing paranoid_query() can just call the
new paranoid_ynq() with an extra argument, keeping things painless.
For menustyle:full plus paranoid_confirmation:Autoall, if you include
'A' in the class filtering choices then you're prompted for whether
you really meant it. (Same behavior as in the past few weeks.) Yes
auto-selects items matching all other chosen classes, or from all
classes if 'A' is the only choice. (Again, same behavior.) n|no
moves on to menu:full's second menu. If anything else was chosen
along with 'A', that's what the second menu will offer. (Same as
past few weeks but revised from initial implementation.) If 'A' was
the only choice, it will now use 'a' and offer a choice of everything
in the second menu. (That's a change; it used to cancel if declining
to honor 'A' and nothing else was present.) Now <return> without
answering or q|quit or ESC skips the second menu, whether or not the
rejected 'A' was the only choice made in the first menu. (New.)
Other paranoid confirmations still just accept yes and n|no responses,
treating ESC as n|no.
When paranoid confirmation for menustyle:full's "Autoselect all" is
enabled, it is handling yes vs no backwards.
The initial implementation had it right, then a negation got dropped
when it was expanded to support yes|no via paranoid_confirm:Confirm.
ESC is being treated as 'n' rather than as cancel. Fixing that will
take some more work. This just adds the missing negation to make 'y'
and 'n' behave properly.
Gold on status line can be truncated, so testing the display value
might miss up/down/changed highlights. I don't think that it actually
matters since a hero cannot pick up enough gold to reach the 999999
truncation threshold.
Normal amounts still seem to highlight correctly after this.
The hitpoints and power/energy status values (and corresponding
maxima) shown on the screen are capped at 9999 to control status line
width. The actual values can be bigger than that. Highlights based
on percentages were doing their calculations on the potentially
truncated values rather than on the actual ones.
Add another field to the blstat[] structure, populate it for BL_HP,
BL_HPMAX, BL_ENE, and BL_EXEMAX and switch to it for their percentage
calculations.
Doesn't seem to break highlighting of 'normal' range values but hasn't
been tested for extreme ones.
The options menu for status hilites wouldn't work as intended if the
entries in the initblstats[] array were changed to not be in BL_xyz
order. (No effect on current behavior since they are in that order.)
