I saw no straight-forward way to insert the message earlier in the
sequence, so... I reasoned that you might not yet have a good grasp and
not be able to continue holding the object when reverting form. So, I made
this into a drop case and made the drop message a rare past tense message.
Past tense is still OK for the other drop cases.
While testing this, I noticed you'd keep stealing even after reverting
form. Added code to stop this. Finally, there was a missing MON_NOWEP
call in the stealing code, added it.
When !GOLDOBJ, player polymorphed to a rust monster that attempted to eat
gold in the inventory would fail to eat it, but the gold would be consumed
anyway. Under GOLDOBJ, a later check would work around the invalid prompt.
Refinement of the digging code:
* Picks should not chop down trees, but axes should.
* Picks should break walls, rock, statues, and boulders; axes shouldn't.
* Either picks or axes should chop down doors.
<email deleted>
> Since Priests' knowledge of the buc-status of an object only
> kicks in when the name is being looked at for the first time,
> they get an "X" option when taking items out of a newly-looted
> container, but B, U, and C thereafter; could their ability be
> pre-applied to the container's contents when constructing the
> menu, to avoid this anomaly?
>
- remove special case code from getobj for touchstone
- remove other hacks from getobj that resulted from earlier hack, solves
the "rub on the gold stone" problem completely
- pass correct letter list to getobj from use_stone, like other callers
-Rename is_greystone() to is_graystone() since I've
had one complaint about my choice of spelling for
the macro already.
-Change the recent "#rub touchstone" code to use
the macro which pre-existed under the other spelling
and was already used in the very same "if" statement
with that spelling in invent.c. :-)
Change the prompts for P and R commands to use "put on" instead
of "wear" and "remove" instead of "take off", respectively; W and T
commands aren't affected. There is no change in game play.
<Someone>'s message said this was committed, but the cvs repository
didn't reflect his changes.
> Subject: patch: #rub touchstone
> Date: Wed, 20 Feb 2002 23:33:27 -0800
> <email deleted>
>
> Implement <Someone>'s suggestion.
>
> - allow the #rub command to apply to gray stones
> - update various doc & help files to reflect the change
>
> Committed to CVS.
Defer to the validation code from pickup.c for checking
valid categories. This reduces the number of callback
functions required, and allows combinations of BUCX
to be used in traditional menu style.
getobj used display_inventory when "?" was selected. However, any count
entered via the menu interface was lost. Provide a new internal function
that can return both a letter and a count
1. The switch statement was using the material "GOLD"
rather than GOLD_CLASS.
2. If getobj() had been working for gold when it
came to touchstones, there would have been a
memory leak here because the object returned
would have been from mkgoldobj(). The goldobj
was not being freed anywhere, nor was it being
put on a chain. You also would have had zero
gold after rubbing it on the stone. The intent
was clearly to allow gold since there was a
case in the switch statement.
3. getobj() wasn't working properly for gold
selection here anyway, so this was
not the cause of <Someone>'s gold obj in inventory.
You ended up dropping through to code that
was supposed to print "You cannot verb object."
For touchstones that came out as:
"You cannot rub on the stone gold."
over the place.
Often they would use
"%ld zorkmid%s", amt, plur(amt)
but not consistently, so some of the hard-coded usage
could result in "1 zorkmids"
This adds the function
currency(long)
to return the name of the currency, either plural
or singular depending on the argument passed to it.
That eliminates the need for the extra %s in the
format string and the use of the plur() macro.
The GOLDOBJ fix I posted back on 1/3 caused "Ix" to access a null pointer
(obj) while generating the total line. This patch fixes the bug I added to
xprname.
This adds the BUC-patch, except that it includes four separate choices for
blessed/cursed/uncursed/unknown. The patch only applies to full menu styles.
--Ken A
(Incidentally, I have a suggestion: when deciding what's the first line for
purposes of mailing out messages, use the first nonblank line...)