Use ESHK(shkp)->bill_p consistently. The bill[] array field is used
to initialize the bill_p pointer field rather than be used directly
when manipulating shop bills.
While in there, get rid of some '#if DUMB' from pre-standard C days.
I couldn't reproduce the reported problem but the backtrace suggests
that defsyms[monst->mappearance] was probably out of bounds so that
nh_snprintf() got bad data. That might conceivably happen if the
glyph didn't match the mimic's mappearance, but I not sure how that
would occur.
This avoids using mappearance as an index into defsyms[] and should
give an impossible if that situation does come up.
This time the no_charge object was being carried by a pet.
To trigger, drop an object into shop, decline to sell it,
pick up an object belonging to shopkeeper, decline to buy it,
wait for your pet to pick up the no_charge object you dropped,
teleport out of the shop, wait for shopkeeper to walk out of
the shop.
- Add a vision sanity checking routine
- Recalc block point when digging a door for temporary clouds
- Add recalc_block_point after cvt_sdoor_to_door, because doorways
on the Rogue level have no doors, and otherwise the sanity checking
would complain. This doesn't actually change how the Rogue level
vision works, as it uses a different vision system
- Monster using a trap in a secret corridor revealed the corridor,
but didn't unblock the vision unless you saw the location
Sanity checking was complaining about a no_charge obj in untended shop.
Angry shopkeeper was accepting thrown items as no_charge objects:
To reproduce the impossible, kick down the shop door angering
the shopkeeper. While the shopkeeper is still in their shop,
throw an item they don't want into the shop. Wait for the shopkeeper
to get out of the shop.
Move the anger checking before the sell auto-accept code,
so the shopkeeper will charge for the object.
remove_object cleared the vision when the last boulder was removed
from a location, without considering temporary [poison] clouds.
This particular case happened when pushing a boulder.
We can't just unconditionally unblock vision for a location when a boulder
falls into a pool, because the location may also have a (poison) cloud on it.
Apparently, restoring of saved games on Windows has been
broken since 1f36b98b, 'selectsaved' extension from Oct 10.
That change was altering the names of the files saved on disk
to a new format introduced at that time, but the game was not
opening a savefile with that same name, and the restore failed.
The code that renamed the savefile to match the internal name
was not part of 1f36b98b, it already existed prior to the new
internally-stored format.
To get things functional, this commit disables the code that
carries out the renaming of the on-disk savefile to match the
internal name in the savefile entirely, at least for now.
This relates to GitHub issue #1346 item 2.
Even though most of these are cast to void (but not all), the
mips cross-compiler seems determined to warn about them anyway.
Suppress that particular warning altogether to quiet the build.
That is not the ideal approach, but if the normal way of whitelisting
individual cases isn't working, I'm not sure of another course of
action.
Commit ba731a346b "fix shop steal when
teleporting your engulfer" mentioned that there was no longer any
message given if engulfer+hero got teleported. Add such. It is a
bit lame but the situation is rare enough that it should suffice.
A couple of option processing functions, one of which was called in file.c, were
recently added to sys/unix/unixmain.c, but the wasm build does not include unixmain.c,
it uses sys/libnh/libnhmain.c.
Transcribe the functions into sys/libnh/libnhmain.c.
Also, do not #include "wintty.h" for NOTTYGRAPHICS builds.
Remove start_screen() and end_screen() from the
Window-port interface.
They were only ever used by tty, and there was a comment
carried to several window-ports about how they "really
should go away. They are tty-specific"
term_start_screen() and term_end_screen() are part of
terminal/NO_TERMS supporting routines now.
Add a note about NO_TERMS to include/wintty.h for clarity.
Rename tty_startup and tty_shutdown to term_startup() and
term_shutdown(). They are found in termcap.c for !NO_TERMS
like most of the other term_ routines, as well as having
versions for several of the NO_TERMS platforms. They aren't
part of the tty_interface called from the core. The tty
implementation does call and rely on them.
Remove some conditional #ifdef's around term_shutdown()
(formerly tty_shutdown()) and just ensure that all the
tty platforms have an implementation that they can link
with, even if it is just a stub presently.
Put the protype for nethack_exit in extern.h to reduce
maintenance to a single spot, and remove it from other
locations. A warning in the msdos cross-compile led to
this change.
Issue reported by ostrosablin: having Kick enabled as one of the
values for the 'autounlock' option succeeded it prompting "kick it?"
when walking into a locked closed door, but answering "yes" behaved
the same as answering "no".
There's bound to be a better way of fixing this, but this works.
Fixes#1360
Dented pots got their own encyclopedia entry, so they shouldn't still
match to "helmet". Even without this change, they match the "dented pot"
entry correctly, but only by virtue of it appearing earlier in the
encyclopedia.
Inverting the match to "~dented pot" isn't necessary since it isn't
something that would otherwise match "helmet", so just remove it.
Noticed when I summoned a quantum mechanic in wizard mode with a
starting character who should have no armor protection against their
teleport attack, but every touch resulted in "You are not affected". It
turns out the if statement checking for armor protection is backwards,
so you were never affected when you have no protection and were almost
always affected when you had good protection.
This appears to date back to when the all-purpose 'negated' variable was
removed and "You are not affected" moved to after the negation check;
the new conditional kept the ! by mistake.
Using #monster to make the steed use the breath weapon often
failed because the steed did not want to breathe at weak or
too strong monsters.
Make #monster force the steed use the breath, and if there is
no targets available, make the steed make some noise as feedback.
The tin-eating context was pointing to a non-existent object,
causing an error when the fuzzer somehow managed to continue eating
the freed tin object.
Clear the pointer when the tin leaves inventory or the object
is deleted.
Picking up a shop item and not paying it, getting swallowed
by a monster, and then teleporting the monster out of the shop
with you in it, the shopkeeper didn't notice the theft.
But the object was not marked as paid either.
Also prevent giving a message of the swallower disappearing
and appearing when it was teleported. (Although now there's
no message given, so something should be added ...)
If water walking boots haven't been discovered yet and underwater
hero rises to the surface when putting a pair on, discover them.
(Sinking while removing such on water already discovers them.)
Options processing can be early, even before ttyDisplay is allocated.
If we find that TTY_PERM_INVENT initialization is happening too early,
just set a marker (iflags.perm_invent_pending) to try again a bit later.
The changes in win/share are just to be able to sucessfully
reproduce the original issue on Windows. It was easily reproduced
on Unix, just by building with TTY_PERM_INVENT in include/config.h
and setting OPTIONS=perm_invent in config file.
This originated with a bug in NerfHack in which the developer specified
an inventory for a quest nemesis, but neglected to include the Bell of
Opening in it. Since monsters' inventory contents from makemon() were
tossed out completely, this caused a situation where the Bell was
deleted and the game was unwinnable. The first part of this change is
guarding against that by adding mdrop_special_objs before discarding the
inventory. This does create a possibility where if the programmer *does*
specify a nemesis get the Bell item in their inventory, while neglecting
to remove its special case generation in makemon.c, it would generate
twice - but two Bells is better than none.
Working on that fix led me to think about a limitation of the current
sp_lev.c behavior. You could either have a monster generate with its
species-typical inventory by not specifying an inventory for it, or you
could have it generate with custom inventory but then have to use that
to clumsily reproduce the normal inventory's complex chances and
conditionals in mongets(). So the remainder of this commit implements
another flag for des.monster(), keep_default_invent, that allows for
more flexibility in two ways:
1. When des.monster() contains an inventory function and
keep_default_invent is true, the monster will retain everything it
gets from makemon() and the objects in the inventory function are in
ADDITION to those. This is useful for augmenting a monster's default
kit with something to make them more threatening, or just more loot.
2. When des.monster contains no inventory function and
keep_default_invent is false, the monster will get NO inventory even
if its species is normally supposed to. I'm not sure where exactly
this would be used, but it doesn't hurt to have it available.
When keep_default_invent is not specified at all, the behavior remains
the same as it is now - if inventory is provided, default items are
discarded, and if not, they are kept.
When the des.monster() statements for the vampire ladies were changed to
use the lua-table form, the coordinate argument was not given the coord=
name in the table, so the lua loader was ignoring it and the vampire
ladies were placed on random spaces on the level. Fix this by supplying
the coord=; testing shows that they now appear back in the niches.
Also lowercase the monster species id "Vampire Lady" to "vampire lady".
The uppercase didn't affect the species being generated but having the
id be the same case as in monsters.h is consistent with how it's done
everywhere else.
Noticed when testing the recent bec de corbin change which makes ravens
generate as peaceful; if you happened to enter medusa-3 while wielding
one, all the ravens are peaceful. Even without one, if you entered the
level as a neutral character, some of them would randomly be peaceful
due to matching alignment. But in the medusa-3.lua file, the ravens are
all unconditionally flagged as hostile.
The reason for this behavior is that the lua loading code does not
recognize "hostile" (instead peaceful=0 needs to be set), so it does
nothing and leaves the ravens to generate as if it had been unspecified.
It appeared to affect only these ravens; no other des.monster() uses
hostile=1 instead of peaceful=0.
This bug has been around in the 3.7 development branch since the change
to Lua, but doesn't happen in 3.6 because the des parser does interpret
"hostile" as meaning never peaceful.
I considered augmenting lspo_monster so that it could handle "hostile"
and treat it like peaceful=0, but figure it's probably better not to
have two different booleans that control the same flag (what if someone
specified peaceful = 1 and hostile = 1?)
Noticed a few corners in some bigroom maps were | instead of -, which
doesn't have any gameplay effect but was mildly annoying for what I was
doing at the time (copying the maps out into documentation that is
supposed to show what the maps look like in-game).
There are other special levels out there that still use | for corners;
this doesn't address those, only the bigrooms.
My commit 82f0b1e8ea to make monsters which had nowhere
to move would panic attack the hero if possible, broke the
special unicorn handling; they avoid being in-line with hero,
so often had nowhere to move...
Fixes#1344
Remove the XP gain for tourist seeing a new type of monster
nearby, as it apparently made tourists a bit harder by forcing
early level gains.
Monsters next to hero are still marked as seen close-up, but
fix the code so it doesn't count undetected monsters.
Tourists still gain XP from "taking photos" of new types of monsters,
but only if they haven't seen the monster close up before.
(No actual photos are taken.)
