Change sort ordering of
diluted potion of bar
diluted potion of foo
potion of bar
potion of foo
potion of fruit juice
to
potion of bar
diluted potion of bar
potion of foo
diluted potion of foo
potion of fruit juice
so that potions of the same type are grouped together. Bless/curse
state (when known) takes precedence over dilution, so "blessed
diluted potion of foo" will come out before "uncursed potion foo".
Start coloring after the space which follows the selection indicator
instead of on that space. The difference isn't noticeable when the
highlighting is just a color, but it is if that highlighting includes
inverse video or underline which visibly apply to spaces. So for
a - entry A
the old code produced
a -########
and this revised code produces
a - #######
where '#" indicates characters subject to menu coloring.
I saw a lich in solid wall at one of the spots which gehennom.des
marks with a pool (so that baalz_fixup() can find the two spots that
need post-wallification fixup). I could understand the special level
loader placing a swimming or flying monster there, but don't know
whether it might do that for a lich (which doesn't need to breathe)
so am not sure whether this actually fixes what I observed.
The lich was there for far too long to have been a shapechanger, but
when I went back to the save file it was no longer there, producing
another puzzle.
Digging a grave witha a pick-axe converted the grave to floor but
did not dig a pit and unearth the grave's contents. [Caused by a
change to maketrap() intended to prevent wizard-mode wishing for
traps on top of furniture.] Digging a second time succeeded in
creating a pit since the location was no longer furniture.
When items were sorted alphabetically, holy water ended up in the H's
and unholy water in the U's. Force them to get placed with water in
the W's, as would happen if water wasn't given an alternate name when
blessed or cursed.
The code to apply an automatic annotation to the knox level was looking
for a drawbridge like on the castle level, but knox doesn't have any
drawbridge. Look for its door instead. (It's initially a secret door,
so won't be revealed via magic mapping. It needs to be found or
destroyed to get mapped as a door or empty doorway in order to trigger
the annotation.)
Also, give a tiny bit of variation to the knox level layout. It used
to have both the throne and the secret door on the lower of two similar
rows and the door into the treasure vault on the upper one. Now each
of the three can be on either of those two rows (independently of each
other), making eight possibilities. This doesn't accomplish much,
other than to make the secret door locations not always be at the same
fixed spot.
Silly shapechange message if <mon> is sensed via telepathy and takes
on a mindless form. In the case I noticed, it was a doppelganger on
the far side of a maze wall who changed from something ordinary into
a mummy while the hero was wearing an amulet of esp.
3.6.0 could deliver this message, but I think changes since then have
increased the chance for newcham() to give shapechange feedback.
getobj() was caching 'invent' in 'firstobj', dating from the days
of the !GOLDOBJ configuration, and sortloot() could change the value
of invent, making firstobj end up pointing somewhere into the midst
of the inventory list. So collecting letters of applicable items
could miss things (typically right after restoring a saved game).
Repeating the command would operate on already sorted invent, making
firstobj remain valid and things mysteriously reappear after having
been missed before.
Just get rid of 'firstobj' since it's no longer useful.
flags.sortloot was changed from boolean to xchar, but proper type
is plain char. (Presumeably it was originally off or on, then got
changed to 'n' for off, 'l' for on, plus 'f' for super-on.)
Also, make the sortloot menu for 'O' mark the current value as
preselected when interactively setting the value. (I've been
meaning to do this for various other options but haven't gotten
around to it. The need to workaround PICK_ONE+MENU_SELECTED menu
behavior is a nuisance.)
... when exploding chest trap destroys uchain without using
unpunish() to un-wear it first. The '!carried(uball)' clause
should be applied to the uball->ox,oy test only, not to both
uchain->ox,oy and uball->ox,oy.
Force the menu for the look-here command when 'here' is the inside
of an engulfer to be PICK_NONE. That way '>' won't exit the menu
by choosing the extra inventory item "> - hero".
For menustyle:Traditional, the object class prompt for 'D' includes
an entry choice of 'm' to request a menu. Supplying real classes
and 'm' resulted in a menu limited to those classes, as intended,
but any of BUCX for curse/bless state and 'm' without any actual
classes resulted in a menu of entire invent. A one-line fix once
the proper place for that fix was located.
For menustyle:Traditional or menustyle:Combination, 'A' includes an
extra choice of 'i' to examine relevant inventory prior to choosing
object classes (and object identification also offers that), but
the inventory display showed everything rather than just the items
applicable to 'A' (or to object ID). Figuring out where to apply
the fix was trivial, but the fix itself was a bit more involved and
it exposed a latent bug in display_pickinv(): "" was supposed to be
the same as NULL when passed in as list of target inventory letters,
but it wasn't being handled correctly.
A patch in late January to suppress suits as likely candidates for
the 'R' command when wearing a cloak also unintentionally suppressed
rings when wearing non-cursed (or not yet known to be cursed) gloves.
Cloak always blocks suit removal; gloves only block ring removal if
cursed.
Extend #stats beyond just monsters and objects. Have it display
memory usage for traps, engravings, light sources, timers, pending
shop wall/floor repair, regions, bones tracking, named object types,
and dungeon overview.
No doubt there are other memory consumers that I've overlooked.
When typedefed to C99's bool type, Clang complains in container_contents about "comparison of constant 108 with expression of type 'boolean' (aka 'bool') is always false".
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.
This set is the same as the default ascii symbols except that corner
walls are represented with '+' instead of '-' or '|' so that wall
joins are clearer. The baalz level looks a little better this way,
although not a lot. Unfortunately, most levels look a bit cluttered
with this, so I imagine it won't get a lot of use. At least it
serves as an example of being able to use "'c'" instead of "\123".
Originally I specified every terrain symbol explicitly, which was
how I noticed that S_darkroom and S_vibrating_square weren't being
handled. This has cut it down to just the wall symbols, serving as
explicit example of accepting default symbols for unspecified ones.
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.
That is, use NetHack's RNG instead of the direct system RNG. This fixes
maps generated with randlines to interact correctly with potential
future RNG system changes e.g. switching PRNG algorithms, supporting
NAO343's RNG reseeding, and even supporting replays like NetHack 4.
Based on DynaHack commit e464f63 (lev_comp: Fix system RNG use in
randline) by me.
[Subject should mention Unix, but would exceed 50 characters.]
Explicit build rules ignore $(CPPFLAGS), but the implicit C rule
(at least in GNU make) specifies it. If user has a value for this
in the environment, that value would apply to building some source
files but not others. This patch gives it an explicit empty value,
so building via implicit rule should expand it to nothing and match
the fact that it's omitted from explicit rules.
There was one C++ file which relied on the implicit C++ rule. I've
added it to the files processed by 'make depend' and re-run that.
It now will get built via an explicit rule.
Also, a small amount of reformatting for HACKCSRC.
Other half of the Debian reproducible-builds patch. For Unix
Makefile.top, explicitly set locale to generic 'C' when running
'dlb' during install, so that wildcard expansion will yield a
predictable ordering regardless of collation order specified by
the local enviroenment. Otherwise contents of the 'nhdat'
container might be different--when viewed as a single data file
itself--during subsequent rebuild even when no changes to source
or data have been made and each module inside remains the same.
This assumes that locale doesn't matter during generation of any
of the data files (whether destined for dlb or not). I don't
think the utility programs attempt any sorting on the fly or
other locale-dependent output but wouldn't swear to that....
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.
The Makefile race condition report included a link to a log file
of the build attempt, and it contained this:
makedefs.c: In function 'do_grep_control':
makedefs.c:611:26: warning: suggest parentheses around operand of '!'
or change '|' to '||' or '!' to '~' [-Wparentheses]
#define ST_LD(old, opp) (!!(old) | (!!(opp) << 1))
^
makedefs.c:722:37: note: in expansion of macro 'ST_LD'
grep_stack[++grep_sp] = ST_LD(grep_writing, !isif);
^
They're using a more recent version of gcc than I am, because my
CFLAGS includes -Wparentheses (via -Wall) and I don't get that.
It's a little confusing, but I think it's whining that we might
have meant !!((old) | (!!(opp) << 1))
rather than (!!(old)) | (!!(opp) << 1).
The latter is what we get (and what we intended--no bug here).
I changed it to something that more directly reflects the intent
since it's not bit twiddling within some crucial innermost loop.
