The "sortloot revamp" patch six or seven weeks ago broke filtering
for '?' menu in display_pickinv() called by getobj(). The old code
handled 'lets' when building an array of object pointers to be
sorted. The revamp code did away with that to sort the linked list
instead, but neglected to put 'lets' handling into the subsequent
menu creation loop which is now operating on full invent rather
than the filtered subset.
Hitting a rust monster with a greased weapon would rust the weapon
instead of removing the grease. Likewise for monsters with passive
acid or corrosion damage. passive_obj() was ignoring grease.
Fast and Very_fast share the same property index, but from_what()
didn't handle that. Enlightenment for a Very_fast hero--which
can only happen via worn equipment (speed boots) or timed effect
(potion of speed or spell of haste self)--would be erroneously
described as "very fast innately" for roles who get intrinsic
speed at level 1, or "very fast because of experience" when high
enough level for roles who get intrinsic speed later.
When hero with two-handed weapon, or samurai with katana and without
shield, hits a monster which is wielding a weapon, there is a chance
for defender's weapon to be destroyed via shattering. The chance is
reduced--by increasing the chance to resist--if the hero's weapon is
rusty or otherwise eroded. That works as intended. This changes
things to make the chance be increased--by reducing the chance to
resist--if defender's weapon is rusty or otherwise eroded.
Add support for character enclosed within single quotes. Single
character without quotes would work for most characters, but not
'#' and possibly not '^' or '\\'. All the values in dat/symbols
are specified via backslash+digits so it isn't obvious that some
other form of value is allowed.
I think this parsing accepts all valid values. It doesn't reject
all invalid ones: opening quote followed by valid escape sequence
followed by junk followed by closing quote will ignore the junk.
I don't think there's any pressing need to worry about that.
Symbol set parsing rejected S_darkroom and S_vibrating_square.
Now it will accept them.
The fact that this bug wasn't noticed indicates that none of the
3.6.0 symbol sets (other than "Default symbols") is specifying a
value for either of these symbols.
This also changes the default vibrating square value from yellow
'^' (caret) to purple '~' (tilde). I don't think there's any risk
of mistaking it for a long worm tail (brown '~') and it emphasizes
that it isn't really a trap.
Quite a bit of special case code for something so inconsequential.
Tweak the baalz level layout a little to make it be a bit more
interesting, and perform custom wallification on it so that the
beetle layout becomes clearly visible. It looks great with
DECgraphics (and presumably IBMgraphics). It's recognizeable but
not as interesting with ordinary ascii because corner walls use
'-' or '|' so don't join up nicely. It looks a little weird
with tiles; the square aspect ratio of individual tiles makes it
end up being very elongated compared to character cell map it was
designed for.
As far as the level layout goes, the pair of secret doors into
Baalzebub's chamber have been give a random alternative. The two
right-most accessible columns were diggable--I don't know whether
that was intentional; it's been reduced to one right-most column.
The middle pair of legs were asymmetrical; this fixes that. The
beetle also now has eyes and an entry door in its mouth.
Take the 4-5 line Debian patch and turn it into six dozen lines of
new code. The submitted patch introduces use of several C library
routines that aren't presently in use, so would need testing by all
functional or nearly-functional ports to verify that it wouldn't
break anything. It also switched the formatted build date+time
from localtime to UTC. This makes the code conditional so it can
be ignored by anybody and avoid the risk of breakage. And a lot of
the increase in size is comments attempting to explain what the new
conditional is for: when REPRODUCIBLE_BUILD is defined, makedefs
will use getenv("SOURCE_DATE_EPOCH") (whose value is an integer
representing seconds since 1-Jan-1970) instead of current date+time
when generating date.h. The purpose is to be able to rebuild at a
later date and produce an identical program, which doesn't happen
when compile time gets incorporated into the binary.
I've added some sanity checking to try to make sure the getenv()
value obtained isn't bogus. And the version string put into date.h
will be slightly different, allowing someone who sees date.h or 'v'
output to tell whether SOURCE_DATE_EPOCH was involved: showing
"<port> NetHack <version> last revision <date>" instead of the
usual "... last build <date>".
To test, checkout a new branch for building, make any local edits
to unixconf.h and config.h, including enabling REPRODUCIBLE_BUILD,
git add+commit them, then use
SOURCE_DATE_EPOCH=`git log -1 --pretty=%ct` make install
Other ports will need a bit more work to set up the environment,
but can still use git to track file dates and supply the latest.
Building with alternate configurations could be accomplished by
using tags instead of 'log -1' or by using distinct build branches
where nothing is commited/merged/rebased after completed build.
Unresolved issue: BUILD_DATE, VERSION_ID, and COPYRIGHT_BANNER_C
contain formatted date+time but omit timezone. SOURCE_DATE_EPOCH
is assumed to be UTC but the formatted values don't say so, so it
might appear to be incorrect when compared with local time. We
definitely don't want to start mucking about with timezones within
nethack, so I think we just live with this. It's not an issue for
default configruation where REPRODUCIBLE_BUILD is left disabled.
Make 'zeromonst' global instead of local to makemon.c. Its address
isn't used as a special value like &zeroobj, but it is useful to
have available for initializing various pseudo-monsters.
modified:
include/decl.h
src/decl.c, makemon.c, mkobj.c, mplayer.c, teleport.c
Some worthwhile stuff from abandoned 'git stash':
is_plural() macro wasn't comprehensive;
a couple of return values where writing with a magic marker was
causing time to elapse even though nothing happened;
comment formatting for saddle being left in shop by dying steed.
Rescuing an old revision from bit rot: If one of fog clouds or
vampire bats has been genocided and you try to polymorph a vampire
disguised as the other, it won't change form because the shape it's
currently in is the only candidate shape left for vampshifting.
This makes shapechangers who fail to take on a new shape when
polymorphed try again, specifying original form on the second try.
It's unlikely to affect chameleons, but disguised vampires will
sometimes become undisguised instead of seeming to be immune from
polymorph.
Noticed when testing tty menucolor changes recently, using the 'O'
command to interactively add a new entry would accept one and then
quit, unlike remove which accepts multiple at a time and then goes
back to the menu where you could choose 'remove' all over again.
Adding is still done one entry at a time, but instead of finishing,
it goes back to the menu where you can choose to add another.
After some permutation of commands which displayed items, the 'd'
command presented a prompt with the list of letters scrambled (in
loot order or pack order rather than invlet order), so explicitly
sort when getobj operates. Done for ggetobj too.
For menustyle:Traditional, ',' followed by 'm' presented a pickup
list in pile order even when sortloot was 'l' or 'f'. That was an
unintentional change during the 'revamp'.
Reported directly to devteam for recent git code, the "sortloot
revamp" patch could trigger an object lost panic after calling
query_objlist() when menustyle was full or partial and player
picked up a subset of available items. Modified head-of-list was
not being propagated to its source in pickup(). Use an extra layer
of indirection.
Reported directly to devteam (for 3.4.3 but still present in 3.6.0):
an unseen landmine explosion which caused scatter() to break a
boulder or statue would give feedback as if the hero could see the
boulder or statue being destroyed.
Also, a couple of landmine explosion messages didn't take deafness
into account.
This one had been intended for longer than several years, but I
hadn't gotten around to it. When consorting with succubi and
incubi, very high Cha+Int no longer guarantees that a positive
outcome will occur.
Chance of positive outcome is still quite high and most of the
negative outcomes are pretty easy to repair, so this isn't likely
to make a significant impact. However, the possibility of losing
spell power will matter for some players....
This was sitting around for several years. When positive luck
lessens a negative effect from sitting on a throne, reduce luck so
that repeated occurances will eventually get the intended result.
Most of the humanoid species have Lords and several have Kings,
but none of them have Ladies or Queens. When a female grows up
to reach that level of monster, she changes into male. This fix
gives an alternate message acknowledging that change rather than
prevent taking on the stronger form. A better fix would be to
add ogre ladies and dwarf queens as separate monsters, but doing
so will break 3.6.0 save file compatibility.
(I started out with an alternate fix, adding mons[].fname for the
dozen or so creatures which warrant an alternate name for females.
But that requires statues, figurines, corpses, tins, and maybe
even eggs to track gender [some statues already do, and corpses
and statues with attached mtraits also implicitly do] and to not
stack with equivalent ones of the opposite gender. Plus glyphs
to track them, and new tiles. It was becoming too complicated
for such a relatively unimportant feature. Separate monsters is
the way to go, deferred until save file format changes again.)
Blindness due to face covered by pie was ignored for several cases
of magically curing blindness--cleaning the face seems better than
adjusting timeout to account for u.ucreamed for those cases. A few
instances of taking stun or confusion damage overrode existing stun
or confusion rather than increasing it. Plus a copy/paste mistake
for dual stun+confusion when casting an expired spell.
There was also a suggestion that vomiting when already nauseated
should decrement the timer instead of increasing it. But there is a
negative effect for as long as it's in effect, so I left that as is.
Fix some typos in the sort-by-invlet code and a logic error in the
lately added subclass sorting for sort-by-pack. Regular inventory
display only works correctly for the latter if invlet is the tie-
breaker within object classes. When helmet/gloves/boots/&c and
ammo/launcher/missile/&c sub-categories already break ties for armor
and weapon classes, inventory ended up out of alphabetical order.
When removing items from a container via menu, list gold as '$'
instead of 'a' when it is the first item. Requested during beta
testing last year....
When gold isn't first ('sortpack' false, or custom 'inv_order[]'),
it uses the next letter in sequence instead of '$', otherwise it
would be the only item out of sequence.
Change the sortloot option to use qsort() instead of naive insertion
sort. After sorting, it reorders the linked list into the sorted
order, so might have some subtle change(s) in behavior since that
wasn't done before.
pickup.c includes some formatting cleanup.
modified:
include/extern.h, hack.h, obj.h
src/do.c, do_wear.c, end.c, invent.c, pickup.c
Accept "male" or "female" when specifying monster type for ^G.
Groundwork for testing and hopefully eventually fixing "female
gnome" grows up into "gnome lord" and becomes male.
Polyself with gender change into a creature with fixed gender
would deliver a message containing "a <creature>" regardless of
whether "an" was warranted.
(Into any creature which supports both genders it yielded
"a male <creature>" or "a female <creature>" so "an" was never
needed. And when no gender change was involved, it used an()
so got "a <creature>" or "an <creature>" as applicable.)
There have been two or three reports on getting feedback about
amulets rusting. Object formatting doesn't display erosion for
them, so being told about damage then not seeing that damage
feels like a bug. Even if damage was displayed, it has no effect
on them so would still feel somewhat strange. It does display
erosion for wands and rings, which is strange too.
This limits erosion damage--and its feedback--to items which are
actually impacted by erosion: armor, weapons and weapon-tools;
also heavy iron balls and iron chains since they've traditionally
shown rust even though it has little effect.
A side-effect of this change is that flammable items (other than
armor and weapons) which don't burn up immediately will no longer
become burnt, then very burnt, thorougly burnt, and finally be
destroyed. Since the player couldn't see or possibly repair the
erosion state, it seemed incomplete. It could be reinstated by
making other flammable items be subject to erosion and displayed
as such by xname() & co.
Wishing now avoids applying erosion and erosion-proofing to items
that aren't affected by it, regardless of material. It also now
allows wishing for "rusty rustproof <iron-object>" which used to
suppress "rusty" in that combination and triggered a couple of
old bug reports.
Heavy iron balls and iron chains can have rust repaired and can
be made rustproof by wielding, then reading enchant weapon while
confused, as if they were weapons.
Pt 1 was about the wrong message delivered when a high priest
rejects being given a name by the player, and was fixed weeks ago.
Pt 2 is about zaps on the Elemental Plane of Air which reach the
edge of the map not having their temporary display effect removed
after "the <zap> vanishes in the aether". There was a 'goto' in
use which bypassed the tmp_at(DISP_END) call. I guess Dijkstra
earns an "I told you so" here.
"Looting many containers via menu cannot be stopped". When the
player uses #loot command at a location with multiple containers,
a menu of which ones to loot is presented and player can pick any
or all of them. But if you terminate the looting of a particular
container with ESC, it goes on to the next selected one rather than
stopping the loot action because that's what the 'q' choice does.
The simplest fix would be to allow choosing only one container
from the "loot which?" menu, but this retains the ability to loot
multiple containers on a pile in one turn. It makes looting
stoppable by extending the ":iobrsq or ?" prompt, adding 'n' for
"next container" and changing 'q' from "done with this container"
to "done looting" (with ESC still a synonym for 'q'). When just
one container is being looted, or when on the last of N containers,
'n' is not shown but is still accepted (and treated as 'q').
Also, use_container() was using a menu for ":iobrsq" if player had
menustyle set to Full when it was intended to be for Partial (name
confusion...). This switches Partial to use menu for loot action,
and leaves Full with that since that's how 3.6.0 has been behaving.
Traditional and Combination use the prompt string and single char
response.
The bug report was actually about letting monsters use fire horns
without checking whether they could actually use wind instruments.
The previous fix probably handled most cases by excluding animals
and mindless creatures, but this is a more specific fix for MUSE
of fire and frost horns--they must pass the same test as the hero
and it's not limited to stopping being turned into slime.
There was no check for being capable of using items when an attempt
to cure being turned into green slime picked scroll, wand, or horn
of fire.
Also, implement a 'TODO' in the same section of code. Monsters
can enter fire traps to cure themselves from slime. I made that
be for monsters smart enough to use items too, even though there's
no actual item involved.
Let monsters who have a weapon attack for non-physical damage dish
out physical damage instead of doing the drain life or drain
strength they usually do if they happen to be wielding cockatrice
corpses or a couple of particular aritfacts that do more harm
than just level drain. (Other artifacts are candidates, but I
don't think it's worth checking for them since the monsters
involved have such a small chance of acquiring and wielding them.)
Also switch to physical if monster's ability has been cancelled.
Only barrow wight, Nazgul, and erinys are affected. Yeenoghu and
the Master Assassin have a weapon attack for physical damage and
another one for non-physical damage (not necessarily delivered in
that order). They haven't been changed--only the physical damage
attack has a chance to apply their weapon's special damage.
While looking at #H4265 ("Bug - Monsters opening doors" about
feedback naming the unseen monster who opened a door), I didn't
find the the problem. But I did notice a couple of suspicious
constructs. Fix an assignment that gave a boolean variable a
value of 16, and add parentheses around 'a & b' in (a & b && c).
The latter isn't incorrect, it just looks strange.
Report states that using OSX Xcode IDE results in use of 'clang
Modules', whatever those are, and role.c's 'filter' struct ends up
conflicting with a function declared by <curses.h> (or possibly
<ncurses.h> since one includes the other). src/role.c does not
include <curses.h>, so this smacks of the problems caused by using
precompiled headers on pre-OSX Mac.
Instead of trying to import nethack into Xcode, I temporarily
inserted '#include <curses.h>' at the end of unixconf.h. gcc did
complain about 'filter' in role.c (but not in invent.c, despite
-Wshadow), and then complained about termcap.c using TRUE when it
wasn't defined (after in had been #undef'd, where there's a comment
stating that it won't be used in the rest of that file), and also
complained about static function winch() in wintty.c conflicting
with external winch() in curses.
This renames 'filter' and 'winch()' to things that won't conflict.
Also, our winch() is a signal handler but had the wrong signature
for one. And the troublesome use of TRUE was in code that was
supposed to be dealing with int rather than boolean.
Lawful angels deliver taunt messages from a pool of messages which
might mention the lawful god; demons and non-lawful angels draw from
another pool which doesn't mention any gods. Since it is odd for a
'renegade' angel to claim to be operating for its god, choose taunts
from the other pool of messages for renegade lawful angels.
Not related: some formatting fixups in include/mextra.h.
One entry among many in #H4216: make shuriken be a pre-discovered
item for monk role. The word "shuriken" comes from Japanese and
martial-arts monk is primarily Chinese, but shuriken/throwing-star
is a martial-arts type of weapon and monks get a multi-shot bonus
for it (even though they can't advance its skill beyond basic...).
Two different reports complaining that having the Wizard steal the
hero's quest artifact is a bad thing. This doesn't change that,
but it does make all quest artifacts become equal targets so that
wishing for other roles' artifacts doesn't offer such a safe way to
have whichever special attributes they provide.
Quest artifacts are actually higher priority targets for theft than
the Amulet. I suspect that probably wasn't originally intended,
but I left things that way. Taking quest artifacts leaves the hero
more vulnerable to future thefts, and once they're gone the Amulet
has priority over the invocation tools.
When using a stethoscope or wand of probing on a long worm, report
the number of segments it has in the feedback given.
Some of the extra bhitpos and/or notonhead assigments may not be
necessary. They were added when I was trying to figure out the
question of why probing of a tail segment revealed a long worm's
inventory even though the code explicitly prevents that. (Answer:
it didn't; I had misinterpreted bz 12 to think that that was what
was being reported. You need to use wand of probing--or "insigtful"
Magicbane hit--on the head in order to see its inventory or be told
"not carrying anything".)
I initially misunderstood this bug report about a nymph who was
polymorphed into a long worm while carrying a cursed figurine.
It wasn't about a long worm having inventory or about probing of
the worm's tail revealing that it had inventory, it was about the
message given when the cursed figurine activated itself. If that
happened while the head was out of view but at least one tail
segment was visible, the message about the new monster emerging
from the long worm's backpack implied that that pack was carried
by the tail segment.
Only give the emerge-from-backpack message when the worm's head
is visible. Likewise if a carried egg hatches.
Requested during beta testing last year, include a menu entry of
"- - your bare hands" (or "your gloved hands") for wielding,
"- - empty quiver" for readying quiver,
"- - your fingertip" for engraving, or
"- - your fingers" for applying grease
if the user responds with '?' or '*' at the
"What do you want to {wield|ready|write with|grease}? [- abc or ?*]"
getobj prompt. (First dash is inventory selector 'letter', second
dash is menu separator between the letter and its choice description.)
Even out the summoning distribution by adding more lawful candidates.
There used to be only 4; now there are 10. Chaotics have 14, so are
still more likely to get "neutral or own alignment" and stop, but the
difference is now pretty small once you factor in the 18 neutral ones.
In theory nasty() could summon 200 critters at a time, although the
chance seems fairly remote. But it was biased towards having lawfuls
summon more critters than others since there are fewer lawfuls in the
nasties[] list. This puts a cap of 8 successful makemon() calls,
enough to completely surround the hero. More than 8 monsters can be
generated, if any of the makemon() calls produces a group. (I think
fire giants are the only thing in nasties[] that ever come in groups.)
It's still biased toward lawful summoners trying more times hoping to
produce a lawful creature and generating chaotic ones in the process.
The bug report also thought there was some problem between chaotic
and unaligned or with the Wizard, but unaligned is treated as if it
were chaotic (due to use of sgn() in the two or three places where
alignment type is manipulated) so that isn't an actual problem.
Death Quotes have reached the current limit of 30 passages per 'book'.
Instead of increasing that, change the selection code to be able to
operate on a subset (dropped from 30 down to 20) at a time while
keeping the excess available for later selection.
Chatting with Death (more than 20 times since he also delivers non-
tribute messages) should cycle through 20 of his 30 passages without
repeating. After that, another subset of 20 out of the 30 will be
chosen, independent of the first set so might contain all, some, or
none of the 10 that left out before.
