PatR [Sun, 25 Feb 2018 03:35:56 +0000 (19:35 -0800)]
fix #H6861 - whatis behaves weirdly with plurals
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.
PatR [Fri, 23 Feb 2018 21:07:49 +0000 (13:07 -0800)]
switch docall() to safe_qbuf()
Simplify docall() for object types. Adds some different complexity to
a new routine so the overall simplification is rather minimal, but we
already have a routine to construct prompt buffers involving formatted
object names without allowing overflow, so use it.
tty getlin() limits the input to COLNO characters, so 80 by default.
To get potential QBUFSZ overflow, I had to increase COLNO in global.h
and rebuild from scratch. A value greater than 127 triggers a lot of
warnings. I didn't try 127. 126 gets one warning, involving use of
FARAWAY (defined as COLNO+2) in dogmove.c.
We should change things to limit object names to much less than 80,
but this doesn't attempt to implement that.
PatR [Fri, 23 Feb 2018 15:25:37 +0000 (07:25 -0800)]
fix "wonky secret door" in Cav quest
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....
PatR [Thu, 22 Feb 2018 06:44:15 +0000 (22:44 -0800)]
fix #6870 - clairvoyance feedback
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.
PatR [Wed, 21 Feb 2018 03:32:47 +0000 (19:32 -0800)]
pline() -> raw_print() -> dumplog()
Reorder some code in pline() so that early pline messages which use
raw_print() instead of putstr(WIN_MESSAGE) are included in the DUMPLOG
message buffer. If the game ends soon enough they'll be shown in the
final log; otherwise they'll get pushed out of the buffer once enough
later messages are delivered.
Alex Smith [Tue, 20 Feb 2018 21:53:27 +0000 (21:53 +0000)]
Wake up monsters, and let them stop eating, before angering them
If we do it the other way round, then mimics will forget what
they're mimicking without a seemimic() call, meaning that the
line-of-sight calculations can get confused if the mimic was
mimicking something opaque.
PatR [Mon, 19 Feb 2018 19:59:14 +0000 (11:59 -0800)]
fix #H6867 - mail buffer overrun
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.
PatR [Sun, 18 Feb 2018 02:54:52 +0000 (18:54 -0800)]
static analyzer bit
I can't find the original message at the moment, but one of the things
that an analyzer complained about was the *s='\0' possibly assigning
to a Null pointer. The superfluous test of 's' in the while condition
has fooled it into thinking that's possible when it's not.
if (s) {
while (s && ...) {
*s++ = ...
}
*s = '\0';
}
keni [Fri, 16 Feb 2018 17:07:37 +0000 (12:07 -0500)]
infrastructure fixes:
- fix bug in git hooks that loses file permissions when doing variable expansion
- fix execute permissions on sys/unix/hints/macosx.sh
- explicitly call out perl as required for hooks in Developer.txt
PatR [Thu, 15 Feb 2018 18:13:42 +0000 (10:13 -0800)]
place_lregion() bug
Noticed while looking into the TROUBLE_STUCK_IN_WALL prayer bug,
place_lregion() has been using the wrong row for 'low y' in its
whole-level handling, presumeably ever since it was first introduced.
3.4.3 definitely had the same bug; I didn't check any further back.
For maze levels which only consider every other row and every other
column to be viable locations this probably didn't matter. And even
non-maze levels usually don't have anything on row 0, so this fix
isn't likely to be noticeable.
PatR [Thu, 15 Feb 2018 02:38:35 +0000 (18:38 -0800)]
fix #H4240 - linking on VAX/VMS
First reported two years ago, then again this week by someone else
who didn't go through the web contact page (so no new #H number or
bugzilla entry). Using vmsbuild.com to build on VAX complains about
not being able to resolve a bunch of functions--it's basically
trying to build the full program using only the code supplied by
sys/vms/vmsmain.c. The original report mentioned a workaround and
was also dealing with a second issue (already fixed post-3.6.0) that
I incorrectly guessed was responsible for the linking problem. This
report had the correct linker magic to fix the linking issue.
I'm still not sure whether the order of /Library and /Include after
the name of an object library file on a LINK command line matters.
In a linker options file, which vmsbuild.com constructs and uses,
/Include needs to come first so that the contents of the library are
searched after the explicitly included object modules are processed.
Building with the Makefiles (using DEC's MMS or some versions of
freeware MMK) doesn't collect the object files into a library so was
never affected by this. And the linker options ordering issue is
apparently specific to the VAX/VMS linker; vmsbuild.com run on Alpha
and on IA64 linked 3.6.0 successfully without this fix.
PatR [Thu, 8 Feb 2018 01:31:44 +0000 (17:31 -0800)]
'Iu' vs unknown container contents
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.
PatR [Tue, 6 Feb 2018 00:36:35 +0000 (16:36 -0800)]
fix #H4459 - shopkeeper/scare monster bug
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.
PatR [Sun, 28 Jan 2018 08:38:08 +0000 (00:38 -0800)]
fix #6691 and a couple other twoweap issues
Report was for dual-wielding hitting an enchanter and assumed that
a resistant artifact as primary weapon was protecting vulnerable
secondary weapon. Actual reason was simpler.
When in normal form, dual-wielding attacks against creatures which
cause erosion to the weapon which hits them would only inflict the
passive erosion damage to the primary weapon, even if it missed and
secondary hit. Make primary attack always trigger passive counter-
attack--before second swing now, rather than after--even if it misses,
and secondary attack trigger another one if that hits. Both weapons
are now subject to passive erosion (but only when they actually hit);
when secondary weapon hits, hero gets a double dose of counter-attack.
Hero poly'd into a monster with multiple weapon attacks (various
leaders: dwarf lord, orc-captain, and so forth) would try to emulate
dual wielding and first hit with uwep then with uswapwep. But it
would do that even if uswapwep was a bow or stack of darts that the
player had no itention of using for hand-to-hand. Stick with repeat
hits by uwep when uswapwep seems inappropriate.
Splitting a pudding while dual-wielding would only do so when hit by
uwep of appropriate material, never when hit by uswapwep. So silver
saber and longsword could split if longsword was primary but never
split if saber was primary. Check material and splitting separately
for each hit. It's now possible to split twice with one dual-weapon
attack if both weapons hit and both are made of the right material
(iron or 'metal'; among relevant objects the latter is only used for
tsurugi and scapel).
PatR [Tue, 23 Jan 2018 08:52:57 +0000 (00:52 -0800)]
fix 'makedefs -z' for config using FILE_PREFIX
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.
PatR [Mon, 22 Jan 2018 00:30:58 +0000 (16:30 -0800)]
fix object pickup
Mentioned in the newsgroup: picked up items have stopped merging with
compatible stacks in inventory.
The commit 0c5155584975731f2c37ace88acd046a54ae5aa6 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.
PatR [Sat, 13 Jan 2018 00:13:14 +0000 (16:13 -0800)]
T-shirt punctuation
'It reads: "foo bar quux"' is a sentence so should have a terminating
period. Technically that ought to be placed inside the quotes, but
putting it after distinguishes slogans which have their own punctuation
from ones which don't.
A couple of entries contain multiple sentences. Some used two-space
separation between those sentences, some only one; make all use two.
Add a few new T-shirt messages, including a couple with pop culture
references which are only 10 years old instead of 20 or more....
Alex Smith [Sat, 6 Jan 2018 00:31:11 +0000 (00:31 +0000)]
Fix an exploit involving bags and potions of water
Discovered while writing the previous commit. If you dipped a sack
full of potions into an uncursed potion of water, the potions would
dilute but you wouldn't lose the original potion, letting you repeat
until all were diluted.
Allowing people to do this trick to blank multiple potions from one
potion of water seems like it's not an abuse, given that it can be
done in a more tedious way with water walking or the like and it
costs resources, but it's definitely abusive to make it possible
entirely for free.
Alex Smith [Sat, 6 Jan 2018 00:12:49 +0000 (00:12 +0000)]
Give feedback when oilskin sacks get wet
We can identify them by elimination in this case (they're the only
bag-like container that doesn't produce a message, the others all
do), so it's probably best to be more explicit as to what's going
on (for user interfaces and TDTTOE purposes).
PatR [Fri, 5 Jan 2018 09:23:56 +0000 (01:23 -0800)]
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.
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.
PatR [Tue, 2 Jan 2018 01:14:37 +0000 (17:14 -0800)]
fix #H6707 - double "gush of water hits" messages
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.)
PatR [Mon, 1 Jan 2018 01:19:38 +0000 (17:19 -0800)]
special level mimics
The special level loader would allow the level description to specify
an alternate monster appearance for any type of monster, and if one
was specified for a mimic then that mimic would be polymorphed into
the appearance instead of masquerading as it. This changes it to
only use an appearance for mimics, the Wizard, vampires, and general
shapeshifters (chameleons, doppelgangers, sandestins). The mimic
case doesn't work as expected: map display shows the symbol for the
specified shape but farlook describes it as a mimic. The Wizard case
hasn't been tested. The chameleon and vampshifter cases seem to work.
It also allowed shapechangers (including vampires) to be given an
object or furniture appearance. I didn't try things out to find out
what what their behavior would be if/when that happened.
I'm not sure whether the farlook issue for mimics-as-monsters is with
the pager code or the monster name formatting code. (Possibly the
mimic just needs to be flagged has 'hidden' as well has having an
alternate appearance.) I'm not going to worry about it since none of
our special levels attempt to give mimics a monster shape. Mimicking
a monster is a feature for clones of the Wizard, not for mimics,
although it might be nice if the latter worked correctly someday.
PatR [Sun, 31 Dec 2017 11:38:29 +0000 (03:38 -0800)]
fix #H6704 - appearance of mimic's replacement
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".
PatR [Sat, 30 Dec 2017 00:20:05 +0000 (16:20 -0800)]
uncursing prayer vs helm of opposite alignment
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.)
PatR [Thu, 28 Dec 2017 23:40:11 +0000 (15:40 -0800)]
playing music while impaired
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.
PatR [Sun, 24 Dec 2017 22:00:49 +0000 (14:00 -0800)]
fix #H6624 - missile miss message redundancy
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."
PatR [Sat, 23 Dec 2017 23:42:20 +0000 (15:42 -0800)]
fix #H6648 - can't wear via 'W' but can via 'P'
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.
PatR [Sat, 23 Dec 2017 23:19:27 +0000 (15:19 -0800)]
flags.sortloot
This should maximize save file compatibility between 3.6.1 and 3.6.0,
at the risk of breaking save files for folks using post-3.6.0 git
sources. (It's unlikely that many in that situation are using a
configuration which will be affected, so probably nobody will notice.)
PatR [Thu, 21 Dec 2017 18:04:18 +0000 (10:04 -0800)]
fix #H6628 - secret doors display as wrong wall
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 '"'.
PatR [Fri, 15 Dec 2017 00:39:21 +0000 (16:39 -0800)]
rehumanizing while Unchanging
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.)
PatR [Fri, 15 Dec 2017 00:22:36 +0000 (16:22 -0800)]
fix #H6610 - completely burnt paper golem
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'.
PatR [Wed, 13 Dec 2017 01:53:54 +0000 (17:53 -0800)]
self-genocide's "you feel dead inside"
It seems to me that the reaction to "you feel dead inside" when you're
polymorphed into an undead creature at the time would be "so what else
is new?". Vary the "dead" when current form is something which gets
reported as "destroyed" rather than "killed" when killed. That happens
for things flagged as non-living. Now undead "feel condemned inside"
and golems "feel empty inside". Neither of those are ideal but they're
more interesting than "feel dead inside".
After becoming dead inside, give a reminder about that during
enlightenment and if you restore a saved game in that condition. It
was the latter that set this in motion: I wanted to confirm that
restoring with u.uhp == -1 didn't give "you aren't healthy enough to
survive restoration" when polymorphed. (It doesn't; the game resumes
and you'll die if/when you rehumanize.)
Alex Smith [Sat, 9 Dec 2017 14:12:40 +0000 (14:12 +0000)]
Add an instance flag for being inside parse()
Some windowports that are currently being written by third parties
need more information about the engine than they currently have.
Two specific reported problems: a) needing to know whether a
putstr() call relates to a count (so that it can be placed in a
different part of the user interface from the message area); b)
needing to know whether a request for a character relates to
command input (some hangup handling routines need this so that
they can determine what behaviour is potentially exploitable).
Knowing whether or not you're inside parse() fixes both of them.
This would be cleaner to do by changing the windowport API, but
that'd break existing windowports, which isn't really ideal.
Setting a globalish variable that the windowport can inspect, but
can ignore if it prefers, means that existing windowports will
continue to work fine, but new windowports will have more
information and thus more flexibility in how they handle command
entry.
PatR [Sat, 9 Dec 2017 08:36:19 +0000 (00:36 -0800)]
fix #H6597 - genocide exploit
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.
PatR [Sat, 9 Dec 2017 07:06:25 +0000 (23:06 -0800)]
fix #H5590 - pets not shown on dumplog map
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.
PatR [Fri, 8 Dec 2017 22:12:35 +0000 (14:12 -0800)]
fix #6598 - monster briefly rendered as hero
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.
Alex Smith [Wed, 6 Dec 2017 18:49:08 +0000 (18:49 +0000)]
TDTTOE: Discourage generating elf corpses on sleeping gas traps
These are elven /adventurers/, so they get sleep resistance at
experience level 4 (not immediately), and so there's an outside
chance they'll be killed by a sleeping gas trap. This commit
reduces the probability, though.
PatR [Tue, 5 Dec 2017 11:38:23 +0000 (03:38 -0800)]
more #adjust (#H6571)
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.
PatR [Fri, 1 Dec 2017 03:15:45 +0000 (19:15 -0800)]
address #H6552 - #adjust 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.
PatR [Sun, 26 Nov 2017 01:01:06 +0000 (17:01 -0800)]
more explosion vs u.ustuck
Fix a FIXME (poly'd hero hit by explosion while holding a monster
which is also hit by that explosion takes double damage even if the
held monster got killed) and an incorrect comment.
Add a FIXME about grabbers (monster or hero) who are outside the
explosion radius but holding someone who is inside.
Alex Smith [Fri, 24 Nov 2017 00:42:42 +0000 (00:42 +0000)]
Some traps on early depths were triggered already
The hero isn't the only adventurer seeking the Amulet. It's clear
from various other events in the game that others have been there
beforehand. As such, we can expect many of the traps on the first
few levels to already have been triggered repeatedly by questing
adventurers.
This commit allows for the creation of adventurer corpses in
early-game traps, together with a small amount of cursed junk
(i.e. a miniature bones pile) and any items created by the trap
itself. On dungeon level 1, this is guaranteed for the vast
majority of harmful traps, in order to avoid near-unavoidable
deaths in the very early game due to not having enough max HP to
survive a trap hit.
Wizard mode testing shows that this case doesn't trigger very
often; maybe once a game on average. (Traps are rare on filler
levels, at least early on, and many types of trap would leave no
evidence, e.g. a teleportation trap won't kill people on its own
square.) As a result, the balance impact from the actual items
here is likely to be minimal (it may help out ranged combat roles
slightly but they could do with the boost). The main change,
therefore, is to reduce the number of unfair very early deaths
(replacing them with fairer "you shouldn't have investigated
what created that corpse!" deaths).
PatR [Fri, 24 Nov 2017 00:37:20 +0000 (16:37 -0800)]
fix #H6489 - explosion double damage to ustuck
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.
Alex Smith [Sun, 19 Nov 2017 16:16:00 +0000 (16:16 +0000)]
Balance fix to level drain and potions of restore ability
Right now, the punishment for being hit more than twice by a level
drainer pre-Quest is disproportionate; grinding back up to level
14 from level 13 takes a long time, and yet isn't particularly
difficult, just slow, and a potion of full healing will only
regain one of the lost levels (as only half the lost levels can
be regained this way).
Meanwhile, potions of restore ability are currently automatically
blanked by almost all spoiled players; they don't do anything that
doesn't have more convenient sources (unicorn horn or the spell),
so they're only useful in the very early game for getting poison
resistance.
This commit aims to fix both problems, by allowing potions of
restore ability to restore lost experience levels, in addition to
lost attribute points; an uncursed potion restores one lost level
(with multiple potions making it possible to hit the cap), a
blessed potion restores all of them. That gives players an
incentive to keep them around rather than blanking them. (Notably,
the spell and tool were not changed the same way; for restoring
levels, you need to use the potion.)
PatR [Sat, 18 Nov 2017 07:38:28 +0000 (23:38 -0800)]
impossible fixup
For USE_OLDARGS, the varargs calls in pline.c actually need to pass a
fixed number of arguments (padded with dummies for unused ones) when
using a compiler which checks argument usage for consistency.
pline.c used to be the only core source file which needs VA_PASSx()
handling, but it looks like calls to config_error_add() in files.c now
need it too. (If there were any calls to panic() in end.c, they would
need it as well, but there aren't.)
PatR [Sat, 18 Nov 2017 00:05:35 +0000 (16:05 -0800)]
options processing: ascii_map vs tiled_map
Toggling either ascii_map or tiled_map with the X11 interface switches
the map window from one style to another, but it was only working as
intended when done via the 'O' command. Setting ascii_map via initial
options only worked if tiled_map was explicitly cleared. This fixes
that.
Alex Smith [Thu, 16 Nov 2017 16:42:16 +0000 (16:42 +0000)]
Less misleading message when impossible() is called
Telling people to #quit due to something going wrong internally is
probably a bad idea; the game might or might not be corrupted, but
even if it is, most players will want to play on rather than lose
their game entirely.
Instead, advise saving and reloading; this will fix the underlying
cause of many impossible()s (which are normally related to
inconsistent internal structures; the save file format has much
less redundancy, therefore less chance of inconsistency, than the
in-memory format).
PatR [Tue, 14 Nov 2017 23:31:26 +0000 (15:31 -0800)]
vomiting while fainting
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....
Pasi Kallinen [Tue, 14 Nov 2017 13:57:18 +0000 (15:57 +0200)]
TTY: Treat carriage return as newline
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.
Alex Smith [Mon, 6 Nov 2017 01:28:48 +0000 (01:28 +0000)]
Intentionally spoil foodpois mechanics when it happens
One of the huge strengths of NetHack is that there's a lot of
mechanical content in it; you can continue learning about the game
more or less continuously, and when you die, it's usually possible
to figure out what you did wrong and avoid that for future games.
There are two parts to this: a) a death should only happen if the
player didn't play perfectly, b) the nature of the problem should
be clear.
FoodPois status meets a) just fine, but not b); food poisoning
mechanics tend (based on my research) to actively give the wrong
impression to new players. (Normally, something along the lines of
"corpses are sometimes randomly dangerous", which is insidious in
the sense that it'll cause players to leave them as a last resort
and thus never discover what they're doing wrong.) The easiest way
to fix this is to explain what the rule is explicitly.
Additionally, this should hopefully go some way towards changing
the incorrect perception many people who haven't played (any/much)
NetHack have that the game is arbitrarily cruel... It's important
to get the "everything happens for a reason" attitude across from
an early stage, by tying it to an event like this that's commonly
seen by new plyers.
Experienced players should not be affected much if at all by this
change, because they hardly ever get food poisoning anyway.
(Note: there are actually two main mechanics related to food
poisoning, one widely applicable, one much more subtle. The message
here is focused mainly on the common case, but doesn't actually
contradict the rare case, and attentive players may be able to
deduce both mechanics from the one message. Most likely, players
will hit the common case, see the message, learn the common case,
and some time later hit the rare case, get the message again, and
read it more carefully this time.)
PatR [Sat, 4 Nov 2017 23:04:46 +0000 (16:04 -0700)]
fix #H6391 - artifact #invoke for charging
Latent bug: if a non-role-specific artifact which could be invoked
for charging existed, it would never work as if blessed because the
test for no-role was wrong. Caused when 3.3.0 changed the Role_if()
predicate and artilist[] array to use monster index numbers (PM_foo)
instead of role letters; the non-role value changed from '\0' to
NON_PM (-1) but the test for non-role didn't.
No fixes36.1 entry; there aren't any artifacts which were affected.
Alex Smith [Wed, 1 Nov 2017 15:22:28 +0000 (15:22 +0000)]
Don't use a plain %s when writing to a buffer
My compiler was understandably concerned about a potential buffer
overflow here. I don't think the string could get long enough to
cause that to happen, but it's hard to be certain. It's much safer
to limit the length of the string so that it fits in the buffer, as
done here, and if there really wasn't a problem the change will
cause no harm at all. (If there was, the string will be truncated
rather than corrupting memory. This code is in showing the
config-file version of a status highlight, something where
truncated text will probably be obvious to the user.)
Alex Smith [Wed, 1 Nov 2017 14:55:40 +0000 (14:55 +0000)]
It's OK for pets to oscillate near the player
This change was coded by FIQ, who suggested it by email.
The main change here is related to monster anti-oscillation code.
When a monster believes it's stuck in an AI loop, it looks for an
alternative strategy. That applies to pets too. However, if the
pet is currently near the player, we can typically assume that it's
there because it wants to be there, and an oscillation is not
because it's stuck but because it's already in the best possible
place. This commit causes pets to be "allowed" to stay near the
player, rather than running the wrong way down a corridor because
it's the only way to do something different than what they're
currently doing.
If the pet is far from the player, we use the old behaviour unless
the pet is leashed or the player tried to call it with a whistle
or the like, in order to avoid the risk of a genuine AI loop trying
to get back to the player. (Whistling happens rarely enough that it
won't cause AI loops of its own - the player isn't going to whistle
every turn - and it makes flavour sense that a pet might interpret
it as "you're going in the wrong direction!".)
Pasi Kallinen [Tue, 31 Oct 2017 19:18:21 +0000 (21:18 +0200)]
X11: Fix renaming at player selection
Due to the new player selection dialog I did, it was possible
to rename your character - but this didn't rename the lock files
and tried to load a save from the wrong name.
This is a bit of a hack, but seems to work and didn't seem to
cause problems for the tty.
PatR [Sat, 28 Oct 2017 21:12:50 +0000 (14:12 -0700)]
fix #6284 - empty perm_invent
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.)
PatR [Sat, 28 Oct 2017 08:18:25 +0000 (01:18 -0700)]
fix #H6338 - naming mimicked potion
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.
projects / nethack / log