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.
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).
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.
'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....
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.
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).
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.)
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.
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.
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.)
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'.
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.)
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.
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.
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.
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.
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.
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).
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.
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.)
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.)
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.
