Under some circumstances, when all the marauding orcs belonging to the
horde operating within the gnomish mines had been provided with their
spoils and placed appropriately, there could still be some pillaged stuff
left-over on the migrating obj chain. Orcs created by regular monster
generation elsewhere would then be susceptable to receiving that stuff
until it was used up. That part is fine, except that the orcs were then
being named as part of the same horde operating within the mines. Now
they will no longer be named as part of the Gnomish Mines horde.
Mythos: There's a good chance that these particular orcs received the
stolen goods from the Gnomish Mines horde.
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
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.
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.
Previously the "fast-moving" when getting a target location
was always by 8 units. If this option is on, fast-moving
will instead skip the same map glyphs. This should be much more
useful for blind players.
Compound option whatis_filter, filters the eligible map locations
when getting a cursor location for targeting. Accepts 'n' (none),
'v' (map locations in view), or 'a' (map locations in the same area,
eg. room or corridor).
Report was about "Pet vampire" but the relevant aspect was that the
vampire had been assigned a name, not that it was tame:
You observe a Hilda where a Hilda was.
Investigating this has uncovered two other bugs, one potentially
serious. m_monnam() overrides hallucination but seems to be getting
used to some situations where hallucination should be honored (several
instances). Dynamically constructed format strings are including
monster or object names in the format (rather than the usual use as
arguments), so player assigned names containing percent signs could
cause havoc (a few instances). This fixes some of the former and one
of the latter, but doesn't deal with various other cases revealed by
grep.
Attempting to name the relevant type of item with an artifact's name
(such as a runesword with "Stormbringer") fails with "your hand
slips" in order to prevent turning the item into an aritfact. Since
that only happens when the name is valid, it indicates that the hero
is literate so violate illiterate conduct.
(Naming items in general doesn't affect [il]literacy so that player
can assign names to inventory or stash items to maintain notes.)
Keep getpos's autodescribe feedback out of the DUMPLOG message history.
Unfortunately it still gets put in interface-specific message history
and is liable to fill up the buffer there, forcing actual old messages
to be flushed away.
To-be-3.6.1 bug, caused by a patch (of mine...) incorporated about
a week after 3.6.0 was released that was intended to be for naming
Sting or Orcist. Any artifact creation ended up breaking illiterate
conduct whether user-assigned naming was involved or not (because
oname() is always used to apply the name, not just when do_name() is
executing).
This should be handled differently but I don't want to go through
the dozen and half or so calls to oname() to add an extra argument.
Adds two new configurable keys to the cursor targeting: 'A' (getpos.menu)
and 'a' (getpos.menu.cansee). First one shows a menu of all interesting
glyphs on the map, second one shows only those in sight.
Travel command also now obeys the "request menu" -prefix, showing
the menu with interesting targets in sight, and then traveling there.
Idea via the NetHack accessibility research by Alexei Pepers.
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.
Yet another accessibility feature. When asked for a location
to travel, and autodescribe is on, the location description
has "(no travel path)" appended, if there is no known path
to that location.
While testing something I noticed that moving the cursor to visible '^'
by typing '^' while getpos was asking me to pick a location, it didn't
always cycle through all visible traps. The most straightforward
culprit was after trap detection (via confused gold detection, not ^F)
had found a trap door or level teleporter in a closet that itself was
a secret corridor spot. But it turned out to be any location that
hadn't been seen yet. This is a substantial overhaul of the relevant
code and so far works for all the cases I've tried, but there are
bound to be cases I haven't tried yet and those may or may not work
correctly.
There's also a bunch of formatting cleanup, and some simplification of
the m/M/o/O/d/D/x/X handling.
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.
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.
