Building with an old version of gcc with various warnings enabled
generated a lot of noise. Most of it was due to not guarding string
literals with `const', but there were a couple of actual problems too.
[forwarded from newsgroup]
When polymorphed into a handless monster, you can't loot a chest
that's on the ground but you can pick it up and then apply it when
it's in your inventory.
use get_adjacent_loc() rather than getdir() directly for some things where
you want to ensure valid adjacent coordinates are returned
<email deleted> wrote:
>>> [...]
>>> I've noticed that the loot adjacent spot code doesn't have any
>>> isok(x,y) test, so will risk crashing if used at the edge of
>>> the screen (whether deliberately, or accidentally due to being
>>> confused or stunned when picking the direction).
>> Would this not be a problem elsewhere, such as use_leash() too?
> Yes, that looks like the same risk. getdir() doesn't validate
> that the <u.ux+u.dx, u.uy,u.dy> is safe and neither does m_at(),
> so their callers need to.
>
> I did manage to provoke a crash with #loot on the plane of earth,
> although an accidental case would be a lot less likely to happen.
Fix the reported bug of an unskilled rider who is unable to pick
items off the floor while mounted still being able to dip into water.
There might be other actions which need similar checking; this one only
handles the dip into pool/moat case.
Provide more control over message handling for monsters' use
of equipment. This fixes the statue revival problem (inappropriate
feedback when monster puts on speed boots) mentioned in the earlier
"intrinsics of dead monsters" patch.
Noticed with recent looting patch: QBUFSZ is not big enough
to reliably hold formatted object names. (I haven't looked through
any other source files for similar problems.)
Newsgroups: rec.games.roguelike.nethack
Subject: Re: YANI - empty containers interface
<email deleted>
On Mon, 2 Sep 2002 12:13:49 +0300, <email deleted> wrote:
> I find the behaviour when trying to put something in an empty container
> quite irritating. Let's remind it:
> #loot
> "The <container> is empty. Do you want to put something in it? (y/n)"
> This means I have to read the message and to press 'y' or to cancel via
> Esc.
> For comparison, non-empty containers behave like this - please forgive
> me that I've forgotten the exact words:
> #loot
> "Do what?
> o - take out
> i - put in
> b - both of the above"
> So my suggestion is to change the behaviour of empty containers to be
> the same as non-empty ones. That is:
> #loot
> "Do what?
> i - put in"
> This way, I don't have to look at the container. If I want to put
> something in, pressing 'i' will lead to the same results in both cases.
This part of the suggestion was not implemented, however:
> If I want to take something out, then pressing 'o' or 'b' - although
> they are not in the list of choices - will display a message "This
><container> is empty" and end the #loot-ing session.
From the newsgroup: taking a shop-owned pick-axe out of a
container inside a shop gave a misleading message telling the
player to take the pick-axe out of the shop. It was caused by
using the object's `unpaid' field before addtobill() had set it.
Several flags added since 3.4.0 were destined for flags
(to be saved with the game) but were placed in iflags for
savefile compatibility. These include:
boolean lootabc; /* use "a/b/c" rather than "o/i/b" when looting */
boolean showrace; /* show hero glyph by race rather than by role */
boolean travelcmd; /* allow travel command */
int runmode; /* update screen display during run moves */
This patch has no effect unless you define this in your port's
XXconf.h file.
#define SAVEFILE_340_CONVERT /* allow moving of some iflags fields to flags
without destroying savefile compatibility */
Without it, the new flags remain in "iflags." With it, the flags are moved to
"flags" and the structures are converted when the save file is read. There
is no reverse compatibility. If you save the game after conversion, you
can't load the savefile on 3.4.0, only 3.4.1.
Fix the reported bug of being double-billed for a bag of
holding destroyed if #loot is used to put a wand of cancellation
into it while it's on a shop floor. (The bug report neglected
to mention a second aspect of the situation: you wouldn't get
billed for the wand if you used an unpaid one to trigger this.)
There's a check in doloot that's supposed to disallow looting nearby
monsters if you loot a container at the current location. But, it only
worked if you looted the last container. Make the behavior consistent.
<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?
>
- this is brute force, always update the status line each time you
insert something into a container. If you look closely, you may still
see the Burdened message disappears momentarily doe to the many possible
messages between the freeinv() call and the point where the object is
actually put into the container.
- the "Burdened" message could disappear from the status line if it was
updated partway thru in_container, clearing the bot flags. Re-order
message so it comes after add_to_container, as in 3.3.1.
Replace "feature_toggle" implementation with an easier-to-understand
boolean option called "lootabc".
Provide "showrace", an option to display the hero by race glyph rather
than by role glyph.
Document the above.
Remove some obsolete Mac options.
This adds a generic feature_toggle mechanism to
the game. Code that wants to offer two different
ways of doing something can add an entry to
feature_toggles[] (in decl.c), and create a
preprocessor macro for its array index in decl.h.
Then the code can test it using
if (feature_toggle(FEATURE_NAME))
..do_this..
else
..do_that..
The player can toggle the alternate code path
on using OPTIONS=feature_toggle:feature_name_1 feature_name_2 ...
This seems better than creating brand new options
for controlling features (ala prayconfirm, which
could switch to this single option feature_toggle
mechanism as well)
My first use of it is to allow toggling of the selectors
on the loot menu, which I'm hesitant to just change back
because now people are actively using the new selectors and
the complaints would be really loud if the interface were
to just switch back after they adjusted.
The default behaviour is the new behaviour "iob", but with an
OPTIONS=feature_toggle:loot_menu_selectors
in your config file, it will revert to using "abc" as it did
in 3.3.1. I'll add a Guidebook page of "features/behaviour
that can be toggled" later.
The toggles can only be done in defaults.nh, and are
not saved with the game.
Most NetHack players have picked up on the fact that you can
easily distinguish between a fake amulet and the real thing
simply by trying to put it into a container. That's too easy.
The message was adjusted too, to make it seem less
like the objects have their own special will to resist, something
that a hunk of plastic is unlikely to have.
Devteam: message has been modified from what was previously
circulated.
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.
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...)
