Add pickup_stolen option to autopick items stolen from you by a nymph or
monkey, even if they don't match your normal autopickup settings.
Replace was_dropped, was_thrown with a 2-bit bitfield that can contain
values LOST_DROPPED, LOST_THROWN, and LOST_STOLEN (or 0), since they
should all be mutually exclusive anyway as they track the most recent
way the item left the hero's inventory.
[Rebase/merge conflict fixed up. PR]
Previously, if you threw a dagger into a pile of daggers, you'd pick up
the entire pile with pickup_thrown on. Since pickup_thrown and
dropped_nopick options are supposed to apply specifically to items
you've handled, don't merge items with different values in those fields.
This is based on a feature in UnNetHack (and I think some other variants
as well). If the hero intentionally drops an item with 'pickup_dropped'
disabled, don't autopick it back up when walking over that square again.
Typically when the player drops an item, it's because she doesn't want
it in her inventory any more, and this option stops autopickup from
defeating that goal (especially useful for tasks like stash management
without a container). Players have come up with workarounds to this
problem like toggling autopickup when approaching their stash pile or
adding name-based autopickup exceptions to allow them to exclude
individual items from autopickup, but this behavior should reduce the
need for those things.
I think 'pickup_dropped' is a little unfortunate because it suggests
equivalence to 'pickup_thrown' (i.e. any dropped items will be
automatically picked up regardless of autopickup exceptions). Calling
it something like 'nopick_dropped' might be better, but as far as I can
tell options cannot start with the word 'no' because it's interpreted as
a negation of the rest of the option name.
When known discoveries was displayed on a window of type NHW_MENU,
header lines sent to it via menu_add_heading() disappeared into the
bit bucket. Switching back to putstr() made them show up. But I also
changed the type to NHW_TEXT. A menu_add_heading() in artifact.c was
overlooked, and after the window type change that started triggering
a panic when '\' or '`a' was used while any artifacts were discovered.
Not sure how other interfaces were dealing with this.
Thinko in the reformatting, not triggered during testing because I was
using !CRASHREPORT. With it enabled, setting a watchpoint in gdb on
something unrelated resulted in nethack going into crashreport_init()
and never caming out. (I imagine that it would have eventually but 10
or 15 minutes with nothing noticeable taking place was unbearable, and
the program hadn't even really started yet.)
Fixup some of the inconsistently formatted code that has been
introduced recently or been building up for a while. Done manually.
I wasn't systematic except for looking for lines ending in '&' or '|'
(which wouldn't find such things if they're followed by a comment)
so there might be lots more. I changed a bunch of C++-style //...
comments to old style C /*...*/ so that they'll match the rest of
the core's code rather than because they shouldn't be used.
A couple of things I noticed while running umpteen tests for tty
perm_invent. Remove the update_inventory() from unmul(), and limit
the one that deals with seeing inventory when recovering from blindness.
Just a drop in the bucket overall, and the screen updates nearly
instantly for update_inventory() except when debugging perm_invent so
players aren't likely to notice this.
As part of the tty resize handling revision, code dealing with the
perm_invent window was moved out of tty_destroy_nhwindow() was moved
into a separate routine. The new routine would have been called for
a window of NHW_PERMINVENT, but WIN_INVENT doesn't have that type,
just ordinary NHW_MENU, so the cleanup wasn't happening, resulting in
a memory leak.
Silence a bunch of complaints from heaputil about freeing Null
pointers. The C standard allows that but it makes the data collected
about mallocs and frees not match up when nethack has MONITOR_HEAP
enabled.
There were 6 brown 'd' monsters; move wolf and werewolf to grey,
and warg to black, as those colors had no canines.
The wolf tiles are already greyish; changed warg tile to be
slightly darker.
where calling term_start_color(NO_COLOR) would have the same
effect as calling term_end_color().
That change only included a change for termcap, but not any of
the NO_TERMS configurations. (NO_TERMS is defined for an
implementation where termcap is not used).
This attempts to make sys/msdos/video.c and sys/windows/consoletty.c
honor the change.
The msdos change has not yet been tested.
No attempt was made to alter the term_start_color() implementations
within the outdated tree.
opttext[] was given 120 elements but the MAXOPT macro used to limit
populating it was only 40. There happen to be exactly 40 lines of
runtime info--at least for my config--and the last slot was going to
waste, so the final dupstr("") at the end of build_options() wasn't
being tracked and freed.
It's interesting the whatever other memory checker is being used
failed to find something caught by old heaputil. Maybe the configs
running whatever it is are generating smaller options text?
There are many red major demons, and hezrous and vrocks
now emit poison gas, so change the symbol color to green.
Also adjust vrock tiles to have green. The hezrou tiles
already are green.
I think this fixes all problems with the boundary boz drawn around
perm_invent. Also, if you enabled perm_invent in inuse_only mode
while there are already more items in use than would fix in the
available number of lines, it wasn't switching to two columns until
the next update_inventory(). And the new color handling wasn't
incorporate into tty_refresh_inventory() so after a corner window
clobbered some of perm_invent, it got redrawn but without color,
again until the next update_inventory().
With any luck this fixes more bugs than it introduces....
Make term_start_color() more versatile. If it gets passed NO_COLOR
then it performs term_end_color(). Should be able to streamline
some of the color handling this way although this hasn't done so.
Prior to this commit, there was no good way to deal with swarms of
weak, good-AC enemies using magic; trying to play a wizard as a
pure spellcaster would make bees and ants very difficult to deal
with (because they would usually dodge force bolts).
This commit adds a new spell designed to be very good against
swarms of weak enemies: "chain lightning", which does 2d6 lightning
damage to every monster around you. It has an initially short range,
but can chain from monster to monster to cover potentially large
distances (as long as none of the monsters en route are shock
resistant or tame/peaceful; the spell can't chain past shock
resistant monsters and avoids peacefuls). Monsters within one
space of the visible lightning bolts are affected. Unlike other
lightning effects, this one does only 2d6 damage, not enough to
blind affected monsters.
This commit breaks existing save and bones files (thus the
EDITLEVEL increase).
Features like menucolors and so forth, are now done in the
core, and passed to the window interfaces via add_menu().
TTY_PERM_INVENT was disregarding the passed color value.
That can be turned off by the option !menucolors.
If a way to turn off menucolors in TTY_PERM_INVENT (or
perhaps in any perm_invent implementation), while keeping
it on for other menus, then a new option will be required.
Revise the tty permanent inventory window's in-use mode to be able to
switch back and forth between one full width panel and two side-by-side
half width panels on the fly as needs dictate.
A lot of trial and error involved but I think it has reached a state
where it is reliable, and the smaller number of lines required at
present can probably be viable for actual usage. At the moment it
requires at least 10 extra lines below the standard tty mesg+map+stat
display, 34 lines total for statuslines:2 or 35 for statuslines:3.
The top and bottom of the 10 or more extra lines get drawn as boundary
lines using wall characters, leaving 8 lines for full width or 16 half
lines when 8 isn't enough. If more that 16 items are in use (maybe
lots of lit candles forced into separate inventory slots or a
menagerie on leashes), the excess get skipped. However, it will use
more lines if they are available. Prior to a few days ago it was
requiring 17 extra lines and able to show 15 items as full lines only,
unable to take advantage of more lines when available.
The change to Sokoban difficulty calculation introduced a balance
issue: previously the Sokoban prize was obtainable before item-
destruction attacks became common and would protect from them,
whereas now they commonly appear in Sokoban itself, before the
prize is accessible. This makes scrolls and potions much less
usable as escape items, and potions of healing less usable for
HP recovery, because they either get stashed or destroyed (and
in either case aren't usable by the character in time-critical
situations).
This commit attempts to alleviate the problem by adding a way to
protect items from cold and fire in the early game. It's a
little unreliable, and requires equipping an item that has bad
stats and generally isn't otherwise used, but which is generally
easy to find early on.
Not included in this commit, but probably necessary for a
"finished" version of the feature: some way of letting players
know the new mechanic. It shows up in enlightenment, but there
should probably be at least rumors (and maybe even a major Oracle
consultation) hinting at the mechanic. We might also want to
change the unIDed description of the dwarvish cloak as a hint,
although that would require, e.g., new database entries.
The same checks were being repeated for every damage type; this
sends them through two centralised functions (one for checking
whether an extrinsic blocks a specific instance of item destruction
and one for the enlightenment message), so that new mechanisms of
item destruction prevention will need to change only one point in
the code.
Allow perm_invent to be enabled with 1 less line when statuslines==2
by not reserving a line for statuslines==3. If the player changes
that from 2 to 3, the perm_invent window is torn down and repositioned
one line lower if that will fit. If it won't fit, it won't reenable.
Temporarily(?) allow perminv_mode==InUse to be enabled with room for
only 8 lines instead of requiring 15. It will use more than 8 if are
more rows.
8 happens to be the amount (via 1+21+3+(1+8+1)) that will fit within
35 lines which is the biggest I can make fit on may laptop without
switching to a smaller font. Switching is a nuisance, worse than that
for the font tiny enough to fit the full perm_invent.
ToDo: if in-use won't fit in the number of lines allotted, switch to
two columns before resorting to ignoring the excess.
Maybe: allow fewer lines for full perm_invent too and use the '|'
command to scroll them. Might be too clumsy to be worthwhile.
A few add_menu_heading() calls were added to the '\' and '`' commands
which use a text window rather than a menu. For some reason they were
using create_nhwindow(NHW_MENU) but only populating it with text so
the heading lines sent as menu entries were lost. (Might panic with
Qt; I didn't check.)
