Requested during beta-testing however long ago: want a way to
look at specific map locations while #terrain is showing them
without monsters and/or objects and/or traps being displayed in
the way. The post-3.6.0 autodescribe feature for getpos() made
this pretty easy to achieve, although the lookat() aspect felt
more like trail-and-error than careful design.
Instead of putting up a --More-- prompt, ask the player to pick
a location with the cursor. Moving the cursor gives the terse
description for every location traversed. Actually picking a
spot just ends #terrain and goes back to normal play.
Discovered while working on an enhancement to #terrain....
Various detect magic (objects, food, &c) performed while underwater
temporarily removes the hero from the water in order to have access
to the regular map. In 3.4.3, a hangup save during the detection
would leave the hero standing on top of the water. 3.6.0 added a
flag to track should-be-underwater so that during a hangup save the
hero could be put back in when going into the save file. It also
added #terrain, another situation that uses the remove-from-water
hack while manipulating the map.
The flag wasn't being cleared after use, only during save, so normal
play without a hangup left it pending until next regular save. The
result being that after restore, the hero would be considered to be
underwater again regardless of current location, and the map display
would be limited to a view of the adjacent spots as if underwater.
Then, any move--even using '.' to rest--would notice that the
'underwater' hero was not at a water location and put things back to
normal, with feedback of "you are on solid land again." So to the
player, this would seem like a pair of map display and nonsequitor
message issues, not the internal logic one it actually is.
Being polymorphed into a creature capable of eating metal objects
was treated as if the hero didn't/couldn't eat. Treat it the same
as being able to eat ordinary food instead.
Being fainted or unconscious from other than sleep both ran
metabolism at full rate, unlike being asleep which skips per-turn
consumption 9 times out of 10 (but retains periodic ring/amulet
and hunger/regeneration/conflict consumption). Switch to 'Unaware'
to handle sleep, unconsciousness other than sleep, and fainted
from lack of food as one metabolic condition. Being paralyzed
isn't included but maybe should be.
Changing how metabolism operates when fainted changes the amount
of time until starvation occurs, so I adjusted that by an arbitrary
amount. It will probably need tuning. As things stand, you'll
still faint umpteen times before starving, bringing about lots of
frustration since the player can't do much during that time.
Put in Ron Vaniwaarden's fix for crash occuring if player quits
right after choosing a character and declines to disclose anything.
Just a guess, but deleting the never-viewed inventory window might
be the cause. (3.4.3 didn't delete it.)
There's a small amount of reformatting, but cleaning that up
manually is a monumental task.
When you're swallowed, an angry god trying to zap you will kill
the engulfer and hero gets credit (experience) and blame (possible
loss of luck and/or alignment if engulfer is peaceful or tame) for
the act. But hero didn't actually kill the critter, so don't
increment the kill counter that monitors pacifism.
I think there are other circumstances where hero gets credit and/or
blame for something he or she didn't directly do, but offhand I
can't think of them. They might warrant similar treatment.
Tidying of xkilled() triggered by malformed block comment which is
actually a hybrid of an end of line comment (the boulder one, not
the 'dest' parameter one)....
The report that parse_config_line() could overflow its buffer
when passed a long value from parse_config_file() was already
fixed for 3.6.1, but longer config lines mean that later stages
of option parsing need to be aware of the possibility of lines
longer than BUFSZ. This fixes the three special options which
deal with regular expressions. Autopickup exceptions, message
types, and menu coloring all could exceed BUFSZ when formatting
a value to put in the menu for 'list' or 'remove' of existing
entries. Menu colors could overflow by an arbitrary amount,
message types by up to 13 bytes, and autopickup exceptions by
just 1 byte.
Both tty and X11 seem to cope with long menu entries (wider
than can be displayed but not exceeding BUFSZ) by truncating.
For menu colorings, that hides the color and highlight attribute
since those are placed after the regexp.
Menu line truncation for tty was straightforward, just chopped
a big chunk off the end of the long string. For X11, it did
that too, taking off a lot less but ending up with much of the
menu hidden off the left edge of the screen. Dragging it into
view showed that the width fit the whole screen (or possibly
fit the width of the map, which was also as wide as the screen).
So the initial position is being miscalculated.
Reported directly to devteam 7-Jan-2016, two issues with cursed
potion of levitation:
1) the go-up-stairs effect for cursed potion still let you choose
not to escape the dungeon if it occurred on level 1 stairs. I've
left that as-is; perhaps there's a gate across the entrance.
2) both the go-up-stairs and bonk-head-on-ceiling effects were
skipped if the hero was already levitating. I don't know whether
that was intentional but there was no comment explaining why, so
I've changed it to happen regardless of whether already levitating.
In the process, I changed the head-bonk case to do more damage when
a helmet is worn:
old: no helmet 1..10 hp, any helmet 1 hp damage;
new: no helmet 1..10 hp, soft hat 1..6 hp, hard helmet 1..3 hp.
Also, not in the report: when you aren't already levitating you
get the "you float up" message, but for cursed potion there was
never any corresponding "you float down" message because you ended
up not levitating. Now you'll levitate for 1 turn and float down
on the next, landing in a trap if one is present.
'Your <single-potion> boils and explodes.'
'One of your <stack-of-potions> boils and explodes.'
'Some of your <stack-of-potions> boil and explode.'
'All of your <stack-of-potions> boil and explode.'
The last variation had an extra space in the message prefix....
In addition to removing the excess space, this adds
'Both of your <stack-of-potions> boil and explode.'
to be used for the (All == 2) case.
The bug and fix also apply to stacks of potions 'freezing and
shattering' and to stacks of scrolls 'catching fire and burning'.
The lower two levels of Vlad's Tower were got showing the wizard-mode
special level indicator '[level_abbrev]' in #overview, nor appearing
for ^O or in the level teleport menu, indicating that Is_special()
wasn't finding them. It took a while to figure out why, but the fix
is trivial.
...to make it more interesting. Using #vanquished in wizard mode
or answering 'a' to the "disclose vanquished monsters?" prompt will
put up a menu to choose how the list of vanquished monsters should
be ordered. Right now there are 6 choices:
Traditional: by monster level, by internal index within level;
by monster toughness, by internal index within monstr[] rating;
alphabetically, first unique monsters, then others;
by monster class, low to high level within class;
by count, high to low, by internal index within tied count;
by count, low to high, by internal index within tied count.
Two other orderings are implemented but suppressed from the menu
since they seemed uninteresting (alphabetical with uniques
intermixed with other monsters, and by-class high to low within
class). The first two are very similar to each other and one of
them should probably be discarded too. The by-class order(s) have
class-name separator lines between classes.
Options parsing for end of game disclosure has extended current
+v (always show vanquished monsters)
-v (never show vanquished monsters)
yv (prompt about them, with default response 'y')
nv (prompt about them, with default response 'n')
to include
#v (always show vanquished monsters and choose the ordering)
?v (prompt about them, with default response 'a' to choose ordering)
The 'a' response was picked because it's easy to use ynaq()
instead of ynq(), but it can be considered to mean "ask about sort
order". (Neither of the two new option values could be "av"; 'a'
for disclosing attributes would become ambiguous.)
+v or answering 'y' for any of yv, nv, or ?v uses the most recent
sort ordering (if #vanquished has been used in wizard mode) or the
traditional one (normal mode, or #vanquished not used). Players
will probably want to specify a default order and then use +v
rather than choose the final order from a menu. That hasn't been
implemented here. Count high to low might be a better default than
level high to low.
While looking through Guidebook.tex to try to determine whether
the new text needed special handling, I spotted multiple mistakes
in the existing text. Probably all from earlier updates of mine;
this attempts to fix them. As usual of late, Guidebook.mn has been
tested and Guidebook.tex hasn't.
At the end of December, farlook was changed to use doname() instead
of xname() in order to give more information when looking at stuff
the player had already seen. But it ended up giving away precise
stack size for mergable objects too, even if they hadn't been seen
up close. Changing doname() to be vague when dknown wasn't set
only worked for items in particular classes; dknown is pre-set for
a lot of things. So this changes mksobj()'s dknown handling to not
do that for stackable items.
The change to objclass.h is just comment formatting (for the first
part of the file only), provoked by the second line of the one for
oc_pre_discovered.
From a bug report sent directly to devteam 16-Jan-2015 (subject:
"NH343 (NAO version) - display bug"), if the hero was blind and
levitating and searched next to 'I' (text) or '?' (tiles) which
was displayed on top of a known pool and the remembered unseen
monster was no longer there, the 'I'/'?' was removed but the spot
was redrawn as floor rather than water.
This ended up being more elaborate than I anticipated. 'Q' will
now accept the wielded weapon as a choice of item to quiver. If
that item is a stack of more than one, it will offer to split N-1
into the quiver and leave 1 wielded. If the offer is declined, or
if there is already just 1, it will require confirmation to move the
item from the weapon slot to the quiver slot. The alternate weapon
is handled similarly, with different phrasing when in twoweapon
combat mode.
Just to be crystal clear: a single object cannot be in more than
one weapon, alt-weapon, or quiver slot at the same time. 'Q's old
behavior of rejecting the wielded weapon was to avoid accidentally
becoming empty-handed, not anything to do with multiple worn/wield
slots.
'Q' will also accept a count when picking an inventory item, then
put 'count'-many into the quiver, leaving N-count in original stack.
Except when the chosen item is already in the quiver; it that case,
it undoes the stack split and leaves things as they were. (That
restriction may not have been necessary but I'm not planning to
revisit it....)
Change sort ordering of
diluted potion of bar
diluted potion of foo
potion of bar
potion of foo
potion of fruit juice
to
potion of bar
diluted potion of bar
potion of foo
diluted potion of foo
potion of fruit juice
so that potions of the same type are grouped together. Bless/curse
state (when known) takes precedence over dilution, so "blessed
diluted potion of foo" will come out before "uncursed potion foo".
I saw a lich in solid wall at one of the spots which gehennom.des
marks with a pool (so that baalz_fixup() can find the two spots that
need post-wallification fixup). I could understand the special level
loader placing a swimming or flying monster there, but don't know
whether it might do that for a lich (which doesn't need to breathe)
so am not sure whether this actually fixes what I observed.
The lich was there for far too long to have been a shapechanger, but
when I went back to the save file it was no longer there, producing
another puzzle.
Digging a grave witha a pick-axe converted the grave to floor but
did not dig a pit and unearth the grave's contents. [Caused by a
change to maketrap() intended to prevent wizard-mode wishing for
traps on top of furniture.] Digging a second time succeeded in
creating a pit since the location was no longer furniture.
When items were sorted alphabetically, holy water ended up in the H's
and unholy water in the U's. Force them to get placed with water in
the W's, as would happen if water wasn't given an alternate name when
blessed or cursed.
The code to apply an automatic annotation to the knox level was looking
for a drawbridge like on the castle level, but knox doesn't have any
drawbridge. Look for its door instead. (It's initially a secret door,
so won't be revealed via magic mapping. It needs to be found or
destroyed to get mapped as a door or empty doorway in order to trigger
the annotation.)
Also, give a tiny bit of variation to the knox level layout. It used
to have both the throne and the secret door on the lower of two similar
rows and the door into the treasure vault on the upper one. Now each
of the three can be on either of those two rows (independently of each
other), making eight possibilities. This doesn't accomplish much,
other than to make the secret door locations not always be at the same
fixed spot.
Silly shapechange message if <mon> is sensed via telepathy and takes
on a mindless form. In the case I noticed, it was a doppelganger on
the far side of a maze wall who changed from something ordinary into
a mummy while the hero was wearing an amulet of esp.
3.6.0 could deliver this message, but I think changes since then have
increased the chance for newcham() to give shapechange feedback.
... when exploding chest trap destroys uchain without using
unpunish() to un-wear it first. The '!carried(uball)' clause
should be applied to the uball->ox,oy test only, not to both
uchain->ox,oy and uball->ox,oy.
For menustyle:Traditional, the object class prompt for 'D' includes
an entry choice of 'm' to request a menu. Supplying real classes
and 'm' resulted in a menu limited to those classes, as intended,
but any of BUCX for curse/bless state and 'm' without any actual
classes resulted in a menu of entire invent. A one-line fix once
the proper place for that fix was located.
For menustyle:Traditional or menustyle:Combination, 'A' includes an
extra choice of 'i' to examine relevant inventory prior to choosing
object classes (and object identification also offers that), but
the inventory display showed everything rather than just the items
applicable to 'A' (or to object ID). Figuring out where to apply
the fix was trivial, but the fix itself was a bit more involved and
it exposed a latent bug in display_pickinv(): "" was supposed to be
the same as NULL when passed in as list of target inventory letters,
but it wasn't being handled correctly.
A patch in late January to suppress suits as likely candidates for
the 'R' command when wearing a cloak also unintentionally suppressed
rings when wearing non-cursed (or not yet known to be cursed) gloves.
Cloak always blocks suit removal; gloves only block ring removal if
cursed.
Extend #stats beyond just monsters and objects. Have it display
memory usage for traps, engravings, light sources, timers, pending
shop wall/floor repair, regions, bones tracking, named object types,
and dungeon overview.
No doubt there are other memory consumers that I've overlooked.
The "sortloot revamp" patch six or seven weeks ago broke filtering
for '?' menu in display_pickinv() called by getobj(). The old code
handled 'lets' when building an array of object pointers to be
sorted. The revamp code did away with that to sort the linked list
instead, but neglected to put 'lets' handling into the subsequent
menu creation loop which is now operating on full invent rather
than the filtered subset.
Hitting a rust monster with a greased weapon would rust the weapon
instead of removing the grease. Likewise for monsters with passive
acid or corrosion damage. passive_obj() was ignoring grease.
Fast and Very_fast share the same property index, but from_what()
didn't handle that. Enlightenment for a Very_fast hero--which
can only happen via worn equipment (speed boots) or timed effect
(potion of speed or spell of haste self)--would be erroneously
described as "very fast innately" for roles who get intrinsic
speed at level 1, or "very fast because of experience" when high
enough level for roles who get intrinsic speed later.
This set is the same as the default ascii symbols except that corner
walls are represented with '+' instead of '-' or '|' so that wall
joins are clearer. The baalz level looks a little better this way,
although not a lot. Unfortunately, most levels look a bit cluttered
with this, so I imagine it won't get a lot of use. At least it
serves as an example of being able to use "'c'" instead of "\123".
Originally I specified every terrain symbol explicitly, which was
how I noticed that S_darkroom and S_vibrating_square weren't being
handled. This has cut it down to just the wall symbols, serving as
explicit example of accepting default symbols for unspecified ones.
Add support for character enclosed within single quotes. Single
character without quotes would work for most characters, but not
'#' and possibly not '^' or '\\'. All the values in dat/symbols
are specified via backslash+digits so it isn't obvious that some
other form of value is allowed.
I think this parsing accepts all valid values. It doesn't reject
all invalid ones: opening quote followed by valid escape sequence
followed by junk followed by closing quote will ignore the junk.
I don't think there's any pressing need to worry about that.
Symbol set parsing rejected S_darkroom and S_vibrating_square.
Now it will accept them.
The fact that this bug wasn't noticed indicates that none of the
3.6.0 symbol sets (other than "Default symbols") is specifying a
value for either of these symbols.
This also changes the default vibrating square value from yellow
'^' (caret) to purple '~' (tilde). I don't think there's any risk
of mistaking it for a long worm tail (brown '~') and it emphasizes
that it isn't really a trap.
Quite a bit of special case code for something so inconsequential.
Tweak the baalz level layout a little to make it be a bit more
interesting, and perform custom wallification on it so that the
beetle layout becomes clearly visible. It looks great with
DECgraphics (and presumably IBMgraphics). It's recognizeable but
not as interesting with ordinary ascii because corner walls use
'-' or '|' so don't join up nicely. It looks a little weird
with tiles; the square aspect ratio of individual tiles makes it
end up being very elongated compared to character cell map it was
designed for.
As far as the level layout goes, the pair of secret doors into
Baalzebub's chamber have been give a random alternative. The two
right-most accessible columns were diggable--I don't know whether
that was intentional; it's been reduced to one right-most column.
The middle pair of legs were asymmetrical; this fixes that. The
beetle also now has eyes and an entry door in its mouth.
[Subject should mention Unix, but would exceed 50 characters.]
Explicit build rules ignore $(CPPFLAGS), but the implicit C rule
(at least in GNU make) specifies it. If user has a value for this
in the environment, that value would apply to building some source
files but not others. This patch gives it an explicit empty value,
so building via implicit rule should expand it to nothing and match
the fact that it's omitted from explicit rules.
There was one C++ file which relied on the implicit C++ rule. I've
added it to the files processed by 'make depend' and re-run that.
It now will get built via an explicit rule.
Also, a small amount of reformatting for HACKCSRC.
The meta keystroke commands which use an uppercase letter were all
missing from dat/hh:
M-A annotate level
M-C show conduct
M-N name something (synonym for M-n, which is a synonyn for 'C'all)
M-O display dungeon overview
M-R ride/unride steed
M-T tip a container
(All meta keystroke command shortcuts are missing from dat/help.)
Noticed when testing tty menucolor changes recently, using the 'O'
command to interactively add a new entry would accept one and then
quit, unlike remove which accepts multiple at a time and then goes
back to the menu where you could choose 'remove' all over again.
Adding is still done one entry at a time, but instead of finishing,
it goes back to the menu where you can choose to add another.
After some permutation of commands which displayed items, the 'd'
command presented a prompt with the list of letters scrambled (in
loot order or pack order rather than invlet order), so explicitly
sort when getobj operates. Done for ggetobj too.
For menustyle:Traditional, ',' followed by 'm' presented a pickup
list in pile order even when sortloot was 'l' or 'f'. That was an
unintentional change during the 'revamp'.
There was a report during beta testing that menu lines which were
displayed in color showed the whole line in color, unless/until an
item was selected or unselected, in which case the '-', '+', or '#'
was rendered in monochrome. The suggestion then was to redraw the
selection character in color, but I went the other way. Menu
entries will render the selector letter and selection indicator in
monochrome all the time, and only the text of the menu entry will
honor menucolors.
Reported directly to devteam for recent git code, the "sortloot
revamp" patch could trigger an object lost panic after calling
query_objlist() when menustyle was full or partial and player
picked up a subset of available items. Modified head-of-list was
not being propagated to its source in pickup(). Use an extra layer
of indirection.
Reported directly to devteam (for 3.4.3 but still present in 3.6.0):
an unseen landmine explosion which caused scatter() to break a
boulder or statue would give feedback as if the hero could see the
boulder or statue being destroyed.
Also, a couple of landmine explosion messages didn't take deafness
into account.
Most of the humanoid species have Lords and several have Kings,
but none of them have Ladies or Queens. When a female grows up
to reach that level of monster, she changes into male. This fix
gives an alternate message acknowledging that change rather than
prevent taking on the stronger form. A better fix would be to
add ogre ladies and dwarf queens as separate monsters, but doing
so will break 3.6.0 save file compatibility.
(I started out with an alternate fix, adding mons[].fname for the
dozen or so creatures which warrant an alternate name for females.
But that requires statues, figurines, corpses, tins, and maybe
even eggs to track gender [some statues already do, and corpses
and statues with attached mtraits also implicitly do] and to not
stack with equivalent ones of the opposite gender. Plus glyphs
to track them, and new tiles. It was becoming too complicated
for such a relatively unimportant feature. Separate monsters is
the way to go, deferred until save file format changes again.)
Blindness due to face covered by pie was ignored for several cases
of magically curing blindness--cleaning the face seems better than
adjusting timeout to account for u.ucreamed for those cases. A few
instances of taking stun or confusion damage overrode existing stun
or confusion rather than increasing it. Plus a copy/paste mistake
for dual stun+confusion when casting an expired spell.
There was also a suggestion that vomiting when already nauseated
should decrement the timer instead of increasing it. But there is a
negative effect for as long as it's in effect, so I left that as is.
Accept "male" or "female" when specifying monster type for ^G.
Groundwork for testing and hopefully eventually fixing "female
gnome" grows up into "gnome lord" and becomes male.
Polyself with gender change into a creature with fixed gender
would deliver a message containing "a <creature>" regardless of
whether "an" was warranted.
(Into any creature which supports both genders it yielded
"a male <creature>" or "a female <creature>" so "an" was never
needed. And when no gender change was involved, it used an()
so got "a <creature>" or "an <creature>" as applicable.)
There have been two or three reports on getting feedback about
amulets rusting. Object formatting doesn't display erosion for
them, so being told about damage then not seeing that damage
feels like a bug. Even if damage was displayed, it has no effect
on them so would still feel somewhat strange. It does display
erosion for wands and rings, which is strange too.
This limits erosion damage--and its feedback--to items which are
actually impacted by erosion: armor, weapons and weapon-tools;
also heavy iron balls and iron chains since they've traditionally
shown rust even though it has little effect.
A side-effect of this change is that flammable items (other than
armor and weapons) which don't burn up immediately will no longer
become burnt, then very burnt, thorougly burnt, and finally be
destroyed. Since the player couldn't see or possibly repair the
erosion state, it seemed incomplete. It could be reinstated by
making other flammable items be subject to erosion and displayed
as such by xname() & co.
Wishing now avoids applying erosion and erosion-proofing to items
that aren't affected by it, regardless of material. It also now
allows wishing for "rusty rustproof <iron-object>" which used to
suppress "rusty" in that combination and triggered a couple of
old bug reports.
Heavy iron balls and iron chains can have rust repaired and can
be made rustproof by wielding, then reading enchant weapon while
confused, as if they were weapons.
Pt 1 was about the wrong message delivered when a high priest
rejects being given a name by the player, and was fixed weeks ago.
Pt 2 is about zaps on the Elemental Plane of Air which reach the
edge of the map not having their temporary display effect removed
after "the <zap> vanishes in the aether". There was a 'goto' in
use which bypassed the tmp_at(DISP_END) call. I guess Dijkstra
earns an "I told you so" here.
"Looting many containers via menu cannot be stopped". When the
player uses #loot command at a location with multiple containers,
a menu of which ones to loot is presented and player can pick any
or all of them. But if you terminate the looting of a particular
container with ESC, it goes on to the next selected one rather than
stopping the loot action because that's what the 'q' choice does.
The simplest fix would be to allow choosing only one container
from the "loot which?" menu, but this retains the ability to loot
multiple containers on a pile in one turn. It makes looting
stoppable by extending the ":iobrsq or ?" prompt, adding 'n' for
"next container" and changing 'q' from "done with this container"
to "done looting" (with ESC still a synonym for 'q'). When just
one container is being looted, or when on the last of N containers,
'n' is not shown but is still accepted (and treated as 'q').
Also, use_container() was using a menu for ":iobrsq" if player had
menustyle set to Full when it was intended to be for Partial (name
confusion...). This switches Partial to use menu for loot action,
and leaves Full with that since that's how 3.6.0 has been behaving.
Traditional and Combination use the prompt string and single char
response.
There was no check for being capable of using items when an attempt
to cure being turned into green slime picked scroll, wand, or horn
of fire.
Also, implement a 'TODO' in the same section of code. Monsters
can enter fire traps to cure themselves from slime. I made that
be for monsters smart enough to use items too, even though there's
no actual item involved.
