Issue reported by Umbire: suggestion to always destroy adjacent webs
via 'F'<dir> if wielding Sting or Fire Brand.
Sting already did that; this adds Fire Brand.
This also augments the #untrap command when wielding either of those,
or any other blade. And rephrases successful untrap message
"You remove {the or your} {bear trap or webbing} from Fido." to
"You extract Fido from {the or your} {bear trap or web}." since the
trap remains intact.
Forcefight and #untrap against webs ought to be reconciled to remove
[some of] their differences and/or share code. But not by me...
Closes#1201
Avoid two new warnings in xname_flags() about strncpy() not supplying
a terminating '\0'. That's exactly why strncpy() was being used.
The gcc manual lists -Wno-stringop-truncation to suppress the warning
but not -Wstringup-truncation to voluntarily enable it, so the pragma
stuff in warnings.h probably won't work for this. Just switch from
strncpy() to memcpy() instead even though it seems like obfuscation.
u_init.c had had assessments for nonnull arguments on
its local functions carried out already.
A couple of new static functions added earlier today immediately
dereference their args, so declare those as nonnull.
This also gives a more self-describing name to one arg.
PR #1140 added checking the thrown, stolen, and dropped flags of an
item when testing whether it would merge (at my suggestion...) with
a stack in the target list (hero's invent). That interferred with
picking it back up--whether via autopickup or explicit pickup--while
inventory was full even when the item would otherwise be mergable.
There was some trial and error involved when trying to figure where
to put the fix but things seem to be working.
This replaces a static analyzer workaround and could possibly bring
its unwarranted complaint back.
Try harder to prevent buffer overflow when formatting objects.
I don't have any test cases where overflow has been happening so
don't really know whether this works reliably. And it doesn't try
to check prefix construction by doname(). [Yet?]
"blue potion" wasn't a very good example for an item in a container;
plain "blue" isn't a potion description.
Add an extra sentence to make the association between a container's
"item count" that's really a stack count and the fact that inventory
slots are for stacks rather than for individual items too.
Style/usage bit: avoid using "another" twice in the same sentence.
Fix a typo in the spelling of "contents".
Run GC on the themeroom lua states, as they're not freed
until end of game.
Allocate the exact amount of data we use instead of padding it.
Free our state data after closing the lua state; doing it
the other way is the way to madness, which was kept at bay
by the padded allocation amount.
Have monster spells
| "shower of missiles" (AT_MAGC+AD_MAGM: Angels, Yeenoghu)
scuff an engraving at the hero's spot if there is one,
| "frost" (AT_MAGC+AD_COLD: only Asmodeus)
freeze water and lava terrain,
| "flames" (AT_MAGC+AD_FIRE: moot, no monster has this attack)
burn items on the floor at the hero's spot and melt ice terrain,
| "pillar of flame" (AT_MAGC+AD_CLRC+randomly chosen clerical spell)
which already burns floor items, melt ice too, and
| "lightning" (same casters as pillar of flame)
give a tiny chance of destroying iron bars. The chance to hit bars
is low and the hero has to be targeted while located on an iron bars
spot so probably won't happen before the sun burns out, but only
needed one extra line of code.
Only the first two have been thoroughly tested.
If a covetous monster tried to teleport adjacent to the hero but the
level was too full to move it from its current spot, it would be
sent off level to wait for the hero to leave and return instead just
staying put.
Issue reported by chappg: if a monster or object covered an engraving,
examining that monster or object with farlook would include the text
of the engraving even though it wasn't the thing being examined.
The report was for a bones level but that only mattered because it was
a ghost on top of a grave (and the engraving on its headstone) that was
being examined; bones data itself wasn't pertinent. It would happen
with any engraving once the spot was mapped as an engraving or a grave
provided that something else was currently displayed at the location.
Bug was introduced by commit 389f03e90e
two months ago. Mea culpa.
Closes#1200
Hero attempting to cut an adjacent web can so with secondary weapon
if dual wielding and primary isn't a blade.
Mostly message handling for the 'neither weapon is a blade' situation.
Adds a new boolean option, spot_monsters. If on, every time
the hero notices a monster which was out of sight before,
a message is given. Combine with accessiblemsg to get the
monster location:
(3north): You see a newt.
Breaks saves and bones.
Change MON(name, ...) to MON(NAM(name), ...) and get rid of MON3(),
replacing it with MON(NAMS(malename,femalename,neutername), ...).
That eliminates the macro which uses 16 parameters. Standard C
allows compilers to impose a limit of 15, rejecting 16 or more while
still being in compliance.
That necessitated some reformatting since it made the first line of
each entry longer. Shorten that by having all entries start with
name(s) and symbol on the first line, then LVL() and generation flags
on the second line, then attacks start on the third.
Reformat attacks to change ATTK(one) + 4 * NO_ATTK on one line plus
an orphaned NO_ATTK on the next line to always use ATTK(one) on first
line and all 5 NO_ATTKs on the next line. Similarly, change ATTK(1of2)
ATTK(2of2) NO_ATTK on one line followed by 3 * NO_ATTK on the next line
into ATTK(1of2) ATTK(2of2) followed by 4 NO_ATTKS. For three attacks,
list two on the first line then the third and 3 * NO_ATTK on the next.
Four or more attacks use a third line; ATTK(1of4+) ATTK(2of4+) on the
first, ATTK(3of4+) ATTK(4of4+) on the second, and whatever's left on
the third. SIZ() follows on its own line for each of the cases.
Split the final line of each entry so that the difficulty value is the
first thing on that line, followed by color and enum tag. This may or
may not make moving the difficulty into LVL() easier someday (which
would have been an alternate way to reduce the 16 args that MON3 had).
The file gets stretched out by many lines but entries should be easier
to read (matter of taste, I suppose).
I didn't attempt to clean up M1_foo, M2_bar, M3_quux; too hard....
I also didn't touch SIZ() or resistances which are less cluttered than
the other stuff.
