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.
Move the details of autodescribe out of getpos into a separate
routine.
I think 'cartesian' mode should be renamed 'compass' mode, and
'absolute' mode perhaps should be 'map' mode. And we should have
a new 'screen' mode which shows rows,columns (1..N rather than
0..N-1). For tty, row is line+2; message and prompting "window"
is row 1, line 0 of map is row 2. Columns are straightforward
since column 0 of the map isn't used for map display: column 1
of map is column 1 of screen. Non-tty mostly shouldn't care and
might as well use the same conversion.
Always include the hero's location in the set of spots for 'm',&c to
cycle through. This way the set will never be empty so checks for that
can be dropped, and choosing initial index becomes trivial (set to 0,
then increment to reach nearest spot of interest or decrement to reach
farthest). Also, it makes it easier for player to see when successive
'm's,&c have been through all the interesting locations if there are
multiple monsters or objects clumped near the last one in the cycle.
Extend the 'm' and 'M' functionality (move cursor to nearest monster
or farthest monster, respectively, then to next nearest/next farthest
when used successively) to 'o' and 'O' for objects.
'M' was picking the wrong monster (nearest) on first use; now fixed.
Hero is now included in the monster list, and will be the last one
reached if you cycle all the way through in either direction. (Makes
it easier to tell that you have actually been all the way through.
Unfortunately, objects don't have any seen-'em-all indicator. Perhaps
the hero's coordinates should go on that list too?)
Fixing a couple of warnings led to discovery of a couple of real bugs.
Warnings:
1) -Wshadow warning for 'dist2' variable blocking access to dist2()
function.
2) Declaration not at top of block not allowed for C89/C90 (let alone
for pre-ANSI).
Bugs:
3) there might be 0 visible monsters, in which case the code prior to
qsort will call alloc(0). I think ANSI requires malloc(0) to return
a unique pointer which can be freed, but pre-ANSI malloc might
return Null to satisfy it, leading to panic from nethack's alloc().
4) visible monsters in direct line with hero horizontally or vertically
were unintentionally skipped when collecting monster locations.
I think looking at monsters is the wrong way to implement this. It
should be scanning the map for monster glyphs instead. (Coin toss as
to whether it should also treat statues-shown-as-monsters as if they
were monsters while doing this. I'm leaning towards yes. And what
about warning glyphs and instances of the remembered-invisible monster
glyph? They aren't interesting to look at but they might provide a
shortcut to positioning the cursor near something else.)
Using '^' to move to next trap moves from hero's position to end of
hero's line, then columns 1 to N of next line, and so on to bottom
right, then top left columns 1 to N, second line 1 to N, on down to
hero's line. Having 'm' traverse monsters from nearest to farthest
feels like a noticeable inconsistency between the two. Especially if
you move the cursor with direction or topology keystrokes prior to 'm'.
Some monsters can't be named, but if the user tried to assign them a
name that matched what they were already called, the rejection message
could be silly. Reported case was "I'm Izchak, not Izchak!". The fix
is more general than just for shopkeepers, although their reject
message was silliest when complaining about the name already in use.
For the cited case, feedback will now be 'He is already called Izchak.'
60: getpos() doesn't report the offending keystroke accurately when
rejecting M-something as a movement keystroke while moving the cursor;
61: typing M-N as a command keystroke produces
|Unknown command 'M-
| '.
where the '.' on the second line clobbers the top line of the map.
I can't reproduce the first one without extending the altmeta hack
[a run-time option to treat two char sequence ESC c as M-c] to getpos()
and nh_poskey(), which I've done for testing but am not including here.
I can't reproduce the second as it's described, but M-^J produces
|Unknown command 'M-
|'.--More--
and this fixes that, with a general fix that applies to any meta char.
The diffs include some cleanup/groundwork for maybe extending altmeta.
High priests used a different message to refuse accepting a user-supplied
name than regular temple priests because they're flagged as unique. The
effect was cosmetic; it didn't reopen the hole that let you recognize
which high priest was which via the 'C' command on the Astral Plane.
[I never received the mail for #H4062 but saw it in bugzilla.]
Requested by a beta tester back in June: naming Sting or Orcrist
violates illiterate conduct. I left it at that; any object naming
could be construed as being literate, but I don't think breaking
conduct for doing such would be a good idea.
Fixing up mis-indented block comments, but hit some files that hadn't
had the earlier mixture of tab replacement, etc, so it's bigger than I
expected. If I get to it, they'll be another round of this tomorrow.
Make novels be wishable in normal and explore modes in addition to
wizard mode. I don't think this weakens the tribute and it prevents
someone who attempts such a wish from getting misleading feedback of
"Nothing fitting that description exists in the game."
Wishing for "novel" will yield "novel named Foo" where "Foo" is a
randomly chosen Discworld title. Wishing for "novel named Bar" will
yield "novel named Bar" or "novel named The Bar" if "Bar" or "The Bar"
is a valid Discworld title, or else override "Bar" and pick random
Discworld "novel named Foo" if it isn't.
Since first read of a novel bestows some experience (once per game, no
matter how many novels become available), a pacifist with an early
wish can get a head start. I don't think that's a big deal. And it
will require an awful lot of wishes for any player who wants to acquire
all 41 titles in one game. I imagine someone will manage it.
to polymorphed into something which is hiding under an object.
Also, make the attempt to name a floor object while hallucinating give
a more interesting result.
Implement Boudewijn's suggestion that #name be extended to allow naming
something of the floor. I'm sure he wants this so that he can avoid
picking up gray stones, but it's something I started to implement years
ago (probably at an earlier suggestion from him...) and then forgot all
about.
This changes the #name menu to be
m - a monster
i - a particular object in inventory
o - the type of an object in inventory
f - the type of an object upon the floor
d - the type of an object on discoveries list
a - record an annotation for the current level
What do you want to name?
with the i and o choices omitted when inventory is empty. If the
'lootabc' option is set it will use a through f instead, but then the
last three entries change letters when inventory is empty. 'y' and 'n'
are still accelerators (effectively hidden choices) for the i and o
entries, corresponding to the answers for the 3.4.3 and earlier "name
an individual object?" prompt.
The floor choice asks you to pick a location. If you pick yourself,
then the top object of the pile underneath you is targetted. Otherwise,
the target must be an object glyph, and the object must have its dknown
bit set, so have previously been seen up close or revealed via blessed
potion of object detection. To make it be more useful, targetting an
object on an adjacent square will set the dknown bit. (Just the top
object if there is a pile there.) There's no cockatrice corpse touch
check since you aren't actually touching anything, just looking.
The setting of dknown bit for an adjacent object has been extended to
the '/' and ';' commands for examining things on the screen as well.
It's only done for adjacent spots you actively select, not all 8 spots
around you.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
When you turn on the automatic description of a glyph under cursor,
we want to show the short description of what glyph it actually is.
The long full description of all possibilities is far too long, so
may cause more-prompts, and is awkward for blind players.
Changes to be committed:
modified: doc/fixes35.0
modified: include/extern.h
modified: src/do_name.c
modified: src/objnam.c
This pretty much completes the code portion of the book tribute.
- The book will appear in the rare books shop.
- When you read the book, a random passage is drawn for a
tribute file (suggested by Mike).
- The book cannot be renamed because it already has a
name (observed/suggested by Sean).
The data file (dat/tribute) has a few test passages, but needs to be
filled out. Sean and Mike Stephenson have indicated that
possibly they may be able to help contribute to that. Ideally,
there should be at least one passage from each of the books.
Look up remembered dungeon features, not user-visible glyphs,
and ignore uninteresting features (room, corridor and wall tiles).
Original patch by Patric Mueller, from UnNetHack
Pressing '@' will move the cursor on top of the hero.
Pressing '#' will toggle automatic description mode, where
the feature under the cursor is automatically described
when the cursor is moved.
There is a lot of code affected by this, and Pat Rankin correctly
observes that it would be better to store roguelike as a level flag
rather than just using Is_rogue_level. A note for the future.
Add dupstr() as a substitute for strdup() so that out-of-memory
handling will be consistent with the rest of nethack, and make it aware
of nethack's heap logging. It's treated like alloc() so that its caller
can be logged for NH_HEAPLOG.
I put it into use in a few places, but there are lots more candidates
besides the existing calls to strdup() that should be replaced.
There was a second instance of curs()+flush_screen() that had the
calls swapped 5.5 years ago and is being restored to 3.4.3 state here.
It turns out that swapping the other instance of those two calls
didn't help with the original problem (^R during getpos() redrew the
screen but left the cursor at the end of the 2nd status line) at all.
Only adding the pline() call after docrt() fixed it. pline() calls
flush_screen(1) which ultimately puts the cursor back on the hero. I
still don't understand why curs(WIN_MAP,x,y)+flush_screen(0) leaves it
on the status line instead of at the specified map coordinates. That
must be a bug in the tty code somewhere.
This ought to fix the problem excountered by Ken, where the cursor
wasn't at the spot '/y' was reporting on. This reverses part of a change
from May, 2005. I still don't understand the original behavior, which
was that docrt() for ^R followed by positioning the cursor at a specific
map coordinate and calling flush_screen() was leaving the cursor at the
end of the second status line. Reversing flush_screen and curs(WIN_MAP)
made it work for tty but screwed up X11. It turns out that including
pline("Move cursor to %s:") *also* makes things work as intended, so that
the flush/position hack wasn't necessary once that other change went in
(same 2005 patch, but the cursor hack was implemented first at that time;
once this reversal is in place, commenting out the pline() does bring the
odd behavior for tty back).
3.4.3 and earlier had a bug that let players discover luck stones
and amulets of esp by attempting to name unID'd gray stones or amulets
after corresponding quest artifacts and seeing whether they got "your
hand slips" feedback. There's been a fix for this in place for a while,
but after recent newsgroup discussion I wanted to confirm that it works
as intended for amulets as well as for gray stones. It does. I ended
up with "a circular amulet named T*e Eye of the Aethiopica" (where that
asterisk was something other than the original "h" due to slippage)
which looks odd to me. I've modified the code to leave leading "the"
intact and only distort the remainder of such a name. This doesn't go
so far as to make sure distortions don't touch the "of the" portion in
the middle although it probably should.
From a bug report, the text change applied
when you try to give an artifact's name to am item of that artifact's type
would choose a letter from 'a' through 'y' when replacing the randomly
selected target letter. Rather than fixing the off by one bug which
prevented 'z' from being chosen, this switches to the existing routine
used for mangling engravings. (Unfortunately the fix is not as simple as
first expected, because wipeout_text() doesn't guarantee to change text
which has spaces in it and all the quest artifact names have those.)
