I tracked down the widest lines, which sometimes occur due to mis-indent
of block comments (see tradstdc.h for an example), and fixed those up.
For the files affected, I also converted tabs to spaces.
A couple of macros with comments in the midst of their expansions got
badly mangled by the automated reformat and one ended up with a line
that was over 150 characters wide.
Some reformatting (replacing tabs with spaces), but mostly updating some
of the comments, particularly about SYSCF.
Shouldn't GENERIC_USERNAMES be controllable via SYSCF?
When reading a novel, select a random passage which hasn't been shown
already. Once you've run through all the passages, it resets to get
them all again (with new random order that might happen to the be same
order if there aren't many passages). Switching to a different novel--
even another copy of the same one--will cause the previous passage
selection to be discarded and restarted from scratch if the prior book
is read again. Passage tracking for the most recently read novel is
kept across save and restore. (That means I needed to bump EDITLEVEL,
so it will need to be reset to 0 again before release.)
The fun stuff section in config.h contains nothing fun anymore,
so let's remove it. Move SCORE_ON_BOTL to the next section,
and add couple other defines there too.
The memory leak (monst->mextra->edog, monst->mextra->mname,
monst->mextra for some monster were not released) I noticed recently
was due to recording a pet's full monster attributes with its corpse.
During save and restore, obj->oextra->omonst was being treated as a
full-fledged monster so worked as intended, but when freed, omonst
was treated as a black box and its mextra details weren't handled.
> Somebody has changed versioning so that the game incorrectly states
> 3.6.1 in messages. It looks like someone updated patchlevel instead of
> editlevel?
Yes, that was me. I meant to increment EDITLEVEL and nobody noticed
the mistake until now....
This changes PATCHLEVEL back to the correct value of 0, and implicitly
resets EDITLEVEL to 0 for release (by not changing it to 1 as it was
supposed to have been for the past 3-4 weeks).
Data files from Oct. 18 through today are actually compatible but will
be rejected once anyone rebuilds with this fix, same as would happen
when EDITLEVEL changs. Data files from before Oct. 18 will be
incompatible but be accepted by nethack but not work correctly due to
a change in the 'context' structure.
This should address the issue that the problem patch to display_pickinv()
was trying to deal with: releasing the inventory window before exiting
the program so Pasi's memory checker doesn't think it's a memory leak.
Not related, but in the same file:
The older qsort comparison routines are tagged with CFDECLSPEC to deal
with some C vs C++ interaction issue. I added that to the relatively
recently added 'sortloot' qsort compare callback.
I also changed worn_wield_only(), although it isn't actually called.
(display_minventory() has provisions to call it, but both of the latter's
callers pass in MINV_ALL so allow_all() gets used instead.)
Move this small utility routine to hacklib.c where other such things
live and where it's feasible to find them if you need the functionality
elsewhere.
Replace the code that Dean objected to with something a little bit more
robust. It doesn't rely on the two stacks being adjacent or having the
same inventory letter. It is still vulnerable to having another
splitobj() occur between the offending split and its attempted unsplit,
or to either of the two halves of a split being extracted from their
object chain. As before, failure to unsplit only results in the two
halves of the split remaining separate stacks, not anything more drastic
like the panic() that prompted all this.
Simplification of hallucinated currency names got mixed in with this
patch. I haven't bothered separating it back out.
Whoever reset PATCHLEVEL to 0 jumped the gun. This patch increments it
since change to the 'context' structure breaks save file compatibility,
so it will need to undergo another reset before release.
Flesh out wet towels a bit:
1) wielding a wet towel--or a dry one which becomes wet--won't give a
"you begin bashing with your wet towel" message when attacking;
2) if a formerly wet towel dries out completely while wielded, *do* give
"you begin bashing with your towel" on the next attack;
3) successfully hitting with a wet towel no longer always loses wetness;
4) water damage to dry towel always confers at least 1 point of wetness;
5) taking fire damage (via burnarmor() which is used for most types of
fire damage) has a chance to partially or fully dry a wet towel
(regardless of whether it's wielded at the time; applies to monsters
as well as hero; each towel being carried is checked until one is
affected, then any others escape drying.
Not done:
-) attacking with a wielded wet towel perhaps ought to be treated as a
weapon attack using whip skill rather than an augmented arbitrary-
junk-by-weight attack;
-) throwing a wet towel should probably ignore wetness--it's just a wet
piece of cloth when not finishing with a whip snap; right now, it
loses a point of wetness when thrown and usually--#3 above--another
point if it hits...;
-) hitting burning creatures is no different than hitting anything else;
-) likewise for hitting wet creatures.
Bustling Town can be generated with inaccessible areas outside the
top edge of the fixed town map. If you end up in one of those area
without any way to dig or teleport, you're stuck.
This adds a new level flag "inaccessibles" to force checking for
such inaccessible areas, and add secret doors, holes/trapdoors,
or some random escape item into the areas.
Implement the suggestion that applying a non-cursed unicorn horn can
cure deafness like other similar troubles. Also, applying a cursed one
can cause deafness, although I made the chance be half of what it is
for the other troubles since they tend to be more significant.
This is entry #2 on the bugzilla list, but I haven't figured out how to
update that yet.
Add macros W_WEAPON and W_ACCESSORY, similar to existing W_ARMOR, bitmask
of all the relevant worn bits. Just for code readability; there should
be no change in behavior.
Also, reformat the "ugly checks" portion of getobj(). Slightly better
readability and fewer continuation lines, but only a modest improvement.
Implement the requested feature to have an automatic annotation on the
dungeon level with the quest entry portal where you sense the leader
summoning you. It stays even after entering the portal (which results
in another automatic annotation of "portal to quest"), up until you
return to that level after having completed the quest.
Add a second one for the quest home level once the leader has given
you the go ahead to start the quest. After completing the quest that
one remains but its wording is changed.
This ought to haved incremented EDITLEVEL but I decided to risk leaving
current save files viable. That should work ok for anyone who isn't
overriding the default definition of Bitfield(), although odd behavior
could conceivably occur. New games have nothing to worry about.
Allow one item to be taken out of a pile, and leave framework in place
for partial splits so that all monsters will take up to their capacity,
rather than leaving the whole pile if it's too big to take all at once.
From Boudewijn:
> y a light (tame yellow light called Snertkat) [seen: normal vision,
> infravision]
> Snertkat deliberately jumps onto a polymorph trap!
So make yellow and black lights floaters.
Changes to be committed:
modified: include/context.h
modified: include/extern.h
modified: src/files.c
modified: src/invent.c
modified: src/sounds.c
modified: src/spell.c
Add a couple more tribute easter eggs.
- can lead to a remark by Death if you happen to have a pratchett book on
your person, as suggested by M. Stephenson (fat chance you will, or
think to #chat if you do, but it could be a tournament novelty or something
obscure to strive for).
- can draw some additional Death quotes from the tribute file. (There's two
in there right now. If anyone wants to add or suggest some more, please go
ahead. The Death quotes are at the end of the tribute file. One-liners
only please or the code will only pull the last line.
Three fixes, the first leading to the need to fix the second, and that
fix making dealing with the third be straightforward.
First, make the furthest level reached in any given branch be considered
interesting by #overview, even if no interesting features have been
encountered. This will result in listing Gnomish Mines and their first
level when someone goes down the stairs and immediately back up. It will
also produce a reminder of how far you've been--in each branch--after
retreating for any reason, without the need to manually add an annotation.
Second, #overview was suppressing the range of level numbers for Sokoban
because the author realized that the values were wrong. The record of
the furthest level reached was incorrect for builds-up branches, always
sticking with the deepest level even though it was the entrance. The
overview patch neglected to do the same suppression for Vlad's Tower and
the level range ("36 to 38" or similar) there was wrong. This fixes the
furthest level reached problem and also fixes #overview's level range
handling for builds-up branches.
Third and last, a long-standing issue which I don't think has ever been
formally reported: the level difficulty calculation used for monster
creation treated the upper (harder to get to) levels of builds-up branches
as if they were easier since they're closer to the surface as the gopher
burrows. So sokoban generated easier monsters on its final level than on
the ones leading up to that. Make depth for difficulty purposes account
for descent to the entrance and then ascent to the level of interest.
There was a distressing amount of trial and error involved. The dungeon
layout structures are not exactly easy to work with, and I never managed
to get builds_up() based on branch data to work correctly. Basing it on
dungeon data works as intended provided the branch has more than one
level, but it will yield incorrect result if we ever add a single-level
branch reached via stairs up rather than stairs down.
Add MG_OBJPILE flag, which windowports can use to check if a location
has more than one object stack. If use_inverse is on, TTY will use
inverse to show such piles. If a boulder is the topmost item on a pile,
then the object pile flag is not used; mainly because boulders are "solid",
boulders dropped by monsters are nearly always over other objects, and so
that special levels such a Sokoban can "hide" items under the boulders.
TODO: a "pilemark", analogous to "petmark", perhaps a green plus sign,
which can be used by windowports with tiles.
Changes to be committed:
modified: doc/window.doc
modified: include/qt_win.h
modified: include/trampoli.h
modified: include/winX.h
modified: include/wingem.h
modified: include/winprocs.h
modified: include/wintty.h
modified: src/display.c
modified: src/windows.c
modified: sys/amiga/winami.p
modified: sys/amiga/winfuncs.c
modified: sys/amiga/winproto.h
modified: sys/wince/mswproc.c
modified: sys/wince/winMS.h
modified: win/Qt/qt_win.cpp
modified: win/X11/winmap.c
modified: win/chain/wc_chainin.c
modified: win/chain/wc_chainout.c
modified: win/chain/wc_trace.c
modified: win/gem/wingem.c
modified: win/gem/wingem1.c
modified: win/gnome/gnbind.c
modified: win/tty/wintty.c
modified: win/win32/mswproc.c
modified: win/win32/winMS.h
print_glyph now takes a second parameter.
Tiles on tiled ports always looked odd on places like the plane of air
where the background color of the tile didn't match the general background
of the surrounding area.
3.6 made that even worse and more glaringly noticeable with the introduction
of darkened room tiles.
The code to actually send something useful through the new parameter
for window ports to take advantage if they want will follow.
The Blindfolded_only macro didn't track u.uroleplay.blind so would
give a false positive if wearing a blindfold, not able to see due to
the blind option, and not afflicted with any other blindness factors.
Dipping a worn blindfold into holy or unholy water is supposed to
reveal a glow if that blindfold is the only reason for blindness but
the glow was described even when blind-from-birth.
There's no feedback at all when the glow isn't seen. I'm punting on
that one. (This change didn't introduce that, just added one extra
situation where it happens.)
Honor things like OPTIONS:role=!tourist and NETHACKOPTIONS='race=!orc'
when performing interactive role selection. I don't think it was
completely correct when players let the program choose, but it must
have been close enough because we haven't gotten any complaints.
The post-3.4.3 interactive selection was ignoring options-base filtering
entirely and did get complaints for the pre-beta.
Role selection has a ton of code which bloats the program without doing
anything useful for actual game play. It ought to be split off into a
separate front end.
Changes to be committed:
modified: include/botl.h
modified: include/extern.h
modified: include/wintty.h
modified: src/botl.c
modified: src/options.c
modified: src/windows.c
modified: win/tty/wintty.c
get the tty versions started
