A shop-owned glob picked up by the hero was added to shop's bill
and if that shrank to nothing it moved from the unpaid portion to
used-up portion as intended. But once there it retained obj->owt
of 0 and if 'sanity_check' was enabled, that triggered a warning
every move until finally paid for. Both the 'Ix' list of used-up
items and itemized shop billing revealed a weight of 0 aum if
'wizweight' was enabled.
Keep track of the weight a glob had when it becomes unpaid, then
reset from 0 to that amount if it becomes used-up. This overloads
the obj->oextra->omid field which is an unsigned int previously
only used for corpses. Now for globs it is pre-bill obj->owt which
is also unsigned int. I didn't add new oextra access functions for
it; it is only used in two places and existing omid ones suffice.
triggering an impossible warning about "wall_angle: unknown" due
to the known conflict between door state and wall info which both
overlay the flags field for map locations.
Reported and diagnosed by vultur-cadens: if a shop's wall was dug
open, followed by use of locking magic to plug the gap with a door,
and then unlocking that door, the D_CLOSED door flag was left as
invalid wall_info when shop damage was repaired. Map re-display
complained. Leaving the door locked or opening it after unlocking
did not result in any complaint because the values for those door
states do not conflict with wall angle values.
The problem was reproducible and is now fixed by adding an extra
field to the shop damage structure. A similar change has been
made to the vault guard's 'fake corridor' structure but I have no
test case for that so don't know whether it makes any difference.
At least it doesn't seem to have broken anything.
Existing save and bones files are invalidated by the fixes.
Fixes#606
for helm of opposite alignment.
Discovered and described by vultur-cadens.
The #adjust command can be used to split an object stack and if the
shop price of the two halves are different, the new stack will have
its obj->o_id modified to make the prices the same. That could be
used to tip off the player as to what the low bits of the next o_id
will be. Since no time passes, no intervening activity such as
random creation of a new monster can take place, so the player could
wish for something that depends on o_id with some degree of control.
Matters mainly for helms of opposite alignment intended to be used
by neutral characters since the player isn't supposed to be able to
control that. (Other items like T-shirt slogan text and candy bar
wrapper text had a similar issue but controlling those wouldn't have
had any tangible difference on play.)
The issue writeup suggested allowing the player to specify a helm's
alignment during a wish. That would defeat the purpose of having
o_id affect the helm's behavior in an arbitrary but repeatable way
so is rejected.
I implemented this fix before seeing a followup comment that suggests
using a more sophisticated decision than 'obj->o_id % N' for the
arbitrary effect. This just increments context.ident for the next
obj->o_id or mon->m_id by 1 or 2 instead of always by 1 and should
be adequate. It also has the side-effect that two consecutive wishes
for helm of opposite alignment won't necessary give one for each of
the two possible 'polarities', even with no intervening activity by
monsters, reinforcing the lack of player control.
Minor bonus fix: it moves the incrementing check for wrap-to-0 into
a single place instead of replicating that half a dozen times. Ones
that should have been there for shop billing and for objects loaded
from bones files were missing.
Fixes#596
It's redundant with g.moves, so there is no more need for it.
Way, way back, it looks like g.moves and g.monstermoves can and did
desync, where g.moves would track the amount of moves the player had
gotten (and would therefore increase faster if the player were hasted)
and g.monstermoves would track the amount of monster move cycles, aka
turns. But this has not been the case for a long time, and they both
increment together in the same location in allmain.c. There are no
longer any cases where they will not be the same value.
This is a save-breaking change because it changes struct
instance_globals, but I have not updated the editlevel in this commit.
Drinking a potion sets the in_use flag so that it can be deleted
if found in a hangup save file. That flag wasn't being cleared if
a shop-owned item is used up and goes onto the shop bill instead of
being discarded. The recently revised object sanity checking was
complaining (turn after turn after turn until player paid for the
potion) that there was an object with its in_use bit set.
Restore only purges in_use objects in invent and didn't mess up
billing by getting rid such objects since they're on another list.
when perm_invent is displayed. The persistent inventory window
showed unpaid items with their prices, but when using itemized
billing those prices went away when an item was purchased.
The prices and item-by-item prompting continued correctly with
remaining unpaid items; only the perm_invent display was affected.
Fixes#541
Allow shopkeeper to remove webs and pits.
Change the damage fix messaging to be more specific when
shopkeeper removes a trap. Before this the message was
"A trap was removed from the floor", which sounds really silly
when it comes to holes.
Change the damage fixing so the shopkeeper will fix one damage spot
at a time (instead of all at once), so it's more like a monster action.
Some code cleanup, splitting into smaller functions.
While doing this, I noticed that shopkeepers don't actually bill
the hero for the damage, but that'll have to be another commit...
When shopkeeper fixes a wall and there are items on that location,
shopkeeper tries to move those items into their shop. Split
the code dealing with that into separate functions.
Higher charisma will make it more likely for monsters to be affected.
Conflict will also now require the monster to see the hero.
Originally from SporkHack by Derek Ray.
A recent change made it possible for a glob to have its dknown flag
cleared and that exposed globby_bill_fixup() passing Null shopkeeper
to get_cost(), triggering a crash.
Make the routine that clears dknown/known/bknown/&c also be the
routine used to initialize those flags for a new object so that it
is the place that handles various special cases. That hides the
shop bug again.
But also fix the shop bug even though it won't be triggered.
Fixes#509
when taming is used to pacify hostile shopkeeper. I haven't
figured out how to reproduce and eliminate the double dismissal,
but this will prevent the second one from issuing duplicate "the
Kops (disappointed) vanish into thin air" and also from trigging
the warning "dmonsfree: N removed doesn't match 2N pending."
The first dismissal leaves defunct Kops on the monster list, as
expected; second dismissal found them still there and sent them
away again instead of skipping them as already gone.
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.
If a container holds anything that a shop wouldn't ordinarily
buy and sell and you sell it for gold, the 'foreign' contents
are marked no_charge and hero still owns them. But selling the
same container+contents for credit instead of gold would take
shop possession of all the contents without increasing the
credit amount.
The fixes entry is longer than the fix. It solves cited case but
I won't be surprised much if it messes up some other case(s).
Kicking a container that had gold in it took the gold amount
away from hero's credit or added to hero's debt, then didn't
give a refund if the container and its gold landed within the
shop. Throwing behaved likewise, just less verbosely.
The problem is caused by addtobill() treating gold specially
and then subfrombill() not being able to perform a reverse
operation. Actually, it may be possible for subfrombill() to
do that, but verifying all its uses is too much work. This
moves the gold handling for drop+selling into its own routine
and adds calls to that for the throwing and kicking refunds.
The other calls to subfrombill() outside of shk.c appear to be
ok as-is. (The calls inside that file are the ones that still
need evaluation if the gold handling is to move to there.)
bill_dummy_object() now uses the same o_id assignment for its
dummy object as split_object() does for its new partial stack.
I don't know whether the old code led to any price glitches.
When SCORE_ON_BOTL is enabled, you could tell how much gold is
inside a container with unknown contents by having 'showsore' On
and watching how much the score changed on the status line when
picking the container up.
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.
Introduce eight achievements that can be attained by more players.
Entered Gnomish Mines - self explanatory
Entered Mine Town - the town portion, not just the level
Entered a shop - any tended shop on any level
Entered a temple - likewise for temple
Consulted the Oracle - bought at least one major or minor oracle
Read a Discworld Novel - read at least one passage
Entered Sokoban - like mines
Entered the Big Room - not always possible since not always present
The novel and bigroom ones aren't always achieveable since novels are
only guaranteed if a book or scroll shop gets created and bigroom is
only guaranteed in wizard mode. No one ever claimed that every
possible achievement can be attained in a single game. (If one for
entering the Fort Ludios level--or perhaps entering the Fort itself--
eventually gets add, that won't be possible in every game either.)
The mine town one probably needs some tweaking. Two of the town's
seven variants have no town boundary (despite a rectangular area of
pre-defined map) and at present simply arriving on either of those
levels is enough to be credited with the entered-town achievement.
Bump EDITLEVEL because u.uachieved[] has increased in size. This
time it has been expanded to the maximum that xlogfile's bitmask of
achievements can handle, enough for up to 9 more achievements without
another EDITLEVEL increment.
When GOLDOBJ was activated unconditionally, several texts started referencing
"money" instead of "gold".
As we don't have the intention to introduce a complex coin system with
different denominations, change it back and also some other places that
reference "money".
Submitted for 3.7.0; all but one also apply to 3.6.3.
I rewrote the curses terminal-too-small message instead of just
fixing the spelling of "minumum".
Flag existing occurrences of "You hear" as "Deaf-aware" so
that a grep for that string in the future doesn't need to
trigger further investigation of those.
Fix a couple of bugs I stumbled across while testing something else.
The sell prompt for a container dropped in a shop had phrasing issues.
This fixes a couple but there are more. The message composition
assumes that contents fall into two categories: those already owned
by the shop and those the shopkeeper is offering to buy from the hero.
But there is a third: stuff the shopkeeper doesn't care about so
won't buy. The count_contents() routine can supply total contents or
shop-owned contents. Subtracting one from the other yields combined
hero-owned without any way to separate out shk-cares and don't-care.
Dying in a shop while carrying partly eaten food would place that food
on the floor without marking it no_charge. But marking it that way
wouldn't have helped because as bones data gets saved, every object on
the level has its no_charge flag cleared. So 'no_charge' needs to be
explicitly set for partly eaten food in tended shops as a bones level
gets loaded.
Most of the shk.c diff is reformatting, but it does change the
get_pricing_units() routine to lie that the quantity is zero for
partly eaten food so that when multiplying with price it won't matter
whether the price has been forced to zero or been left non-zero.
