I tried to polymorph a shopkeeper into a long worm (which isn't
allowed) and EDIT_GETLIN preserved "long worm" for default input
on the first retry. I just pressed <return> without modifying the
preloaded input, so a cycle of repitition occurred until eventually
it returned Null. But then the outer caller also retried, starting
it all over (at least without preserving the old failed input this
time).
Change it so that if the same unacceptible input is given twice in
a row, or empty input even once, preload the buffer for the next
retry with "random". Player can still edit that but if <return> is
used then an acceptable random choice gets made.
Only applies to the "what type of monster?" for polymorph target
when monpolycontrol is On since that's where two levels of retrying
happens.
Pull request from entrez: the just-picked-up flag on recently
picked up items was being reset when you stepped on other items
without picking anything else up.
Closes#784
Pull request from entrez: the change to show the result of a wish in
its gamelog/livelog event resulted in a segfault if that result was
&zeroobj. It occurs for wizard mode wishes producing terrain changes
instead of objects.
Closes#787
When taking stuff out of a container, specifying a subset count for
an item and getting the pickup_burden prompt, answering 'q' undid the
subset split but answering 'n' did not. If the item in question was
a stack of gold, the container would end up with two stacks. That
action could be repeated as long as any of the stacks was big enough
to trigger pickup_burden confirmation so an arbitrary number of gold
stacks could be produced. (Eventually they would be too small for a
subset to cause an increase in encumbrance, or possibly all reduced
to just one gold piece, then no more stacks could be created.)
Situation occurred for all menustyles; traditional and via-menu needed
separate fixes. It didn't occur for pickup off the floor.
Report was for 3.6.6 but the bug was still present in dev version.
Wishing for "N <size> globs [of pudding type]" produces 1 glob
starting at <size> and then multiples weight by N (so possibly
increasing <size>). When not it wizard mode, N can be replaced by
a random amount to prevent the total weight from being huge. When
N was less than 6, it was possible for that random amount to be
larger than what the player asked for.
Change the way the random amount is calculated so that it won't
ever be larger than what player specified. Also for wizard mode
prompt whether to make the substitution so that the player can
choose to abide by the limit or to obtain a huge glob for whatever
testing is being conducted.
Extend the log event for a wish to include what was produced. It
would be better to show the item as fully ID'd but then #chronicle
gives away information.
The backslash+newline pairs were inserted for this log message. In
the game and in dumplog those two lines are each one wide line. The
turn numbers shown are actually arbitrary since ^W takes no time.
|Logged events:
| Turn
| 1: wizard the chaotic male orcish Wizard entered the dungeon
| 2: made his first wish - "protection", got "a tattered cape"
| 3: made his first artifact wish - "blessed +2 rustproof magicbane",\
got "an athame named Magicbane"
| 4: wished for "master key of thievery", got "a key named The Master\
Key of Thievery"
Pull request from vultur-cadens: if a wish is declined by asking
for "nothing" or "none" or "nil", log that for gamelog/livelog as a
declined wish. Likewise when specifying monster species or class to
genocide as "none" or "nothing" or ESC, log it as declined genocide.
Closes#768
I forgot to do this with yesterday's post garbage collection fix
update. Record lua warnings in paniclog during normal play too, not
just when in wizard mode.
Now that the garbage collection problem has been fixed, record lua
warnings in the paniclog file rather than showing them on the screen.
Move nhl_warn()'s warnbuf[] to struct g in case restart ever gets
implemented so that it can be cleared if the restart occurred while
a warning message was under construction.
Writing lua warnings to paniclog (coming soon; tested without the
garbage collection fix in order to have test data) could crash on
the last pair. Those are written after the 'nomakedefs' structure
had been freed so version_string was Null.
The NAO PANICLOG_FMT2 code triggered a warning about the test for
g.plname; it is array so will never be Null.
realloc(NULL, size) is legitimate usage and nhrealloc() shouldn't
log a "< 0x00000000 __FILE__ __LINE__" entry for it. heaputil
would complain about freeing Null.
Add new routine 're_alloc()' that functions as MONITOR_HEAP-aware
libc realloc(). 'nhrealloc()' is the version that passes source
file and line info if built with MONITOR_HEAP enabled. The heaplog
data might now contain '<' (freed by realloc), '>' (replacement
allocation by realloc), and '*' (resized by realloc) entries in
addition to the previous '+' (allocated) and '-' (freed) entries.
heaputil has already been updated in the NHinternal repository.
Move FITSint_() and FITSuint_() from hacklib.c to alloc.c so that
they can be accessed by miscellaneous utility programs.
Remove three or four copies of FITSint_() that were duplicated in
utility programs like dlb and tile2bmp due to those not having
access to src/hacklib.o. They do have access to src/alloc.o (and
util/panic.o).
Pull request from entrez: fixes the combination of A and P for
menustyle:Full. For menustyle:Traditional, it fixes selecting P for
putting stuff into a container. Using P for multi-drop (D) already
worked and I haven't tried to figure out why the two commands behave
differently with just-picked.
Closes#774
Add the patch from entrez to describe the tower of flame effect from
a scroll of fire as "the blast" rather than "your spell" if it reveals
a secret door.
This will be an annoyance for wizard mode until someone actually
figures out and fixes the problem. The complaints from lua during
garbage collection aren't new, they were just being ignored before.
Remove a ton of tabs in nhlua.c and add missing whitespace to a bunch
of 'if(test){' lines and to a few casts.
Also simplify? obj handling during garbage collection (does not fix
the current gc problem) in nhlobj.c.
The grounded() macro wasn't fully handling is_clinger(). Not sure
what impact this fix will have.
Add ability to cling to the ceiling to enlightenment feedback. If
it gets fixed up to a state where it is useable while polymorphed,
some or all of it should be moved to non-magic ^X feedback.
If a monster killed a pudding, the resulting glob was dropped on
the map but might now be shown depending upon interaction--or lack
of such--with nearby globs.
The commit also changed the indentation of a label; I've reversed
that. Having labels always be indented one space means there's
no need to look into nested blocks to find them. But having no
indentation at all interferes with GNU diff (which is used for git
diff) showing the function that a band of changes occurs in (done
by augmenting the change bars in front of the band). That is based
on the most recent preceding line having a letter in the leftmost
column. Back when we had K&R-style function definitions which
didn't indent their arguments, that diff feature wasn't useful.
But after switching to ANSI-style definitions it is--except when an
unindented label interferes.
Something else noticed while looking for something unrelated. The
original code is correct but I think the revised code is a little
easier to take in when looking at it.
An end of line comment that spans multiple lines needs to start the
continuation line(s) with '*' or clang-format will convert it into
a block comment that follows the initial line.
foo(); /* call foo
but not bar */
would become
foo();
/*
* call foo but not bar
*/
however
foo(); /* call foo
* but not bar */
would stay as-is.
All that for a one-line change, and then I've changed this particular
instance to be
/* call foo but not bar */
foo();
There are lots of these that should eventually be fixed. I just
happened to notice this one when looking for something else.
explosion that reveals a secret door
Make the fix to feedback when an exploding potion of oil reveals a
door and then destroys it not affect other zap_over_floor feedback.
This incorporates the followup comment from entrez.
3.7 has a new size prefix for globs that 3.6 didn't. The code that
decides whether player is naming slime molds after an actual object
needs to know about it.
A couple of things I noticed when trying--and failing, so far--to figure
out the revive panic:
1) revive() treated y==0 as out of map bounds (x==0 is out of bounds
but y==0 isn't);
2) get_mon_location() might yield stale coordinates for steed (but
moot since that's only used for mobile lights and no light emitting
monster can wear a saddle; didn't affect light emitting objects
carried or worn by monsters).
When using 'm #wizkill' to kill monster(s) off without giving the
hero any credit or blame, temporarily force context.mon_moving On
so that collateral damage (other monsters killed by targetted gas
spore's explosion) also don't give the hero any credit or blame.
Make sure that some message identifying the monster is given when
targetted monster is killed even if hero can't see or sense it.
Add a way to get rid of specific monsters in wizard mode without
fighting, zapping, &c. #wizkill command lets you kill creatures by
picking them with getpos().
You can pick multiple monsters by targetting them one after another.
You don't have to be able to see or sense them but if you target a
spot that has no monster, the command ends.
By default, the hero gets credit or blame as if having killed the
targets but #wizkill can be preceded by 'm' prefix to treat their
deaths as if they had been caused by a monster.
I meant to wish for a "wand of cold" and accidentally typed "wand of
ice". Instead of being told that there's no such thing or receiving
a random wand, the spot I was standing on was changed to ice.
Only check for a terrain-change wish if an object class hasn't been
stripped from the wish text.
Having the preprocessor rename a variable called 'index' to one
called 'strchr' is not the source of any bugs (in execution; it can
cause pain when trying to ask a debugger to display the value and
then be told no such thing exists). Change the name to 'indx' to
avoid any confusion.
If we switch to strchr() we should still avoid using 'index' as a
variable name.
When picking an item from inventory and then picking 'I - adjust
inventory by splitting this stack' in the item-action menu,
yn_function("Split off how many?") is used to start getting the
count without needing to wait for <return>. It includes the response
in message history (so review of history will see that first digit).
The code then uses get_count() to obtain any additional digits. Tell
the latter to store "Count: N" in message history if N is different
from the first digit.
That's not as good as updating message history to replace the entry
showing the prompt with the first digit with one that shows the full
count but at least it's accurate when the count is 10 or more.
When a game is restored while hero is Gehennom, give the "It is hot
here. You smell smoke..." message after the welcome back message.
For both entering Gehennom and restoring there, switch from "smell" to
"sense" in the second part of that message if poly'd into a form that
doesn't have sense of smell.
Some unrelated stuff that got caught up in this diff:
1) move welcome()'s call to l_nhcore_call() to the start of the routine
instead of placing that after a potential early return;
2) remove a redundant glyphmap flags reset line; the routine being
called starts by setting its flags field to 0 for level change so
caller doesn't need to do that;
3) look_here() is just a formatting bit.
Construct a synoposis line if a message flagged for delivery by pline
gets changed to delivery by window and doesn't already have one.
deliver_by_pline(), deliver_by_window(), and deliver_splev_message()
were doing more work than necessary.
I wasted a bunch of time yesterday trying to figure out why a maze
level in Gehennom wasn't being shown with orange walls and ended up
reformatting a few glyph handling macros while hunting for the problem.
It turned out that the wall color choosing was working as intended.
I was looking at a maze bordered by solid stone (pale blue with Qt's
tiles, unlike tty's blank space) rather than by walls.
Anyway, a couple of the macros have had a little bit of common code
factored out rather than just be reformatted so I'm putting this in.
[For future, maybe stone should be given branch-specific coloring
similar to walls?]
The change to add a menu choice for naming an adjacent monster via
\#therecmdmenu was unintentionally requiring that the monster have
monst->mextra. So it worked on pets (regardless of whether they
were already named) because they have mextra for 'edog' extension,
but not on the majority of monsters. And when it failed the program
would crash with a 'segmentation fault' error.
Fix the check for whether a target monster already had a name when
deciding to use "name <mon>" or "rename <mon>" in the menu entry.
Reported by jeremyhetzler and confirmed by k2: dead monsters weren't
leaving corpses at the spot they died.
Don't set a monster's mx,my coordinates to 0,0 when taking it off the
map (unless it is migrating to another level; mx==0 is the bit of data
used to indicate that). Corpse drop happens after that and expects
the dead monster's former map coordinates to be intact.
Fixes#764
Pull request from vultur-cadens: some of the quest nemeses death
messages mention releasing noxious gas or noxious fumes so create
a poison gas cloud for them.
Closes#763
When wormgone() takes a long worm off the map, clear its stale mx,my
coordinates. None of its callers need those anymore.
Also a bit of potential long worm clean up that occurred to me when
I looked at object bypass handling. Expected to be a no-op here.
The change to zero out a monster's map coordinates when it is taken
off the map yesterday messed up migration between levels inside the
Wizard's tower. (Didn't apply when accompanying the hero between
levels, so probably unlikely to be noticed.)
Noticed while moving some replicated code into its own routine.
Instead of always retaining a blank spellbook when failing to write a
novel, make 2/3 chance to retain and 1/3 chance to destroy. Same odds
(but separate chance) to attempt to write the Great Yendorian Novel
versus awful fan fiction.
Pull request by entrez: don't create a Pratchett novel by writing
"novel" or "paperback book" on a known blank spellbook with a magic
marker.
Blanking a novel produces a blank spellbook; there isn't any blank
novel. That's intentional. Writing "novel" on a blank spellbook
and getting a randomly chosen Pratchett one wasn't intentional.
Closes#761
Reported directly to devteam by a hardfought player and also by
entrez. The recent mon_leaving_level() change resulted in objects
dropped by a dying monster not being displayed immediately.
It justed needed the relobj(mon, 0, FALSE) to relobj(mon, 1, FALSE)
change in m_detach() but this does some related cleanup in
mon_leaving_level()'s callers. wormgone() takes a long worm off the
map but leaves its stale coordinates set because some code relied on
that. This takes away the need for that but still doesn't actually
clear them.
This adds redundant 'return' statements at the end of a few void
functions that are longer than fits within a typical screen display.
They make searching for the end of the current routine in an editor
or pager easier without resorting to regular expressions and can
also be used to search for the beginning if/when preceding routine
ends in 'return' too.
I recently captured preprocessor output for a file and the amount of
code being expanded--and subsequently compiled--for canspotmon() was
quite an eye opener. This converts most of the macros it uses into
function calls. The resulting executable generated for OSX (built
for x86_64 and containing four interfaces) is about 5.5% smaller! and
there wasn't any difference in speed that I could notice.
The knowninvisible() macro has been in error for as far back as the
git logs go (which include those for the second cvs repository, so
over 20 years now).
Reported directly to devteam by entrez, the rloc() monst vanishes/
appears nearby/&c message was being given before "satisified, <shk>
suddenly disappears" making the latter redundant. As discussed, the
fix isn't as simple as suppressing one message or the other because
both are given conditionally.
This seems to solve it but has only been lightly tested.
Give more information when magic whistle is already discovered and
applying it affects multiple pets, without much increase in verbosity.
For each of the three categories
1) was already in view and moves to another spot still in view,
2) was out of view and arrives at a spot within view,
3) was in view but gets sent to a spot out of view,
show the pet by name (which might be "your <monst>" if it hasn't been
named) when there is just one, or "two creatures", "three...", "four...",
"several...", or "many..." when there are more than one. The first
category with more than 1 says "creatures". When there are additional
categories with more than 1, their part of the message says "others" if
prior part(s) already mention "creatures", or it says "other creatures"
if the prior part(s) only list pets by name.
For example
|Three creatures appear.
|Fido shifts location and Fang appears.
|Your pony shifts location and two other creatures appear.
|Many creatures shift locations, several others appear, and two others
disappear.
|Two creatures appear and two others disappear.
Restore old behavior of magic whistle causing pets to be moved to
different locations even when already adjacent to the hero.
This lets rloc() give its relatively new, more verbose messages if
a magic whistle isn't discovered yet but suppresses those when
already discovered in order to issue its own message. For a single
pet that starts within view and arrives elsewhere within view it says
"shifts location" rather than "vanishes and reappears". For multiple
pets, it gives one summary message instead of a separate one for each
pet affected by whistling.
Reverse the sense of dochugw()'s new 'X' argument. Use True for the
usual case and False for the special case rather than the other way
around.
Call the special case variant when a monster teleports so that hero
stops occupation if the monster jumps to a position where it becomes
a threat.
Issue #752 by vultur-cadens: initialization of characteristics had
off by one errors when reducing over-allocation and when increasing
under-allocation, biasing Str over Cha.
This simplifies the code very slightly but it still seems somewhat
confusing to me.
A couple of reformatting bits are included.
Closes#752
For char *next; don't compare (next = index(...)) != '\0'.
'\0' has value 0 and 0 used in a pointer context is a null pointer.
So the code worked as intended even though it wasn't written as
what was intended. Fix: take off the char decoration.
Fix the problem reported by entrez of a zombie corpse reviving and
crawling out of the ground while the hero was busy doing something
(searching, digging, &c) and having the hero fail to react and just
keep doing whatever the thing was because the zombie was already
inside the range where a monster changes from no-threat to threat.
Done in the monster creation routine so any new monster (including
one revived from a corpse) that is visible,&c will cause the hero's
action to be interrupted. Teleport arrival probably needs this too.
Only interrupts an occupation, not other voluntary multi-turn
actitivy such as running or traveling. That would be trivial to
change ['if (g.occupation...' to 'if ((g.occupation || multi > 0)...']
but I'm not sure whether it ought to be extended to that.
Implement 'untrap' as an 'autounlock' action. Quite a bit more work
than anticipated. The new documentation is rather clumsy; too many
if-this and if-not-that clauses have intruded.
I'll be astonished if all the return values are correct....
[A couple of places were checking for (rx != 0 && ry != 0) to decide
whether they were performating an autounlock action at <rx,ry> but
that erroneously excludes the top line of the map if the current
level extends that far. Just check rx for zero/non-zero.]
When probing a trapped container, report that it is trapped.
Done with a one-line message in the zap code and also in the title
of the contents display if it isn't empty.
For wizard mode wishing, if both "trapped" and "broken" are specified,
produce an untrapped container with a broken lock.
Also for wizard mode wishing, ignore "trapped" if player wishes for
"trapped secret door".
This gives the player more control over what autounlock does. It is
now a compound option rather than a boolean, and takes values of
autounlock:none
!autounlock or noautounlock (shortcuts for none)
autounlock:untrap + apply-key + kick + force (spaces are optional
or can be used instead of plus-signs, but can't mix "foo bar+quux")
autounlock (without a value, shortcut for autounlock:apply-key).
Default is autounlock:apply-key.
Untrap isn't implemented (feel free to jump in) so is suppressed from
the 'O' command's new sub-menu for autounlock. It's parsed and
accepted from .nethackrc but won't accomplish anything.
[Just musing: it should be feasible to kick in direction '.' to break
open a container or #force to an adjacent spot to break open a door.
If that was done, autounlock:kick+force (or more likely autounlock:
apply-key+kick+force when lacking a key) would resort to force if hero
couldn't kick due to wounded legs or riding.
This changes struct flags so increments EDITLEVEL again.
This includes pull requests #750 from entrez and #751 from FIQ but was
entered from scratch rather than using use their commits.
Closes#750Closes#751
Extend pull request #737,
commit d6ab241b8c, to magic portals.
If hero is on or next to a magic portal, have pets behave as if food
they want is being carried, like PR #737 did for hero standing on
stairs. (To be on one, hero must have come through from the other
side and not moved off the receiving portal yet, or else is in the
endgame but no longer carrying the Amulet.)
savelev() gets run to clean up memory even if the player quits before
level 1 is created, and a change made yesterday panicked if it couldn't
figure out what level the hero is on. Caught by entrez, again....
If not actually writing a level's file, don't panic if both u.uz and
g.uz_save are 0. Having one of those be non-zero is only essential
when the level being processed is the Plane of Water or Plane of Air.
It is astounding that after all this time no one noticed that
incrementing EDITLEVEL wasn't doing the job it's intended to do.
Diagnosed by entrez: since VERSION_COMPATIBILITY was defined as
3.7.0-0 and up, increasing the fourth component wasn't resulting in
old 3.7.0-x files being rejected.
This increments EDITLEVEL yet again, because my testing after
commenting out VERSION_COMPATIBILITY still wasn't rejecting older
files. Proably because the oldest I had available already had the
verison info with the preceding EDITLEVEL so weren't actually out
of date yet.
Once I had old files be rejected, I discovered that the rejection
message was invisible (for tty on OSX). The message line showed
spaces, matching the length of the intended message, followed by
--More--. This fixes that too.
It's possible to get a strange command result of ECMD_CANCEL+ECMD_TIME.
If/when that happens don't just treat it as cancel, make sure that time
elapses.
If an invalid command is provided, clear the do-again queue so that ^A
won't attempt to try the same invalid command again.
The air bubbles on the Plane of Water and the clouds on the Plane of
Air were being saved and restored as part of the current level's state
(which is the 'u' struct and invent and such) rather than with the
current level itself. That was ok for normal play, but for wizard
mode's ^V allowing you to return to a previously visited endgame level
after moving to a different one it meant a new set of bubbles for
Water and new set of clouds for Air. Even that was ok since it only
applied to wizard mode, but using #wizmakemap to recreate Water or Air
while you were on it added a new set of bubbles or clouds to the
existing ones. If repeated, eventually there wouldn't be much water
or air left.
Instead of just adding a hack to #wizmakemap, change save/restore to
keep the bubbles/clouds with the level rather than with the state.
That wasn't trivial and now I know why the old odd arrangement was
chosen. Saving hides u.uz by zeroing it out for levels that the hero
isn't on and it is zero during restore so simple checks for whether a
given level is water or air won't work.
This also adds another non-file/non-debugpline() use of DEBUGFILES:
DEBUGFILES=seethru nethack -D
will make water and clouds be transparent instead of opaque. It also
makes fumaroles and other light-blocking gas clouds be transparent
which wasn't really intended, but avoiding it would be extra work that
doesn't accomplish much.
Increments EDITLEVEL for the third time this week....
Noticed when testing the forcefight against obscured furniture fix:
if you attempted forcefight against the edge of the map, you got
feedback about having already moved as far in <direction> as possible
rather than about forcefight failing to attack anything. Have the
can't move out bounds test check for forcefight before deciding to
give to its normal feedback.
against "unknown obstacle"
Pull request #746 by entrez: give better feedback when 'F' prefix
is used toward furniture covered by objects and towards solid rock
terrain on arboreal levels.
Fixes#746
instead of as fake bear traps
Use the new traps and their tiles when confused gold detection finds
trapped doors and trapped chests. (Large boxes can be trapped too;
they use the trapped chest trap and corresponding tile rather than
have their own.)
Usually these pseudo-traps go away when as soon as they are within
line of sight. (While testing, I noticed that seeing a trapped door
from outside its room rather than inside didn't behave that way.
The door was created by wizard mode wishing; I don't know whether
that was a factor.)
I also discovered that secret doors weren't being handled correctly.
They can't be trapped because of their use of both the doormask and
wall_info overlays of levl[][].flags, but I had a secret door be
falsely displayed as a trap. This fixes that.
We should have obj->tknown and rm->D_TRAPKNOWN so that the hero won't
forget about these traps after declining to attempt to untrap them.
But that's more work than I care to tackle.
"add glyphs+tiles for door+chest traps",
commit d1217b9f25,
missed a couple of S_vibrating_square references, resulting in
screwed up rendering of zaps and explosions.
When trap detection finds trapped doors and trapped chests, it shows
those as bear traps. When the hero comes within view, they revert to
normal and the detected trap is forgotten. This doesn't change that,
it is just groundwork to be able to show them distinctly. Like the
TT_BEARTRAP patch, it increments EDITLEVEL so this seemed like a good
time to put the groudwork in place.
There shouldn't be any visible changes even though internal glyph and
tile values have been renumbered after inserting two new entries.
Adding traps after S_vibrating_square was quite a hassle and suffered
though a couple of off-by-one errors that weren't trivial to find and
fix.
Issue #745 by k2: when using two-weapon combat, the second attack
would still take place even if the first attack caused the hero to
become paralyzed (hitting a floating eye or g.cube).
Cleaver's up-to-three attacks had the same problem but did stop if
the hero underwent life-saving after some fatally damaging counter-
attack. Two-weapons didn't. Make them both stop early if either
paralysis or life-save occurs.
Multiple attacking monster against monster and against poly'd hero
already deal with paralysis; life-saving doesn't apply.
Fixes#745
When not wielding anything, ^X reports "you are empty handed" if
wearing gloves or "you are bare handed" if no gloves. The ')',
'w-', and 'A)' commands were using "empty handed" unconditionally.
Make them be consisitent with ^X.
After this, body part HANDED is no longer used anywhere except in
body_part().
Reported directly to devteam: when a Rider revived, its corpse
didn't get used up.
The change to have delobj() never destroy Rider corpses, like it
won't destroy the Amulet or invocation items, didn't take into
account that they should be destroyed when Riders revive from them.
Add delobj_core() to be able to do that without changing existing
delobj() usage.
I'm surprised hardfought players haven't been all over this one.
Reported directly to devteam: changing levels while riding gave an
impossible warning, "no monster to remove".
mon_leaving_level() was trying to take hero's steed off the map but
that isn't on the map in the first place. Only noticable if built
with EXTRA_SANITY_CHECKS enabled. Normally remove_monster(x,y) just
sets level.monsters[x,y] to Null but with extra checks enabled it
first checks whether that is already Null.
Commit 593c3532fc took the 'catchup'
argument away from repair_damage() and calculated it in the routine.
Commit 699a25c00b put the argument
back but neglected to remove calculating and assigning it, making
the passed value be ignored. Take that away, finishing 699a25c00b.
That affected shop repair messages but wasn't enough to prevent a
shop wall repair display glitch. This seems to make things work
properly but is little iffy.
Like the commit message for #743, the followup to it was misIDed
as #744. This one is for #744. There's no need to check a name
against all the "<class> of typename" unless it contains " of ".
Pull request #744 from vultur-cadens: the object specification
supported by des.object() was ambiguous for items whose name in
objects[] doesn't include the object class name. For instance ring
and spellbook of protection are just named "protection" (unlike
"cloak of protection" which has its full name).
Fixes#744
The commit message for pull request #743 misidentified it as #744,
so didn't get marked closed properly. Do that now...
Closes#743
If you have 'fixinv' set to Off and and an inventory of three items,
they'll always be a and b and c. #adjust had you pick 'from' slot
among [abc] and the prompt for 'to' was supposed to show the letter
you picked plus 'd' for 'move to last'. But it was only showing
the 'from' letter itself as likely candidate, omitting the last+1
choice. (Anything after the last letter in use could be picked and
yield the right result, only the list of likely candidate slots in
the prompt wrong.)
Fixed more by trial and error than by understanding why the old code
didn't do what was intended.
There's no 'w-' or 'Q-' for alternate weapon, but context-sensitive
inventory is starting from the object rather than the command so can
finesse that. 'A' does allow alternate weapon to be directly unset
(aka reset to bare/gloved hands) but is not friendly to being passed
queued input.
This adds an extra internal command which only handles unset uswapwep,
even though that is something which is awfully specialized to get it's
own command. Users don't see this command so that shouldn't matter.
For context-sensitve inventory, if player picks the item occupying
the quiver slot, offer '-' as a choice. Like for wielded weapon,
picking that will clear the slot. Also, don't include the 'Q' for
quivering it choice since it is already quivered.
Unlike nethack4, we don't currently have a way to explicitly clear
uswapwep. The sequence #swap, #wield '-', #swap won't work if
primary weapon is cursed and isn't safe to use if alternate one is.
It would be simple enough to just directly call setuswapwep(NULL)
and untwoweapon() in the item-action routine instead of queuing up
some command to do it but that feels a bit unclean. Adding yet
another internal command for it would work too but this one wouldn't
be for variant user-interaction of an existing command.
The fire command could claim that time passed when it hadn't (fill
quiver with ammo, which takes no time, then queue commands to switch
to matching launcher, which should also take no time while queueing,
only during subsequent execution).
If quiver is empty or has ammo in it, give wielded thrown-and-return
weapon (aklys) priority over filling quiver or switching to ammo's
launcher. Don't do that if quiver has non-ammo in it, otherwise
players running Valks who wield Mjollnir with super strength but
want to throw quivered daggers would complain.
When player is being asked what to fill the quiver with, use the
\#quiver command to do that. Using it honors a count to split a
stack, handles switching uwep or uswapwep to uquiver, and gives
feedback. This is actually a fairly substantial change.
For 'fireassist', when switching to a launcher that isn't already
uswapwep pick one known to be blessed or uncursed over one having
unknown BUC status. But use the latter as last resort.
Reported by vultur-cadens: slow digestion from wearing white dragon
scales/mail blocked per-turn hunger and didn't cause any hunger,
unlike ring of slow digestion which blocks per-turn hunger but still
causes some hunger as a worn ring itself. If no rings or amulet
were worn, wearing the suit prevented the hero from ever burning any
nutrition.
Change to treat wearing the suit to be quite a bit like wearing a
ring, unless hero is also wearing an actual ring of slow digestion
(then the hunger cost of the suit is 'free').
Wearing a ring of slow digestion and another ring consumes two units
of nutrition every 20 turns, no matter what suit. Wearing white
dragon scales/mail and two non-slow digestion rings now consumes three
units of nutrition every 20 turns. Using the suit to effectively get
an extra ring finger isn't free.
Fixes#742
Issue #729 by argrath points out that one of the checks in
edibility_prompts() couldn't work.
For the next-meal effect after reading a blessed scroll of food
detection, the check whether a corpse was tainted but not dangerous
because the hero had sickness resistance could never be evaluated.
An earlier condition would cause the routine to return before
reaching that check.
Move it sooner, even though doing so violates the "order by most
to least dangerous" guideline. It was either that or eliminate it
altogether.
edibility_prompts() had a lot of repetitive code that has now been
condensed.
Simplify acid blob corpse handling--for all of eating, not just for
edibility_prompts()--by treating that as "never rots" so that the
'rotted' variable always stays 0. Now checks for that variable
being greater than some threshold don't need to include "and not an
acid blob corpse" as an exception. A side-effect of this change is
that not only do they never become tainted, they'll no longer yield
the "you feel sick" outcome when they're old but not old enough to
exceed the tainted threshold.
Bug fix: edibility testing stopped warning about green slimes.
That worked in 3.6.x, but 3.7 changed the 'cadaver' variable to
exclude them so the check for eating a glob of green slime could no
longer be reached.
Fixes#729
Reported by entrez. Don't make 50% of neuter monsters be flagged as
female. It doesn't matter for live monsters but gets inherited by
their corpses, where female and non-female corpses stack separately.
Noticed earlier when testing the status_hilite_menu_fld() changes:
if you enter a duplicate rule (with different highlighting), it didn't
replace the previous one and the old rule continued to be used.
This still doesn't do replacement, but by adding the new rule at the
end of the list of rules for the specified field instead of inserting
it at the beginning, the new rule gets used.
A change made 5 or 6 weeks ago that was meant to enhance tracking of
artifact creation had an unintended side-effect of making every object
obtained via wishing have its dknown flag be set. That made them
behave differenly from items picked up off the floor, so revert to the
old behavior.
Pull request #740 by argrath removes some redundant code. Instead
of adopting that, this rewrites the section of code in question.
The menu involved allows the user to select both "delete hilites"
and "add new hilite" but if both are selected it would only do
deletion. It also falsely claimed to have done something if delete
was chosen but no highlights were selected to be deleted. And it
only added one new highlight for the specified field when adding.
This supports both add and delete on the same menu invocation, for
addition it keeps adding until no new highlight is specified, and
has caller do the highlight updating if any changes are made.
Supersedes #740
More context-sensitive inventory support. While examining inventory,
if you pick an item other than gold and it has a quantity of more
than 1, "I - Adjust inventory by splitting this stack" will be one
of the menu choices.
Breaking doorganize() into two parts was much easier than expected,
but the new internal command added to be an alternate for the first
part had more niggling details than anticipated.
Message history only shows the first digit with "Split off how many?"
if the player enters more than that.
Add context-sensitive inventory item-action 'i' to run the #adjust
command. Groundwork for item-action 'I' to use #adjust to split a
stack is included but non-functional.
Also reorders some of the enums and switch cases to be alphabetical
by their menu selection letter, dip moves from 'd' (which is drop)
to 'a' and offer/sacrifice moves from last to 'O'.
hero when hero is [impatiently waiting...] on stairs
My attempts to cherry-pick this failed, so this was done manually.
It is a reimplementation of
NullCGT:feature/monster-item-use:dc2cef0562542fece1732dd2d4c4f0775308faff
] Pets approach the player if they are standing on the stairs.
]
] One of the most frequent complaints I have seen is that pets refuse
] to follow their owners down the stairs. While this can be resolved by
] waiting, most players, especially new ones, are not willing to spend
] multiple dozens of turns waiting for their pets to approach closely
] enough to follow them. This simple commit makes pets react to a player
] standing on stairs as if the player is holding a tripe ration. Simple,
] non-disruptive, and should solve many headaches.
PatR