The comment I added to data.base--to explain that despite what the
short description says, an aklys wouldn't return to sender after being
thrown--was bugging me, so I've made aklyses behave like Mjollnir.
If thrown when wielded as primary weapon, it will usually return and
usually be re-wielded. I also added a new message when either thrown
Mjollnir or thrown aklys is expected to return and fails to do so.
Most of the diff to dothrow.c is a change in indentation level. The
amount of code needed was quite small.
Autopickup for thrown Mjollnir which had failed to return was putting
it into the quiver slot if that was empty. Note quite an outright bug,
but it started wielded and can't be thrown if quivered, so exclude it
from the stuff that will auto-fill the quiver slot when added to invent
(post-3.6.0 issue).
Reported suggested that "congratulations" was too modern for use by
your god during ascension and that the longer phrases which were
shortened to yield it were too modest for the god to use. Make the
suggested change.
Report indicated that looking up "more info?" for "kittens" would show
the data.base entry for "kitten" and then when the display window was
dismissed, another "--More--" prompt for a empty second display window
would occur. Looking up "2 arrows" from a closely-seen object on the
map behaved similarly. User correctly diagnosed that the two-pass
lookup left the 'found_in_file' flag set from the first pass during
the second but that just clearing that resulted in "I have no info
about such things" on the second pass. The code is on the convoluted
side and needed an extra flag to handle 'seen on first pass' in
addition to clearing found flag after the first pass. I also added a
check to skip the second display if primary and secondary keys don't
match each other but both find the same entry. To test it, I tried
"a +0 aklys named aclys". That found the aclys entry but failed to
find "+0 aklys", so I added another change to have the key massaging
remove +/-N after removing "a", "an", or "the".
If "Want to see more info \"" + lookup string + "\"?" was too long,
the prompt buffer passed to yn() was being left uninitialized. Also,
test for too long was based on BUFSZ but yn() complains (to paniclog)
if the prompt is longer than QBUFSZ. Make checkfile() construct a
truncated prompt if the lookup string is too long.
I untangled some spaghetti by making all the 'goto's be forward. It
didn't help a lot but did simplify a few early returns by having them
jump to a common exit instead of replicating the file close.
Incorporate some git information into NetHack so that it
is potentially visible to a player. That's useful when
collecting details about the version that they are
running and, if the gitinfo is present, it can tie the
code to a specific git commit in the repository.
This modifies 'makedefs -v' to check for the presence of a data file
called dat/gitinfo.txt and if it is there, parse out its
contents, then write additional lines to include/date.h beyond
what 'makedefs -v' was previously putting in there, similar to
this sample:
#define NETHACK_GIT_SHA "0c84e564c78e2024e562d39539376ce2e21eec8e"
#define NETHACK_GIT_BRANCH "NetHack-3.6.0"
The contents of an appropriate dat/gitinfo.txt are as follows,
and trailing/leading whitespace is not significant:
githash = 0c84e564c78e2024e562d39539376ce2e21eec8e
gitbranch = NetHack-3.6.0
It also adjusts the contents of the 'v' version information to
include the additional git info when available.
Also adds some hooks DEVEL/hooksdir and a perl file to DEVEL
for simplifying and automating the deposit of dat/gitinfo.txt
so that it generally reflects the most current git commit.
DEVEL/gitinfo.pl can be used to build dat/gitinfo.txt at any
time without doing a commit, merge, or checkout.
perl DEVEL/gitinfo.pl
command line --version and -version support
To complement the extra information being provided in the
version by the 'v' command, this also adds support for the
following new command line arguments:
--version
-version Output the NetHack version string then exit.
--version:paste Output the NetHack version string and also copy it to
-version:paste the platform's paste buffer for insertion somewhere,
then exit.
If the paste variation of -version is requested on a platform that
hasn't incorporated any support for the capability, it will deliver
the version info then an error message, prior to exiting.
To support the extended -version:paste variation, a port needs to:
- provide a port-specific routine to perform
the paste buffer copy in a port code file.
- #define RUNTIME_PASTEBUF_SUPPORT in the include/portconf.h header file.
--skeleton--
void port_insert_pastebuf(buf)
char *buf;
{
/* insert code to copy the version info from buf into
platform's paste buffer in a supported way */
}
macosx and Windows have both added support for RUNTIME_PASTEBUF_SUPPORT
The earlier fix for hoizontal vs vertical doors would have worked for
the Cav quest (lower left in leader's chamber) where door handling
occurs before wallification, but it wasn't working for minend-3 (east
wall of entry room) which already had walls. The more recent fix
solved the second case but broke the first one. I think this actually
solves both modes of door classification. I hope....
Forwarded to the contact form from a github "issue": in some
circumtances clairvoyance lets you move the cursor around to examine
the revealed map, and when doing so starts with "for instructions
type '?'". When extended clairvoyance periodically kicks in, as
opposed to explicitly casting the spell, there wasn't sufficient
context to figure out what it was prompting for (unless you actually
answer '?' to get instructions). Depending upon the most recent
message, it could seem like quite a strange prompt. Explicitly give
a clairvoyance-specific message prior to that.
Also, the getpos() help was including suggestions for targetting
monsters that aren't appropriate when it's being used for detection.
do_name.c has had quite a bit of formatting rot slip in since 3.6.0.
This fixes up the stuff I spotted by manual inspection.
Web contact report of a github pull request. A previous fix from
same user dealt with potential crash caused by freeing mailbox data
when the mailbox came from getenv("MAIL"). getenv() doesn't return
a value obtained by malloc so freeing it was bad. The fix was to
allocate memory to hold a copy of getenv("MAIL") so that free() was
valid. Unfortunately it didn't allocate enough space to hold the
terminating '\0' so potentially corrupted malloc/free bookkeeping
data. And the alloc+copy was being performed every time the mailbox
was checked, resulting in leaked memory from the previous check (if
MAIL came from player's environment). Fortunately the recheck only
takes place after new mail is actually detected and reported to the
player so the leak was probably small for most folks.
This compiles for the set of conditionals that apply to me (after
taking out -DNOMAIL that the hints put in my Makefile) but I can't
test that it actually works since mail is never delivered to this
machine.
An inventory of unpaid items where more than one was present would
show
|> bag's contents N zorkmids
if any of the items were inside a container whose contents aren't
known. But if there was only one item (so container must be owned
by hero) the 'Iu' output menu was skipped for pline and yielded
|> scroll of magic mapping 133 zorkmids
Force the menu display if the lone unpaid item is inside a container
whose contents are unknown.
I'm not sure whether a hero-owned container can have both unknown
contents and an unpaid item in normal play. I managed it while
trying to fix a reported problem--except I can no longer find the
relevant report--where itemized shop billing also revealed unseen
container contents (for any number of items, not just 1). That isn't
fixed yet, but I want to get the simpler 'Iu' part out of the way.
Reported about 18 months ago: standing on a scroll of scare monster
while next to a shopkeeper who was blocking the shop entrance because
hero was carrying unpaid shop goods would yield "<shk> turns to flee"
but <shk> wouldn't move. This was a side-effect of making standing
on scrolls of scare monster be stronger than on "Elbereth" when the
latter was nerfed. Make shopkeepers inside their own shops and temple
priests inside their own temples be immune to the effect of hero
standing on scare monster.
Also, make the Wizard, lawful minions, Angels of any alignment, the
Riders, and shopkeepers and priests in their own special rooms (ie,
all creatures that now ignore standing on scare monster) be immune to
the fright effect of tooled horns. Innate magic resistance usually
prevented them from being scared anyway, but make it explicit.
Reading a scroll of scare monster or casting the spell of cause fear
still rely on innate resistance to avoid chasing away those monsters.
I'm not sure whether they should have the same adjustment.
Apply user-contributed patch to make do_vision() handle FILE_PREFIX
correctly. It was putting that value into the filename buffer, then
overwriting it with the ordinary filename instead of appending.
Deletion of just-made vis_tab.h when creation of vis_tab.c fails would
have failed too if FILE_PREFIX had been working.
The patch was against 3.4.3 and didn't apply cleanly to current code,
but it is a staightforward fix, although the file deletion case was
buggy (failed to clear "vis_tab.c" from buffer before reconstructing
"vis_tab.h" via appending stuff). FILE_PREFIX seems to be Amiga-only
so I've only tested the usual case where it isn't defined.
Mentioned in the newsgroup: picked up items have stopped merging with
compatible stacks in inventory.
The commit 0c51555849 by me on January 5
|
| fix #H6713 - unpaid_cost: object not on any bill
|
| Stealing a shop object from outside the shop with a grappling hook
| would result in that item being left marked 'unpaid' after the shop's
| bill was treated as being bought and not yet paid for. This led to
| "unpaid_cost: object wasn't on any bill" every time inventory was
| examined. The problem was caused by handling the shop robbery after
| removing the object from the floor but before adding it to inventory,
| so it couldn't be found to have its unpaid bit cleared.
|
inadvertently caused that. The effect was actually deliberate but it
wasn't intended to be so widespread. Handle extract/bill/addinv/rob
sequencing differently instead of overriding inventory merging.
Stealing a shop object from outside the shop with a grappling hook
would result in that item being left marked 'unpaid' after the shop's
bill was treated as being bought and not yet paid for. This led to
"unpaid_cost: object wasn't on any bill" every time inventory was
examined. The problem was caused by handling the shop robbery after
removing the object from the floor but before adding it to inventory,
so it couldn't be found to have its unpaid bit cleared.
When investigating this I came across a more severe bug: if the hero
had never entered the shop, the shopkeeper's bill wasn't initialized
properly and add_one_tobill() could crash while attempting to execute
bp->bo_id = obj->o_id;
because 'bp' was Null.
When polymorphed into an iron golem (or gremlin with 2/3 chance),
triggering a rust trap would give "a gush of water hits <you or some
body part>" and then give a second "a gush of water hits you" when
dealing with golem or gremlin effects. That made it seem as if the
trap was hitting twice. This removes the redundant messages. (Rust
trap against monster iron golem or gremlin didn't have them.)
If mimics were genocided before loading a special level which
contained mimics with specific appearances, whatever random monsters
took their place also end up having their intended appearance.
monst->cham uses NON_PM rather than 0 to mean "not a shapechanger".
Implement the suggestion that hero's current god not uncurse a worn helm
of opposite alignment when prayer result is fix-worst-cursed-item or
uncurse-all-cursed-items since doing so makes it easy for hero to switch
to another god. The second boon will still uncurse non-worn helms of
opposite alignment since that has no effect on how easy or hard it is
for the hero to change alignments. (The first boon only applies to worn
items plus luckstones and loadstones; non-worn helms aren't applicable.)
Newsgroup discussion mentioned that it was possible to open the castle
drawbridge with musical notes even while confused. There was already
some handling for confusion: improvisation treats magical instruments
as their mundane equivalents. This takes if farther: when stunned
or confused or hallucinating you'll always improvise instead of being
given a chance to choose notes. Being stunned now behaves the same
as being confused in regards to magical instruments (possibly/probably
it should prevent playing music altogether). Hallucination gives
different feedback at start but still allows magical playing.
Excess verbosity for multi-shot throwing/shooting by monsters.
The Green-elf shoots 2 elven arrows.
You are almost hit by the 1st elven arrow. The 1st elven arrow misses.
You are almost hit by the 2nd elven arrow. The 2nd elven arrow misses.
Just give one or the other of the miss messages. If it reaches the
hero's location, give the first. If it lands somewhere else, give the
second. (It might be possible to get both if hero is displaced and
the monster thinks he/she is behind his/her actual location. I'm not
sure.)
Also, only say "you are almost hit" if it is true: the dieroll nearly
got past your armor. Otherwise, say "The Nth arrow misses you."
More fallout from allowing W/T on accessories and P/R on armor without
combining them outright. If poly'd into verysmall or nohands critter,
'W' yields "don't even bother" before even prompting what to wear, but
'P' would prompt for an accessory and then wear armor if that was what
got picked. Now 'P' will still prompt, in case it's for an accessory,
but picking a piece of armor no longer wears that armor.
'W' still doesn't even prompt, so won't allow accessories as well as
no armor. I'm not sure whether that should be changed.
A relatively recent change to make secret doors within horizontal walls
become horizontal doors after discovery was making some secret doors
that should have remained vertical become horizontal too. While still
hidden, they got displayed as horizontal wall segments in the midst
of vertical walls. Example was the "Catacombs" (minend-3) variant of
mines' end. The hidden door on the east wall of the entry room was
shown as horizontal, while another one on the west wall of that same
room was correctly vertical. This fix uses different criteria to
decide horizontal vs vertical, partly because I couldn't understand
how the previous code was supposed to work.
Hidden doors now seem to display as correctly oriented walls and once
discovered seem to become correctly oriented doors. I tested by
checking quite a few special levels (and some regular ones)--but not
all--with '#terrain d'. Plus some searching to unhide secret doors
while using a custom symbol set that displayed closed horizontal doors
(S_hcdoor) as '=' and vertical ones (S_vcdoor) as '"'.
When hero poly'd into paper golem "burns completely" he is rehumanized
even if he has the Unchanging attribute. A comment states that that is
intentional, but there was no explanation given to the player. Report
that "your amulet of unchanging failed" when rehumanization despite
Unchanging happens. (Don't ask me how or why it fails; I don't know.)
When a monster killed a paper golem with a fire attack, the player was
told that the golem "burns completely" yet it might still leave some
blank scrolls as 'corpse'. The fix for that was one-line, but several
other death-by-fire situations which didn't report "burns completely"
were also leaving scrolls: fireball spell or scroll of fire or other
fire explosions (if any), also wand of fire. Fire trap and poly'd
hero with fire attack were already suppressing 'corpse'.
Self-genocide (own role or race) while polymorphed sets u.uhp to -1
so that you'll be killed during rehumanization. I found a couple
of places which were testing (u.uhp < 1) without checking polymorph
state, and one of those was where monster movement decides whether or
not to attack. This bug seems to have been present since start of
the second cvs repository, so has been around for quite a long time
without anybody letting on that they'd noticed. So it probably isn't
a very effective exploit, although it would certainly make ascending
without wearing armor become much more feasible.
There are bound to be other places which examine u.uhp directly
instead of '(Upolyd ? u.mh : u.uhp)' but I only checked m*.c.
When ascending or escaping from the dungeon, adjacent pets are moved
onto the 'mydogs' list so that they can be included in the score and
mentioned as being with hero in the final messages. But keepdogs()
was caled to do that before the known portion of the map was drawn
in the dumplog file, so adjacent pets were missing. Defer that until
after the map has been dumped so that pets will still be present.
When swapping places with a pet, the hero's coordinates are changed
before some tests which might disallow the swap, and if the pet was
a hidden mimic or was trapped and became untame, the attempt to draw
the revised pet or former pet would actually draw the hero and have
that mistake be visible during the message about not swapping. That
last bit only occurred when the pet couldn't move diagonally (due to
being a grid bug or to being unable to squeeze through a tight space).
Also, spoteffects for arriving at a new location took place even
though the hero hadn't changed position.
Make the suggested change that only adjusting something into its own
slot be the way to collect/merge compatible stacks with it, instead
of any #adjust without a split count. This removes the previous
special case for a count that matches the stack size. Having to
know the exact count was not a burden on the player, but being able
to move things around without merging with other stacks makes more
sense than the original behavior or the hack to work-around that
behavior.
The report stated that '#adjust a c' after '#adjust 1a b' moved all
the original 'a' to 'c' instead of leaving the one in 'b' alone.
That's true, but it is also the intended behavior. Splitting off
with a count explicitly avoids gathering compatible stacks (but
does merge into the destination if compatible, instead of swapping).
Moving a whole stack gathers compatible ones and puts the whole
merged group into the destination.
But that leaves a gap in functionality: there's no way to get the
don't-collect-other-stacks without splitting; there ought to be.
So, allow the player to specify full count to move a stack from one
slot to another without collecting compatible stacks (the behavior
when no count is given) or splitting (the behavior when count is
less than full amount). In the example above, if 'a' started with
5 doodads and had 4 left after splitting one to 'b', '#adjust 4a c'
will move those 4 (all of 'a') to 'c' without merging 'b' into them.
The method is a bit obscure but it's also something which doesn't
come up very often.
Report asked why u.ustuck takes double explosion damage, and concocting
a reason uncovered several inconsistencies. Grabber takes double damage
for reaching into hero's spot, but only when that spot is within the
explosion's radius and only if hero isn't engulfed. Poly'd hero takes
double damage if holding a monster which is hit by the explosion.
There are still multiple bugs here: if the hero is grabbing a monster
which gets killed by the explosion, the fact that one was held is
forgotten by the time damage is inflicted upon the hero. Just a messy
detail that I opted not to get bogged down in. But much messier is
that grabber might be outside the explosion radius reaching into that
to hold grabbee, in which case no damage is inflicted. Handling that
for out-of-range monster holding exploded hero shouldn't be very tough,
but handling it for out-of-range hero holding exploded monster could be
hard. Anyway, it's more headache than I intend to tackle.
From a beta-tester running 3.6.0:
|You faint from lack of food.
|You suddenly vomit!
The latter has already been changed to "You vomit" (it's given at the
end of a multiple-message vomiting countdown so wasn't "sudden") but is
still odd if your stomach is so empty that you're subject to fainting.
Give an alternate message in that case:
|Your stomach heaves convulsively!
Vomiting while unconscious (when that's due to something other than
fainting from hunger) should pose a risk of choking to death, but I'm
going to pretend that this hasn't occurred to me....
Before this change, more-prompts and input text -prompts could not
be accepted with carriage return. Now, just like in menus, carriage
return is treated the same as a newline.
To test, use 'stty -icrnl'
There's far too much gold just laying around on the floor.
Didn't previous adventurers grab most of it?
This should incentivize gold detection and digging out vaults,
selling stuff to the shopkeeps, and making it harder to donate
for protection.
Most radical reduction on the first few levels, for dlevel 1,
average amount of gold was 80, is now 10, for dlevel 2, 95->15
Does not change the amount of gold deposited by mineralize,
in the vaults, or contained in chests and large boxes.
Report was for tty, but X11 exhibited the same behavior. With the
perm_invent option enabled, when the permanent inventory window is
displayed, it would be empty if not carrying anything. For tty, that
meant a naked "(end) " selection prompt. Put a separator line of "Not
carrying anything" into the menu so that it won't be completely empty.
The selection prompt is still present but it is attached to something.
(The behavior is different from !perm_invent, where you get that same
text via pline without any menu at all.)
Player tried to #name a potion on the floor and got prompted to call a
stream of fluid (sink feedback) instead of a potion. A mimic posing
as an object is represented by a partially initialized object when
examining its map location. #name for floor object uses the same data
as look_at.
obj->fromsink overloads obj->corpsenm which is set to NON_PM (-1) even
when creating a non-init'd object. 'fromsink' was only being forced to
0 when creating an init'd object (unlike leash which has its overload
of corpsenm set properly regardless of caller's request to init). So
docall() treated a mimicked potion as a sink stream.
The fix is straightforward but has pointed out another bug which is
harder to fix. Examining a floor object next to you sets that obj's
dknown flag as if you had seen it up close (a new feature in 3.6.0).
But a mimicked item is discarded as soon as it's been looked at, so
looking again from a non-adjacent spot will give different feedback
since the previously set dknown will be unset when replaced by a new
fake object. So you can use '/' and ';' to recognize mimics without
provoking them into motion. Best fix: mimicking an object should use
a fully initialized one which is tracked via monst->mextra, but that
will break save file compatibility. Possible hack: change monst->
mappearance into a mask which uses N bits for object type (instead of
full 'int') and one of the other bits to track obj->dknown. Examining
an adjacent object probably ought to set bknown for priests, so bknown
and blessed/uncursed/cursed would need to be tracked too.
Doors in des-files were always generated vertically.
This wasn't visible unless you had separate symbols for
closed vertical and horizontal doors, or used tiles.
The followup message about the fix for #5056 was trapped by the spam
filter so didn't reach us for a while.
xlogfile has an extra field to track various achievements made during
the game it logs, two of which are fully exploring the gnomish mines
and fully exploring sokoban. Those are accomplished by finding the
special 'prize' item on the final level of their branch: luckstone
for mines and bag of holding or amulet of reflecition for sokoban.
3.6.0 had a bug where any item of the target type found anywhere in
the dungeon resulted in achieving the relevant goal. A post-3.6.1 fix
for that required that the item be found on the end level of the branch
and attempted to require that it an item explicitly placed there by the
special level loader, but the latter aspect had a bug which meant that
random items of the appropriate type placed on final level would count
as the prize. Chance of extra luckstones on mines' end is fairly high,
so potential for false completion of the achievement was also high.
The second complaint was that since the achievement was only recorded
if the special prize item was found on final level, then if a monster
took it to another level then the achievement became impossible. (Not
true, the player could take it back, drop it, and pick it up again, but
that is admittedly a pretty silly hoop to jump through.) On the other
hand, if a monster removed the item before the hero found it, then a
case could be made that the hero hadn't really fully explored the
level. However, this fix records the achievement no matter where the
hero picks up the item. The final level must be entered--otherwise no
monster could possibly acquire and transport the item--but it isn't
guaranteed to have been fully explored. Big deal....
The prize could also be acquired in bones data. Before the second
portion of this fix, that wouldn't have mattered. But now it does, so
clear the prize indicator when saving bones unless it happens to be the
same level where that item is created (impossible for sokoban, where no
bones are left; not sure offhand about mines' end). The former prize
stone or bag or amulet becomes an ordinary one of its type.
This can all be done in a much cleaner fashion once we give up on the
current save file compatability. Putting obj->o_id values into new
context.mines_prize and context.soko_prize, plus a hack to mkobj() to
not reuse those two values if the o_id counter ever wraps back to 0,
would cover most of the details. Adding an achievement tracking flag
to lev_comp's object handling for use by the special level loader
would cover most of the rest.
The recent fix to prevent #adjust from letting the player move things
into slot '-' (if compactify() reduced any sequence of consecutive
letters to x-y, introducing dash into the string of characters that
could be chosen from) was triggering a complaint about mixing &&
and || without parentheses. Fixing that was trivial, but I ended up
making a much more substantial change.
If the '#' overflow slot is in use, you can move something into it
even when you no longer have all 52 regular slots in use. (When it
isn't already in use, you can't access it. Previously you could swap
from '#' to any letter but not vice versa.) If you manage to get
gold in multiple slots or in some slot other than '$', you can move
or merge it into the '$' slot. And when that situation isn't present
(if even possible--I had to force it with a debugger to test), then
gold will no longer be listed among the inventory letters to adjust.
(That became an issue when GOLDINV came into use, but either nobody
ever noticed or at least never reported. "Adjust what? [$abd]",
then pick '$' and be told you can't adjust gold. Prior to GOLDINV,
'$' wasn't included in the list of candidates.)
Poly'd into a giant with a full inventory that already contains at
least one boulder, moving onto a boulder (that can't be pushed due
to a wall or other obstacle) yielded
You try to move the boulder, but in vain.
However, you can easily pick it up.
You are carrying too much stuff to pick up another boulder.
You see here a boulder.
The second and third statements contradict each other. Make the
code that dishes out the second message smarter. If autopickup is
set for it and you will pick up the boulder:
However, you easily pick it up.
If autopickup is not set for it but would have worked if it was:
However, you could easily pick it up.
If your inventory is full and you have a boulder (or are in Sokoban)
However, you easily push it aside.
That last one is instead of "however, you can squeeze yourself into
a small opening" that you'd get if not a giant and not carrying much.
Reading a scroll while blind is permitted if you know its label, but
message is "as you pronounce the words, the scroll vanishes" unless
you are poly'd into a form which can't make sounds, in which case you
"cogitate" rather than "pronouce". Switch to the cogitate variant if
you are suffering from strangulation.
Casting spells didn't even have the distinction; you could cast them
without regard to speech capability. Check for that. Unlike with
scrolls, now you can't cast if you can't speak (or grunt or bark or
whatever) instead of having a variant description of the action, so
this is a bigger change.
