new .h files: hacklib.h selvar.h stairs.h
new .c files: calendar.c, getpos.c, report.c, selvar.c, stairs.c,
strutil.c, wizcmds.c
cleanup of hacklib.c and mdlib.c
hacklib contains functions that do not have to link with the core
relocate wiz commands from cmd.c to wizcmds.c
relocate CRASHREPORT stuff to report.c
relocate getpos stuff from do_name.c to getpos.c
remove temporary struct definition from extern.h
cross-compile PRE-section split into cross-pre1.370 and cross-pre2.370
Windows sys/windows/Makefile.nmake and sys/windows/Makefile.mingw32 and
visual studio project file updates
Unix sys/unix/Makefile.src, sys/unix/Makefile.utl
populate selvar.c and selvar.h
build on MS-DOS (not cross-compile) Makefile updates
for sys/msdos/Makefile.GCC (untested)
vms updates for above (untested)
Replace tabs, split 'if (condtion) do_something' across two lines,
insert lots of spaces in things like 'if(condition){'. I changed
a lot of C++ style comments to traditional C style, but left quite
a few of those as-is.
This also rewrites the code that pull request #1216 purports to fix.
I still can't make sense of the original and the patched edition.
Supersedes #1216Closes#1216
The 0x1000000 bit (NH_BASIC_COLOR bit) was used to mark
CLR_BLACK when storing it in u->ucolor. Now, all of the basic CLR_*
colors are stored that way.
The NH_BASIC_COLOR bit indicates that the value in u->ucolor is
not an rgb value, rather it is one of the 0-15 basic NetHack colors.
The window-ports need to strip the NH_BASIC_COLOR bit off before using
it for color changes.
creates new coloratt.c file
Also, this attempts to fulfill a wish-list item by paxed, to
allow naming colors in symbols file by name as an alternative
to using r-g-b values. The basic color names as well as html
color names are supported.
Calling sprintf with NULL string for a %s format identifier seems to be
undefined behavior. I got some semi persistent crashes while calling
the extend options menu with mO.
Any plain text symbol set specified in .nethackrc or NETHACKOPTIONS
didn't get loaded but did set the symset name.
Faulty 'if' logic excluded loading of symbol sets that used the
default handling type of H_UNK.
Recharge only handles items carried by hero.
I don't think it really matters that we just skip it, but leave
a FIXME in the code if anyone has enough energy to improve this later.
Fallout from the unified item destruction.
Add options 'showvers' (boolean) and 'versinfo' (numeric mask) to
show nethack's version on the status lines during play. It won't be
particularly interesting to ordinary players but should be useful
when making screenshots or video to be streamed, or for someone who
switches between git branches or between nethack and variants.
I worked on this several months back but it was combined with
unfinished changes to 'hitpointbar'. I've separated it out so that
it can be put into use. When enabled, one or more components of
"<name> <branch> <version>" will be shown right justified after
status conditions. At present the default is "<branch>" if that is
available and overall status isn't 'released', or "<version>" if
'released' or if branch isn't available. That might need some
refinement.
It works as intended for tty and curses, although some abbreviation
mechanism would be useful if/when the program resorts to abbreviating
status conditions to make things narrow enough to fit.
For X11, it works ok for fancy_status:True (the default, controlled
via NetHack.ad settings) but is messed up for tty-style status. The
text is positioned correctly but there are gaps in it, making it
appear garbled, similar to what I saw when I tried and failed to
implement statuslines:3 for X11. [It might be due to having empty
condition widgets be 1 pixel wide instead of being totally removed
but I don't think the situation is that simple.]
For Qt, if the text needs to be truncated in order to fit, the center
portion of the string will be shown, discarding parts from the left
and right. That ought to discard from left and retain rightmost
portion instead.
For win32|mswin|Win GUI, no attempt to support it has been included.
Things should be ok when 'showvers' is left as False (the default)
but I don't know what will happen if that gets toggled to True. At a
minimum, the version info won't be right justified. The information,
or at least some of it, is displayed in the game window's title bar
so there isn't any pressing need to add it to status, but toggling
the option will need to behave sensibly if it doesn't already.
Adds a new extended command #lookaround, which will describe
the map around the hero they can see or remember.
Adds a new boolean option mention_map, which will give a message
when an interesting map location in sight changes.
When makemon was called with all-zero arguments (e.g. for random
monster generation over time), ptr==NULL means "a random monster".
This was being forwarded to mon==NULL in makemon_rnd_goodpos, and
then mtmp==NULL in goodpos, which means "an object, not a monster".
Because objects can be generated under monsters, this meant that an
attempt to create a random monster could end up choosing a location
that already had a monster, which would then cause the monster
generation to fail.
This mostly wasn't noticeable in normal play: it effectively
reduced the monster generation rate depending on how many locations
outside LOS happened to contain a monster. Normally that's a very
small proportion, so the bug had no obvious effects: but when there
are very few locations outside LOS (i.e. the player can see almost
every location on the level), the bug effectively caused monster
generation to stop once those locations became occupied by
non-moving (e.g. hiding) monsters, something that became observable
in games where the player decided to dig out and light almost an
entire level.
This commit fixes the problem by adding a new flag to goodpos that
requests that it not choose a position that already has a monster.
This bug was diagnosed, and this fix committed, by ais523; but
nhmall wrote almost all of the code implementing the fix.
Insert a space between cast operator and target.
For 'x | y' expression spanning multiple lines, split with bitwise OR
operator at the beginning of second line instead at the end of first.
I changed a macro that was expanding to 'expr_1; expr_2' into
'(expr_1, expr_2)'. Both expressions modify arg 'a' which would be
a no-no within a single expression, but the comma operator provides a
sequence point that guarantees that the first expression will be fully
evaluated with side-effects--assignment to 'a'--completed before the
second one starts, making both assignments be well defined.
Add a new boolean option showdamage, if on, outputs a message
like "[HP -2, 14 left]" - several variants have something similar,
but I chose the message based on how eSpeak said it, while keeping
it short.
A bunch of routines return a pointer which is never Null but weren't
telling the compiler that such was the case. A couple (strsubst(),
stripchars()) were accepting Null output argument and then returning
Null, but callers had no reason to use them that way, so they've been
changed. (upstart() could have been changed similarly; I've already
forgotten why I left it as-is.)
The recent "trap.c reformatting" commit included a non-formatting
change switching from gb.bhitpos.x,.y to local x,y in the rolling
boudler trap routine. The part of that routine used when a rolling
boulder hits another boulder and transfers its remaining momentum
to that other one got switched to wrong x,y and the first boulder
basically kept going, possibly hitting itself at each new position.
DUMPLOG requests the DUMPLOG feature as it does now
DUMPLOG_CORE requests the internal buffering only (used for CRASHREPORT)
This allows CRASHREPORT to access recent messages without performing
any file I/O.
Note: Original change is from xNetHack by copperwater <aosdict@gmail.com>,
but this commit comes from HACKEM-MUCHE by Erik Lunna, with
some minor code formatting.
From xNetHack commit a0a6103bea:
'The original goal: nerf item destruction using a method I initially
proposed for SpliceHack, in which the number of items subject to
damage from any single source is limited by the amount of damage the
effect caused. The intent was to be more fair all around and prevent
aggravating situations where, for instance, a chest shock trap zaps
you for 4 damage and immediately ten of your rings and wands blow up.
Problem 1: no easy way to limit the items destroyed without biasing
heavily towards the start of the invent chain. The old code was able
to get away without bias by just indiscriminately destroying
everything eligible with a 1/3 chance. Here, I had to introduce
reservoir sampling in a somewhat more complex form than I've applied
it elsewhere, since there are a pool of potential items.
Problem 2: destroy_item no longer worked remotely like destroy_mitem,
which still destroyed 1/3 of items indiscriminately. Commence the
process of squishing them into one function that handles both the
player and monsters. (Which required making a lot of adjustments to
destroy_one_item, now named maybe_destroy_item, on nits such as
messaging and when to negate damage. An annoying consequence of the
merge is that in the player case, their HP is deducted and they can
be killed directly, but for monsters they need to add up the
destruction damage and return it.)
Unifying destroy_item and destroy_mitem has some advantages: in
addition to the obvious code duplication removal, it ensures monsters
now take the same damage as players for destruction (previously they
took a piddly 1 damage per destroyed item). Now when you hit
something with Mjollnir and their coveted wand of death breaks apart
and explodes, you at least get the satisfaction of knowing they took
the standard amount of damage from it. Monsters also now get
symmetry with players in having extrinsic elemental resistance
protect them from item destruction, and damage negation from item
destruction if they were appropriately resistant.
Problem 3: a lot of callers didn't preserve the "amount of incoming
damage" that this refactor relies on. E.g. if the defender resisted
that element, the local dmg variable would be set to 0. So I had to
do some wrangling with callers to save that original damage
value. The rule of thumb is: all *incoming* damage counts. So that
includes the player's spellcasting bonus if applicable, but not
things like half damage, negation due to resistance, or extra damage
due to being vulnerable to cold/fire.
Then I figured, while I'm here let's get rid of all those silly cases
where destroy_items is called multiple times for various different
object classes, and cut the object class parameter out of it. This
has a few minor effects:
- Places where different object classes previously rolled
independently for destruction to happen at all now roll
once. (Which, by my calculation, generally means less incidences of
destruction - a fire attack now won't have three separate chances
to hit your scrolls, potions, and spellbooks. On the flip side, a
lucky roll will no longer save an entire object class in your
inventory.)
- Callers can no longer specify different probabilities for
destroying different object classes. The only place this was really
used was to call destroy_item with a slightly lower probability on
SPBOOK_CLASS. With the nerf in this commit, less of them ought to
be destroyed anyway.
- A very edge case of where explosion-vs-monster damage was totted up
differently for golems, which could result in differences of a hit
point here or there.
- All object classes being processed in one go means that less items
are destroyed than would be if they were still processed
independently. This is not really visible compared to the old
baseline of just destroying 33% of everything, but would be a
marked difference versus a copy of the game that still called
destroy_items separately for different object classes. To
compensate, I adjusted my planned damage-to-destruction-limit
scaling factor down from 8 to 5.
Not done: merging in ignite_items(), though that would probably be
really easy now.'
Notes from porting from xNetHack:
- It might be necessary to reexamine at all the conditional checks for
calling destroy_items. Because item destruction is much more
restrained and uses the actual damage from an effect, we might now
need to check 'if (!rn2(3))' and similar in all the places item
destruction occurs.
Monstly changing '<type>* <var>' to '<type> *<var>'. Wrap or shorten
a few wide lines.
One of the rolling boulder routines accessed gb.bhitpos.x,y many times;
change that to use local x,y instead.
If a punished hero's inventory is empty, have a nymph usually take
off the attached chain and indirectly fix punishment. If hero is
trapped by being chained to a buried iron ball, sometimes take off
the implicit chain and indirectly release hero from the trap.
Monkeys won't do this and nymphs will only do so if there is no
inventory (aside from gold and/or embedded dragon scales which they
aren't allowed to target).
It's a lot simpler than I was expecting when I wrote the TODO about
it recently.
If a trap is blocking levitation or flight and you use wand of opening
or spell of knock to get out, you'd get things like
|You start to float in the air!
|You are released from the bear trap.
Give the release message before the actual untrapping.
Simplify the valid-position highlighting via '$' by combining the
tmp_at(start) and tmp_at(populate) steps.
Add highlighting for a couple of targetting operations that would
give valid/invalid feedback via autodescribe but weren't displaying
highlight markers for $.
I made several jumping changes, most of them dealing with picking
hero's own spot.
Redo getpos() highlighting. If bgcolors is Off, '$' toggles between
no highlighting and showing dollar signs at valid spots. ^R removes
those if they're present. When bgcolors is On, '$' cycles among
three settings: highlighting via background color, no highlighting,
and highlighting by drawing dollar sign characters. ^R switches to
background color mode.
This doesn't directly solve the problem of background color causing
conflict with the foreground color of some objects or monsters, but
being able to get rid of the background with a keystroke should be an
improvement.
'bgcolors' defaults to On, which was a problem for tty when 'color'
was Off. Turn it Off (in the core) for text map if color is Off and
bgcolors hasn't been explicitly set. Conversely, Qt was leaving
color Off and then using color with abandon. Turn in On (in the core)
for tiled map if it hasn't been given an explicit value. Those two
changes should cope with most situations and still let the player
override.
