Some code I recently added was misusing count_unpaid() and would
traverse some or all of inventory instead of just container's contents
when looking for unpaid items. Add mew routine `is_unpaid(obj)' to do
what I was intending to do with count_unpaid().
The earlier change involving "you sneaky cad!" got me wondering, so
I looked up cad in the dictionary: "an ungentlemanly man". I can see
that being extended to a male gnome, even to an orc, but not to a women.
Use verbalize instead of pline for shop "thank you, scum" message
(From a bug report. Suppress shop "you sneaky cad" message
when removing a hero-owned pick-axe from a container inside a shop if the
shk is unable to speak; also give it at most one time per move (taking
multiple pick-axes out of a bag at once was way too verbose). Honor
addtobill's silent flag for the bill overflow message when/if that occurs.
Also adds a safe_qbuf usage for the #tip command that I had pending
for pickup.c.
Make objects created by applying or #tipping a horn of plenty which
is owned by a shop also start out being owned by the shop. That's in
addition to the usage charge for using an unpaid item.
I think wishes conferred by unpaid objects, or by entities released
from unpaid objects, should probably work that way too, but have left
that alone.
[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.
Prevent heroes in giant form from picking up boulders once they run
out of available inventory slots to avoid an uncontrolled number of '#'
entries. There is an exception: if not already carrying any boulders,
they can put one into the '#' slot. Loadstones are treated the same way,
although since they stack and are rare to begin with, someone would have
to have gone far out of their way to have gotten many # entries with them.
Assuming that you can get something other than a boulder or loadstone
into the # slot (which is definitely possible, I just can't remember how),
you could relatively easily get three total # entries by picking up a
loadstone and polying into a giant and picking up a boulder. But I don't
think there's anything wrong with that.
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.
[I accidentally left this out of the previous commit.]
Throwing didn't handle a container owned by the hero which contained
items owned by the shopkeeper. I'm still not quite sure what's going on
there, but throwing the container out of the shop didn't give any feedback
but did add to shop charges which don't show up in ``I x'' (but do get
revealed by ``$'' or ``I $''). Now there's some shop feedback for the
throw and the contents show up for ``I x''.
Try to fix multiple container-in-shop bugs; it seemed as if every time
I tried to investigate one I stumbled into another. billable() (post-3.4.3
code, but already present in branch as well as trunk) didn't handle
containers properly. It sometimes gave the wrong answer and it didn't
clear the no_charge flag of contained items as the old code in addtobill()
it replaced did. stolen_value() didn't use the actual bill price for an
item already on the shop bill; it generated a new price which might be
different if the object was unID'd (3.4.3 had this one). Throwing didn't
handle a container owned by the hero which contained items owned by the
shopkeeper. I'm still not quite sure what's going on there, but throwing
the container out of the shop didn't give any feedback but did add to shop
charges which don't show up in ``I x'' (but do get revealed by ``$'' or
``I $''). (This was intertwined with some of the other stuff and I don't
know how 3.4.3 behaved in this regard. Now there's some shop feedback for
the throw and the contents show up for ``I x''.) An unpaid container which
contained another nonempty unpaid container showed a different price when
picked up and in inventory display [k - a bag (unpaid, NNN zorkmids)]
compared to what was on the bill and showed by ``I u'' because the first
two included double billing of the nested container (just it, not its own
contents). [There where a few recursive calls of the form
x += func(x)
which should have been either
x = func(x)
or x += func(0).] Purchasing used the right amount, I think. I'm not
sure whether 3.4.3 had this particular bug or whether fixes for some of its
other container bugs inadvertently caused this one.
This patch also changes stolen_container() to work like the other
recursive shop routines: it just handles the contents, leaving the outer
container itself to be handled by its caller. It seemed inconsistent, and
changing it simplified the fix for using bill price on stolen unpaid items.
Eliminate a couple of minor redundancies; no change in game play.
dropy() - only check about selling object if there is a shop on the level.
pick_obj() - leave it to addinv() clear object's no_charge bit.
This eliminates a whole bunch of the "Query truncated" entries in
the nethack.alt.org paniclog file by using safe_qbuf() where applicable.
It also makes selling queries and some other shop messages be less verbose
when shopkeepers are invisible (not uncommon after characters achieve see
invisible capability) by using shkname() to get "Manlobbi" instead of
Monnam()'s "Manlobbi the invisible shopkeeper" (something I had planned
to do even before seeing the truncations in that paniclog; repetition of
"the invisible shopkeeper" was very annoying when stepping through
multiple unpaid objects with itemized billing).
This also simplifies several GOLDOBJ conditional sections which
happened to be near the other code I was modifying.
- ensure that wchar.h is included even if it is not included
from another system header file as it is on some platforms.
- attempt to make the NHWCHAR_P definition more appropriate
for more platforms.
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.
Explicitly truncate the query prompt string to QBUFSZ-1 characters.
For tty and Amiga, no longer include the choices and default within that
length limit; use a bigger buffer to hold them along with the prompt.
[See cvs log for doc/window.doc for more details.]
Explicitly truncate the query prompt string to QBUFSZ-1 characters.
For tty and Amiga, no longer include the choices and default within that
length limit; use a bigger buffer to hold them along with the prompt.
-----
While trying to eliminate the "Query truncated" entries present in
nethack.alt.org's paniclog, I seem to keep going backwards. Allowing
<win>_yn_function() to accept a full QBUFSZ worth of characters will
simplify the existing yn_function() in the core and greatly simplify the
revised safe_qbuf() I've been working on.
Some interfaces don't seem to care how long the prompt string is; I've
left those along. Several of the others already copied the prompt string
into a BUFSZ sized buffer instead of a QBUFSZ sized one, making them
unlikely to suffer from buffer overflows. This changes the rest (just tty
and Amiga, I think) to do the same. Also for all that have any size
constraint, it now truncates the prompt query to QBUFSZ-1 chars as it is
used rather than continue to rely on the caller doing so. This assumes
that appending the set of acceptable choices and the default response won't
overflow, which is a safe assumption unless/until QBUFSZ gets enlarged til
it's too close to BUFSZ.
Only tty's topl.c has been tested. The others should work ok, but
might possibly be bitten by a typo or two. Qt's implementation of the X11
"slow" method (reusing a persistant one-line window for prompts) has been
handled, but its C++ class-based variant is untouched; NetHackQtYnDialog::
Exec() is completely baffling to me but doesn't appear to have any length
issues.
According to a newsgroup followup, a hidden pet summoned via magic
whistle could produce the same effect as the level change case (where
sometimes the glyph for unseen monster would appear unexpectedly). I was
unable to reproduce this one, but I don't see anything in the code to deal
with the situation, so I suspect that the monster is moving immediately
and being revealed before I have a chance to notice anything odd.
I assume that other situations where hidden monsters get teleported
are being handled as attacks which expose them. At least I hope so.
From the newsgroup: if a pet was hiding under an object next to you
when you changed levels, it could arrive hidden at the destination if there
was something available to hide under there too, and sometimes you'd start
the new level with a hidden monster glyph at its location. I was able to
reproduce that once with current trunk code, but while trying to figure
out what is actually happening I've been unable to make it happen again.
However, it doesn't make sense for a monster to be able to remain in hiding
during the level change in the first place, so this patch prevents that.
(I'd still like to know how/why map_invisible() is sometimes getting called.
[The test character was a level 1 tourist without auto-search capability.]
I'm reasonably sure that it won't happen any more once this fix in place.)
This also brings adjacent pets out of hiding when they accompany you
during ascension or dungeon escape, but it seems that that wasn't actually
necessary. The end of game disclosure already lists such by name rather
than as "it", contrary to my expectations. (I had forgotten that end-of-
game forces true names so that blindness and hallucination don't interfere
with disclosure; obviously that ends up handling hidden monsters too.)
This patch attempts to add some levels of unicode support
to NetHack.
The master on/off switch for any Unicode support is
defining UNICODE_SUPPORT in config.h. Currently
there is code support for two subsets of unicode support:
UNICODE_DRAWING
If UNICODE_DRAWING is defined, then the data
structures used to house drawing symbols are expanded
to the size of wchar_t, big enough to hold unicode characters.
A typdef called `nhsym' is involved and if UNICODE_DRAWING
is defined, it is wchar_t, otherwise it is uchar.
UNICODE_WIDEWINPORT
If UNICODE_WIDEWINPORT is defined, then the data
structures inside the window port are expanded to the size of
wchar_t, big enough to hold unicode characters. Both map
symbols and text within the window port are expanded, in order
for potential support for displaying multinational characters some
day, but this patch only provides viewing of map symbols.
A typdef called `nhwchar' is involved and if UNICODE_WIDEWINPORT
is defined, it is wchar_t, otherwise it is char.
The only window port with code support for UNICODE_WIDEWINPORT
currently is the TTY port. Don't enable UNICODE_WIDEWINPORT
unless:
- it is a TTY port
- the underlying platform specific routines can
handle the larger data structures.
Don't enable UNICODE_SUPPORT unless:
- your compiler can handle wchar_t.
- your compiler can accept L'a' characters.
- your compiler can accept L"wide" strings.
Note that if your compiler can handle the above, you could
enable the larger data structures (currently if TTY) even if your
platform can't actually display unicode or UTF-8, by messing
with u_putch() in win/tty/wintty.c to only deal regular chars.
That should be the only function that actually pushes wide characters
out to the display.
If you enable UNICODE_SUPPORT, and your platform is capable
you will need to turn on the unicode run-time option to be able to
load unicode character sets from the symbol file, to be able to
push unicode characters to the display. You'll also want to load
a unicode symbol set once the unicode option is toggled on. In
a config file you would do that via these two lines:
OPTIONS=unicode
OPTIONS=symset:Unicode_non_US
The repository was stamped with NETHACK_PRE_UNICODE
prior to applying this patch, and stamped with
NETHACK_POST_UNICODE afterwards. The code differences
between those two tagged versions are this patch.
This patch attempts to add some levels of unicode support
to NetHack.
The master on/off switch for any Unicode support is
defining UNICODE_SUPPORT in config.h. Currently
there is code support for two subsets of unicode support:
UNICODE_DRAWING
If UNICODE_DRAWING is defined, then the data
structures used to house drawing symbols are expanded
to the size of wchar_t, big enough to hold unicode characters.
A typdef called `nhsym' is involved and if UNICODE_DRAWING
is defined, it is wchar_t, otherwise it is uchar.
UNICODE_WIDEWINPORT
If UNICODE_WIDEWINPORT is defined, then the data
structures inside the window port are expanded to the size of
wchar_t, big enough to hold unicode characters. Both map
symbols and text within the window port are expanded, in order
for potential support for displaying multinational characters some
day, but this patch only provides viewing of map symbols.
A typdef called `nhwchar' is involved and if UNICODE_WIDEWINPORT
is defined, it is wchar_t, otherwise it is char.
The only window port with code support for UNICODE_WIDEWINPORT
currently is the TTY port. Don't enable UNICODE_WIDEWINPORT
unless:
- it is a TTY port
- the underlying platform specific routines can
handle the larger data structures.
Don't enable UNICODE_SUPPORT unless:
- your compiler can handle wchar_t.
- your compiler can accept L'a' characters.
- your compiler can accept L"wide" strings.
Note that if your compiler can handle the above, you could
enable the larger data structures (currently if TTY) even if your
platform can't actually display unicode or UTF-8, by messing
with u_putch() in win/tty/wintty.c to only deal regular chars.
That should be the only function that actually pushes wide characters
out to the display.
If you enable UNICODE_SUPPORT, and your platform is capable
you will need to turn on the unicode run-time option to be able to
load unicode character sets from the symbol file, to be able to
push unicode characters to the display. You'll also want to load
a unicode symbol set once the unicode option is toggled on. In
a config file you would do that via these two lines:
OPTIONS=unicode
OPTIONS=symset:Unicode_non_US
The repository was stamped with NETHACK_PRE_UNICODE
prior to applying this patch, and stamped with
NETHACK_POST_UNICODE afterwards. The code differences
between those two tagged versions are this patch.
Add putmixed() to the window port. It allows map symbols to
be included in the string by encoding them in a unique fashion.
This was done because Unicode symbols, for instance, could be
longer than the size of a char.
The encoding of the map symbols in this patch is done by
prefixing a glyph value with \GXXXX, where XXXX is a
random value for the current game. The reason for the random
prefix is to minimize the possibility that a player can trigger
the escape sequence processing within text under their control
(dog names, etc.) the way they could if the sequence was fixed
in the source code. The random prefix remains the same throughout
the lifetime of a game because message window strings are
saved in the save file.
(There was actually a bug present because of the embedded
character even before the recent symbol changes, because if
someone was using a different set of characters between games,
the saved messages would reflect the original characters, rather
than the current. That bug was introduced with the ability to
save messages to the savefile.)
A window port does not have to supply an XXX_putmixed() routine,
it can use genl_putmixed() which uses the old behavior of
embedding the sequence as a character within the string
and calling putstr(). genl_putmixed() takes care of the decoding
of the escape sequence.
This also #ifdef's out code in pager.c for converting a glyph
to a character, and uses mapglyph() to do that instead. Does
anyone see a problem with doing that through mapglyph instead
of repeating similar code within pager.c?
From the newsgroup: if you were wielding a cockatrice corpse without
gloves while polymorphed into something capable of doing that, then were
turned to stone when rehumanizing, you'd be left wielding the untouchable
corpse if life-saving kept the game going. This causes it to stop being
wielded if you get that far. Likewise for monsters.
From the newsgroup: it was possible to saddle, mount, and ride on a
sleeping jabberwork without it ever waking up. Movement was checking for
timed sleep (!mon->mcanmove, set when mon->mfrozen contains a timer count
for either sleep or paralysis) but not indefinite sleep (mon->msleeping).
This moves the checking into its own routine which handles both types.
And it gives monsters a chance to wake up when they get saddled or mounted.
Extend the identifying information used to prefix paniclog entries
from version + date to version + date + time + userid + mode (where mode
is 'D' for wizard mode, 'X' for discover mode, and '-' for normal play).
hacklib.c ended up getting more of a revision than I intended, but
the date/time handling routines now have less clutter. I hope I didn't
break anything in the process.
There is a quote in data.base for squeaky board traps:
A floorboard creaked. Galder had spent many hours tuning them,
always a wise precaution with an ambitious assistant who walked
like a cat.
D flat. That meant he was just to the right of the door.
"Ah, Trymon," he said, without turning, and noted with some
satisfaction the faint indrawing of breath behind him. "Good
of you to come. Shut the door, will you?"
[ The Light Fantastic, by Terry Pratchett ]
This patch makes each squeaky board trap on a level produce
a unique sound. If you had visited the trap yourself prior
to hearing a monster on it, you could actually know where
a monster was by the unique pitch of the squeak.
If someone wants further refinement of the roles, this could
be adjusted to only work for musically adept roles/species,
with the others only hearing a generic squeak. As it stands
right now, everyone benefits. Does anyone thing the
separation by role or species would be good? If so, which
roles/species are musically proficient, and which are not?
Since this patch increments editlevel anyway, it also sneaks in a
context structure change for an upcoming patch.
From a bug report: if you
attempted to eat a Rider corpse and got the 1/7 chance that non-yet-rotten
food will be treated as rotten, then also got "the world spins and goes
dark" result for rotten food, you would both survive the eating attempt
and also end up with a partly eaten Rider corpse. This patch treats Rider
corpses like lizard and lichen corpses; they'll never yield rotten food
effects. That way, they'll always be fatal to eat. They'll still end up
being partly eaten if you are life-saved, but since they'll immediately
revive, the only way you'll know that is to use probing or stethoscope to
discover that they've revived at less than full health.
Nearly two years ago, <email deleted>
suggested that lembas wafers and cram rations be treated like fortune
cookies and never yield the rotten food result. I'm guessing that cookies
are handled that way so that rotten food feedback doesn't override false
rumor delivery when they're cursed, rather than because they're considered
to be rot-proof. This implements <Someone>'s suggestion, except that cursed
lembas and cram will still behave like rotten food.
One from the way-back machine. A nurse would hit you-as-cockatrice repeatedly
and never turned to stone. With this change, nurses will turn to stone (and
also don't heal cockatrices, which seems fair). I considered giving them
gloves, but that seemed like too much effort. There are other cases where a
monster "hits" but will not petrify. However, it doesn't seem like passiveum
detects all the specific ways the monster "hit" you so I left them alone.
The palette option is supposed to be allowed in the config file
without a value for win32 to trigger a load of a predefined
NetHack palette, but that wasn't working.
This fixes that. To prevent the use of any palette modification
code at all, just leave the palette option out of the config
file entirely.
Fido grows up into a large dog.
The soldier becomes a sargeant.
Similar feedback was previously given only when the monster was going to be
killed off due to its new form having been genocided.
The shortest extended commands were being formatted differently in
Guidebook.txt than longer ones, looking a little odd. Force them to seem
longer so that they all end up with similar formatting.
Untested; based on how short option names are handled. And I have no
idea whether the TeX version ought to have something similar done; I lack
the means to view it. (In theory I could format it into Postscript,
transfer the result to a PC [a different one than what I'm using as a
terminal], convert it into PDF there, then use Acrobat to look at it. In
practice, that's more effort than I care to expend for something so minor.)
<Someone> pointed out that bugles, although noisy, only affect soldiers.
This didn't make sense to me either. Added code so they will also affect
monsters near the bugler.
Pat Rankin wrote:
> I was about to also suggest that there
> be a rogue/non-rogue (with perhaps a third choice meaning "both")
> attribute. That way we could keep the rogue choices from being
> listed in the "symset" menu and the non-rogue choices from the
> "roguesymset" menu. Players who deliberately wanted to switch
> over would need to modify the attribute, possibly on a cloned set.
> Or perhaps they could just explicitly set their desired choices
> via NETHACKOPTIONS or .nethackrc and not use the 'O' menues--the
> new attribute doesn't necessary have to block which sets get used
> where, just filter menu entries to display the most applicable
> candidates.
Clean up the preprocessing associated with the
loadable symbol stuff.
Base it on new LOADSYMSETS, rather than on the
previously existing ASCIIGRAPH preprocessor define.
