When dual-wielding and you wield a different weapon, two weapon combat
was silently toggled off even when the new weapon was eligible to be
dual-wielded. If the verbose flag is On, explicitly tell the player
when wielding something toggles off two-weapon mode. Wielding '-' is
an exception because you already get told that you're empty handed.
Reject arrows and darts as candidates for wielding two weapons at
once.
Make the check for being able to two-weapon when polymorphed be more
robust. Instead of just testing whether the monster form's second
atttack is a weapon attack and then assuming that the first one is
too, test the first three to validate that at least two of those are
AT_WEAP. The existing code works but seemed fragile.
Don't allow dual-wielding if either wielded or alternate weapon
(or both) is a launcher: bow, crossbow, or sling. (I thought that
this had been addressed ages ago.)
Refine the "can't twoweapon" feedback. The message for having
either or both hands empty is the same, but sentence construction
is different. The not-a-weapon feedback is slightly different, now
mentioning whether it's the wielded or alternate weapon which isn't
allowed. The case where neither are acceptable still just reports
uwep; mentioning both it and uswapwep would be too verbose.
Make more things be described as "(wielded)" instead of "(weapon in
hand)". It was just stacks with quantity more than 1. That's now
joined by ammo and missiles (any stack size, but in reality just 1
since greater was already being caught here) and any quantity of
non-weapon, non-weptool. It's overridden if dual-wielding so that
right/left stay matched.
When dual-wielding, list primary as "(wielded in right hand)" and
secondary as "(wielded in left hand)" instead of "(weapon in hand)"
and "(wielded in other hand)". The vaguer wording was better for
bows since they're held in the off hand but now that they can't be
dual-wielded that doesn't matter. (Single-wielding a bow is still
"(weapon in hand)".)
When not dual-wielding, the item in the alternate weapon slot is
still described as "(alternate weapon; not wielded)" even if it's
not actually a weapon. I couldn't think of better phrasing.
There was a concern that some things resulted in "is not a weapon"
when trying to twoweapon, then were subsequently refered to in
menus as "weapon in hand."
Remove any perceived inconsistency by simply adjusting the first
message.
After the "make 'w' parallel with 'Q'" patch, wielding bare hands
was erroneously treating object id 0 as a split of zeroobj. That
isn't in inventory so seems 'lost'. Fixed by testing for nonzero.
There was another bug: you could wield a partial stack even if your
current weapon was cursed. Fixed by reordering if/else-if/end-if.
If you're wielding a stack of N items, issuing the command to quiver
them asks whether you want to quiver N-1 of them (implicitly leaving
one wielded). If you answer no then you're asked whether to quiver
all of them. You could also give a count when picking the item to be
quivered and the stack would be split based on that.
However, if you have a stack of N items quivered, issuing the command
to wield them just did so, leaving the quiver empty. And picking an
item ignored any count, so even explicitly asking for 1 (out of N)
wielded the whole stack. Change 'w' to parallel 'Q'; if you try to
wield a quivered stack, you'll be asked whether to wield just 1 of
them. For no, ask whether to wield the whole stack. Or you can give
an explicit count when picking any stack in inventory to wield.
Both 'w' and 'Q' probably ought to handle the alternate/secondary
weapon similarly when it contains a stack. This doesn't address that.
Changing an inventory item's bknown flag wasn't followed by a call to
update_inventory() in many circumstances, so information which should
have appeared wasn't showing up until some other event triggered an
update.
Applying a non-wielded cursed pick-axe first wielded it, then dug,
but it didn't report "pick-axe is welded to your hand". (Attempting
to drop it or wield something else did report that, after the fact.)
The same thing happened if you used a pole-arm rather than pick-axe.
Redo how updates of permanent inventory window are suppressed during
restore. Reverses part of e9f1e03271
which included a simpler attempt to deal with this.
It looks like we should have been getting impossible "unpaid_cost:
object wasn't on any bill" but segfault was reported; I haven't tried
to figure out why. The band in xname() ought to be redundant now but
is included for bulletproofing.
I think this finally quashes the "cursed without otmp" issue.
Various ways of destroying wielded weapon used setnotworn() rather
than unwield(), so the previous change to have unwield() clear the
pending W_WEP bit from takeoff.mask wasn't sufficient to prevent
'A' moving on from another item (blindfold--it's the only thing
processed before primary weapon) to weapon which wasn't there any
more. Also, if weapon was already set in takeoff.what to be
processed on the next move, clearing W_WEP from takeoff.mask wasn't
sufficient either.
Move the previous unwield() 'fix' to setworn() and setnotworn() and
extend it to include cancel_don() if the item being replaced or
removed is in progress or scheduled for next. (Most of the time,
remove_worn_item() has already done that before setworn() or
setnotworn() is called.)
The do_wear.c part just eliminates some redundant code but shouldn't
produce any change in behavior.
The steal.c part should fix problems with 'A' when outer items are
taken off during theft in order to steal an inner item, where the
outer item is next to be removed (call to cancel_don() wasn't being
made). The wield.c part matches the X_off() behavior and is needed
to handle a weapon item that's slated for removal but isn't next (so
wouldn't pass the donning()/doffing() test to trigger cancel_don()).
If this seems a lot like trial and error, it is....
"Your pair of speed boots glow silver for a moment." should be
"Your pair of speed boots glows silver for a moment.". The fix
reverses a post-3.6.0 change to is_plural(). Also, add new
pair_of() to test for object formatted as "pair of Bars". For verb
usage, that's definitely singular, but for pronoun usage, sometimes
plural seems better (although it might actually be incorrect).
I fixed up the formatting of a block comment in obj.h, but it is
still a candidate for tab cleanup.
This ended up being more elaborate than I anticipated. 'Q' will
now accept the wielded weapon as a choice of item to quiver. If
that item is a stack of more than one, it will offer to split N-1
into the quiver and leave 1 wielded. If the offer is declined, or
if there is already just 1, it will require confirmation to move the
item from the weapon slot to the quiver slot. The alternate weapon
is handled similarly, with different phrasing when in twoweapon
combat mode.
Just to be crystal clear: a single object cannot be in more than
one weapon, alt-weapon, or quiver slot at the same time. 'Q's old
behavior of rejecting the wielded weapon was to avoid accidentally
becoming empty-handed, not anything to do with multiple worn/wield
slots.
'Q' will also accept a count when picking an inventory item, then
put 'count'-many into the quiver, leaving N-count in original stack.
Except when the chosen item is already in the quiver; it that case,
it undoes the stack split and leaves things as they were. (That
restriction may not have been necessary but I'm not planning to
revisit it....)
Reading a non-cursed scroll of enchant weapon has a side-effect of
uncursing a weapon welded to hand(s). Make it do the same thing for
cursed tin opener, the only non-weapon/non-weptool that welds to hand.
The automated reformatting put a space in casts of the form
'(type)(expression)', yielding '(type) (expression)', but it didn't
do that for '(typedef)(expression)'. There are lots of instances of
'(boolean)(expression)'; (uchar) and (xchar) also occur. I haven't
noticed other types, but I haven't looked in very many files yet.
Flesh out wet towels a bit:
1) wielding a wet towel--or a dry one which becomes wet--won't give a
"you begin bashing with your wet towel" message when attacking;
2) if a formerly wet towel dries out completely while wielded, *do* give
"you begin bashing with your towel" on the next attack;
3) successfully hitting with a wet towel no longer always loses wetness;
4) water damage to dry towel always confers at least 1 point of wetness;
5) taking fire damage (via burnarmor() which is used for most types of
fire damage) has a chance to partially or fully dry a wet towel
(regardless of whether it's wielded at the time; applies to monsters
as well as hero; each towel being carried is checked until one is
affected, then any others escape drying.
Not done:
-) attacking with a wielded wet towel perhaps ought to be treated as a
weapon attack using whip skill rather than an augmented arbitrary-
junk-by-weight attack;
-) throwing a wet towel should probably ignore wetness--it's just a wet
piece of cloth when not finishing with a whip snap; right now, it
loses a point of wetness when thrown and usually--#3 above--another
point if it hits...;
-) hitting burning creatures is no different than hitting anything else;
-) likewise for hitting wet creatures.
Add macros W_WEAPON and W_ACCESSORY, similar to existing W_ARMOR, bitmask
of all the relevant worn bits. Just for code readability; there should
be no change in behavior.
Also, reformat the "ugly checks" portion of getobj(). Slightly better
readability and fewer continuation lines, but only a modest improvement.
Replace instances of strings split across lines which rely on C89/C90
implicit concatenation of string literals to splice them together
with single strings that are outdented relative to the code that uses
them. It's uglier but it won't break compile for pre-ANSI compilers.
This covers many files in src/ that only have one or two such split
strings. There are several more files which have three or more. Those
will eventually be '(2 of 2)'.
Noticed along the way: the fake mail message/subject
Report bugs to devteam@nethack.org.
wasn't using its format string of "Report bugs to %s.", so would have
just shown our email address. Doesn't anybody enable fake mail anymore?
I modified that format to enclose the address within angle brackets and
made a similar change for the 'contact' choice of the '?' command.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
This old feature alert from 3.3.0 is pretty stale, so remove
if from the code because everybody has probably suppressed
it by now.
/* Because 'Q' used to be quit... */
if (flags.suppress_alert < FEATURE_NOTICE_VER(3,3,0))
pline("Note: Please use #quit if you wish to exit the game.");
This started out as a one line change. After I saw someone in the
newsgroup mention that Sunsword's light was inferior to that of a lamp,
I decided to make it work better (than in 3.4.3, that is, becoming the
same brightness as a lamp) when blessed and worse when cursed (useless to
hero but still visible if wielded by a monster). But then it needed to
change light radius when its curse/bless state changed, and it needed
message feedback when doing so, and that got kind of complicated. I
wouldn't have bothered if I'd known what I was getting into, but I don't
want to throw it away now that I've done all this work....
Sunsword now gives a light radius of 3 when blessed (same as a lit
lamp), radius of 2 when uncursed (same as a lit candle and as it has been
providing since added in 3.4.0), and a radius of 1 when cursed (nearly
but not completely useless, as mentioned above). Also, it now "shines"
rather than "glows" since we usually use the latter for temporary effects.
<email deleted> reported back on 8/31/06 that elven weapons were not
affected when he poked a fire elemental with them. This is true, but
moreover, there was no code to have passive fire to affect attackers.
Now erode_obj() supports all the same damage types as rust_dmg(), and added
the connecting code to allow passive fire attacks do something.
There probably should be macros for the damage types used by rust_dmg
and erode_obj, and possibly these functions should be combined, but they
are slightly different and dealing with that requires more thought.
From a bug report, trying
to invoke a wielded artifact after changing alignment resulted in "the
<artifact> evades your grasp" but it remained wielded, contradicting the
message. This adjusts the message in touch_artifact() if the object is
already in inventory, and adds retouch_object() to handle cases where
failing to be able to touch ought to force unwearing/unwielding.
From a bug report, applying a bullwhip
towards a monster to try to steal its weapon would report that a cursed
cockatrice corpse was welded to the monster's hands even though corpses
wielded by the player never become welded. Code for monsters deciding
what to wield knew that corpses don't weld; everywhere else seems to
assume that they only wield weldable weapons. Add a routine to check
whether a wielded item is welded, similar to what's done for the hero. I
fixed a couple of other spots besides use_whip() but didn't hunt all over.