PatR [Sun, 27 Jan 2019 23:28:31 +0000 (15:28 -0800)]
Wine Cellar tweak
User-contributed fix; bypassed the contact form so no #Hnnnn number.
On the Gnome King's Wine Cellar version of Mines' End, a couple of
wall stubs in the lower far right were diggable, unlike all other
walls on the level. One single-spot wall stub was leftmost of three
undiggable spots, wall+floor+stone. The floor spot wasn't noticeably
different from normal (not sure whether digging a pit was prohibited)
but the stone one was.
nhmall [Sun, 27 Jan 2019 16:55:23 +0000 (11:55 -0500)]
domove_core() out of domove(); assess domove_core() results
new domove_core() assessment results
potentially smudge engravings
Proceed to wipe engraving after domove_core() now, but only under
all of the following conditions:
- you can reach the floor
- preceding domove_core() move attempt was marked as
having succeeded in domove_core()
- there is actually an engraving there to impact at
your original spot, or your new spot, or both
PatR [Thu, 24 Jan 2019 23:25:50 +0000 (15:25 -0800)]
band-aid for #H4041 - build warning: has_colors()
Since no one has come up with a better fix for has_colors() being
implicitly declared, add a hack for suppressing a compiler complaint
about has_colors() on linux and/or sco unix that use sufficiently old
<curses.h>.
Report was right after release of 3.6.0 but my fix at the time broke
compile when using more recent <curses.h>.
PatR [Wed, 23 Jan 2019 02:15:49 +0000 (18:15 -0800)]
fix #H6422 - hmonas against shades
I did much of this quite some time ago, as prequisite for a different
bug report about monsters vs shades, then set it aside. It ended up
being more complicated than I anticipated.
When deciding whether various non-weapon attacks might hit a shade,
hmonas() was not checking for blessed or silver armor that should have
been applicable. It did check boots when kicking, but not gloves or
rings (when no gloves) when touching, or outermost of cloak/suit/shirt
when hugging, or helmet when head-butting. (The last one is actually
moot because nothing with a head-butt attack is able to wear a helm.)
The problem was more general than just whether attacks might hit and
hurt shades. Various undead and/or demons are also affected by blessed
and/or silver attack but weren't for non-weapon attacks by poly'd hero.
At least two unrelated bugs are fixed: a rope golem's AT_HUGS attack
gives feedback about choking but was fully effective against monsters
which fail the can_be_strangled() test. And it was possible to hug a
long worm's tail, rendering the entire worm immobile.
The report also suggested that all artifacts be able to hit shades for
full effect, but by the time shades are encountered everyone has an
artifact so that would nullify a shade's most interesting ability.
TODO: monster against hero and monster against other monster need to
have similar changes.
PatR [Tue, 22 Jan 2019 02:54:37 +0000 (18:54 -0800)]
shielding bashing
Extracted from a larger patch: the only way to get silver damage
bonus from attacking with a shield of reflection (polished silver
shield) is to throw it or to wield it. Give different feedback when
hitting something while wielding a shield (or an iron ball; it seemed
appropriate despite having nothing to due with wanting to dish out
silver damage).
PatR [Tue, 22 Jan 2019 02:49:44 +0000 (18:49 -0800)]
hmonas() simulated twoweap
Regular two-weapon requires that both weapons actually be weapons or
at least weapon-tools. Simulation of that while polymorphed allowed
any one-handed object as the primary weapon.
Items on floor in the free spot one step inside a shop's doorway were
showing shop sell prices. Treat items on that spot as if they were
flagged no_charge as on the floor of other shop squares.
Report stated that sometimes they showed a 'for sale' price and
sometimes they didn't, but I didn't see any cases where they didn't.
PatR [Fri, 18 Jan 2019 21:22:43 +0000 (13:22 -0800)]
fix #H7980 - multiple weapon attacks when poly'd
This fixes the weapon related aspects of #H7980: having an alternate
weapon be used in cases where it shouldn't when polymorphed into a
monster form with multiple weapon attacks. The most egregious was
using an off-hand artifact, but it would also use off-hand two-handed
weapon, off-hand silver weapon when in silver-hating form, or any
reasonable off-hand weapon when wearing a shield. That last is iffy
whether or not to allow, since you'll still get the extra attacks
whether it switches to secondary weapon or stays with the primary.
I've made it re-use the primary since two-weapon mode doesn't allow
a shield. The other oddity was being able to use the secondary
weapon on the second swing even if the first swing was weaponless.
I went with ingoring the secondary weapon if there's no primary one
or if the primary is two-handed.
Report included "cursed secondary doesn't weld" but that has nothing
to do with polymorph attacking. I've changed that to drop the weapon
if you attack with it when it's cursed, similar to what happens when
secondary weapon becomes cursed while two-weaponing.
It also included "marilith's attacks beyond the second don't use any
weapon and can hit cockatrices without touching them". A marilith has
two weapon attacks and then four claw attacks. Claw attacks only use
the weapon if it hasn't been used yet, so marilith hits with primary,
secondary (or primary a second time if no secondary), claw, claw,
claw, claw and that's the intended behavior. It is able to hit
cockatrices if wielding anything at all, same as a monster with just
a single attack. Since it is impossible to wield six weapons or three
pairs of gloves, that has to be intended behavior too. Playability
trumps realism even if it is silly to hit without a 3rd through 6th
weapon and be safe from touching the target due to the 1st weapon or
one pair of gloves. [Situation is different from having no control
over unsafely biting something after making a safe weapon or claw
attack; perhaps a better solution would be to refrain from using the
four claw attacks when attacking something that is fatal to touch.]
PatR [Wed, 16 Jan 2019 23:08:11 +0000 (15:08 -0800)]
fix #H6285 - flooreffects and deltrap panic
Reported 14 months ago, a monster reading a scroll of earth which
dropped a boulder that killed another monster in an adjacent pit
was giving credit/blame to the hero and could also trigger a panic.
If the monster was killed, the pit would be filled and deleted via
m_detach and then when flooreffects tried to delete the same trap,
it accessed freed memory and deltrap could panic.
PatR [Tue, 15 Jan 2019 02:13:59 +0000 (18:13 -0800)]
potion mixing bit
Noticed when looking at whether alchemy ought to remove user-assigned
name. Get rid of the potion being dipped into sooner so that it won't
still be present if a perm_invent update takes place.
PatR [Tue, 15 Jan 2019 00:35:19 +0000 (16:35 -0800)]
level arrival
The check I added to make sure that a monster was at the hero's
coordinates before deciding to move one or the other would have been
confused by a long worm's tail. Check that they're at that spot but
not by comparing monst.<mx,my> coordinates with <ux,uy>.
Also, don't have wiz_makemap() assume that each level of the Wizard's
Tower has the same boundary coordinates. Keep track of whether hero
is inside that tower before discarding the old level.
PatR [Mon, 14 Jan 2019 17:28:10 +0000 (09:28 -0800)]
\#wizmakemap followup
Both u_on_rndspot() and losedogs() might result in having a monster
and the hero be at the same location. Have wiz_makemap() use the
same fixup for that as goto_level().
PatR [Sun, 13 Jan 2019 23:24:08 +0000 (15:24 -0800)]
\#wizmakemap update
The need for resetting lock picking when swapping in a new level made
me wonder whether other things should be reset too, and there were a
bunch: digging, travel destination, polearm target, being in water,
being swallowed or held, hiding. Hero placement was ignoring arrival
region. Also, it turned out to be pretty easy to fix the FIXME about
steed.
PatR [Sun, 13 Jan 2019 23:17:40 +0000 (15:17 -0800)]
blocking or unblocking levitation or flight
when level teleporting or digging. Level teleporting while levitation
was blocked due to being inside solid rock didn't notice that it should
be unblocked until you moved from whatever type of terrain you landed
on (room, for instance) to some other type (such as corridor). Digging
down to make a pit or hole while inside solid rock converts that spot
to floor so should also check whether to unblock levitation/flying, and
not fall if unblocking occurs.
PatR [Sun, 13 Jan 2019 01:43:52 +0000 (17:43 -0800)]
bz 406/#H4298 revisited
Redo the Ft.Ludios entry hack to suppress the lit walls on the left
and top rather than to light the upper-right corner. Only noticeable
if carrying a lit candle. Usually, that is. This simpler hack could
be detected visually from the treasure room side of the walls involved
but normally won't be.
PatR [Sat, 12 Jan 2019 03:08:02 +0000 (19:08 -0800)]
workaround #H4298/bz 406 - vision glitch
The entry chamber for the Fort Ludios level would be completely lit
except for one corner wall if you arrived carrying a lit candle. The
unlit spot turns out to be correct, it is beyond candle radius, but
spots further away than that were showing up lit. That's due to them
bordering a lit region on the opposite side and lit regions seem to
be bigger than their specified dimensions.
I tried to make the lit walls be unlit but it wasn't working. (Making
the lit region be smaller would probably work but might have unintended
consequences when populating the zoo room. I didn't try that.) This
makes the unlit corner show up if light hits the spot next to it, so
that it behaves like the other lit walls surrounding that entry area.
I haven't marked the bug report closed because I don't think this is
the proper way to fix this.
PatR [Sat, 12 Jan 2019 01:18:48 +0000 (17:18 -0800)]
enum values
Give the enum lists in several header files explicit values. Adding
or removing new entries will be more tedious, but doing that is rare
and being able to grep the headers for numeric values in addition to
names is very useful.
rm.h also has a bunch of tabs replaced with spaces.
PatR [Thu, 10 Jan 2019 11:10:35 +0000 (03:10 -0800)]
SEDUCE=0
When SEDUCE is disabled, instead of swapping attacks in mons[] once,
do it on the fly in getmattk() whenever needed. That allows mons[]
to become readonly, although this doesn't declare it 'const' because
doing so will require a zillion 'struct permonst *' updates to match.
This seemed trickier than it should be, but that turned out to be
because the old behavior was broken. Setting SEDUCE=0 in sysconf or
user's own configuration file resulted in all succubus and incubus
attacks being described as monster smiles engagingly or seductively
rather than hitting (while dishing out physical damage). I didn't
try rebuilding 3.4.3 to see whether this was already broken before
being migrated to SYSCF.
PatR [Thu, 10 Jan 2019 02:18:11 +0000 (18:18 -0800)]
characteristics loss
A hero run by the fuzzer that has characteristics plummet to 3 and
then sometimes hang around there instead of being recovered by restore
ability is happening because loss that tries to reduce the base value
below 3 lowers the max (peak) value instead, and once that also gets
down to 3, restore ability is no longer able to do anything with it.
This changes an attempt to reduce a characteristic by N points below 3
to reduce it by rn2(N + 1) instead. That's N/2 on average and a 50%
chance to be 0 when N is 1, so the peak value reached doesn't plummet
to 3 quite to quickly. It can still drop to that though.
There is a pull request dealing with simplifying attribute handling
and part of it affects the code being changed here, but the bit of
simplification included in this patch doesn't use it.
PatR [Thu, 10 Jan 2019 02:10:55 +0000 (18:10 -0800)]
hero infravision
Take a first step towards making the mons[] array be readonly.
The only other place that updates it is when changing succubus and
incubus AD_SSEX attacks to AD_SEDU ones and that can be handled
via existing getmattk(), but so far has proven to be trickier than
anticipated.
PatR [Wed, 9 Jan 2019 09:13:01 +0000 (01:13 -0800)]
make zeroany, zeromonst, zeroobj 'const'
They're never modified. Minor complication: &zeroobj is used as
a special not-Null-but-not-an-object value in multiple places and
needs to have 'const' removed with a cast in that situation.
PatR [Tue, 8 Jan 2019 22:42:54 +0000 (14:42 -0800)]
travel targetting via keyboard
Some phrase substitution in getpos() or its helpers produced
``Pick a target interesting thing in view for travel''
for 'm _', which sounds pretty awkward. Change that to be
``Pick an interesting thing in view for travel destination''
leaving "target" implied.
For plain '_', typing '!' yielded
``Using a menu to show possible targets.''
but then nothing happened. Change that to be
``Using a menu to show possible targets for 'm|M', 'o|O', 'd|D',
and 'x|X'.''
to explain when a menu will actually appear.
PatR [Mon, 7 Jan 2019 04:59:20 +0000 (20:59 -0800)]
stale vptrs for obj->{nexthere,ocontainer,ocarry}
'struct obj' contains a union of mutually exclusive pointers, but
removing an obj from a list wasn't clearing whichever one had been
in use. If something is removed from a monster's inventory, clear
the object's pointer back to that monster; if something is removed
from a container, clear the object's pointer back to that container;
and whenever something is removed from the floor, clear the pointer
to the object which followed it at that floor location.
PatR [Sun, 6 Jan 2019 10:36:41 +0000 (02:36 -0800)]
get_cost_of_shop_item() crash
More shop price determination fallout. After the most recent change
to get_cost_of_shop_item(), using ':' inside an engulfer carrying at
least one item while inside a shop would try to follow the item's
obj->ocontainer back-link and crash when that led to the engulfing
monster rather than to a container.
PatR [Sat, 5 Jan 2019 11:21:39 +0000 (03:21 -0800)]
fix #H7865 - shop prices for container contents
The recent attempt to have looking inside a container show shop
prices had multiple problems. Worst one was showing shop prices as
if the hero would be buying for items already owned by the hero.
Item handling inside containers on shop floor was inconsistent: if
shop was selling those items, they would include a price, but if not
selling--either already owned by hero or shopkeeper didn't care about
them--they were only marked "no charge" if hero owned the container.
This is definitely better but I won't be surprised if other obscure
issues crop up. Gold inside containers on shop floor is always owned
by the shop (credit is issued if it was owned by the hero) but is not
described as such.
PatR [Sat, 5 Jan 2019 03:03:34 +0000 (19:03 -0800)]
options.c formatting; glob as named fruit
This started out removing one tab and I got carried away. It moves
some labels to column 2, removes some parentheses where sizeof is
used on strings rather than types, adds or revises several comments,
replaces a couple of 'while' loops which can be simplified as 'for'
loops, and updates named fruit handling.
"glob of black pudding" became "candied glob of black pudding" if used
as a fruit name, but "small glob of black pudding" was used as-is and
became indistinguishable from an actual small glob. Unless you had
more than one; then you could try to check whether they merged into a
stack or coalesced into a bigger glob (but if neither of those changes
happened, you still couldn't tell which was the glob and which was the
named fruit).
PatR [Sat, 5 Jan 2019 02:28:50 +0000 (18:28 -0800)]
'm ^T' menu fix
Fix fuzzer feedback. The new wizard mode ^T menu had an early return
which bypassed destroy_nhwindow(), leaving the menu around. Fuzzer
eventually got "No window slots!" panic from tty. Make sure that the
menu window is torn down fully before returning.
Also, make the normal wizard mode teleportation chioce be preselected
so that not picking anything doesn't lead to an early return any more.
ESC still does though.
PatR [Fri, 4 Jan 2019 01:37:00 +0000 (17:37 -0800)]
fix github #172 - ^T inconsistencies; add m^T
Fixes #172
Casting teleport-away via ^T used different requirements for energy,
strength, and hunger than casting it via 'Z'. The strength and hunger
requirements were more stringent, the energy one more lenient. When
it rejected a cast attempt due to any of those, it used up the move,
but 'Z' didn't.
When testing my fix, I wanted an easier way than a debugger to control
how ^T interacts with wizard mode, so finally got around to a first
cut at being able to invoke it via wizard mode but not override those
energy/strength/hunger requirements. It uses the 'm' prefix to ask
for a menu. 'm^T' gives four options about how to teleport. (There
are other permutations which aren't handled.)
Also noticed while testing: ^T wouldn't attempt to cast teleport-away
if you didn't know the corresponding spellbook. 'Z' will attempt that
because it is possible to forget a book and still know its spell.
PatR [Wed, 2 Jan 2019 22:20:53 +0000 (14:20 -0800)]
sortloot vs gems
Some object classes (such as armor and weapons) are split into
"subclasses" when sortloot applies an ordering (for armor, all helms,
then all gloves, then all boots, and so on). Give gem class subsets.
Simple (1) valueable gem, (2) worthless glass, (3) gray stone, (4) rock
would give away information; instead, factor in discovery state and use
(1) unseen gems and glass ("gem")
(2) seen but undiscovered gems and glass ("blue gem"),
(3) discovered gems ("sapphire"),
(4) discovered glass ("worthless pieced of blue glass"),
(5) unseen gray stones and rocks ("stone"),
(6) seen but undiscovered gray stones ("gray stone"),
(7) discovered gray stones ("touchstone"),
(8) seen rocks ("rock").
If everything happens to be identified, the simpler ordering happens
(via 3, 4, 7, and 8) because the other subsets will be empty.
PatR [Wed, 2 Jan 2019 21:42:45 +0000 (13:42 -0800)]
create_particular long worm tail vs mkclass
Similar to ^G of 'I' triggering impossible "mkclass found no class 35
monsters", using a leading substring of "long worm tail" (other than
"l" and "long worm") would trigger impossible "mkclass found no class
59 monsters and kill the fuzzer when it escalates impossible to panic.
Tighten up the substring matching.
^G of '~' wasn't affected; it deliberately creates a long worm rather
than the tail of one. But it was possible to ask for "long worm tail"
as a specific monster type and then override the switch to long worm
when prompted about whether to force the originally specified critter.
I've added a check to prevent that opportunity to override even though
a tail without a head seemed to be harmless.
PatR [Tue, 1 Jan 2019 00:48:14 +0000 (16:48 -0800)]
tweak the Astral Plane level
Even out the difficulty (from one game to another) somewhat. Instead
of a 75% chance that two large areas will be opened up on the left
and right sides of the arrival area plus 13.5 (avg) * 1.5 (avg) extra
monsters in that region, change to 60% chance that the left side will
be opened up with 7 (avg) * 1.5 (avg) extra monsters and a separate
60% chance that the right side will be opened up with 7 * 1.5 (avg)
extra monsters. The chance that both sides get opened up drops to
36% but the chance that neither side gets opened drops to 16%, with
difference made up by 24% chance each for just one side or the other.
I was a little surprised that this actually worked. I hope there's
a less clumsy way to have a loop index.
PatR [Sun, 30 Dec 2018 23:30:38 +0000 (15:30 -0800)]
'O' vs bouldersym
The 'O' handling for bouldersym was updating the display value for
boulder even if the value had been rejected, and if it still had the
default of '\0', the map would end up with <NUL> characters. (When
examined via '//' or ';', those matched dummy monster class #0 and
led to the impossible "Alphabet soup: 'an("")'" that was suppressed
yesterday.)
Attempting to set bouldersym to ^@ or \0 would also be rejected as
duplicating a monster symbol. That is now accepted and used to reset
the boulder symbol to default. However, other control characters are
also accepted--not due to this patch, they already are, and from a
config file in addition to via 'O'--so bouldersym can still disrupt
the map. But that's no different from putting control characters
into a symbol set or setting them from config file via S_foo:^C.
PatR [Sun, 30 Dec 2018 04:41:16 +0000 (20:41 -0800)]
minor memory leak
I ran the fuzzer with MONITOR_HEAP enabled and heaputil found a dozen
or so un-free'd allocations, all made by the same dupstr() call in
special_handling() for "symset" and "roguesymset". (Reproducible with
a few tens of thousands of fuzzer moves, although you have to take
over from the fuzzer and make a clean exit rather than just interrupt
it or there'll be lots of other un-free'd memory.) I haven't actually
figured out how/why it was leaking, but reorganizing the code has made
the leak go away (according to a couple of even longer fuzzer runs) so
I'm settling for that.
PatR [Sun, 30 Dec 2018 04:39:11 +0000 (20:39 -0800)]
alphabet sour warning
A recently added impossible to check for an(Null) and an("") was
triggered by the fuzzer: Alphabet soup: 'an("")'. I reproduced it a
couple of times and tracked it do_screen_description(for '/' command)
matching the symbol from mapglyph to monster class #0, a placeholder
with symbol value '\0'. So mapglyph() returned a symbol of '\0', but
not necessary from showsyms[0 + SYM_OFF_M].
The pager lookup code's monster loop shouldn't have been attempting
to match against class #0, and since this fix I haven't been able to
reproduce the situation again. But I also didn't trigger it with a
bunch of temporary checks in mapglyph() so don't know what is really
going on under the hood.
PatR [Sun, 30 Dec 2018 02:38:30 +0000 (18:38 -0800)]
curses splash/copyright screen, role prompt
Back out '#include "date.h"' so that cursinit.c won't be recompiled
every time any other file(s) need to be compiled. It doesn't need
patchlevel.h either. There is already a straightforward way to fetch
the copyright banner lines from version.c.
The splash screen (ascii art spelling "NetHack" preceding the normal
copyright lines) was invisible when showing white text on white-ish
background. Make it honor !guicolor.
"Shall I pick a character's role, race, gender and alignment for you?
[ynaq] (y) " was too wide to accept the answer on the same line on
an 80-column display so "(y) " was placed on the second line. That's
constructed in the core; change the construction to omit " a" when
using "character" rather than a role name. (tty shortens it by omitting
the default " (y)"; with " a" gone, it could revert to normal prompt.)
Also a bit of lint cleanup and some reformatting of cursinit.c....
PatR [Sat, 29 Dec 2018 11:28:07 +0000 (03:28 -0800)]
X11 on OSX
The change to Makefile.src for X11+XPM on linux broke linking X11 on
OSX. This updates the hints files (except for the -qt one) so that
make WANT_WIN_X11=1
and
make WANT_WIN_X11=1 USE_XPM=1
work correctly.
The comment in macosx10.14 about what version(s) it's intended for
and been tested on is just cloned from 10.10 and should be updated.
Pasi Kallinen [Sat, 29 Dec 2018 05:19:18 +0000 (07:19 +0200)]
X11: default to XPM-format tile file and rip screen
People have been wondering how to change the tiles on the X11
version, and the old default of NetHack-specific binary tile data
isn't directly editable with image editing tools.
Also show in the #version info if xpm and graphic rip are enabled.
PatR [Sat, 29 Dec 2018 03:10:54 +0000 (19:10 -0800)]
create_particular 'I' vs mkclass
The revised mkclass() [actually new mkclass_aligned()] has an extra
check which didn't used to be there, and attempting to create a
monster of class 'I' with ^G triggered impossible "mkclass found no
class 35 monsters" which the fuzzer escalates to panic.
PatR [Fri, 28 Dec 2018 02:36:26 +0000 (18:36 -0800)]
fix github issue #170 - stacks of non-missiles
Fixes #170
Monsters never throw athames or scalpels but some fake player monsters
on the Astral Plane are given those. Since they're stackable the
quantity usually gets boosted but there's no point in having more than
one if they won't be thrown.
This could have been fixed by letting monsters throw those two items,
but I prevented the quantity from being boosted instead.
PatR [Thu, 27 Dec 2018 23:37:06 +0000 (15:37 -0800)]
stack merging vs shop pricing
When merging one stack into another and they have different obj->o_id
price adjustments, keep the o_id of whichever one commands the higher
shop price.
PatR [Thu, 27 Dec 2018 23:01:15 +0000 (15:01 -0800)]
stack splitting vs shop prices
I misread part of the original code and the revision introduced a bug
based on that. obj->o_id price variations are used for all types of
non-IDed items, not just non-glass gems.
PatR [Thu, 27 Dec 2018 22:12:48 +0000 (14:12 -0800)]
fix #H7103 - shop pricing
Player came across a stack of 2 gray stones in a shop and kicked one.
That one ended up with a different (in his case, lower) price once it
was separate. This behavior only applies to non-glass gems which add
a price variation derived from internal ID (obj->o_id) number. Make
splitting stacks always yield the same price per item in the new stack
as was being charged in the old stack by choosing a similar o_id. Do
it for all splits (that can vary price by ID, so just non-glass gems),
not just ones performed inside shops.
He picked up the lower priced one and dropped it back on the original
higher priced one; the combined stack took on the lower price. That
will no longer happen if they come from splitting a stack, but this
fix doesn't address merging with different prices when they start out
as separate stacks. (Unpaid items won't merge in inventory if prices
are different, but shop-owned items will merge on floor.)
PatR [Thu, 27 Dec 2018 21:31:42 +0000 (13:31 -0800)]
mines luckstone as achievement marker
It was possible to have the guaranteed luckstone at Mines' End become
merged with a random one and lose its specialness for achievement
tracking. Mark it 'nomerge' when created and clear that if/when the
achievement is recorded.
PatR [Wed, 26 Dec 2018 01:07:45 +0000 (17:07 -0800)]
container_contents() vs show goods
Fix another inconsistency with containers in shops: prices shown when
looking inside. Apply had them (because shop goods in containers are
flagged as 'unpaid' when hero carries the container), and loot did not
(because they aren't flagged that way).
PatR [Wed, 26 Dec 2018 00:45:41 +0000 (16:45 -0800)]
stolen_value() vs containers
stolen_value() treated hero-owned container holding shop-owned goods
as free for the taking.
The fix I'm working on which led to discovering this first added
stolen_value() then eventually stopped using it so I don't have an
example of where it is giving the wrong result.
PatR [Tue, 25 Dec 2018 21:48:51 +0000 (13:48 -0800)]
prices of items on shop floor
get_cost_of_item() was giving different information from shop #chat
when dealing with containers owned by hero containing objects owned
by the shop. And when it was legitimately reporting a price of 0,
doname_with_price() wasn't reporting 'no charge' for items inside a
shop that were owned by hero or that shopkeeper didn't care about.
Extend the shop price reveal to far-look, but only when hero and item
being examined are inside the same shop.
PatR [Tue, 25 Dec 2018 02:43:51 +0000 (18:43 -0800)]
status gold vs symset:Blank
Symset:Blank sets all the map symbols (except STRANGE_OBJECT) to
<space>. The status lines for !STATUS_HILITES force status to use '$'
instead of ' ' for the prefix before ":1234" for gold, but the status
lines for STATUS_HILITES did not. tty ended up with ":1234" for gold.
win32 and curses both ignore the prefix and construct their own, but
since win32 uses the map symbol for that it must also be ending up
with ":1234" (I assume; I haven't seen it). curses is forcing '$' for
the prefix, even on the rogue level.
This attempts to fix win32 without be able to test the result. I've
left curses alone.
PatR [Mon, 24 Dec 2018 10:08:44 +0000 (02:08 -0800)]
fix temporary strength loss that was permanent
Watching the fuzzer, I saw hero's strength plummet to 3 again and not
rise above 5 after that. It turns out to be due to life-saving, which
was fixing severe hunger but was not restoring the point of strength
that's lost when you go from hungry to weak.
Another fuzzer bit: the monk I was watching was bitten by a wererat
early on and was still inflicted with lycanthropy when he reached
level 19. (I've no idea how his level got to be so high; it jumped
from 14 to 19 while I wasn't paying attention.) Extend the earlier
hack for drinking a blessed potion of restore ability to recover lost
characteristcs to sometimes drink a potion of holy water instead.
PatR [Mon, 24 Dec 2018 01:25:14 +0000 (17:25 -0800)]
implement #H6051 - fake players resist Conflict
The rationale is that since the player character resists conflict,
fake players should too.
[I'm not sure that I buy that. Player character is always the one
*causing* conflict and it doesn't affect self. But this is simple
as long as no other resistance checks are against attack-by-ring.]
PatR [Sun, 23 Dec 2018 20:37:26 +0000 (12:37 -0800)]
fix #H6942 - dropx vs hold_another_object
Dropping an existing fragile item while levitating will usually
break it. Getting a new wished-for fragile item and dropping it
because of fumbling or overfull inventory never would.
Some callers of hold_another_object() held on to its return value,
others discarded that. That return value was unsafe if the item
was dropped and fell down a hole (or broke [after this change]).
Return Null if we can't be sure of the value, and make sure all
callers are prepared to deal with Null.
PatR [Sun, 23 Dec 2018 02:09:44 +0000 (18:09 -0800)]
fix github issue #155 - encumbrance vs water
Fixes #155
When drowning, you need to be unencumbered in order to crawl out of
water. When not drowing, you don't, but put a limit on how much can
be carried. If polymorphed into a swimming creature, allow stressed
or less; otherwise (magical breathing), burdened or less. (Doesn't
apply on the Plane of Water since there's no climb from water to land
involved.)
PatR [Sun, 23 Dec 2018 00:35:15 +0000 (16:35 -0800)]
fix #H7749 - "you detect it"
'Detect' is used for observing a vampire shape change without being
able to see the vampire. The problem here is that it changed from
bat form to fog cloud form in order to pass under a closed door,
and the message was being delivered when it was already at the door
location instead of before the move from a visible spot to that door.
I'm not happy with this fix, but any other alternative I considered
seemed to be worse. Having the shape change use up the monster's
move is probably a better way to go. Then on its next move it will
be in the right form to make a normal flow-under-door move.
PatR [Sat, 22 Dec 2018 01:11:22 +0000 (17:11 -0800)]
fix #H2709 - exercise_steed() for riding skill
Code appears to intend that riding for 100 turns be treated like a
successful weapon hit as far as skill training goes, but it was
actually requiring 101 turns each time. It's conceivable that that
was intentional, but unlikely.
PatR [Fri, 21 Dec 2018 22:36:55 +0000 (14:36 -0800)]
monsters on melting ice
Reported seven years ago, when ice melts underneath a monster, it
hovers there until its next move, then falls in and drowns. Dunk it
immediately, and give hero credit/blame if it happens during the
hero's turn (so presumably the melting was caused by the hero).
Also, let monster with teleport capability who gets dunked teleport
away from the water before getting wet, the way hero does.
PatR [Fri, 21 Dec 2018 09:14:45 +0000 (01:14 -0800)]
fix #H2680 - IDing unpaid gem should adjust price
Another one from 6.5 years ago, identifying a type of gem should give
a new price for any unpaid gems of that type and adjust shopping bill
accordingly. Report was for rubbing with touchstone and learning
worthless glass with price not changing until the learned 'gem' was
dropped. Fix works for that and also other forms of identification
(and for amnesia, raising prices of forgotten gems); no dropping is
required for the price to change.
Theoretically could apply to any type of item, but prices of gems are
by far the most sensitive to whether or not they're identified.
PatR [Fri, 21 Dec 2018 02:58:44 +0000 (18:58 -0800)]
data.base lookup bit
When testing the change to the Eyes of the Overworld wording and asking
for information about inventory item
k - a pair of lenses named The Eyes of the Overworld
I got "I don't have any information on those things". Not because that
item wasn't identified, but because the lookup was for "pair of lenses"
(finding nothing) and then for "The Eyes of the Overworld" (and not
finding it due to "The" which is stripped from the first attempt but
wasn't from the second nor present in the data.base key).