GitHub 1343 report by @ars3niy:
"When you are blind and see with telepathy a monster whom you then hear read
a scroll, said monster turns into an "I". While it reveals which one exactly
read the scroll, it is strange that you can no longer see it with telepathy
until it moves to another square."
Fixes#1343
There was a transcription error in the comments in cstd.h for
the standard list of header files, where only the description
remained for <stdlib.h>, not the name of the file itself.
Remove several extraneous inclusions of the standard C99 headers.
Tested on the following afterwards:
Linux (using hints/linux.370) including tty, curses, qt6, and X11
macOS (using hints/macOS.370) including tty, curses, qt5, and X11
Windows MSYS2 using sys/windows/GNUmakefile
Windows Visual Studio using sys/windows/Makefile.nmake
msdos cross-compile on Ubuntu using djgpp cross-compiler
Various bits I had in progress before Michael's commit.
Mainly forget engravings when bones are saved instead of leaving them
flagged as seen for the next hero who gets the level.
GitHub issue reported by ars3niy:
https://github.com/NetHack/NetHack/issues/1303
@ars3niy commented on Oct 27:
Stepping on a square with a dust or "graffiti" engraving while blind
produces no message because presumably you can't read them by swiping
the floor with your hands, however the engraving glyph still shows up on
the map afterwards. While this helps zen players, it looks like a bug.
@ville-v commented 3 days ago:
Searching while blind also reveals the engravings. Here is a save file
demonstrating the issue.
[...]
This adds an erevealed bit to engravings, to accompany the the eread
bit that is already there.
eread: refers to the text of the engraving
erevealed: refers to the engraving map symbol
Hopefully, this resolves issue 1303 without creating additional bugs.
This invalidates existing save files and bones.
Fixes#1303
Issue reported by elunna: the message given when zap_over_floor()
hits iron bars with lightning or acid was substituting a couple of
words or phrases in the wrong order, resulting in
|The {melt|dissolve} iron bars somewhat but remain intact.
when the iron bar location is flagged as non-diggable. It should be
|The iron bars {melt|dissolve} somewhat but remain intact.
Not mentioned: the corresponding message for locations that aren't
flagged as non-diggable used "melt" unconditionally. Change it to
keep "melt" for lightning but switch to "corrode away" for acid.
Fixes#1342
After finding a trap on a chest or a large box, remember it
as trapped: "You see here a trapped large box."
Randomly generated chests and boxes can be obviously trapped.
Allow defining obviously trapped containers via lua.
Invalidates saves and bones.
A fix in Janurary to avoid appending engraving text or headstone
text when examining a map location where a monster or object covers
the engraving or headstone inadvently broke the /e and /E variations
of the '/' command, which is intended to list such text even when
covered.
We can't rely on doopen_indir return value to
check whether hero moved and opened a door.
Instead, explicitly check whether the door is still
closed, and whether hero moved.
The ones below marked "left,revisit" might be worthy of code changes
explode.c:removed: arg sx,sy passed to breaks() are coordxy and so are the parameters
invent.c: removed: discover_artifact() parameter is xint16, so change cast to match
mail.c: removed: gv.viz_rmin[] contains coordxy's, and enexto() 2nd param is too
mkmaze.c: removed: x, y are coordxy and so are cc->x, cc->y
mkroom.c: removed: tx, ty are coordxy and so are parameters to occupied()
mplayer.c: left,revisit: x,y declared int, but mk_mplayer() params are coordxy
sp_lev.c 2890: left alone: x,y declared int, but is_ok_location() params coordxy
sp_lev.c 4114: left alone: cast from lua_Integer
sp_lev.c 4123: left alone: cast from lua_Integer
sp_lev.c 4650: left alone: cast from lua_Integer returned from lua_tointeger
sp_lev.c 4765: left alone: cast from int_Integer returned from lua_tointeger
sp_lev.c 4772: left alone: cast from int_Integer returned from get_table_int
teleport.c 366: left alone: cast from int returned from rn2()
timeout.c 2171: left alone: cast from long
vault.c: left,revisit: guardx,guardy declared int, but bestcc fields are coordxy
worm.c 791: left,revisit: wseg.wx, wseg.wy are coordxy, so are nx, ny, but not
ox, oy; why are ox, oy needed at all?
worm.c 955: left alone: wx, wy are coordxy, wseg_at() params are int x, int y
zap.c 5061: left alone: cast from long
Issue reported by loggersviii: attempting #untrap from an adjacent
doorway can move the hero diagonally out of the doorway.
A followup comment by elunna pointed out that a monster's attack that
results in knockback can produce similar result.
Fixes#1305
Issue reported by elunna: if the 'fireassist' option is on and the
quiver contains ammo, 'f' while wielding an aklys switches to the
ammo's launcher instead of throwing the aklys.
Fixes#1337
Luck from sacrificing is now limited by the value of the sacrifice.
This fixes two exploits, both of which rely on getting luck up to
maximum as soon as you have an altar, a luckstone, and a few
rations, via altar-camping until you accumulate enough luck. One of
them is to use the resulting luck to throw off the balance of combat
via using it to make hit chance calculations irrelevant. The other
is to use it to get crowned early in the game; in particular,
getting crowned pre-Sokoban is often viable and, especially for
chaotic characters, solves most of the game's difficulty at that
point (because the intrinisics and weapon are enough to carry a
character to the Castle given even mediocre luck with finding armor).
After this commit, becoming crowned very early in the game is more
difficult (likely requiring unicorns and identified gems), and the
hit chance gain from luck becomes a more gradual gain over the
course of the game rather than all happening immediately upon
finding the altar and luckstone.
In addition to making the game more balanced, this also discourages
grinding by reducing the incentive for altar-camping, so it will
hopefully make it more fun as well.
In 3.6, artifact gifts are often either a) entirely useless or
b) gamebreaking, neither of which is really ideal from a balance
perspective.
This commit aims to make artifact gifts more useful in the early
game by greatly increasing the chance for situational artifacts to
generate positively enchanted. However, the most powerful
artifacts will now only be gifted if you offer a high-value corpse,
meaning that they are only likely to be accessible later in the
game. The selection of which artifact to gift has become more
complicated in order to a) increase the chance that it fits the
character and b) reduce cheese strategies (e.g. it is no longer
possible for elves to force the gifting of Stormbringer as the
first sacrifice gift).
Issue reported by ars3niy: pets with reflection or ranged attacks
would only attack floating eyes when rolling the 10% random chance
that other pets have even though they could have always safely
attacked.
This fixes the situation for melee attacks by pets who have
reflection.
dog_move() is too complicated for my feeble brain to cope with the
ranged attack aspect. Pets still won't use ranged attacks against
floating eyes.
With the fix for reflection, I discovered that silver dragons
would be subjected to floating eyes' passive paralysis even when
their breath attack was suppressed. (It wouldn't impact them, due
to reflection, but the message about the floating eye being hit by
its reflected gaze was being delivered without being preceded by
any message since no attack had taken place yet.) This fixes that.
\#1336 is still open
Ensure that the destination selection for intentional
teleport begins at the hero, rather than starting at
a place on the map stored from a prior travel command.
The location of the call to dobjsfree() in freedynamicdata()
appears to have been non-ideal.
After getting complaints from a leak-sensing tool after
#quit, the source of the leaks was investigated.
The call to dobjsfree() had been placed immediately following
a call to dmonsfree(), and it did clear out the go.objs_deleted
chain at that point.
Further investigation revealed that the following functions
later on in freedynamicdata() were then adding more deleted
objects to the go.objs_deleted chain:
free_current_level();
freeobjchn(gi.invent);
freeobjchn(gm.migrating_objs);
Move the call to dobjsfree() to a location after those listed
above.
For the wizard-mode command #migratemons at the
"How many random monsters to migrate to next level? [0]" prompt,
allow a negative number to cause it to use existing monsters
already on the level for the forced migration, up until the
absolute value of the number, instead of random new monsters
as it does for a positive number.
For example, specify -20 to force-migrate 20 existing monsters
already on the map.
I don't think this solves the recent light source reports,
but it changes a couple of things in an attempt to get more
information.
1. Having gy.youmonst.m_id field always be zero makes it tough
to distinguish it from uninitialized memory, or a random memory
value. This changes the m_id for the hero's gy.youmonst.m_id
to always hold the identifier 1, instead of 0.
2. write_ls was taking the stashed pointer in the light source,
and using it to immediately extract the m_id field and search
for that m_id. This changes the approach slightly, to actually
try and locate the stashed pointer itself in one of the monster
chains. Only if the monster pointer is located, do we dereference
it to obtain the m_id field.
3. For the interim, mark the saved ls with another set bit when
there has been a failure to locate the monst. At this time,
no code is acting on that bit, but it can be seen in a debug
session.
Hopefully, the next report will provide enough information to
understand the scenario a little better.
