Restore some old behavior for the apply command that was changed
by the "getobj refactor" patch. You couldn't attempt to apply
potions to determine whether they were oil, couldn't apply gray
stones once touchstone was discovered, and attempting to apply
arbitrary items gave "that is a silly thing to apply" rather
than "sorry, I don't know how to use that."
The message given when attempting to light a lantern with no power
left described it as a lamp. Change that to lantern. Also, "has
run out of power" duplicates the message given when it burns out;
change that part to "is out of power".
Your lamp has run out of power. -> Your lantern is out of power.
Fixes#489
Zapping wand of opening or spell of knock at engulfer while swallowed
would make the engulfer expel the hero; this change makes zapping
other holders release their hold. Zapping self now achieves the same
effect, as does breaking a non-empty wand of opening. When poly'd
hero is holding a monster rather than being held, that monster will
be released.
Engulfers can't re-engulf for 1 or 2 turns after releasing the hero
in order to prevent hero from being immediately re-engulfed. Impose
the same limitation on other holders.
without using any time. Targetting an apparently empty spot at
valid polearm range where a monster happens to be hiding reports
"Wait! There's something there you can't see!" and displays the
remembered, unseen monster glyph, then aborts the attack attempt.
It would use a turn if the polearm became wielded in the attempt
but not if it was already wielded. Make latter case take time.
We have a struct called mkroom and a function called mkroom()
so c++ complains about the mkroom() function hiding the
initializer for the struct.
Similarly, we have a struct called attack and a function
called attack().
There may be a more elegant way of eliminating those two
warnings, but renaming mkroom() to do_mkroom() and
attack() to do_attack() was straightforward enough.
If an empty lamp was hit by fire, the feedback was "the lamp
catches fire!" even though it wouldn't light.
ingite_items() imperfectly duplicated catch_lit(). Just call
the latter. The resulting message will be slightly different
but that's insignificant.
This replaces the arcane system previously used by getobj where the
caller would pass in a "string" whose characters were object class
numbers, with the first up to four characters being special constants
that effectively acted as flags and had to be in a certain order.
Because there are many places where getobj must behave more granularly
than just object class filtering, this was supplemented by over a
hundred lines enumerating all these special cases and "ugly checks", as
well as other ugly code spread around in getobj callers that formatted
the "string".
Now, getobj callers pass in a callback which will return one of five
possible values for any given object in the player's inventory. The
logic of determining the eligibility of a given object is handled in the
caller, which greatly simplifies the code and makes it clearer to read.
Particularly since there's no real need to cram everything into one if
statement.
This is related to pull request #77 by FIQ; it's largely a
reimplementation of its callbacks system, without doing a bigger than
necessary refactor of getobj or adding the ability to select a
floor/trap/dungeon feature with getobj. Differences in implementation
are mostly minor:
- using enum constants for returns instead of magic numbers
- 5 possible return values for callbacks instead of 3, due to trying to
make it behave exactly as it did previously. PR #77 would sometimes
outright exclude objects because it lacked semantics for invalid
objects that should be selectable anyway, or give slightly different
messages.
- passing a bitmask of flags to getobj rather than booleans (easier to
add more flags later - such as FIQ's "allow floor features" flag, if
that becomes desirable)
- renaming some of getobj's variables to clearer versions
- naming all callbacks consistently with "_ok"
- generally more comments explaining things
The callbacks use the same logic from getobj_obj_exclude,
getobj_obj_exclude_too and getobj_obj_acceptable_unlisted (and in a few
cases, from special cases still within getobj). In a number of them, I
added comments suggesting possible further refinements to what is and
isn't eligible (e.g. should a bullwhip really be presented as a
candidate for readying a thrown weapon?)
This also removed ALLOW_COUNT and ALLOW_NONE, relics of the old system,
and moved ALLOW_ALL's definition into detect.c which is the only place
it's used now (unrelated to getobj). The ALLOW_ALL functionality still
exists as the GETOBJ_PROMPT flag, because its main use is to force
getobj to prompt for input even if nothing is valid.
I did not refactor ggetobj() as part of this change.
further adjustments to the window port interface to pass a pointer
to a glyph_info struct which describes not just the glyph number
itself, but also the ttychar, the color, the glyphflags, and the
symset index.
This affects two existing window port calls that get passed glyphs
and does the parameter consistently for both of them using the
glyph_info struct pointer:
print_glyph()
add_menu().
The recently added glyphmod parameter is now unnecessary and has been
removed.
add MALE, FEMALE, and gender-neutral names for individual monster species
to the mons array. The gender-neutral name (NEUTRAL) is mandatory, the
MALE and FEMALE versions are not.
replace code uses of the mname field of permonst with one of the three
potentially-available gender-specific names.
consolidate some separate mons entries that differed only by species into a
single mons entry (caveman, cavewoman and priest,priestess etc.)
consolidate several "* lord" and "* queen/* king" monst entries into
their single species, and allow both genders on some where it makes some
sense (there is probably more work and cleanup to come out of this at some
point, and the chosen gender-neutral name variations are not cast in stone
if someone has better suggestions).
related function or macro additions:
pmname(pm, gender) to get the gender variation of the permonst name. It
guards against monsters that haven't got anything except NEUTRAL naming
and falls back to the NEUTRAL version if FEMALE and MALE versions are
missing.
Ugender to obtain the current hero gender.
Mgender(mtmp) to obtain the gender of a monster
While the code can safely refer directly to pmnames[NEUTRAL] safely in the
code because it always exists, the other two (pmnames[MALE] and
pmnames[FEMALE] may not exist so use:
pmname(ptr, gidx)
where -ptr is a permonst *
-gidx is an index into the pmnames array field of the
permonst struct
pmname() checks for a valid index and checks for null-pointers for
pmnames[MALE] and pmnames[FEMALE], and will fall back to pmnames[NEUTRAL] if
the pointer requested if the requested variation is unavailable, or if the
gidx is out-of-range.
Allow code to specify makemon flags to request female or male (via MM_MALE
and MM_FEMALE flags respectively)to makedefs, since the species alone doesn't
distinguish male/female anymore. Specifying MM_MALE or MM_FEMALE won't
override the pm M2_MALE and M2_FEMALE flags on a mons[] entry.
male and female tiles have been added to win/share/monsters.txt.
The majority are duplicated placeholders except for those that were
separate mons entries before. Perhaps someone will contribute artwork in the
future to make the male and female variations visually distinguishable.
tilemapping via has the MALE tile indexes in the glyph2tile[]
array produced at build time. If a window port has information that the
FEMALE tile is required, it just has to increment the index returned
from the glyph2tile[] array by 1.
statues already preserved gender of the monster through STATUE_FEMALE
and STATUE_MALE, so ensure that pmnames takes that into consideration.
I expect some refinement will be required after broad play-testing puts it to
the test.
consolidate caveman,cavewoman and priest,priestess monst.c entries etc
This commit will require a bump of editlevel in patchlevel.h because it alters
the index numbers of the monsters due to the consolidation of some. Those
index numbers are saved in some other structures, even though the mons[] array
itself is not part of the savefile.
Window Port Interface Change
Also add a parameter to print_glyph to convey additional information beyond
the glyph to the window ports. Every single window port was calling back to
mapglyph for the information anyway, so just included it in the interface and
produce the information right in the display core.
The mapglyph() function uses will be eliminated, although there are still some
in the code yet to be dealt with.
win32, tty, x11, Qt, msdos window ports have all had adjustments done to
utilize the new parameter instead of calling mapglyph, but some of those
window ports have not been thoroughly tested since the changes.
Interface change additional info:
print_glyph(window, x, y, glyph, bkglyph, *glyphmod)
-- Print the glyph at (x,y) on the given window. Glyphs are
integers at the interface, mapped to whatever the window-
port wants (symbol, font, color, attributes, ...there's
a 1-1 map between glyphs and distinct things on the map).
-- bkglyph is a background glyph for potential use by some
graphical or tiled environments to allow the depiction
to fall against a background consistent with the grid
around x,y. If bkglyph is NO_GLYPH, then the parameter
should be ignored (do nothing with it).
-- glyphmod provides extended information about the glyph
that window ports can use to enhance the display in
various ways.
unsigned int glyphmod[NUM_GLYPHMOD]
where:
glyphmod[GM_TTYCHAR] is the text characters associated
with the original NetHack display.
glyphmod[GM_FLAGS] are the special flags that denote
additional information that window
ports can use.
glyphmod[GM_COLOR] is the text character
color associated with the original
NetHack display.
Support for including the glyphmod info in the display glyph buffer
alongside the glyph itself was added and is the default operation.
That can be turned off by defining UNBUFFERED_GLYPHMOD at compile time.
With UNBUFFERED_GLYPHMOD operation, a call will be placed to map_glyphmod()
immediately prior to every print_glyph() call.
Multiple functions are involved in the process of targeting and
attacking an enemy with a polearm or lance, and these functions
previously used inconsistent tests to determine which targets were
legal. For instance, find_poleable_mon would give up immediately if the
hero was blind, while neither get_valid_polearm_position nor use_pole
cared as long as the hero could detect a target on the square (e.g. by
ESP). find_poleable_mon considered warning symbols as potential
targets, but use_pole discarded them. get_valid_polearm_position
considered moats and pools to be illegal targets, but use_pole would
let the hero successfully hit a monster on those squares; on the
other hand, get_valid_polearm_position would mark squares that were not
visible and did not contain a known monster as legal targets, while
find_poleable_mon and use_pole would exclude them.
Obviously this was inconsistent and could introduce confusion for
polearm users, who would potentially need to explicitly target squares
marked "(illegal)" at some point over the course of their game, among
other problems. This commit makes polearm targeting tests more
consistent; the following rules are applied to positions within the
appropriate range:
* Monsters which are detected by any means that reveals an actual
monster glyph are legal to target, even if the hero is blind
* Monsters the hero cannot detect, but is aware of -- i.e. those
represented by an 'I' -- are similarly legal to target
* Monsters detected via warning are not legal targets, since the hero
does not have as strong a sense of where exactly they are, their shape
and size, etc
* Statues are legal targets, but will not be suggested by
find_poleable_mon unless the hero is impaired (confused, stunned, or
hallucinating); the same is true of tame/peaceful monsters
* Apparently empty squares, including those containing an undetected
monster, are legal to target unless they cannot be seen (whether due
to blindness or a very dark room/level)
* Positions which are otherwise legal but are blocked by an obstruction like a
tree or pillar are not legal targets
Use a linked list to store stair and ladder information, instead
of having fixed up/down stairs/ladders and a single "special" (branch)
stair.
Breaks saves and bones.
Adds information to migrating objects and monsters for the dungeon
and level where they are migrating from.
Breaking a wand didn't require the hero to have free hands.
That's definitely a bug when they're both welded to the same
two-handed weapon. It's debatable when welded separately to
a one-handed weapon and to a shield but simpler to pretend
there's no such distinction.
This also makes glass wand join balsa wand as "fragile". Hero
doesn't need as much strength to break them as other wands and
the wording for breaking them is slightly different.
My fixes entry initially had a trailing space. When I took
that out, I spotted a couple of others so take those out too.
ignitable() was excluding magic lamp and then every place that
used it did so as 'ignitable(obj) || obj->otyp == MAGIC_LAMP'
so just include magic lamp.
I noticed that while hunting for an explanation for report #K2734
where returning to a previously visited level triggered the
warning "begin_burn: unexpected eggs". I've decided that the
zombie apocalypse is probably the cause. It inserted a new type
of timer in the list of such but it didn't bump EDITLEVEL to
invalidate save and bones files which relied on indices into the
old list. I'm not sure whether we should bump that now.
Noticed while working on Qt's version of persistent inventory
window (paper doll-style display of equipment in use), leashing
or unleashing a pet wasn't updating persistent inventory. Leash
descriptions format differently when in use so immediate update
is warranted.
Implement the suggested feature that a camera's flash actually update
hero's memory of the map as it traverses across the level. Turned
out to be more work than anticipated despite having the code for a
thrown or kicked lit candle or lamp to build upon.
Among other things it needed to update the circle code to handle
previously unused radius 0 to operate on the center point only. I've
never touched that before and hope this hasn't introduced any bugs.
Also removes several instances of vision code operating on column #0.
(At least one is still present.)
Applying a bullwhip down while levitating or riding gives a chance
to pick up items from the unreachable floor. Doing so over water
yields "you wrap your bullwhip around <item> on the water" when
that item is actually on the bottom. Same for lava. Don't fetch
items from beneath the surface. Also, for the lava case subject
the whip to fire damage.
This has actually broken the seal on a can of worms. Every item
at a water location sinks to the bottom even if it should float.
I'm not opening that can....
Fixes#319
Unicorn horns are just too good. Nerf it in similar way several
other variants have done: don't let it restore attribute loss.
This makes potion of restore ability more valuable, and the
int loss from the (nerfed) mind flayers matter more.
Before this commit, attaching a lit candle would reduce the amount
of fuel in the candelabrum to 0, 15 or 75 turns due to a failure to
account for time stored in the candle's burn timer. Fixing this is
very important because a time of 0 turns on the candelabrum is not
supposed to be possible.
This may have happened in a 3.7 game on Hardfought. Even if it didn't,
I'm still uncomfortable with the potential for the game to potentially
become unwinnable as a consequence of age field corruption. Add an
impossible() for when this situation happens, and code after the
impossible() to repair the game by removing the candles.
Provide a way to communicate additional behaviors and/or appearances
desired from NetHack window port menus.
This is foundation work for changes to follow at a future date.
Mounting a steed while legs are wounded would offer to cure them
but wasn't going through the heal_legs() routine so didn't update
the status line when Wounded_legs condition is enabled.
Move some common code for describing left/right/both legs into a
new routine used for feedback by jumping, kicking, and ridiing.
For ^X, distinguish between one wounded leg and both but don't
bother with left vs right when it is just one.
Setting or clearing u.ustuck now requires that context.botl be set,
so make a new routine to take care of both instead of manipulating
that pointer directly.
Applying royal jelly listed all of inventory as likely candidates for
what to rub it on, including itself.
Applying it to anything took no time.
After the "you smear royal jelly on <foo>" message,
unsuccessfully applying it to non-eggs gave no other feedback;
successfully applying it to eggs gave no additional feedback.
Allow #rub to use royal jelly too.
Also, require hands to apply or #rub anything.
Not done: fumbling and/or slippery fingers should have a chance to
drop the jelly or to drop whatever gets rubbed with it.
Royal jelly applied on an egg will change a killer bee egg to
a queen bee egg. Cursed jelly will kill the egg, uncursed and blessed
will revive it. Blessed jelly will also make the creature think
you're the parent.
Original patch was by Kenneth Call
There was a complaint that despite charisma of 13 being above average,
the character was described as "ugly". The cut-off was actually >14
for "beautiful" or "handsome" vs <=14 for "ugly". This adds several
more grades of appearance.
teleds() is used for more than just teleportations, the teleportation message
was also given when mounting a steed.
Trying out a new bit flags method parameter design pattern.
Jumping, Newton's 3rd Law hurtling, and throwing an iron ball:
attempting to do any of these in such a way that you would diagonally
pass between boulders/walls causes the Luck penalty. However, none of
these actually get you through the diagonal gap, thus they can't be used
to cheat and the penalty doesn't make sense.
Applying a spellbook allows the player to flip through the pages, providing an
indication of how many reads it has left before turning blank.
Originally from UnNetHack but code almost completely refactored and updated
for post 3.4 changes like deafness and novels.
groundwork only - window port interface change
This changes the last parameter for add_menu() from a boolean
to an unsigned int, to allow additional itemflags in future
beyond just the "preselected" that the original boolean offered.
There shouldn't be any functionality changes with this groundwork-only
change, and if there are it is unintentional and should be reported.
This adds a boolean option, autounlock, defaulting to true. When this is
set to TRUE, messages stating that some door or container is locked are
automatically followed by a prompt asking if you would like to unlock
it, if you are carrying an unlocking tool (key, lock pick, or credit
card).
Architecturally, this extends the pick_lock function to take three
additional arguments (door coordinates or a box on the ground you are
autounlocking).
The code that selects an unlocking tool will always look first for a
skeleton key, then a lock pick, then a credit card. Since curses, rust,
and other attributes don't really have an effect on the viability of the
unlocking device, it didn't seem to warrant making a more complex
function for that.
Add hallucinatory trap names
This adds many funny, realistic, and nonsensical traps to the game, to
be shown when the player is hallucinating.
Architecturally, the biggest change is merging the what_trap macro and
the "defsyms[trap_to_defsym(ttyp)].explanation" pattern into a single
function "trapname", which returns the name of the trap, handling the
hallucination case. There is also a second parameter used for overriding
hallucination in the occasional cases where the actual trap name should
always be returned.
In addition, the what_trap and random_trap macros are now obsolete and
not used anywhere, so they are removed.
reinstate anti-rng abuse bit on hallucination
updates to hallucinatory trap names and fixes37.0 entry
Developed for 3.6 but deferred to 3.7. Most of the testing was with
the earlier incarnation.
Report was that pronouns were accurate for the underlying monsters
when hallucination was describing something random, and also that the
gender prefix flag from bogusmon.txt wasn't being used. The latter
is still the case, but pronouns are now chosen at random while under
the influence of hallucination. One of the choices is plural and an
attempt is made to make the monster name and verb fit that usage.
|The homunculus picks up a wand of speed monster.
|The large cats zap themselves with a wand of speed monster!
|The blue dragon is suddenly moving faster.
There is no attempt to match gender for the singular cases; you might
get
|The succubus zaps himself [...]
or
|The incubus zaps herself [...]
The report mentioned whistles but I had forgotten all about them by
the time I tried to deal with musical instruments. Plain whistles
had deaf handling but magic whistles didn't.
Move makeplural(body_part(FINGER)) into its own routine, with option
to substitute gloves when wearing such.
Wearing slippery gloves (ie, wearing gloves while having slippery
fingers) wouldn't let you put on a ring because you can't take the
gloves off, but removing a worn ring lacked the same restriction.
After changing that, teach prayer that slippery gloves is another
reason why a ring of levitation can't be removed.
Slippery fingers would transfer from bare hands to gloved hands if
you put gloves on. The reverse, transfering from gloves to bare
hands when taking gloves off, was already being prevented for
directly taking them off, but still allowed the slipperiness to
transfer when gloves were lost. This prevents putting on gloves
when fingers are slippery and attempts to handle cases where gloves
get unworn by ways other than 'T' (or 'R') or 'A'.
There's no slippery attribute for objects (way too much work for too
little value); slippery gloves is just the combination of wearing
gloves and having slippery fingers (which now has to have happened
while already wearing those gloves). This changes inventory to use
"(being worn; slippery)" when applicable and much of the patch deals
with funnelling Glib changes through new make_glib() to try to make
sure that persistent inventory adds or removes "; slippery" right
away when changes happen.
If gloves are taken off involuntarily (shapechange to a form that
can't wear them, destruction via scroll of destroy armor or monster
spell of same or via overenchantment, theft), slippery fingers ends
right away instead of the usual few turns later.
