PatR [Thu, 30 Dec 2021 19:06:29 +0000 (11:06 -0800)]
fixes entry for Qt6 support
I had a minor merge issue when incorporating Ray's Qt6 port from
github.com/chasonr/NetHack/Qt6 but it got resolved. This still builds
with Qt5 (and that's the only aspect I've been able to test) but is
supposed to work with Qt6 too. It adds a new hints file for OSX and
someone might need to create a comparable one for linux. Or maybe
the differences can be folded into the existing hints as conditional.
Pasi Kallinen [Thu, 30 Dec 2021 16:46:30 +0000 (18:46 +0200)]
Make extended commands return defined flags
Instead of returning 0 or 1, we'll now use ECMD_OK or ECMD_TURN.
These have the same meaning as the hardcoded numbers; ECMD_TURN
means the command uses a turn.
In future, could add eg. a flag denoting "user cancelled command"
or "command failed", and should clear eg. the cmdq.
Mostly this was simply replacing return values with the defines
in the extended commands, so hopefully I didn't break anything.
Pasi Kallinen [Wed, 29 Dec 2021 17:40:23 +0000 (19:40 +0200)]
Apply a wielded polearm with fire-command
Wield a polearm and use 'f'ire to automatically hit with it,
if there's a single valid target.
With fireassist-option, will swapweapon to a polearm.
This only applies if quiver is empty and autoquiver is off.
PatR [Wed, 29 Dec 2021 10:21:13 +0000 (02:21 -0800)]
no USED_SOUNDS option parsing bit
If the program is build without USER_SOUNDS and encounters any SOUND
or SOUNDDIR directive when parsing the run-time config file it only
issues an error message about the first one. When finished parsing,
have it include suppressed ones in the count of errors encountered.
PatR [Wed, 29 Dec 2021 10:13:34 +0000 (02:13 -0800)]
Qt paper doll fix for two-handed weapons
Allowing optional arguments can be risky. The recent glyph changes
added a new argument to the routine that constructs a mirror image
of a tile but not to the call to that routine. Because an existing
argument was optional, the compiler didn't complain about the new
one being missing.
Obsolete optional 'fem' argument ought to removed but this doesn't
tackle that.
PatR [Mon, 27 Dec 2021 22:27:35 +0000 (14:27 -0800)]
Qt misuse of Role_if()
The Qt paper doll highlights known blessed/uncursed/cursed items with
a color border. It was trying to force obj->bknown for non-blinded
priest[ess] but passed the old role letter argument to Role_if()
instead of the monster number that's used these days. It was also
potentially modifying an invent item in a way that's observable to
the player but not updating persistent inventory to show that.
Probably didn't matter though; I don't think the situation it checks
for can occur anymore. On the off chance that it could, move the
check-and-set out of #if ENHANCED_PAPERDOLL so that same inventory
update would occur for ordinary paper doll even though that doesn't
care about displayed items' bless/curse state.
PatR [Sun, 26 Dec 2021 22:57:29 +0000 (14:57 -0800)]
red dragon's sight
Since wearing red dragon scales/mail confers infravision, give that
ability to red dragons. Matters when the hero is polymorphed into one.
Also give it to the Chromatic Dragon, where I don't think it matters.
A giant that is carrying a boulder and standing on ice who drowns when
the ice gets melted could die a second time if the resulting pool gets
plugged by the boulder. It results in an impossible from dmonsfree()
about bookkeeping inconsistency when dead monsters are removed at the
end of the turn. The fuzzer escalates that to a panic.
PatR [Sun, 26 Dec 2021 08:43:24 +0000 (00:43 -0800)]
curses message management
Switch from 'moves' to 'hero_seq' for tracking whether consecutive
messages were issued on the same move and for whether current move
is still same one after played has responded to --More-- with ESC.
PatR [Sun, 26 Dec 2021 08:16:55 +0000 (00:16 -0800)]
hero_seq
'moves' is actually turns and there hasn't been any straightforward
way to track actual hero moves. Add hero_seq for that. It isn't a
counter but is distinct each time the hero makes a move. I wanted
it for curses ^P support but so far use it for checking stethoscope
usage and for shopkeeper behavior when items in a shop are broken by
the hero.
Increment EDITLEVEL due to change in save file contents.
PatR [Sat, 25 Dec 2021 22:31:33 +0000 (14:31 -0800)]
dragon armor fix
Fix a segfault when polymorphed into a dragon and using ^X.
One inconsistency I've spotted that I hadn't noticed earlier: if
you wear red dragon scales/mail you obtain infravision ability, but
if polymorph into a red dragon, you don't.
PatR [Sat, 25 Dec 2021 18:26:44 +0000 (10:26 -0800)]
dragon armor properties
Special abilities conferred by wearing dragon armor was implemented in
a somewhat half-assed fashion; extend it to 3/4-assed. Abilities came
from wearing dragon armor but not from being poly'd into a dragon or
for monsters that were wearing dragon armor or actually were dragons.
This covers much of that.
There are umpteen calls of 'resists_foo(mon)' and some are now
'resists_foo(mon) || defended(mon, AD_FOO)' but the second part ought
to be incorporated into update_mon_intrinics() so that the extra
'|| defended()' doesn't have to be spread all over the place and the
ones being put in now could/should be removed.
While testing, I noticed that a monster wielding Fire Brand did not
resist being hit by a wand of fire. This fixes that and should also
fix various comparable situations for other artifacts. But so far it
has only been done for zapping (and any other actions which use the
zapping code). Folding defended() checks into update_mon_intrinsics()
matters more than that probably sounds.
PatR [Thu, 23 Dec 2021 03:36:52 +0000 (19:36 -0800)]
sickness countdown
Give messages when sickness countdown has nearly expired to warn
player that hero is dying and also so that death at the end doesn't
seem so abrupt after an arbitrary period with just "TermIll" and/or
"FoodPois" on the status line.
Also, abuse constitution each turn when Sick (either variation, but
not a double amount if both).
PatR [Wed, 22 Dec 2021 20:23:50 +0000 (12:23 -0800)]
curses: urgent messages
This is comparable to the recent fix for tty. When messages aren't
currently being suppressed by use of ESC at --More-- (">>" for
curses), if an urgent message itself triggers --More--, don't start
suppressing messages if player dismisses it with ESC.
PatR [Wed, 22 Dec 2021 19:33:35 +0000 (11:33 -0800)]
curses: fix "---" separators in ^P output
This one has me baffled, first how/when it happened and then why no
one reported it. The line
current_mesg->turn = g.moves;
vanished from mesg_add_line() at some point. It is visible in diff
context of commit 99ed00012e076be07846edceb85e3e5e53f2bb02 from March,
2019 but I can't find any commit since that time which removed it.
[I've been using
git log --no-min-parents --no-max-parents --patch win/curses/cursmesg.c
and then searching within the pager. Maybe that's flaky, but if so,
things wouldn't be any less strange.]
The missing line resulted in mesg->turn being uninitialized, so when
^P compared consecutive messages to decide whether they were issued on
the same turn, arbitrary junk made them all seem to be from different
turns so "---" got inserted before every message. I suppose that if
someone uses a malloc that zeroes the memory it hands out, mesg->turn
field would always be 0 and ^P would behave as if all messages were
from the same turn, so not show any "---" separators. Then players
might not be aware that "---" between groups of messages was intended.
[The messages ought to be grouped by move rather than by turn, but
that's something the core would have to provide.]
PatR [Wed, 22 Dec 2021 08:18:37 +0000 (00:18 -0800)]
switch makedefs from malloc() to alloc()
Avoids any need for MONITOR_HEAP hackery. Link src/alloc.o and
util/panic.o into util/makedefs.
When replacing the realloc() call in fgetline(), I noticed that
fgetline() would miss the last line of an input file if it lacked a
terminating newline. This was hard to test because OSX seems to be
supplying one when it is missing (VMS would do that too). I had to
modify epitaph (my test bed) to take off the final character, run
'makedefs -s' under debugger control and strip away final newline
that stdio added back, build new nhdat and move it into place, then
run nethack and execute #wizrumorcheck all multiple times before
the fix and once more after it. Much effort for little gain...
Plus some of the recent reformatting: indent labels one space,
replace tabs with spaces, shorten or split wide lines.
PatR [Tue, 21 Dec 2021 10:56:59 +0000 (02:56 -0800)]
bullwhip and polearm attack feedback
When testing the urgent message for having weapon be snagged by a
bullwhip, in between the occasional weapon grabs (which mention
flicking the bullwhip) I saw lots of regular attacks that said
"<mon> swings his bullwhip." That is accurate but seems odd, so
change it to "<mon> lashes his bullwhip." Do same for the hero.
While working on that, I discovered that monsters using a polearm
for a ranged attack always showed "<mon> thrusts <a polearm>" even
for ones that aren't defined as piercing so should be swung rather
that thrust. And they're allowed to do that when adjacent where
there isn't enough room to thrust or swing a long polearm. Now it's
"<mon> bashes with <a polearm>" in that situation.
Pasi Kallinen [Tue, 21 Dec 2021 09:18:45 +0000 (11:18 +0200)]
Vampire in a genocided shape
When you genocided a monster a vampire was shapeshifted into,
the vampire might've stayed in the genocided form.
Always revert back to vampire form if we tried to pick a genocided form.
PatR [Mon, 20 Dec 2021 16:42:58 +0000 (08:42 -0800)]
additional urgent messages
Now I've remembered why I didn't follow through with these back when
I originally laid the groundwork. New urgent messages:
having an item of armor be destroyed
having weapon be grabbed by a monster's bullwhip
becoming engulfed
being grabbed by an eel
subsequently being drowned by an eel
dying of petrification
turning into slime then dying due to genocide
dying due to fatal illness
PatR [Mon, 20 Dec 2021 16:16:13 +0000 (08:16 -0800)]
fix for urgent messages for tty
If messages aren't currently being skipped due to --More--ESC when a
message flagged as urgent is issued and that urgent message itself
triggers --More-- to have the user acknowledge the previous message,
and the user types ESC at this new --More--, message suppression
starts. With the overly simplistic existing code from a few days
ago, it was too late for the current message to override that. Since
the urgent message gets buffered like any other (until another message
needs the top line or until input is needed), it wouldn't be shown
when the next message came along and discovered suppression in effect.
I'm not sure that all the changes here are necessary; there was some
flailing about involved. But it seems to behave as intended now.
PatR [Mon, 20 Dec 2021 03:31:19 +0000 (19:31 -0800)]
region save/restore
When shortening/splitting wide lines I noticed that the save and
restore code for regions had a bunch of those and they could be
shortened by using an intermediate variable. Easier to read too.
Also, change several 'unsigned int' to just 'unsigned' as is used in
most of the rest of the code.
At one point I omitted a (genericptr_t) cast (which should no longer
be necessary...) and discovered that bwrite() wasn't declaring the
input buffer it never modifies as 'const'.
PatR [Sun, 19 Dec 2021 17:30:07 +0000 (09:30 -0800)]
fix #K3496 - leash description when pet changes
If persistent inventory is displayed and contains an entry for a leash
attached to a pet and the pet's type or name changes, the perm_invent
window didn't get updated to reflect the new leash information:
x - leash (attached to <mon>)
Report was for polymorph but applied to growing into bigger form and
to being (re-/un-)christened as well.
PatR [Sun, 19 Dec 2021 12:54:34 +0000 (04:54 -0800)]
create_door() warning hackery
Redo the warning suppression in create_door(). The unreachable 'goto'
was unnecessary and without it there's no need to toggle unreachable
code warnings off and back on. Taking a step back, the whole 'default'
case is unnecessary since rn2(4) will always hit one of the 0..3 cases.
So instead of just getting rid of the unreachable 'goto', get rid of
the panic() too.
PatR [Sun, 19 Dec 2021 11:46:21 +0000 (03:46 -0800)]
Qt paper doll fix
This fixes the broken paper doll display. Changes for new glyphs
added code to an 'if' but not to the corresponding 'else'.
Showing map column 0 as something other than blank is still a problem.
The splash window shows a red dragon and says "loading". I'm pretty
sure that that used to be a crisp image but it is now a fuzzy one.
It doesn't use glyphs or their tiles so shouldn't have been affected
by changes to them.
PatR [Sat, 18 Dec 2021 01:46:49 +0000 (17:46 -0800)]
'urgent' messages
Follow up on some old groundwork. For tty, if the core has designated
a message as 'urgent', override any message suppression taking place
because of ESC typed at the --More-- prompt. Right now, "You die"
messages, feedback about having something stolen, feedback for
"amorous demon" interaction (mainly in case of armor removal), and
exploding a bag of holding are treated as urgent.
The "You die" case is already handled by a hack in top-line handling;
I left that in place so the conversion of 3 or 4 pline("You die.*")
to custompline(URGENT_MESSAGE, "You die.*") was redundant. There
are probably various non-You_die messages which precede done() which
should be marked urgent too.
Other interfaces might want to do something similar. And we ought to
implement MSGTYPE=force or MSGTYPE=urgent to allow players to indicate
other messages that they want have to override suppression. But I'm
not intending to work on either of those. I mainly wanted to force
the magic bag explosion message to be shown since a sequence of "You
put <foo> into <bag>." messages is a likely candidate for --More--ESC.
PatR [Sat, 18 Dec 2021 00:29:53 +0000 (16:29 -0800)]
fixes entry for pull-req #643 - historic statues
monstone() was using a hardcoded value when flagging the statue of
a unique monster as historic and didn't get updated when the corpse
and statue flags kept in obj->spe were changed last June by commit 04a8ddcce1f2c679706a0e9413f742677dbb0f68.
Michael Meyer [Thu, 2 Dec 2021 23:45:57 +0000 (18:45 -0500)]
Fix: gender, historicity of stoned monster statue
The way statues of stoned unique monsters were marked as "historic" was
not changed when mkcorpstat flags were updated in 04a8ddc, resulting in
unique statues which were no longer marked as historic and were instead
marked as female.
While fixing that, also use the gender-related mkcorpstat flags to
assign the gender of a stoned monster to the resulting statue.
PatR [Thu, 16 Dec 2021 23:56:52 +0000 (15:56 -0800)]
more reformatting - label placement
Indent all labels one space. Having uniform placement makes spotting
them much easier. (Having no indent at all would impact the change
bars of 'git diff'. Those display the last unindented line--which
doesn't start with punctuation--occuring before each band of changes,
so usually the name of the function being changed now that we no
longer have unindented K&R-style function argument declarations.)
While in there, shorten or split various wide lines and replace a few
tabs with spaces.
PatR [Thu, 16 Dec 2021 02:39:29 +0000 (18:39 -0800)]
date.c vs MONITOR_HEAP
I tried building with MONITOR_HEAP defined for the first time in a
while. It wasn't pretty.
date.c was calling libc's strdup() instead of our dupstr() so alloc.c
wasn't tracking those allocations when/if MONITOR_HEAP is enabled.
Then it called free() which is actually a call to nhfree() in that
situation. If the file of allocations and releases was subsequently
fed to heaputil, it would complain about freeing pointers that hadn't
been allocated.
Worse, makedefs and tilemap wouldn't link. For MONITOR_HEAP,
makedefs was undefining free() in order to avoid nhfree() but it now
links with date.o so got nhfree() calls anyway. And it wouldn't link
because that routine isn't available without alloc.o. tilemap
doesn't link with date.o but it does call malloc() and free() and it
wasn't undefining free(), so looked for nhfree() when linking and got
the same no-such-routine failure.
PatR [Thu, 16 Dec 2021 00:45:52 +0000 (16:45 -0800)]
refine #wizrumorscheck
If #wizrumorscheck isn't able to open or read the rumors file,
continue on to check engravings, epitaphs, and bogusmons instead of
immediately returning.
PatR [Wed, 15 Dec 2021 01:15:17 +0000 (17:15 -0800)]
remove duplicate novel titles
For novel title lookups, have the variant spelling substitutions use
the entries from array of titles instead of explicit strings which
duplicate those.
PatR [Tue, 14 Dec 2021 15:43:40 +0000 (07:43 -0800)]
some reformatting
Replace some
(foo &&
bar)
that had crept back into the code with
(foo
&& bar)
to match the reformatting which took place before 3.6.0. There are a
couple of lines ending in '||' still present but they look intentional.
isaac64.c has some trailing '|' bit operators that could/should be
moved to the start of the next line but I didn't touch that file.
While in the affected files, I tried to shorten most overly wide lines
(the right margin is supposed to at column 78 and there are quite a
few lines which are 79 characters long, but I left most of those
rather than introduce new line splits). Also replace a handful of
tabs with spaces. I was a little surprised not find any trailing
spaces (in the dozen or so files being updated). I didn't look for
trailing arithmetic or '?'/':' operators which aught to be moved to
the start of the next line.
PatR [Tue, 14 Dec 2021 10:38:17 +0000 (02:38 -0800)]
insufficient spell power feedback
If attempting to cast a spell without having enough power, you get
|You don't have enough energy to cast that spell.
Recently that was augmented to
|You don't have enough energy to cast that spell yet.
if your current power is at maximum and not enough. Augment again to
|You don't have enough energy to cast that spell anymore.
if current power is at maximum and that maximum is less than the peak
value it once had and that peak value would have been enough.
PatR [Mon, 13 Dec 2021 15:04:30 +0000 (07:04 -0800)]
glob update
Initialize glob weight sooner in mksobj() and have weight() skip the
fix up it had been doing when it was passed a glob with weight 0.
This allows shrink_glob() to be simplified slightly in the situation
where a glob inside a container shrinks away to nothing.
weight(glob) with glob->owt==0 now yields 0 instead of 20. That was
only needed for 'obj->owt=weight(obj)' during object creation and
the new earlier weight init makes the 0 to 20 fixup obsolete. In
turn, that allows a glob which has shrunk to 0 while in a container
to not have to be removed before updating the container's weight.
PatR [Mon, 13 Dec 2021 13:07:30 +0000 (05:07 -0800)]
pickup.c bits
This started out as just some minor reformatting but ended up including
a couple of new comments and a revision in how the use_container()
decides whether it is feasible to put something into the container.
Behavior isn't changing.
PatR [Sun, 12 Dec 2021 19:32:09 +0000 (11:32 -0800)]
attrcurse() on 'see invisible'
If hero has intrinsic see-invisible and a gremlin steals that, the
map wasn't being updated to hide invisible monsters (until the next
iteration of moveloop() after other monsters finished current turn).
Pasi Kallinen [Mon, 6 Dec 2021 22:06:17 +0000 (00:06 +0200)]
Accessibility: give a message when teleporting a monster
Teleporting a monster only updated the map. Give a message
so blind players can get the same information.
Making a monster invisible gives the same message, if you
cannot detect invisible.
Several other places where monsters teleported themselves
now also give the same message.
PatR [Sat, 11 Dec 2021 04:16:30 +0000 (20:16 -0800)]
shrink_glob bug when when glob is totally gone
When a wielded glob shrank away to nothing, an impossible warning:
"obfree: deleting worn obj" would be issued.
If a glob is quivered or wielded or set up as swap weapon when it
shrinks away to nothing, clear the relevant weapon slot before
destroying the glob.
Won't happen for monsters since they never wield globs. Also won't
happen for migrating objects (which overload obj->owornmask) because
they have to have arrived somewhere in order to have their shrink
timer execute.
PatR [Thu, 9 Dec 2021 00:08:57 +0000 (16:08 -0800)]
wizard mode polyself to "priest"
When polymorphing while already polymorphed, picking your own role
will rehumanize (wizard mode only; restores old characteristics and
experience level, unlike becoming a new man which can change those
and even be fatal if level drops below 1). But it didn't work if
you were a priest or priestess because name_to_mon() yields aligned
cleric monster rather than cleric role.
PatR [Wed, 8 Dec 2021 23:31:06 +0000 (15:31 -0800)]
shape change while strangling
Polymorphing into a vulnerable form while wearing an amulet of
strangulation says "your amulet still constricts your neck" if your
previous form was also vulnerable or "your amulet beings constricting
your neck" if previous form wasn't vulnerable. But a change nearly
6 years ago to have the status line be updated to say "Strangling"
during the message--instead of next status update after it--caused
the "still constricts" variation to always be given even when the
"begins constricting" was appropriate.
PatR [Tue, 7 Dec 2021 23:54:46 +0000 (15:54 -0800)]
long worm growth again
The previous change could have resulted in a long worm losing HP when
gaining a segment (if it had gained levels while at the peak amount
for the previous number of segments). I think this is finally right.
PatR [Sun, 5 Dec 2021 23:09:08 +0000 (15:09 -0800)]
misuse of hero_glyph
It isn't just the hero's normal glyph, it gets adjusted when poly'd.
So the way I tried to use it didn't work as intended. Explicitly
check Upolyd separately so that hero_glyph won't be affected by tat
and only returns the player monster or race monster value.
PatR [Sun, 5 Dec 2021 01:18:00 +0000 (17:18 -0800)]
showrace again...
I'm fairly sure that the 'showrace' and PC rogue cases are covered
correctly now despite the approximation in deciding whether the
specified glyph represents the hero. However, I'm not sure how the
accessibility handling ought to work when the hero is not in normal
form. Right now it kicks in if the glyph is any monster, so the
hero is visible as a monster (whether normal or poly'd or on steed).
It does not kick it when mimicking an object (after eating a mimic
corpse or being poly'd into a mimic and then hiding) or furniture
(only if poly'd into mimic) because execution won't make it into the
is_you block in that situation. Same situation applies to setting
the MG_HERO flag bit, but that doesn't seem to be used anywhere.
nhmall [Sat, 4 Dec 2021 20:59:30 +0000 (15:59 -0500)]
rogue symset issues following expanded glyphs
Contributed by entrez
Also, remove the iflags.use_color test from the many if-statements
in reset_glyphmap(), and test and/or override it once before
the assignment to gmap->color.
PatR [Sat, 4 Dec 2021 13:19:45 +0000 (05:19 -0800)]
tracking peak maximum HP and energy
Keep track of the highest value that u.uhpmax and u.uenmax have
attained, in new u.uhppeak and u.uenpeak. They aren't used for
anything yet. u.mhmax (max HP while polymorphed) isn't interesting
enough to track.
Not save and bones compatible so increments EDITLEVEL.
This supersedes pull request #644 by entrez, "Fix: expanded-glyphs
hero color regression". The code to change color for the hero in
special circumstances (for 'showrace' and for some PC rogue stuff)
was relying on the hero's map coordinates rather than verifying
that the hero was shown at that spot. When the hero is invisible
and lacks see invisible, he isn't shown. But the color of whatever
could be seen beneath him was incorrectly having its color changed
(to HI_DOMESTIC for showrace or to YELLOW for PC rogue).
PatR [Fri, 3 Dec 2021 12:34:08 +0000 (04:34 -0800)]
bullwhip inconsistencies
Reported by entrez: applying a bullwhip towards a medium or small
peaceful monster used to be an attack but that stopped working when
'safepet' was extended to peacefuls in order for the hero to be able
to swap places which those. Also, side-effects were different when
hero applied the whip from within a pit compared to when not in one.
This allows the hero trapped in a pit to try to snag furniture or a
boulder even when a small or medium is present, and escaping that
pit if successful. (It still snags big monsters in preference to
furniture/boulder at their location.) When no such non-monster
target is available, it attacks the monster if hostile or peaceful
but not when tame. When revealing a previously unseen monster it
prevents snagging that monster's wielded weapon because hero couldn't
possibly target the weapon in that situation.
This makes other changes, mostly dealing with finding and exposing
concealed monsters, which may introduce some new bugs.
Since I was already in the right place, implement snagging an item
off the floor while flying. It isn't necessary since a flyer can
pick things up off the floor directly, but there isn't any pressing
reason to disallow it. Supersedes the commit in pull request #632
by RojjaCebolla.
PatR [Fri, 3 Dec 2021 02:53:34 +0000 (18:53 -0800)]
feedback for spell cast failure due to energy
If the hero is at full energy but still lacks enough to cast a chosen
spell, say "you don't have enough energy yet" instead of just "you
don't have enough energy."
PatR [Thu, 2 Dec 2021 02:49:48 +0000 (18:49 -0800)]
fixes entry for pull request #642 - shk name vs it
3.6.1 changed a bunch of messages in shk.c to give the actual shk
name even when a the shopkeeper couldn't be seen, to avoid things
like "You owe It <N zorkmids> for <item>." But there are various
messages issued outside of shk.c which were overlooked. Fix those.
Michael Meyer [Wed, 1 Dec 2021 14:31:31 +0000 (09:31 -0500)]
Fix: 'you owe It for goods lost'
Some messages about owing a shopkeeper money would use 'it' when blind,
with weird results such as "You owe It 267 zorkmids for goods lost." It
seems maybe like these were missed in 6591f8b since they were outside of
shk.c/shknam.c. Bring those messages into alignment with most other
shopkeeper-related messages, which use the shopkeeper's name even if the
hero is blind or can't see them at the moment.
Some of the 'it gets angry' ones don't seem so bad, but similar 'gets
angry' messages in shk.c use Shknam so I changed those as well for
consistency's sake.
PatR [Thu, 2 Dec 2021 01:05:27 +0000 (17:05 -0800)]
yet another shrink_glob fix...
When catching up for lost time spent on another level, globs inside
containers that shrank away to nothing didn't need to have those
containers' weight explicitly adjusted because obj_extract_self()
does that, so yesterday I removed the unneeded container_weight()
call. However, ones that shrank only partially did need to have
their containers' weights adjusted and that wasn't being done.
The weight would be brought up to date within 25 or so turns when
the contained glob's next shrink_glob event took place. Until then
attempting to pick up the container by hero or monster, or to pick
up something else by a monster already carrying it, could have been
impacted by the weight discrepancy.
PatR [Tue, 30 Nov 2021 22:04:00 +0000 (14:04 -0800)]
miscellaneous tweaks
Simplify a glob handling bit in a recent shrink_glob change used when
catching for lost time upon returning to a level.
Revise a clumsily worded fixes entry.
Fix a comment typo in makedefs that's been there for a bunch of years
now. It's been within the diff context for several recent patches
and I still hadn't noticed it until just now.
PatR [Tue, 30 Nov 2021 21:01:17 +0000 (13:01 -0800)]
fixes entry for pull request #640 - zoo monsters
Populating some of the types of special rooms can pick monsters that
sometimes come in groups, and getting a group could have some members
spill out of the room (or inhibit other random choices by filling some
spots that haven't been populated yet, preventing subsequent monster
creation there).
The misbehavior isn't new so it seems surprising that no one has ever
previously reported this.
Michael Meyer [Tue, 30 Nov 2021 18:45:09 +0000 (13:45 -0500)]
Fix: zoo monsters spawning in hallways
If a random G_[SL]GROUP monster was generated in a zoo, the resulting
group of monsters could spill out into nearby hallways and other
surrounding areas. Disregard G_GROUP flags when filling a zoo with
monsters to avoid this problem.
PatR [Tue, 30 Nov 2021 11:28:10 +0000 (03:28 -0800)]
CapMons[] entries for hallucinatory monster names
Simplify the handling of capitalized hallucinatory monster names
which should be described as "the Bogon" rather than just "Bogon".
Instead of inserting an ESC character to indicate "this entry
should be freed when done", keep track of how many of the entries
come from mons[] (which always come first and shouldn't be freed)
and just free the rest. So one instance of inserting an ESC and a
couple of skipping it when present and one of testing for it when
freeing are removed.
Also, the check for bogusmons classification code was testing
whether the name started with a letter (or with '@', an obscure
special case for letter()) rather than for the actual type codes
used in dat/bogusmons.txt. If '@' becomes used as a classification
code (so far it isn't one) any entries using it could have been
misclassified and would be misspelled because it would stay as the
first character. And existing entry "/r/tard" was also subject to
misclassification, but since it doesn't start with a capital letter
either with or without leading '/' that had no noticeable effect.
If the leading slash was followed by a capital letter there would
have been a different sort of misspelling with that slash missing
in the copy kept in CapMons[]. I knew all that when I first used
letter() but have decided that it is better to extract 'bogon_types'
from bogusmon() in order for the handling to be more consistent.
PatR [Mon, 29 Nov 2021 14:04:44 +0000 (06:04 -0800)]
rumors again...
The code to provide even distribution for rumors was being successfully
used for engravings, epitaphs, and hallucinatory monster names but not
actually for rumors themselves. Move it into its own routine and have
both the three miscellaneous things and rumors use that.
My testing has verified that asking for a true rumor can produce the
first and last true rumors and not either of the first or last false
rumors, and vice versa when asking for a false rumor. Asking for
unspecified true/false can produce all four of those. Aside from that
verification of correctness (I hope...), I haven't checked that the
distribution when selecting is actually even.
PatR [Sat, 27 Nov 2021 20:23:01 +0000 (12:23 -0800)]
get_rnd_text() for rumors and other stuff
Solve the uneven distribution situation that has been present for
picking random rumors for a long time and for random engravings,
epitaphs, and hallucinatory monster names since 3.6.0. This relies
on the previous partial solution where short lines have been padded
to a longer length. When that length is N and random seek lands in
a long line of length L, retry if the position is in the first L-N
characters. Put differently, it if takes more than N characters to
reach the next newline, reject that random seek and try again. This
effectively makes long lines behave as if they had the same length
of N as the short lines have been padded to and when all lines are
the same length, all entries have the same chance to be chosen.
PatR [Sat, 27 Nov 2021 05:56:58 +0000 (21:56 -0800)]
SOUND=foo vs !defined(USER_SOUNDS)
Give a better message than "Unknown config statement" if SOUNDDIR or
SOUND directives are found in the configuration file being loaded by
an executable built without support for USER_SOUNDS. And just give
it for the first occurrence since when present there will likely be
multiple SOUND instances.
It doesn't attempt to deal with the case where the current interface
does not support sound but USER_SOUNDS is enabled because another
interface in the same executable does.
PatR [Sat, 27 Nov 2021 05:52:38 +0000 (21:52 -0800)]
format issues
Fix a couple of things that prototyping pline() with FORMAT_F(1,2)
pointed out. The mkobj.c one looks familiar; I thought it had
already been fixed. Maybe it matches a pull request that hasn't
been incorporated yet.
PatR [Sat, 27 Nov 2021 05:50:44 +0000 (21:50 -0800)]
compile-time format checking
We've had a few pull requests fixing format/argument mismatches
lately. I did't notice when PRINTF_F(format_index,first_arg_index)
attribute use and the checking gcc and clang do with it got removed,
but that was very useful. Putting it back triggers a whole bunch
of "format string is not literal" warnings, but that's because
'-Wformat-nonliteral' was explicitly added to the *.2020 hints.
Checking pline/You/&c arguments in the cases where the format is a
literal is more valuable than the complaints for sprintf being fed
a generated format, so reinstate PRINTF_F usage and turn off the
check for non-literal format strings.
PatR [Fri, 26 Nov 2021 07:50:11 +0000 (23:50 -0800)]
unpadding capitalized hallucinatory monster names
Two semi-related patches within the span of less than three days and
I overlooked the overlap. When the() deals with a capitalized string,
it calls CapitalMon() to check whether the string matches a monster
and if so whether usage should be "the Monster" (Oracle or Olog-hai
for example) or just "Monster" (Medusa). The first time that gets
called, it collects all capitalized non-the Monsters from both mons[]
and the bogusmon file. The latter just got changed to pad short
lines, and that works fine for selecting hallucinatory monsters at
random via get_rnd_text(), but non-the Monster collection processes
the bogusmon file directly and wasn't updated to strip the padding.
PatR [Fri, 26 Nov 2021 01:57:37 +0000 (17:57 -0800)]
get_rnd_text() selection distribution
While testing 'the("Capitalized Hallucinatory Monster")' I noticed that
some hallucinatory monsters showed up more often than others. When
the random engravings, epitaphs, and bogus monsters were converted from
hard-coded arrays to data files accessed by random seek (3.6.0), they
became subject to the same distribution irregularites that rumors suffer
from. The chance that an entry will be chosen depends upon the chance
that a random seek will hit somewhere in the line which precedes it, so
entries that follow long lines are more likely to be chosen and entries
that follow short lines are less likely. We improved that for rumors
by having makedefs pad the shortest lines. Distribution still isn't
uniform but is much better than it was (and could be further improved
with a longer padding length at the cost of making data files bigger so
possibly slower to access; both overall size and access speed mattered
back when floppy discs were supported but are probably irrelevant now).
Start doing the same thing for the newer files: pad the shortest lines
to increase the chance that seek will find them. The tradeoff is that
the data files become bigger. Rumors, engravings, and epitaphs lines
are all at least 60 characters now; bogus monsters are at least 20.
These are the data file sizes I see (in bytes: old, new; padding for
rumors was already in use so its size hasn't changed):
bogusmon 4449 7211
engrave 1326 2894
epitaph 14159 24075
rumors 49173 49173
The only place that padding is noticeable in-game is #wizrumorcheck.