It was possible to toggle ascii_map On (which toggles tiled_map Off)
and Off (so tiled_map On) during play, but tiled_map was marked as
config-file only so the converse pair of operations weren't allowed.
Allow tiled_map to be toggled On or Off during play.
When USE_TILES is disabled, don't let wc_tiled_map be the default.
Qt is capable of showing an (ugly) ascii map, and will do so if built
with NO_TILE_C after this fix (it defaults to tiles without this),
but it requires that a tiles file be loaded because it displays tiles
in other places besides the map, like role selection. So it can't
skip them when wc_ascii_map is set.
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.
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.
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.
'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.
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.
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.
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.
Dragon scales and dragon scale mails will provide some extra effects
when worn:
- blue: very fast speed
- black: level-drain resistance
- green: sickness resistance
- gold: hallucination resistance
- orange: free action
- red: infravision
- white: slow digestion
- yellow: stoning resistance
gray and silver don't have extra effects - those two are already the
best ones, so don't need any.
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.
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'.
If you have a function named like that, and it goes and
changes the monster state, that's just wrong.
Move waking up the monster from the hit into separate function.
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.
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.
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.
Closes#632
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.
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.
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.
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.
Function the() wasn't supposed to be used for monsters because many
of the ones with capitalized names confuse it, but over time multiple
instances of the(mon_nam()) have crept into the code. Instead of
ripping those out, modify the() to handle that situation better.
Pull request #636 by entrez dealt with this with one extra line of
code, but could end up scanning all the names in mons[] repeatedly
if the("Capitalized string") gets called a lot. This uses a similar
one line fix but calls a whole new routine that scans through mons[]
once collecting all the relevant special case names. As a bonus,
it does the same for hallucinatory monster names which name_to_mon()
couldn't handle.
Fixes#626
Incorporate the functionality of the loadable DLL's (nhraykey.dll,
nhdefkey.dll, and nh340key.dll) into the consoletty.c code and
remove the dll building
Globs never rotted away but did become tainted after a relatively
short while, which seemed like a contradiction. Change them to never
be tainted but shrink by 1 unit of weight approximately every 25
turns. An ordinary glob (one that hasn't combined with any others)
starts out weighing 20 units, so it takes about 500 turns to vanish.
That's roughly twice as long as a corpse takes to rot away.
Shrinking globs give feedback when in hero's invent or in a container
in hero's inventory, but rarely (when going from an exact multiple
of 20 weight units; that is, from integral number of N globs to
N-1 + 19/20, or if weight reduction triggers an encumbrance change).
When a glob goes away completely, there is feedback for those two
circumstances and also for seeing the glob vanish from the floor.
I haven't touched how much nutrition eating a glob confers. I have
changed formatting of glob names to use "small", "medium", "large",
"very large" instead of "small", [no adjective], "large", &c. You
still need to have at least five globs coalesced together for the
adjective to become "medium", same amount as before.
I don't think EDITLEVEL needs to be modified but have incremented it
anyway to play things safe.
I thought there were more places that checked for "it" and substituted
"someone" or "something". Perhaps there are and I'm just not finding
them now. Anyway, this extends x_monnam() and adds some_mon_nam() and
Some_Monnam() to do that during monster name formatting instead of
having various bits of code try fix it up after the fact. The fixups
could be fooled by monsters given the name "it" or "It"; x_monnam()
won't be.
Reported by eakaye. Selection of equipment when creating a soldier
or watchperson can pick a polearm, but random selection among those
had a chance to choose dwarvish mattock which doesn't use polearms
skill and isn't appropriate for a human soldier or watchperson.
Not mentioned, but lance was in the same boat.
Change the selection to only pick something which uses polearms
skill, then make that moot by moving lance and dwarvish mattock out
of the midst of the polearms so that they're no longer candidates
for special case rejection.
A couple of other things which might have had a similar issue were
already ok. Giving a polearm when creating a troll selects between
a few choices rather than among all the polearms. And wishing for
"polearm" only considers items which use polearms skill.
While changing objects.h to reorder the two non-polearms, I removed
a bunch of tabs that were present in the scroll definitions.
EDITLEVEL is incremented due to objects[] reordering, so existing
save and bones files will be invalidated.
Fixes#623
Reported by entrez, wielding something fragile (potion of acid
perhaps), and using F to smash it against iron bars called breaktest()
directly, then a second time indirectly through hero_breaks() via
hit_bars(). There is a random chance to resist breaking (99% for
artifacts, 1% for other items) so breaktest() might say that something
will break on the first call and that it will not break on the second
call, or vice versa. That could remove uwep from inventory then leave
it in limbo without destroying it, or destroy uwep without removing it
from inventory first triggering impossible "obfree: deleting worn obj".
whitelist the valid cases showing up
If an earlier version of clang is showing more cases (particularly
if they don't make sense), the re-enabling of the warning in
sys/unix/hints/include/compiler.2020 can be made clang-version
specific instead. I had no way to test earlier versions.
On 59818fb, MAX_RADIUS was changed from 15 to 16 to intend to support
"radius 0". But MAX_RADIUS doesn't means the range but outer bound of
the radius table, so it should not be changed, and this change led
possible out-of-bound access on view_from() and do_clear_area() in
vision.c.
This commit reverts the change and avoids the problem.
Reported directly to devteam by entrez via email:
>
> I noticed some potential issues with (melting) ice:
>
> * Digging down into ice, or setting a land mine on the ice and
> triggering it, doesn't remove the melt_ice timeout, so it can result
> in a sequence like dig down -> pit fills with water -> freeze water
> -> freezing water tries to set melt_ice timeout -> duplicate timeout
> impossible. Or if you don't freeze the water again, melt_ice will
> run on a non-ice surface, which might at least produce strange
> messages.
>
> * Setting a land mine on ice: melting ice doesn't do anything with
> the trap, so there is still a land mine which you can trigger by
> flying over the water (the land mine's trigger is also still
> described as being 'in a pile of soil', despite being underwater at
> this point). Similar thing happens with bear traps.
>
> * Not really related to _melting_ ice, but an exploding land mine
> doesn't reset the typ from ICE to FLOOR (like normal digging does),
> so it will result in a square with a pit that is also an ice square,
> where the ice can melt under the pit and produce a combination
> pit/moat. If you then freeze the moat, the pit reappears on top of
> the ice.
Fix the vault repair issue that could lead to "wall_angle: unknown"
warning. Unlike shop repair, the original wall info isn't available
so this recreates it. The extra 'flags' field added yesterday could
be eliminated but this leaves it in place.
Fixes#606
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
When you push a pile of boulders, describe the second and remainder
as "the next boulder" rather than just "the boulder". Matters most
when pushing into water or lava and you keep on pushing when the
first one or more sink into the pool or plug it, but also matters
for an ordinary push where the top-most one moves successfully and
then blocks the continuation attempt to push the second one. It was
somewhat confusing when all the messages said "the boulder" whether
they were referring to the same boulder or different ones.
Multiple pushes on the same move has always been a bit odd, but this
doesn't change that, just the feedback it generates.
Get rid of the last reference to 'g.restoring' (which managed to
unintentionally survive the change to 'g.program_state.restoring').
Also have suppress_map_output() check 'g.program_state.saving' and
switch the couple of checks against that flag to use the function.
Eliminate a couple of compile warnings produced when DEF_PAGER is
defined: unixmain.c: g.catmore=DEF_PAGER; wintty.c: fd=open(...).
Override its use when DLB is also defined since an external pager
could access 'license' but not 'history', 'opthelp', &c when those
are in the dlb container file.
In the commented out value for DEF_PAGER, show a viable value for
the default configuration these days.
