From a bug report: moving while blind
and gloveless onto spot containing a cockatrice corpse is fatal if there
are fewer than 5 items there, but harmless when you get the "there are
several/many objects here" result for 5 or more. I thought that this was
something which had already been changed, but it wasn't. Run a touch
check on the whole pile of objects even when no object-by-object feedback
is being given.
Trunk only because it's using the trunk version of corpse_xname().
Simplify the insertion into and removal from of gold in inventory for
the !GOLDOBJ configuration. If GOLDOBJ ever becomes unconditional this
will be superfluous, but in the mean time it unclutters the container and
drop code. Also, tweak a recent getobj() hack so that its purpose might
be a bit clearer.
Reduce the number of questions issued when applying or looting a
container, and offer the opportunity to put things inside before taking
things out. Instead of "Do you want to take something out? [:ynq]",
followed by "Do you want to put something in? [ynq]", this gives just one
prompt; the result is similar to menustyle:full where you start out by
choosing between out, in, and both. There are now two additional choices:
reversed, for both in the opposite order, and stash, to put a single item
inside. Prompt phrasing is rather clumsy; I wanted to keep it short:
"Do what with <the container>? [:oibrsq or ?]", where picking '?' pops
up a brief help window. Inappropriate choices (like 'o'and 'b' when
container is empty) are suppressed from the prompt but still acceptable as
input; " or ?" is suppressed if the cmdassist option has been toggled off,
but entering '?' still works to get help.
Menu mode wouldn't allow 'b' when inventory was empty, despite the
fact that first taking things out might change that. Now 'b' is a viable
choice if the container isn't empty, and the new 'r' is a vialble choice
when inventory isn't empty even if the container is.
Some miscellaneous changes preparatory to enhancing the container
interface. This also fixes a minor inconsistency in object manipulation:
askchain() wouldn't let you split a stack of welded weapons but getobj()
would, so you couldn't get rid of part of the stack using 'D' or #loot,
but you could with 'd' (and post-3.4.3, with #adjust). Now getobj() will
behave like askchain(); if you have 3 cursed daggers welded to your hand,
you won't be able to drop 1 or 2 of them anymore.
There was code to give feedback if you attempted to offer the Amulet
on a regular altar instead of the final high altar, but that code was
unreachable; getobj() yielded "that's a silly thing" whenever you picked
an amulet while not on the Astral (or recently changed, Sanctum) level.
This allows you to try to offer the real or fake Amulet of Yendor on any
altar, but they'll only be listed as likely candidates when on the Astral
level. Conversely, it no longer lists carried corpses as likely candidates
at the Astral high altars; they're still acceptable but not what the hero
is supposed to be fiddling with there. Also, allow corpses on the floor
to be offered on high altars, fixing a complaint we've gotten a few times
over the years. (Unfortunately there's no way to suppress them as likely
candidates on the high altars while still allowing them to be sacrified.)
Several small related changes that ended up being not quite so small:
Allow the Amulet of Yendor to be offered on the altar in the temple
of Moloch's Sanctum level; doing so is fatal. Fake ones can be offered
too, but that doesn't do anything special (they act the same as they do in
the temples on the Astral level). Unlike in the endgame, the Amulet and
its fakes aren't listed as likely candidate for #offer's pick-an-object
prompt; like the endgame, corpses must be carried rather than being on
the altar in order to be sacrificed.
Prevent non-chaotics from destroying the chaotic high altar on the
Astral level via same-race sacrifice. From a bug report. (Chaotics converting non-chaotic high altars
via same method was already handled. I think the behavior for ordinary
altars if wrong here; why should a chaotic altar be destroyed this way?)
Prevent demon princes and demon lords from being summoned in the
endgame. Lesser demons answer instead. Mostly prevents Yeenoghu from
being summoned by a chaotic who performs same-race sacrified on the
chaotic high altar, but might affect the Wizard and arch-liches too.
Identify (via ':', ';', '/') altars in temples on the Astral and
Sanctum levels as "high altars" rather than just as "altars". '/' and ';'
commands now work on those when you're adjacent, like they do when used on
adjacent high priests; from farther away, the altars' alignment is still
suppressed.
From a bug report: you
can dip a worn item such as shirt or suit into a potion of polymorph and
it will become unworn--but as of a couple of days ago, unworn only if the
transformed object's new form can't be worn in the same slot--even if it
is covered by a cursed worn item (suit or cloak). It didn't seem like
trying to fix that special case would be very worthwhile; this fixes the
more general situation of "you could dip worn items even though they were
covered up by other worn items".
In the same report: you could apply grease to rings while wearing
cursed gloves. The code already prevented greasing a suit when it was
covered by a cloak (regardless of whether that cloak was cursed), and a
shirt when it was covered by a suit or cloak or both. This moves that
code into a separate routine which is used for dipping as well as for
applying grease, and now handles rings vs gloves.
Since covered rings, shirt, or suit are no longer eligible to be
dipped or greased, this also makes "?" for the pick-an-item prompt leave
such things out of the list of likely candidates.
[I can't get access to my mail at present, but `cvs update' shows
that there aren't any patch notification messages pending for me.]
Extend a pre-3.4.3 fix--for objects picked up in an untended shop--
to container contents. Without it, dropping a bag or box in a tended shop
and declining to sell it, then picking it back up after the shop has become
untended (shk killed or evicted) would leave the contents with no_charge
set. After that it could be sold in another tended shop, picked back up
for free, then kept or sold a second time. (Picking it back up in the
tended shop would clear the bit; afterwards it behaved normally. And it's
not something prone to abuse; if you can make a tended shop become untended
you really don't need to sell stuff twice. But it'd be noticeably wrong if
anyone ever stumbled across it.)
Inventory display adds "(unpaid, N zorkmids)" to carried unpaid
items, but it didn't show anything comparable for indirect unpaid ones
(hero-owned containers holding shop-owned objects). Now it will include
"(contents, N zorkmids)" in such cases.
Allow '#' as a destination slot if you've given '#' as the source
and there aren't any available inventory letters, making it possible to
use doorganize()'s feature of merging compatible items into one slot even
when that slot is #. ('#' won't work as a destination when the source is
from a regular letter. If the player wants to swap something in letter
slot x with whatever is in the # slot, he'll have to use # -> x rather
than x -> #.)
Also, a post-3.4.3 change made it possible to produce an inventory
that used duplicate letters. Giving a count while specifying the source
slot splits the source object. But the extra '?' choice added to show
inventory letters in use didn't undo the split if player hit ESC to quit
early instead of specifying a destination slot.
Lastly, don't prompt forever if the user doesn't give a valid
destination letter; give up after 5 attempts.
Prevent getobj() from overflowing its inventory letter collection
buffer if someone figures out some new way to fill up their inventory with
a huge number of # entries. Inventory manipulation might become crippled
at that stage but at least it shouldn't be able to trigger a crash.
Also, the !fixinv configuration was never taught about # and did
strange things if you had more than 52 items, both for inventory display
and object selection with getobj.
The reassign()/getobj() situation is definitely confused regarding
gold, using GOLD_SYM in some places and def_oc_syms[COIN_CLASS] in
others, and it's schizophrenic about whether the GOLDOBJ configuration
keeps gold in a letter slot or specially named $ slot. I'm sure there
are some problems there but I'm not planning to try to figure them out.
If someone manages to get three or more items with inventory "letter"
'#', compact inventory selection prompts to list "#-#" instead of showing
every #. It isn't possible to selectively pick a particular one anyway,
so this doesn't affect player choices.
1 #: Which item? [$#a-zA-Z]
2 #: Which item? [$##a-zA-Z]
3 #: Which item? [$#-#a-zA-Z]
4 or more #: same as 3.
This doesn't address the fact that picking up enough boulders as a
giant might overflow the BUFSZ buffer getobj() uses to collect inventory
letters prior to calling compactify() on them.
Change safe_qbuf() so that instead of picking one of three strings
for sprintf() to plug into a prompt string, it actually constructs the
full prompt string itself. Also pass in the unformatted object and a pair
of formatting functions instead of performing dual formatting in advance.
The actual formatting is done via new routine short_oname() which also
takes an object and a pair of formatting routines plus a target length.
It uses the first routine, typically xname() or doname(), and formats the
object, then if the result is too long it makes some transformations, and
tries again. If truncating "called foo" and "named bar" down to 12 chars
and omitting "uncursed, rustproof, thoroughly corroded" attributes still
result in a string that's too long, it uses the other formatting routine.
The latter calls one of several jacket routines around simple_typename()
to produce a short result.
This has been through about four incarnations now and has gotten a
bit less testing each time, but I need to get it in place before I end up
running out of gas and abandoning it. I've got some changes to shk.c
(where safe_qbuf is needed but not currently used) that now need to be
redone and will come eventually.
This is an overhaul to the NetHack drawing mechanism.
- eliminates the need to have separate lists in drawing.c
for the things and their associated explanations by grouping
those thing together on the same inializer in a struct.
- replaces all of these options: IBMgraphics, DECgraphics, MACgraphics,
graphics, monsters, objects, boulder, traps, effects
- drawing.c contains only the set of NetHack standard symbols for
the main game and a set of NetHack standard symbols for the
roguelevel.
- introduces a symbols file that contains named sets of
symbols that can be loaded at run time making it extensible
for situations like multinational code pages like those reported
by <Someone>, without hardcoding additional sets into the game code.
- symbols file uses names for the symbols, so offsets will not break
when new things are introduced into the game, the way the older
config file uchar load routines did.
- symbols file only contains exceptions to the standard NetHack
set, not entire sets so they are much less verbose than all of
the g_FILLER() entries that were previously in drawing.c
- 'symset' and 'roguesymset' config file options for
preselecting a symbol set from the file called 'symbols'
at startup time. The name of the symbols file is not under the
users control, only the symbol set name desired from within the
symbols file is.
- 'symset' config file option loads a desired symbol set for
everything but the rogue level.
- 'roguesymset' config file option loads a desired symbol set
for the rogue level.
- 'SYMBOLS' config file option allows the user to specify replacement
symbols on a per symbol basis. You can specify as many or as few symbols
as you wish. The symbols are identified by a name:value pair, and line
continuation is supported. Multiple symbol assignments can be made on
the same line if each name:value pair is separated by a comma.
For example:
SYMBOLS = S_bars:\xf0, S_tree: \xf1, S_room:\xfa \
S_fountain:\xf4 \
S_boulder:0
- 'symbols' file has the following structure:
start: DECgraphics
Handling: DEC
S_vwall: \xf8 # meta-x, vertical rule
S_hwall: \xf1 # meta-q, horizontal rule
finish
start: IBMgraphics
Handling: IBM
S_vwall: \xb3 # meta-3, vertical rule
S_hwall: \xc4 # meta-D, horizontal rule
finish
- 'symbols' file added to the source tree in the dat directory
- Port Makefiles/scripts will need to be adjusted to move them into
HACKDIR destination
Remove some more code that forced pointers into a long int, and
vice versa where information could be lost (P64 platforms such as
WIN64 have a 64 bit pointer size, but a 32 bit long size.)
This 2nd part deals with timeout functions switching
some arguments from type genericptr_t to 'anything'.
Like part 1, this needs to increment EDITLEVEL in patchlevel.h.
<Someone> reported that he applied an unID'd bag and it became
discovered as a bag of tricks even though a spellbook appeared on the floor
next to him rather than having a monster show up (the monster was a mimic).
Suppress the bag discovery unless you can see or sense a monster appear.
(This doesn't really achieve much for most players, who'll recognize the
bag because they know that only one type of container doesn't prompt to
take things out and/or put things in, but I think it does make sense.)
While mucking with bag of tricks I decided that to be consistent with
the behavior of other containers, the #tip command should release all the
monsters in the bag instead of just one.
And after doing that, I realized that horn of plenty ought to behave
much the same, so #tip will operate on it now. However, it won't be listed
as a likely candidate in the "which item?" prompt unless/until it has been
discovered. (Attempting to empty any other type of horn yields "nothing
happens", same as for a horn of plenty with no charges left.) Emptying a
horn of plenty in a shop can be extremely verbose, but I don't think that
qualifies as a bug and don't currently have any plans to alter it.
When the hero receives the quest artifact "got it" message, set the
artifact's dknown bit in case the hero is blinded. That message describes
the object by name, effectively the same as seeing it up close. (This
would have prevented the "now wearing an Eyes of the Overworld" grammar bug
for monks but not for non-monks, so the previous fix is still necessary.)
This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em. It is
extremely useful while using ranged weapons. When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
[See cvs log for patchlevel.h for longer description.]
It seemed inappropriate to allocate and tack on an oextra
structure just to mark it as unmergable, and the oextra
struct itself wouldn't be released until a save/restore took
place.
This uses one of the freed up oattached bits to prevent the merge.
move oattached and oname and other things that vary
the size of the obj structure into a separate
non-adjacent oextra structure, similar to what has
already been done for mextra. The obj structure
itself becomes a fixed size.
New macros:
#define ONAME(o) ((o)->oextra->oname)
#define OMID(o) ((o)->oextra->omid)
#define OMONST(o) ((o)->oextra->omonst)
#define OLONG(o) ((o)->oextra->olong)
#define OMAILCMD(o) ((o)->oextra->omailcmd)
#define has_oname(o) ((o)->oextra && ONAME(o))
#define has_omid(o) ((o)->oextra && OMID(o))
#define has_omonst(o) ((o)->oextra && OMONST(o))
#define has_olong(o) ((o)->oextra && OLONG(o))
#define has_omailcmd(o) ((o)->oextra && OMAILCMD(o))
changed macros:
has_name(mon) becomes has_mname(mon) to correspond.
The CVS repository was tagged with
NETHACK_PRE_OEXTRA
before commiting these, and
tagged with
NETHACK_POST_OEXTRA
immediately after. The diff
between those two tags is this oextra patch.
The associated mail daemon changes to use an oextra
structure instead of a hidden command located in the
name after the terminating NUL, have not been tried
or tested.
<email deleted> wrote the following on April 10, 2006:
> When blind and levitating, you can produce a message - "You try to feel what
> is lying here on the ice. But you can't reach it!" - which reveals too much
> about the terrain below you.
My recent patch included a typo in a pline() call which broke compile,
and much worse, was accessing scroll of identify after using it up. Cache
scroll->otyp, scroll->blessed, and scroll->cursed instead of re-re-ordering
the identify scroll/spell code.
This patch alters wiz_identify so that it displays an
inventory menu with all items shown identified
without actually identifying them.
You can just press ^I (or whatever the wiz_identify command
is) a second time, while the menu is displayed to actually identify
them (tested with TTY menus only).
Allow rubbing any object against any touchstone even when the latter
is known so only gems make sense. Also, propagate an earlier fix which
allowed rubbing gold against known touchstones to the branch (it had been
trunk only).
cknown and lknown flags for containers are now checked when deciding
whether an item is fully identified, and they're set when identification
takes place. (You'll learn how many items are inside even if you haven't
looked to see what they are yet. This means that an inventory listing of
unpaid items will reveal the contents after you've used enouch magic to ID
an unpaid container.) Also, set those flags for any container in initial
inventory; rogues should know that sack starts out empty.
A post-3.4.3 change dealing with reaching into pits resulted in "you
sit on the air" if you used the #sit command after escaping a pit trap.
Change can_reach_floor() so that caller explicitly controls whether being
on the brink of a pit is a condition that prevents reaching the floor.
This also splits a fairly common message about not being able to reach the
floor into a separate routine.
There is still oddness here: if you're polymorphed into a flyer,
#sit yields "you sit down" followed by "you fly over a pit" (latter occurs
when escaping trap activation). A ceiling hider behaves similarly, but
the second message is "you escape a pit" and doesn't sound quite as silly.
Perhaps #sit should pass TOOKPLUNGE to dotrap(), or maybe there's some
better way to handle this?
When 3.4.0 added the shop price to inventory display of unpaid items,
it resulted in showing that price twice if you used the `I u' command while
carrying just one unpaid object.
k - a potion of object detection (unpaid, 150 zorkmids) 150 zorkmids
With two or more unpaid objects it uses a menu style display and explicitly
suppresses "(unpaid, N zorkmids)" from the inventory formatting. Do the
same suppression when there's one item.
k - a potion of object detection 150 zorkmids
Several places were not using safe_qbuf or anything equivalent to avoid
overflowing a QBUFSZ buffer. Add more uses plus one special case. For
the current max lengths returned by xname(), I think this is
sufficient. This addresses a reported buffer overflow for a
"thoroughly rusty thoroughly corroded helm of opposite alignment", plus more.
Revert mostly to <Someone>'s original approach for keeping track of whether
a container being applied or looted had been destroyed by the operation.
askchain() now knows not to attempt to re-merge an item that has been
destroyed (a theorhetical action since no stackable items can trigger a
magic bag explosion) like the earlier change to menu_loot(). Also have
use_container() clean up after itself so that current_container never has
an old pointer value left around.
This is a minor addition to Pat's doorganize() patch.
This just allows you to press '?' in the midst of an #adjust command
to see what letters are already in use. It is a PICK_NONE menu for
viewing only, because your actual response to the #adjust must not
be limited to the letters already used. It helps to be able to see
what's already consumed without having to terminate the command,
inventory, then start it again.
[Attention: This patch increments EDITLEVEL in patchlevel.h, rendering all
previous save and bones files obsolete.]
Here's the first cut at the two recommended flags lknown and cknown.
I've attempted to stay close to Pat's recommendations:
"Containers ought to have two new flags: lknown for lock status known,
and cknown for contents known (ie, `secret'). Formatted box and chest
descriptions should include locked/unlocked/broken when that is known
and empty/nonempty (or something like "holds N items") when contents
are known. The contents indicator would also apply to nonlockable
containers."
I probably overlooked a place where a flag should be adjusted, but this
should give us a good starting point.
I wasn't sure what to do with the case of the auditory feedback for
magical locking "Click" and "Clunk". The question that came to my mind
was: Should those reveal the locked or unlocked status of a box?
I suppose if you knew the type of wand you were zapping or the spell
you were casting, you could argue that they should.
In the end, I opted for setting lknown right off the zap/cast effect
for anyone playing a Wizard role, and not setting it for anyone else,
thus advancing class differentiation a little bit too.
I haven't checked the cknown results under all flags.menu_style options
at this point, only MENU_FULL.
Allow the #adjust command to be used to split an inventory stack
as well as for moving things to specific slot letters. Splitting is
accomplished by specifying a count along with the letter of the stack to
operate on, similar to when dropping a stack with 'd'. The comment above
doorganize() has more details.
This change will make it possible for users to split stacks of cursed
loadstones which they couldn't easily do before, but I don't see anything
wrong with that. It was always possible to have multiple stacks of load-
stones by starting with ones that had different curse/bless status, so this
hasn't introduced a totally new situation. On the other hand, I haven't
tested this with the GOLDOBJ configuration and am not sure whether there is
any need to prevent gold from being split there. The getobj() call doesn't
specify COIN_CLASS so perhaps it's irrelevant (unless it ought to be
changed the other direction by adding that to intentionally allow gold to
be split?).
I've cleaned up the #adjust routine somewhat while revising it to
support splitting stacks as well as moving them, then have separated the
cleanup from the more substantial changes. The most significant change
here is that #adjust will give up early if used when inventory is empty;
the user used to be forced to choose a letter from an empty list in that
case, then it gave up when no object was selected. There's also a minor
change for users who turn `fixinv' off; the prompt's list of likely
candidate letters for destination slot is reduced to one letter beyond
current usage instead of showing the rest of the alphabet. (Picking any
letter--which users can still do--beyond current usage results in moving
the adjusted item to the end of the list, although it ultimately ends up
with a different letter than the user chose because adjusting from some
other slot frees up that slot; all items past it--including the new last
element--effectively move up one letter [or more if merges occur].)
Despite lack of feedback from the beta testers about it, add the code
which tries to stack an object being added to inventory with the quiver
before trying with other carried objects. Only matters to user if quiver
is non-empty and one or more other slot(s) are compatible with it, but
that's not uncommon for someone who starts a rogue by splitting the initial
daggers into separate wield and throw slots. Firing a dagger from quiver
and then having it merge with wielded weapon instead of back into quiver
when picked back up leads to tedious inventory manipulation. Assigning
different names to the two stacks solves this, but can't help when picking
up an unnamed item which is otherwise compatible. (A rogue with starting
daggers wouldn't encounter that since unnamed ones won't be sufficiently
identified to stack, but any character who just gathers unID'd daggers and
uses them for both melee and throwing has a chance of running into the
"picked up into less desireable slot" trap whenever new ones are found.)
Fix the reported problem of bad inventory management if the user
specified a count (with traditional menu style) when attempting to drop
part of a stack of cursed loadstones. After the "you can't drop that"
message, it tried to undo the stack split, but splitobj was changed
sometime back and the undo hack wasn't adjusted to account for the fact
that it needed to merge with the previous object instead of the next one.
The result was that it would incorrectly increment the count of the next
item instead of the original loadstone, or crash in canletgo() if the
split off stone was the last item in the list.
This prevents cursed loadstones from being split (via getobj()'s
count handling) in the first place, so there's nothing to undo later.
It still uses a similar kludge so that the "can't drop that" message can
be adjusted, but it's now a simpler kludge and I hope a more robust one.
Groundwork for forthcoming stethoscope fix: add an object list
traveral routine (there must be something like this already, but I
couldn't find it...) and a couple of timer access routines.
Reported a while back, a (stonable) hiding monster will hide at a location
containing only a cockatrice corpse. While it would be interesting to
allow monsters to try, and stone themselves as a result, I chose the
simpler fix which is to not have monsters hide in such situations. I found
the hiding code was duplicated in several places, so I moved it into a new
hideunder() function that works for both the hero and monsters.
There was a great deal of inconsistency in
different menus on how headings were displayed.
This allows the user to select what they like best.
I was motivated to do this, because I wasn't satisfied
with the appearance of ATR_INVERSE in the menus
on win32tty, and several of them specified it.
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
Although the overlay stuff is destined to be
removed someday, this patch just makes the
use of STATIC_DCL, STATIC_OVL consistent
in the trunk.
[As a side pointless experiment, I was able
to build a working 8086 port of 3.4.2 after
this change that worked correctly in limited
testing right up until it came time to enter
Ft. Ludios., where it couldn't allocated the
required amount of memory.]
I encountered a look vs pickup cockatrice corpse
bug today.
If you looked at a location with ':', you
would instantly get
"Touching the cockatrice corpse is a fatal mistake..."
but if you used "m," you got the full list of
things at the location to choose from.
This patch makes the behaviour consistent
and more informative to the player.
You now get the partial list of things felt
up until the cockatrice corpse is encountered,
and then you get the
"Touching the cockatrice corpse is a fatal mistake..."
Before, the code was never displaying the partially
built list because the feel_cockatrice() call was
happening before the window display call.
