PatR [Mon, 11 Oct 2021 21:50:29 +0000 (14:50 -0700)]
last? boulder change - Guidebook update
Describe the new feature of m<dir> making it feasible to move to a
boulder'd spot without pushing. Giving specific information among
vague descriptions is awkward....
While in there, move a handful of sentences to separate lines as per
the 'roff guidelines. I did the same for Guidebook.tex even though
it's not needed there, to try to keep things parallel.
nhmall [Mon, 11 Oct 2021 13:48:48 +0000 (09:48 -0400)]
Windows virtual terminal sequences
Microsoft has been making a recommendation that programs should switch
from using the classic low-level console API calls to virtual terminal
sequences for a couple of years.
References:
"Our recommendation is to replace the classic Windows Console API with virtual
terminal sequences. This article will outline the difference between the two
and discuss the reasons for our recommendation."
From:
Classic Console APIs versus Virtual Terminal Sequences
https://docs.microsoft.com/en-us/windows/console/classic-vs-vt
The online documentation for WriteConsoleOutputCharacter() and
WriteConsoleOutputAttribute() have this disclaimer on them:
"This document describes console platform functionality that is no longer a
part of our ecosystem roadmap. We do not recommend using this content in new
products, but we will continue to support existing usages for the indefinite
future. Our preferred modern solution focuses on virtual terminal sequences
for maximum compatibility in cross-platform scenarios. You can find more
information about this design decision in our classic console vs. virtual
terminal document."
Since NetHack started out as a terminal program, before there was a
Windows "classic" console API introduced with Windows NT, it seemed only
fitting that the Windows console port should evolve in the virtual terminal
direction.
This is a first stab at it. The performance won't be as instantaneous as
the low-level console API's. That's likely partly because of this consoletty.c
initial implementation, but it may also partly be because under the hood in
the OS, there's recognitions/translations/conversions going on. Microsoft
states it will continue to evolve the Windows Terminal and console, and
hopefully it will improve. Hopefully it isn't too slow to play. It still
attempts to take advantage of the back buffer stuff that Barton House
introduced to minimize screen updates. At this point, it can still be
recompiled without the virtual terminal support by defining NO_VT when
compiling consoletty.c, or by commenting out the definition of
VIRTUAL_TERMINAL_SEQUENCES at the top of sys/windows/consoletty.c
That's the informational news, and the negative news out of the way.
There's some good news too. Because the virtual terminal sequences
support include 24-bit color support, the Windows console under virtual
terminal sequence can provide a more pleasant set of colors to the NetHack
console interface. To that end, some color changes have been implemented
in consoletty.c now.
It makes the console port ready to accept and display 24-bit color from
the NetHack core, if that should ever happen, as well.
As usual with a first implementation, there may be some bugs. Reports
are welcome.
PatR [Mon, 11 Oct 2021 01:05:11 +0000 (18:05 -0700)]
and even more boulders...
Revise the m<dir>-toward-boulder handling to let a hero who would be
able to squeese into the boulder's spot if it was blocked from being
pushed to do the squeeze without any pushing.
Unlike the previous changes, this might have an impact on play. It
allows squeezing under then stepping past an unblocked boulder that's
in a corridor in order to be able to push it back the other direction
where maybe there's more room to maneuver it out of the way.
PatR [Sun, 10 Oct 2021 22:02:21 +0000 (15:02 -0700)]
yet more boulders: allow m<dir> to not push them
Allow a hero polymorphed into a giant to move to a boulder's spot
via m<dir> no-pickup move, instead of having to push it until the
way is blocked by something and then having push failure move hero
to the spot.
Also change m<dir> when not a giant to no longer push the boulder.
No time will elapse when not moving unless hero who didn't know
that there was a boulder there learns that one is. Since no actual
push attempt gets performed, player doesn't learn whether there is
anything beyond the boulder that inhibits it from being pushed.
PatR [Sun, 10 Oct 2021 19:59:17 +0000 (12:59 -0700)]
boulder sanity checking
Three new checks:
1) boulders are expected to be at the top of their piles, or when
not on top, only other boulders are above them;
2) boulders shouldn't be located at water or lava spots;
3) verify that boulders don't have their 'next_boulder' flag still
set at times when sanity checks take place; that's only valid
during moverock() [plus its calls to boulder_hits_pool()].
PatR [Sun, 10 Oct 2021 19:39:27 +0000 (12:39 -0700)]
"new boulder" fix
The default value for obj->corpsenm is NON_PM which is -1, so the
default value of boulder->next_boulder was non-zero instead of 0
as expected. Because of that, boulder object formatting by xname()
was yielding "next boulder" when plain "boulder" was intended.
Until the boulder or one in a pile above it got pushed, then it
was explicitly reset.
PatR [Sat, 9 Oct 2021 17:54:47 +0000 (10:54 -0700)]
better boulder pushing feedback
When you push a pile of boulders, describe the second and remainder
as "the next boulder" rather than just "the boulder". Matters most
when pushing into water or lava and you keep on pushing when the
first one or more sink into the pool or plug it, but also matters
for an ordinary push where the top-most one moves successfully and
then blocks the continuation attempt to push the second one. It was
somewhat confusing when all the messages said "the boulder" whether
they were referring to the same boulder or different ones.
Multiple pushes on the same move has always been a bit odd, but this
doesn't change that, just the feedback it generates.
PatR [Fri, 8 Oct 2021 20:53:21 +0000 (13:53 -0700)]
simpleonames() fix
Some code from about a month back changed xname() and doname() to
only use a single 'obuf[]'. That was to make sure that perm_invent
update also used at most one obuf. They use some slightly convoluted
code when they called other routines which returned an obuf because
only the most recently allocated one can be explicitly released for
re-use. That works, so I did the same for simpleonames() and
thesimpleoname() and for some reason neglected the convolution for
simpleonames().
For the case where plural was needed, it needs two obufs and tried
to release the first, which is a no-op. So if it was used in a loop
like display_pickinv() uses doname(), it could have cycled through
all the obufs and clobbered one a caller was expecting to remember.
I'm not aware of any instances of this being an actual problem, just
happened to notice that simpleonames() was different from other
similar routines.
PatR [Thu, 7 Oct 2021 17:09:44 +0000 (10:09 -0700)]
more DEF_PAGER
For Unix, add internal vs external pager choice to #version.
Others always use internal pagination so don't need to see that.
Also remove obsolete "command completion" option. I don't know
when it became unconditional but that was long enough ago to be
absent from the git log and from second cvs log included in that.
PatR [Wed, 6 Oct 2021 20:46:27 +0000 (13:46 -0700)]
fix confused remove curse bug
Reported directly to devteam, player observed that objects on the
floor had their bless/curse state change when reading a blessed
scroll of remove curse while confused. Message feedback mentioned
a silver saber being dropped. I didn't attempt to view the ttyrec
playbacks; what I'm sure happened was that the saber was secondary
weapon for dual wielding and had been uncursed; the confused remove
curse effect cursed it, which in turn caused it to be dropped. The
saber's 'next object' pointer became the [previous] top of the pile
at that spot and further object traversal intended to process the
rest of hero's inventory ended up processing floor objects there
instead.
This bug has been present for over 20 years (since 3.3.0 came out
in late 1999, when dual wielding was introduced and cursing of the
secondary weapon forced it to be dropped since making it become
welded was deemed to be too complicated) and never been reported.
Most likely players keep secondary weapons blessed so the scroll
effect doesn't touch them and simple object traversal sticks with
inventory. Or items at the spot have unknown BUC state so having
them be affected wouldn't be particularly noticeable.
PatR [Tue, 5 Oct 2021 08:11:24 +0000 (01:11 -0700)]
fix Unix build with DEF_PAGER defined
Eliminate a couple of compile warnings produced when DEF_PAGER is
defined: unixmain.c: g.catmore=DEF_PAGER; wintty.c: fd=open(...).
Override its use when DLB is also defined since an external pager
could access 'license' but not 'history', 'opthelp', &c when those
are in the dlb container file.
In the commented out value for DEF_PAGER, show a viable value for
the default configuration these days.
PatR [Sun, 3 Oct 2021 21:15:02 +0000 (14:15 -0700)]
displacer monster vs long worm
Reported directly to devteam: monster vs monster location swapping
didn't handle single-segment long worms properly. Multi-segment
worms are disallowed but a worm with no visible segments (which
actually has 1 segment at the head's location) are allowed and the
segment wasn't being moved with the core monster and could trigger
warnings if sanity checking is enabled. The next time that the
worm moved, it got itself back in synch.
I couldn't reproduce the warning but mdisplacem() clearly assumed
that a long worm reporting 0 segments didn't have any so wasn't
attempting to handle the hidden one.
The #adjust command can be used to split an object stack and if the
shop price of the two halves are different, the new stack will have
its obj->o_id modified to make the prices the same. That could be
used to tip off the player as to what the low bits of the next o_id
will be. Since no time passes, no intervening activity such as
random creation of a new monster can take place, so the player could
wish for something that depends on o_id with some degree of control.
Matters mainly for helms of opposite alignment intended to be used
by neutral characters since the player isn't supposed to be able to
control that. (Other items like T-shirt slogan text and candy bar
wrapper text had a similar issue but controlling those wouldn't have
had any tangible difference on play.)
The issue writeup suggested allowing the player to specify a helm's
alignment during a wish. That would defeat the purpose of having
o_id affect the helm's behavior in an arbitrary but repeatable way
so is rejected.
I implemented this fix before seeing a followup comment that suggests
using a more sophisticated decision than 'obj->o_id % N' for the
arbitrary effect. This just increments context.ident for the next
obj->o_id or mon->m_id by 1 or 2 instead of always by 1 and should
be adequate. It also has the side-effect that two consecutive wishes
for helm of opposite alignment won't necessary give one for each of
the two possible 'polarities', even with no intervening activity by
monsters, reinforcing the lack of player control.
Minor bonus fix: it moves the incrementing check for wrap-to-0 into
a single place instead of replicating that half a dozen times. Ones
that should have been there for shop billing and for objects loaded
from bones files were missing.
by the Riders that only damage the hero, not other monsters.
Noticed and diagnosed by vultur-cadens. Attacks dishing out the
damage type AD_DETH (Death), AD_FAMN (Famine), AD_PEST (Pestilence),
and also AD_DISE (Demogorgon, Juiblex, Scorpius) did 0 damage if
inflicted against monsters. That made Death harmless to other
monsters. The others have additional attacks (in the two Rider's
cases, only if both instances of their special attack hit on the
same move so that the second one is converted into a stun attack)
and could manage to kill other monsters.
The uhitm case can't happen. I suspect that the mhitm case was
originally intentionally omitted as something which won't happen,
but that's just a guess.
Be able to run 'make Guidebook{|.txt|.ps}' in the doc subdirectory
without requring a full install first.
makedefs is no longer one of the first things built when building
nethack, and even if it was, nobody should have to rebuild all of
nethack after 'make spotless' when they just want to create one
or more of the formatted Guidebooks. The 'roff versions (.ps and
also .txt) use makedefs as a filter by default, so wouldn't build
if it wasn't there.
Reported and diagnosed by entrez:
recalc_mapseen() has been looking at all slots in u.urooms[] rather
than stopping at the first \0. Since the whole array doesn't get
zeroed out when the value changes, stale room indices might follow
that first \0 and any rooms those referred to would erroneously get
flagged as having been visited by overview updates. Wouldn't matter
for the level where the stale indices got set, since you'd have to
have been in those rooms for it to happen, but would matter once you
moved on to other levels.
The 5 glyphs are now unaligned_altar, chaotic_altar, neutral_altar,
lawful_altar, and high_altar. The latter is only mapped if you are
on astral or sanctum levels.
Reported by entrez as a github issue for evilhack, 'gcc -2' issued
warnings about droppables() possibly returning the address of a local
variable (&dummy). It is mistaken; that never gets returned because
of various checks being performed. But making 'dummy' be static adds
negligible cost and should shut it up (not verified but no doubt
about viability...).
sp_lev.c: In function ‘lspo_altar’:
sp_lev.c:3962:9: warning: declaration of ‘shrine’ shadows a global
declaration [-Wshadow]
3962 | int shrine;
| ^~~~~~
In file included from ../include/hack.h:217,
from sp_lev.c:14:
../include/display.h:959:5: note: shadowed
declaration is here
959 | shrine
| ^~~~~~
Pasi Kallinen [Sun, 19 Sep 2021 10:51:51 +0000 (13:51 +0300)]
Gas clouds expand around terrain rather than being rhomboid
The gas will expand from its chosen center point via breadth-first
search instead of hardcoding a diagonal shape. The search is performed
with a randomized list of directions, and has 50% chance of not spreading
to a space it otherwise would have spread to. This has the effect of fuzzing
the cloud edges in open areas, helping the clouds on, for instance,
the Plane of Fire not be big rhombuses.
Also some other code refactoring related to stinking clouds in read.c
This comes from xNetHack by copperwater <aosdict@gmail.com>
The walls for the mines, gehennom, knox, and sokoban had been
changed at the "tile"-level, with no awareness of the core game,
or non-tile interfaces.
- Expand the glyphs to include a set of walls for the main level
as well as each of those mentioned above.
Altars had been adjusted at the map_glyphinfo() level to substitute
some color variations on-the-fly for unaligned, chaotic, neutral,
lawful altars, and shrines. The tile interface had no awareness of
the feature.
- Expand the glyphs to include each of the altar variations that
had been implemented in the display code for tty-only. This required
the addition of four placeholder tiles in other.txt. Someone with
artistic skill will hopefully alter the additional tiles to better
reflect their intended purpose.
Explosions had unique tiles in the tile window port, and the display
code for tty tinkered with the colors, but the game had very little
awareness of the different types of explosions.
- Expand the glyphs to include each of the explosion types: dark,
noxious, muddy, wet, magical, fiery and frosty.
Pile-markers to represent a pile had been introduced at the
display-level, without little to no awareness by the core game.
- Expand the glyphs to include piletops, including objects,
bodys, and statues.
Recently male and female variations of tiles and monsters had been
had been introduced, but the mechanics had been mostly done at the
display-level through a marker flag. The window port interface then
had to increment the tile mapped to the glyph to get the female version
of the tile.
- Expand the glyphs to include the male and female versions of the
monsters, and their corresponding pet versions, ridden, detected
versions and statues of them.
Direct references to GLYPH_BODY_OFF and GLYPH_STATUE_OFF
in object_from_map() in pager.c were getting incomplete results.
- Add macros glyph_to_body_corpsenm(glyph) and
glyph_to_statue_corpsenm(glyph) macros for obtaining the corpsenm
value after passing the glyph_is_body() or glyph_is_statue() test.
Other relevant notes:
- The tile ordering in the win/share/*.txt tile files has been altered,
other.txt in particular.
- tilemap.c has had a lot of alterations to accommodate the expanded
glyphs. Output that is useful for troubleshooting will end up in
tilemappings.lst if OBTAIN_TILEMAP is defined during build.
It lists all of the glyphs and which tile it gets mapped to, and also
lists each tile and some of the references to it by various glyphs.
- An array glyphmap[MAXGLYPH] is now used. It has an entry for each
glyph, ordered by glyph, and once reset_glyphs(glyph) has been run, it
contains the mapped symindex, default color, glyphflags, and tile
index.
If USE_TILES is defined during build, the tile.c produced from the
tilemap utility populates the tileidx field of each array element with
a glyph-to-tile mapping for the glyph. Later on, when reset_glyphmap()
is run, the other fields of each element will get populated.
- The glyph-to-tile mapping is an added field available to a window
port via the glyphinfo struct passed in the documented interface. The
old glyph2tile[] array is gone. The various active window ports that
had been using glyph2tile[] have been updated to use the new interface
mechanism. Disclaimer: There may be some bug fixing or tidying
required in the window port code.
- reset_glyphmap() is called after config file options parsing
has finished, because some config file settings can impact the results
produced by reset_glyphmap().
- Everything that passes the glyph_is_cmap(glyph) test must
return a valid cmap value from glyph_to_cmap(glyph).
- An 'extern glyph_info glyphmap[MAX_GLYPH];' is inserted into the
top of only the files which need awareness of it, not inserted into
display.h. Presently, the only files that actually need to directly
reference the glyphmap[] array are display.c, o_init.c (for shuffling
the tiles), and the generated tile.c (if USE_TILES is defined).
- Added an MG_MALE glyphflag to complement the MG_FEMALE glyphflag.
- Provide an array for wall colorizations. reset_glyphmap() will draw
the colors from this array: int array wallcolors[sokoban_walls + 1];
The indices of the wallcolors array are main_walls (0), mines_walls
(1), gehennom_walls (2), knox_walls (3), and sokoban_walls (4).
In future, a config file option for adjusting the wall colors and/or
an 'O' option menu to do the same could be added. Right now, the
initializaton of the wallcolors[] array entries in display.c leaves the
walls at CLR_GRAY, matching the defsym color.
- Most of the display-level kludges for some of the on-the-fly
interface features have been removed from map_glyphinfo() as they
aren't needed any longer. These glyph expansions adhere more closely to
the original glyph mechanics of the game.
- Because the glyphs are re-ordered and expanded, an update to
editlevel will be required upon merge of these changes.
Use a slightly more meaningful name for each one rather than
a sequential numerical name.
S_explode1 to S_expl_tl
S_explode2 to S_expl_tc
S_explode3 to S_expl_tr
S_explode4 to S_expl_ml
S_explode5 to S_expl_mc
S_explode6 to S_expl_mr
S_explode7 to S_expl_bl
S_explode8 to S_expl_bc
S_explode9 to S_expl_br
Pasi Kallinen [Fri, 17 Sep 2021 17:52:54 +0000 (20:52 +0300)]
Allow dropping just picked up items
When using a menu to drop or put in items into a container,
allow putting in the item (or items) you picked up previously,
by selecting the 'P' entry from the item class menu
Inspired by the itemcat patch by Stanislav Traykov.
Reported and diagnosed by entrez:
"The <mon> yanks <two-handed weapon> from your corpses!"
It became unwielded and that triggered a perm_invent update and
such updates reformat entire inventory, so if that contains a dozen
or more items it will use all the obuf[] static buffers as least
once. In this case, the bullwhip code had plural of "hand" in one
of those buffers and by the time it delivered the message which
used that, the value had been clobbered.
As the diagnosis mentioned, it can be tricky to reproduce since
either &obuf[0] or &obuf[PREFIX] might be used and if the value
being clobbered didn't overlap, the effect wasn't noticeable.
Instead of fixing the bullwhip message, this changes inventory
display so that it should no longer churn through all the buffers.
It also adds a fixes entry for #K3401, which was already fixed for
3.7 but I hadn't been able to reproduce it for 3.6.x (which I now
blame on the PREFIX trickiness).
Recognize latest version of Visual Studio Community 2017 version 15.9.39
Recognize latest version of Visual Studio Community 2019 version 16.11.3
The removal of the generated $(SRC)\tile.c file moved from
nmake spotless
to
nmake clean
I recently changed a comment in objclass.h and that should have
triggered a full or nearly full rebuild but only resulted in a
couple of files being recompiled. Instead of trying to figure out
why, I just ran Makefile.src through 'make depend' to force it to
be up to date.
A side-effect is that version.c won't be unnecessarily recompiled
every time nethack gets relinked. The reason for that (date.h
being regenerated with new data) is handled by date.c now.
Pasi Kallinen [Sun, 12 Sep 2021 16:44:35 +0000 (19:44 +0300)]
Reveal the monster your strike moved
When you hit a small hidden monster (by eg. force-fighting)
that got moved by the strike, the monster stayed hidden, possibly
causing a sanity checking error.
Save files from before the 'disambiguate WHACK' patch were not
necessarily compatible with ones after it, leading to potential
restore problems.
Comments in objclass.h (from before the patch) suggested that
inappropriate assumptions were being made about field layout.
This deliberately introduces new incompatibility and increments
EDITLEVEL to caused earlier save and bones files to be thrown
away.
when fleeing hero who was wearing gold dragon scales/mail and not
wielding any weapon.
When a gremlin was made to flee "artifact light", code originally
intended for Sunsword attempted to format 'uwep' as an artifact. For
gold scales/mail instead of that, it gave a sane but inappropriate
value if wielding something or segfaulted if not wielding anything.
when an unseen monster picks up an item that the hero knows some
things about. That's intentional, but vision is turned off while
engulfed so throwing or dropping something while swallowed always
treated it as being handled by an unseen monster.
If hero is swallowed or held by a monster or poly'd and holding a
monster, behave as it the monster can 'seen' by touch when items are
added to its inventory.
This is because ice was being treated as a type of corridor rather than
a ROOM space, and running has rules for following similar terrain. In
reality it's not a corridor and should behave like normal room for
running purposes.
This was obvious in the valkyrie quest upper levels with ice fields, in
which running into the edges of the map obliquely, or into the corners
of the map, would send the hero flying around the edge in a different,
probably unintended direction.
triggered by Grayswandir's hallucination resistance. If the game
is saved while hero is hallucinating but having that be suppressed
by wielding Grayswandir, is riding, and the steed is on an object,
then during restore the hero's location will be updated because
of the presence of the object but the attempt to display the hero
there is made before u.usteed has been restored and fails.
Currently weapons are set up as piercing, slashing, or whacking, using
their object's oc_dir field, with the intention that certain weapons
can classify as both. However, since oc_dir is only 2 bits and WHACK is
0, there's no way to unambiguously express some of these combinations.
Certain weapons such as the lucern hammer are defined as combination
piercing/blunt weapons, but the game just sees it as a piercing weapon.
This commit adds a third bit to oc_dir and promotes the WHACK constant
to its own bit. Nothing should be affected by this (wand directions and
the like should remain working as usual) other than the
blunt-and-something-else weapons being defined properly.
Michael Meyer [Fri, 3 Sep 2021 20:55:37 +0000 (16:55 -0400)]
Fix: 'Suddenly you cannot see it'
Updates to m_dowear_type(worn.c) in 5a09a01a13 inadvertently reversed
the effect of an xor near the end of the function, causing it to go from
testing whether a monster's status as 'seen' or 'unseen' changed over
the course of the function to testing whether it remained the same.
As a result, whenever an unseen, invisible monster donned a piece of
armor anywhere on the map, the message 'suddenly you cannot see it'
would be printed. Fix the xor so that it goes back to testing whether
visibility changed since the start of the function.
Pasi Kallinen [Fri, 3 Sep 2021 10:27:36 +0000 (13:27 +0300)]
Fix eel hiding in dry land
When an eel was hiding in a pool and a rolling boulder trap
launched a boulder on top of the pool, and the boulder then
filled the pool, the eel ended up hiding on the dry land.
As a stopgap measure, kill off any monster that is in the
pool location when the boulder hits the pool. This should
probably be expanded to handle flying monsters differently.
projects / nethack / log