Clean up quite a bit of minor things found with simple grep patterns:
operator at end of continued line instead of beginning of continuation
(and a few comments which produced false matches, so that they won't
do so next time), trailing spaces (only one or two of those), tabs (a
dozen or so of those), several casts which didn't have a space between
the type and the expression (I wasn't systematic about finding these).
I think the only code change was in the function for the help command.
and over the hero. 3.6.0's clairvoyance tried to show things in
a non-standard sequence, which was intentional but had unintended
side-effects like the disappearing monsters complained about in the
report. To make it work as intended would have required --More--
whenever it kicked in, which is much too intrusive when it happens
every N turns rather than when explicitly casting the spell.
Redo it substantially, and give preference to monsters over objects,
objects over traps, and traps over underlying terrain like normal
vision-based display does. It now detects all monsters within its
bounding box but shows ones which aren't directly in view as
"unseen monster" unless via spell cast at skilled or expert, or at
basic when also having intrinsic clairvoyance.
Remove trailing spaces, and remove tabs from the files that had
trailing spaces.
Also, rndorcname() was using a random value to terminate a loop
and was recalculating a new one each iteration.
Eliminate a few warnings: array name used as boolean is always true,
parameter 'flags' shadows (blocks access to) global struct 'flags',
initializer discards 'const' (assigning string literal to 'char *').
Plus a couple of simplifications.
Changes to be committed:
modified: include/decl.h
modified: include/dungeon.h
modified: include/extern.h
modified: include/hack.h
modified: src/decl.c
modified: src/do_name.c
modified: src/dog.c
modified: src/dokick.c
modified: src/makemon.c
modified: src/mkmaze.c
modified: src/mkobj.c
modified: src/pager.c
This commit is an attempt to address the complaints about
the orc town variation taking away lots of stuff that is
normally available in mine town. The statement in the level
description says "A tragic accident has occurred in Frontier
Town...It has been overrun by orcs."
The changes in this commit attempt to uphold that premise,
while making things a bit more interesting and perhaps
more palatable for the player.
This update does the following in keeping with the mythos:
- While many of the orcs still remain to wander about the
level, many of the orcs took off deeper into the mines with
some of the stuff that they plundered. You may now be
able to hunt some of it down.
- Adds some appearance of this particular horde of marauding
orcs working as part of a larger collective.
- This evolves the Orc Town mine town variation into a
a feature over multiple levels of The Gnomish Mines,
rather than just the single-level "feature" that it was
previously.
- You may have to work longer and a bit harder for some
things than other mine town variations, but at least with
these changes, there is hope that some of it may be found
elsewhere.
Game mechanics notes (maybe spoily?)
- Add mechanism to place objects into limbo (okay, really
place them onto the migrating_objs list for transferring
between levels etc.) and destine them
to become part of the monster inventory of a particular
species. In this particular usage case, it's using the
M2_ORC flag setting to identify the recipients.
- At present, there is no mechanism in the level compiler
for placing objects onto the migrating objects, nor
with more sophisticated landing logic, so a somewhat
kludgy hard-coded fixup and supporting routines were used.
Some day the need for that might change if additional
capabilities move to the level compiler.
This is a NetHack-3.6.2-beta01 update. Please give it a workout.
Fixes#127
Fixes#116
Farlook in 3.4.3 used xname() and just described any corpse as
"corpse" whether you knew the monster type or not. 3.6.x switched
to doname() and describes it as "<mon-type> corpse", but if it isn't
there anymore, the fake object contructed for it would have a random
corpse type.
For corpses and statues, the map glyph provides enough information
to give the fake object the same type as the original. For other
items that have a monster component (figurines, tins, eggs) it does
not, nor for other doname attributes of objects in general (which
might be picked up by monsters rather than rot away). So this fixes
the rotted-away-corpse-seems-to- become-random-corpse issue but not
the general case of the details for a remembered item which isn't
there anymore.
Having the autodescribe feature enabled and moving the cursor onto
a statue yields "statue of a <mon>" under normal circumtances, but
when done while hallucinating the feedback was just blank (because
the lookat() code couldn't find any monster at statue's location).
Now it will be "<random mon>" (not "statue of a <random mon>")
instead, same as when moving cursor over glyphs of actual monsters.
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.
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.
When polymorphed into a vampire, I saw an '@' in the distance, and
examining that with the cursor yielded "[seen: warned of shopkeepers]".
Fix that to be "warned of humans". (Vampires are warned of "humans
and elves" but this is a place where being more specific seems better.)
This is a modified version of Jason Dorje Short's key rebinding
patch, and allows also binding special keys, such as the ones
used in getloc and getpos.
One of the ways to play NetHack on nethack.alt.org is via a HTML
terminal in browser. Unfortunately this means several ctrl-key
combinations cannot be entered, because the browser intercepts
those. Similar thing applies to some international keyboard layouts
on Windows. With this patch, the user can just rebind the command
to a key that works best for them.
I've tested this on Linux TTY, X11, and Windows TTY and GUI.
The blank symbol set can be used with screen reader software
to prevent it from reading the map symbols.
Prevent a segfault when looking at the map and many symbols
share the same character. Don't list too many symbols when
looking at those, if many share the same character.
farlook was changed (end of December) to use doname instead of xname
to yield more info for items which had already been seen up close,
but it gave away info about ones which hadn't. So doname was changed
(end of April) to use "some" instead of precise quantity (when the
quantity is greater than 1) for the latter, but that doesn't work
well with corpse_xname() when the hero is blind, yielding "a some
<foo> corpses". While testing the first fix attempt, I noticed that
pickup gave "you can only lift some of the some <foo> corpses".
This fix is far from perfect. farlook can still say "some <item>s"
but lookhere and pickup always say "N <item>s". Picking up a stack
while blind will show "N <item>s" in inventory display, but dropping
it while still blind will revert to "some <item>s" for farlook.
The if/elif/else/endif interpretor for '&' command data was too
simplistic. It would allow multiple else clauses, elif clauses
after an else clause, and worst of all, accept a should-be-rejected
conditional block if an else or elif which evaluated true followed
an elif which evaluated false which in turn followed an earlier
true clause. (dat/cmdhelp trigger any of those bugs.)
Implement a rudimentary if/elif/else/endif interpretor and use
conditionals in dat/cmdhelp to describe what command each keystroke
currently invokes, so that there isn't a lot of "(debug mode only)"
and "(if number_pad is off)" cluttering the feedback that the user
sees. (The conditionals add quite a bit of clutter to the raw data
but users don't see that. number_pad produces a lot of conditional
commands: basic letters vs digits, 'g' vs 'G' for '5', phone
keypad vs normal layout of digits, and QWERTZ keyboard swap between
y/Y/^Y/M-y/M-Y/M-^Y and z/Z/^Z/M-z/M-Z/M-^Z.)
The interpretor understands
'&#' for comment,
'&? option' for 'if' (also '&? !option'
or '&? option=value[,value2,...]'
or '&? !option=value[,value2,...]'),
'&: option' for 'elif' (with argument variations same as 'if';
any number of instances for each 'if'),
'&:' for 'else' (also '&: #comment';
0 or 1 instance for a given 'if'), and
'&.' for 'endif' (also '&. #comment'; required for each 'if').
The option handling is a bit of a mess, with no generality for
which options to deal with and only a comma separated list of
integer values for the '=value' part. number_pad is the only
supported option that has a value; the few others (wizard/debug,
rest_on_space, #if SHELL, #if SUSPEND) are booleans.
Make the whatdoes ('&' or '?f') command support the 'altmeta' option
for meta-characters generated by two character seqeunce 'ESC char'.
Also, make it be more descriptive when reporting "no such command"
by including the numeric value it operated on when failing to match
any command. That might provide a way for us to get some extra
information when players report problems with odd keystrokes: we ask
them to type such at the "what command?" prompt and then tell us what
numbers come up.
It's been given a help file to deal with assorted idiosyncracies
which can come up when querying what keys do. Unfortunately that
ended up being way more verbose than intended.
Installation of the extra data file has only been done for Unix.
Other platforms will get "can't open file" if they respond with
'&' or '?' to the "what command?" prompt. The command will still
work though, just without the extra text.
Restore the ability to look up a single space by 'name'.
I thought mungspaces("<all spaces>") kept one space, but it doesn't.
It's a lucky accident that unnaming monsters and objects still works.
There may be other places which intend to give a special meaning to
a single space that don't still work....
When examining a buried object (after detection has revealed it),
suppress setting of its dknown bit when hero is adjacent. [That
couldn't actually happen, because the glyph on the map that we're
trying to examine would be replaced by one for whatever is on the
surface when sighted hero moved next to it, and an earlier clause
in the same test prevents blinded hero from getting to this point.]
Change most instances of detection to offer the player a chance to
move the cursor around on the map so that the getpos() autodescribe
feature can explain things that might go away as soon as the
current detection completes. The few instances that don't offer
such a chance are the ones where everything which has been revealed
will still be there once the action finishes (such as regular magic
mapping and blessed/persistent monster detection).
There were quite a lot of inconsistencies in things like handling
for detection while swallowed or underwater. I didn't keep track
of them to distinguish between 3.6.0, current dev code, or my patch
in progess. They should be much more consistent now but without a
comprehensive fixes36.1 entry.
Blessed clairvoyance (divination spells at skilled or expert) now
shows monsters as well as terrain. I first had it like that for
any clairvoyance, but having getpos/autodescribe kick in every 15
or 30 turns once you have the amulet--or pay the appropriate amount
to a temple preist--was nearly unplayable. When it only follows an
explicit spell cast it is not intrusive.
Make the '^' command catch up with far-look as far as identifying
trapped doors and trapped chests revealed by confused gold detect.
You need to be blinded when approaching the '^', otherwise as soon
as you can see a door or chest or whatever else is there the fake
bear trap will be removed from the map.
When confused gold detection finds a door trap or a chest trap, it
puts a bear trap glyph/tile on the map at that location. (They
disappear once they're within sight.) Those should be given their
own glyphs so that they can have their own tiles, but this doesn't
do that. What it does do is describe such fake bear traps as
"trapped door" or "trapped chest" when examined with far-look.
The '^' command--if used while blind so that '^' hasn't disappeared
yet--needs to catch up: it says "I can't see a trap there" when the
adjacent '^' is a fake bear trap.
Change description of area outside of the swallow animation from
"interior of a monster" to "unreconnoitered". For the animation
characters themselves, don't suppress the list of other screen
features which use the same character ('/' for wand and so on).
Add a data.base entry for "unreconnoitered" in case someone tries
to use it to look up an unfamiliar term.
Replace "dark part of a room" with something more sensible when
examining the map while underwater where water/lava/ice within the
3x3 grid centered on the hero is all that can be seen. Adjacent
non-water, non-lava, non-ice spots are now described as "land".
(Note: this stuff doesn't apply on the Plane of Water where being
underwater gets handled differently.) Spots outside that 3x3 grid
are now described as "unreconnoitered", which sounds a bit odd but
I couldn't come up with anything better. "Not visible" is accurate
when the hero can see but needs adjusting when he can't, bringing
us right back to the current conundrum. I suppose "not accessible"
might be viable but nitpickers would consider it to be inaccurate
if hero has teleport capability. (There are a couple of references
to "unknown" from earlier versions of this revision. I think
"a ghost or unexplored or unknown or land or air (land)" is the only
place left where the player might see it, and it seems reasonable
there, although perhaps it ought to be changed to "unreconnoitered".)
Also fix farlook while swallowed and blind, where blindness was
overriding swallower Id even though it doesn't do so for mon_nam()
and things which use that like combat feedback.
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.
Sometimes you can see a hidden monster without bringing it out of
hiding (wand of probing, blessed potion of monster detection) but
look_at wasn't mentioning the fact that the monster was hidden and
probing described mimics accurately but lumped all hiders together
as "concealed". Describe all hidden monsters more consistently.
Changes to be committed:
modified: doc/fixes36.1
modified: src/pager.c
fix bug bz54; this bug had no web ID
Report:
For /, asking via cursor can't find special named entries like "Hachi"
because the entry for the monster type like "dog" gets used instead.
Change:
Instead of "More info?", when applicable it will now do:
More info about "hachi"? [yn] (n) n
More info about "little dog"? [yn] (n)
Rename the option for adding coordinates to autodescribe feedback for
the '/' and ';' commands from 'getpos_coord' to 'whatis_coord', after
the '/' command that uses it instead of after the internal routine
that implements it. The 'whatis' name was only in dat/hh as far as I
could find, so this changes it to 'what-is' and also updates dat/help
and the Guidebook to mention the name too.
Add a 'screen' choice to the option to show coordinates as row,column
rather than x,y or compass direction(s). Revise the /m, /M, /o, /O
operations of 'what-is' to honor the whatis_coord option (mostly; a
value of 'none' gets overridden by 'map' to force coordinates).
Also, update the description of the functionality of the '/' command
in the Guidebook. The .mn version is tested, the .tex one isn't.
This fixes bz23: Warning glyph info wrong with TRAPS=50, even
though you don't set the trap symbols via TRAPS anymore, the
bug still existed. To trigger it, use SYMBOL=S_arrow_trap:2
and look at monster that appears as warning '2'.
Change "unlockable" to "broken" so that it won't be misunderstood to
mean "capable of being unlocked". The accompanying suggestion to omit
"broken" unless/until a lock or unlock attempt is made is no good since
the main reason for describing the broken lock is to avoid unnecessary
attempts to lock or unlock a container that the hero knows to be broken
but the player may have forgotten.
I also changed remote look-at for objects to use distant_name(doname)
instead of distant_name(xname) so that qualifiers like "empty" and
"broken" will show up on chests you've investigated before but aren't
standing on now. Monster type for corpse also gets shown, instead of
just 'food (corpse)'. Other remote items will become more verbose,
but only those that the hero has already seen up close.
In light of the recent 'bad options' feedback issue where \r messed
up message display, try to to make newline handling be more consistent.
I'm sure there are lots of places that still handle \n manually, but
it's a start.
When examining a trap with '/' or ';', show
|a trap (arrow trap)
instead of
|a trap or a vibrating square (arrow trap)
outside of Gehennom (unless the trap actually is a vibrating square,
which could happen via wizard mode wish). The extra verbosity is
distracting, and limiting mention of the vibrating square to the region
where it's relevant may give a hint to players getting that far for the
first time.
Preformat SYSCF entry 'WIZARDS' so that it can be displayed during panic
feedback without allocating memory for the formatted list at that time.
It also gets displayed for help's "support information" ('?k').
For panic(), push "it may be possible to rebuild" to a second line since
the formatted usernames might make the line long.
