When minimal_xname() set up a dummy object containing as few details
as possible, it wasn't setting up the fruit id field, so xname()
couldn't figure out what type of fruit it had and issued a warning.
I haven't managed a test case that uses minimal_xname so testing of
the fix is less than comprehensive. [Pasi got it through dopay, but
that only resorts to minimal_xname if the formatted name is really
long and would otherwise cause the shopkeeper's prompt to overflow.
Long fruit name combined with long individual object name wasn't
long enough to trigger that. Maybe uncursed, greased, rustproof
the like, or possibly just a longer shopkeeper name than I had?]
The previous fix prevents the crash from 'the()' when NO_GLYPH was
used as an index into the defsyms array, but it resulted in giving
feedback of "you attack thin air" regardless of what was at the
target location, reverting to the situation that the buggy code was
attempting to address in the first place. Handle that differently
by removing the unseen monster glyph sooner. Also, the underwater
handling wasn't working as intended.
I blamed Derek's pudding farming patch for introducing the problem,
but all that did was replace the offending line(s) with different
indentation. The older post-3.4.3 patch which produced the problem
was mine. Sorry, Derek.
Changes to be committed:
modified: include/extern.h
modified: src/files.c
modified: src/objects.c
modified: src/spell.c
- charge a little more.
- no free read in the bookstore.
Changes to be committed:
modified: src/hack.c
modified: src/pager.c
Don't use glyph_to_cmap as an array index into
the defsyms[] array unless it really is a cmap.
Recent situation: glyph_to_cmap will return
NO_GLYPH for the unknown monster glyph 'I', which
is not a valid index for the defsyms[] array.
A recent fault on mingw32 revealed that faulty
code which passes a bad or out-of-range date
value could have game-fatal consequences.
Add some protection.
currently it's locked behind _MSC_VER, but anything that runs on Win32
should be able to use those functions as long as it has something that
can pass as a debug window.
also, add a non-wildcard-accepting version of showdebug for the dumpit()
functions in dungeon.c and questpgr.c; this makes DEBUGFILES=* workable
without being excruciatingly painful
...if the map is filled with monsters, and for some reason
the drowning just won't kill you.
Infinite looping cannot currently happen, because no-one who
can drown can keep surviving the drowning once their amulet
of life saving is used up.
Any monster with rusting or corrosion attack can eat through
the bars. This includes rust monsters, grey oozes, and black puddings.
Original patch by Malcolm Ryan
The intent is to look for platform-specific facilities for regex
matching, to provide portable MENUCOLORS configuration files.
This is a prototype implementation being committed to see if Windows can
use the POSIX regex implementation provided with the C++11 standard
library. If this works, I will write a harness for POSIX regexes and for
pmatch(), and those can be linked in by platforms as appropriate.
pmatch() should be used only as a very last resort, because it breaks
compatibility between platforms.
Add pmatchi() to perform case-insensitive wildcard matching, and
pmatchz() which is also case-insensitive and ignores spaces, dashes,
and underscores like the type of matching done during wish parsing.
At the moment, neither is being used, although DEBUGFILES handling
uses pmatch and needs to be taught to distinguish between case-
sensitive and case-insensitive filenames so will eventually use
pmatchi when appropriate.
From a bug report two years ago, mithril armor should have color
HI_SILVER rather than HI_METAL. Tolkien describes mithril as "like
silver which never tarnishes". (The bug report had a more precise
quote, and a github URL for a patch which I've ignored.) The Amulet
of Yendor has material set to MITHRIL but I haven't changed its color.
All amulets are HI_METAL, so if any modification is needed for it,
change the material rather than the color.
Mithril-coats are displayed as cyan both before and after this patch,
so it's hard to tell whether any change actually happened.
PatR