Update the help text in setup.sh. When building with a hints file from TOP,
the path to the hints file should start from TOP (instead of "hints/foo").
Make the notes in the generated makefiles consistent as to case.
There was a second instance of curs()+flush_screen() that had the
calls swapped 5.5 years ago and is being restored to 3.4.3 state here.
It turns out that swapping the other instance of those two calls
didn't help with the original problem (^R during getpos() redrew the
screen but left the cursor at the end of the 2nd status line) at all.
Only adding the pline() call after docrt() fixed it. pline() calls
flush_screen(1) which ultimately puts the cursor back on the hero. I
still don't understand why curs(WIN_MAP,x,y)+flush_screen(0) leaves it
on the status line instead of at the specified map coordinates. That
must be a bug in the tty code somewhere.
This ought to fix the problem excountered by Ken, where the cursor
wasn't at the spot '/y' was reporting on. This reverses part of a change
from May, 2005. I still don't understand the original behavior, which
was that docrt() for ^R followed by positioning the cursor at a specific
map coordinate and calling flush_screen() was leaving the cursor at the
end of the second status line. Reversing flush_screen and curs(WIN_MAP)
made it work for tty but screwed up X11. It turns out that including
pline("Move cursor to %s:") *also* makes things work as intended, so that
the flush/position hack wasn't necessary once that other change went in
(same 2005 patch, but the cursor hack was implemented first at that time;
once this reversal is in place, commenting out the pline() does bring the
odd behavior for tty back).
Undo the win/tty/wintty.c bands of the H2344 fix until the fix is fixed. I
didn't take out the type changes to hopefully avoid putting people through
a full recompile.
branch only. This adds a check when setting a new fruit so that if no fruits
have been created since the last time the option has been set, the current
fruit is overwritten. Result: the user cannot repeatedly set the fruit
option and overflow the maximum fruit number.
The presence of conditional code for both UNICODE_WIDEWINPORT and
NEWAUTOCOMP in hooked_tty_getlin() was making it be pretty hard to read.
This simplifies the UNICODE_WIDEWINPORT parts similar to what was done in
topl.c a year or two back. The NEWAUTOCOMP parts are still cluttered.
This compiles successfully with UNICODE_WIDEWINPORT enabled but that
configuration is otherwise untested.
Change the post-3.4.3 extended command "#terrain" so that it can be
used in normal play rather than just in wizard mode. It's inspired by
a command in 'crawl' that lets you view the bare map without monsters,
objects, and traps so that you can see the floor at locations which have
been covered up by those things.
normal play
redraw map to show the known portion of it without displaying
monsters, objects, or traps; after player responds to --More--, the
map returns to normal.
explore mode
put up a menu so player can choose between the known portion of
the map as above or the full map. If the level isn't fully explored
then the latter provides information to the player that he hasn't
earned yet, but the _hero_ doesn't learn anything and after --More--
the map reverts to what it showed before. (In other words, unlike
with magic mapping, the unknown portion doesn't become known.)
wizard mode
put up a menu so player can choose among four alternatives: the
two above, the text representation of the map's internal levl[][].typ
codes, or a legend explaining those codes. (Originally, I wanted to
be able to toggle back and forth between these last two, but looking
at one and dismissing it, then reissuing #terrain to look at the
other is much simpler to implement and is good enough.)
My #terrain patch had a typo on the command line and was going
to include doc/fixes35.0 as the log text for a half-dozen files. I
aborted the commit but most of them had already made it into the cvs
repository. This reverts those changes so that the entire patch can
be re-comitted with the right log text. Ugh...
Noticed while looking into whether I could use DUNGEON_OVERVIEW data
for something useful, it was recording accurate terrain type for locations
covered by mimics who were mimicking furniture (such as stairs or altars).
Hero should remember the fake terrain rather than whatever is actually
underneath the mimic.
No fixes entry; user-contributed DUNGEON_OVERVIEW is post-3.4.3 code.
Some old wall display debugging code which gets enabled when
WA_VERBOSE is defined was missing the three terrain types (tree, iron
bars, grave) added way back in 3.3.0. It's extermely unlikely that
anyone other than Dean might actually ever be impacted by this....
This compiles with WA_VERBOSE enabled but is otherwise untested.
I haven't bothered with a fixes entry.
Redo the fix that prevents hangup from putting hero on top of water
if it occurs during magic mapping or object/gold/trap detection. Instead
of copying u.uinwater into another field in struct u so that it can be
reset during restore, copy it into a new field in struct iflags and reset
it during save so that no fixup upon restore is needed.
Noticed while looking at the magic mapping code: u.uinwater is
cleared during mapping and detection so that map updating isn't suppressed
due to underwater vision restrictions, and it was possible for a hangup
save to take place before that state field was reset. After restore, the
hero would end up standing on water, then fall in on the next turn. This
saves it in struct `u' rather than in a local variable, so that the stored
value is accessible during restore.
The u.uburied flag was being ignored, but presumeably it would also
impose severe vision restrictions if it ever gets implemented, so it is
now saved, temporarily cleared, and restored along with u.uinwater during
monster/object/gold/trap detection and magic mapping.
From a bug report, he was running blind while wielding scissors--
I mean Excalibur--and stopped for no apparent reason. The autosearch
capability conferred by that artifact (also by ring of searching, or for
some roles or races once they reach a particular level) had found a secret
door and changed it into a normal door, but since he couldn't see at the
time his map display wasn't updated to show that. This makes the map show
such things even if blind, and also gives a message that the search found
something.
From a bug report, dropping and selling a container that had some things owned
by the hero and some already owned by the shop, you could get "You sold
some items inside <a container> for N gold piecess." Shop handing for
containers has been changed significantly since 3.4.3, but the typo
"pieces" that then optionally gets plural "s" appended was still there.
While testing the trivial fix, I noticed suboptional feedback in the
prompt about selling. For a container owned by the shop, it said "items"
even when there was just one hero owned item inside. Fortunately this
potentinal can of worns only seemed to have one tiny weeny worm in it....
The revised version of count_buc() that I've had laying around for
a while is also included.
The fixes entry is for "piecess", not escaped/captured/exterminated
worms, and goes into fixes34.4 despite this patch being labeled "trunk
only". Separate patch for trunk to follow.
Removing ring or boots of levitation while stuck in solid rock was
silent as intended, but timeout of potion or spell said "you float gently
to the ground" even though there's no actual movement.
Using '>' command while in solid rock said "you can't go down here"
without attempting to toggle off controlled levitation.
Levitation side-effects get skipped if Levitation toggles while it
is blocked, so BFlying (the reason Flying is blocked) could become stale
in some situations. Enlightment feedback about latent flight capability
was the only thing affected.
From a bug report, flashing yourself
with a camera while in gremlin form blinded as with any other form, but
didn't inflict any damage the way that flashing a monster gremlin does.
This fixes that, and also makes light from wand/scroll/spell that hits
you-as-gremlin or monster gremlins do 1d5 damage too. It happens even
if the target is already in a lit spot, but doesn't continue afterwards:
simply being in a lit spot doesn't cause any damage, nor does lamp light.
From a bug report. The first report complained about levitation
allowing you to move through water on the Plane of Water, something that's
come up in the newsgroup lots of times (mostly about how levitation is
the best way to get around, only occasionally wondering why it works:
water walking doesn't work there because there's no surface, so where are
you levitating such that you're kept dry?) The second report complained
about being told you were floating up if you put on a ring of levitation
while stuck inside a wall (perhaps after being stranded when polymorph
into xorn form ended).
This implements intrinsic blocking for levitation and also for
flying. Being inside solid rock (or closed door) anywhere and being in
water on the Plane of Water are the things that do it for levitation;
those two and levitating are what do it for flying. Entering such
terrain turns off ability to float/fly, and leaving there turns it back
on; starting levitation blocks flight, ending it unblocks (levitation
has always overridden flying's ability to reach the floor). Being able
to phase through rock doesn't prevent levitation and flight from being
blocked while in rock; you aren't floating or flying in that situation.
Fix several obscure bugs that can happen when a guard leads someone
out of a vault:
1) non-pit traps created in the temporary corridor would persist inside
solid rock after the corridor was removed (pits dug by the hero were
explicitly removed but several other trap types are possible);
2) lighting the corridor with scroll/wand/spell left the affected spots
flagged as lit after they reverted to rock; tunneling through that
area, either by digging or by teleporting back to the vault and having
another guard appear, unearthed lit corridor there;
3) if you became encased in solid rock because you were in the temporary
corridor when it was removed (which will happen if the guard is killed
while you're in his corridor), you were only told so if you saw part of
it revert to rock; when blind, you simply found yourself unable to move;
4) dragging an iron ball in the temporary corridor could result in part
of that corridor becoming permanent if the guard was killed; in 3.4.3,
it would only occur if the cause of death took away all the guard's
hit points (which happens for most but not all deaths); in development
code after my recent patch, that would be every cause of death.
#4 could also yield "dmonsfree: <N+1> removed doesn't match <N> pending"
warning in 3.4.3 when the fmon list was scanned and a guard at <0,0> with
no hit points was found but hadn't passed through to the end of mondead()
and m_detach(). The previous patch fixed that, I think/hope. Most guard
deaths won't trigger that; grddead() moves the guard to <0,0> but then
removes the temp corridor on its second try, returns true, and mondead()
finishes normally.
Tested on the unix port; I've updated as many other ports as I can figure
out but they're not tested. See window.doc for info on the changed banner
lines. Also adds the ability to override the generic "Unix" port - used now to get
"MacOSX" into the version line instead of "Unix" (so we don't scare people who don't
know what's going on).
From the newsgroup: after killing a vault guard on a level where
every object had been removed or was held by the hero, object detection
gave feedback about finding something but was unable to show anything.
It was finding the dead guard's inventory at <0,0>, a part of the map
which never gets shown. A dying guard is sent to that location instead
of being killed and deleted, because the data for his temporary corridor
to/from the vault is kept in the egd structure attached to him. That's
somewhat obscure but works; dying guards just need to drop inventory
before being transfered there rather than after.
Depending upon how they're killed, it's possible that the umpteen
places in the code that loop over fmon might have been processing them
as if still in play. This sets their mhp to 0 so such loops will ignore
them, and teaches dmonsfree() not to release them. Once the temporary
corridor has been removed, their isgd flag is cleared and they become
ordinary dead monsters and get deleted from the fmon list the next time
it's purged.
This also lets you throw gold to/at the guard when he tells you to
drop it. He already would catch it, but now he won't treat the throw as
an attack. Any gold he carries will eventually disappear when he does,
so dropping it remains a better option for the player.
The ceiling on the Plane of Water is always "water above", not "sky"
when inside air bubbles and "water's surface" when outside. Also, support
throwing things upwards on the planes of air and water and when underwater
instead of silently dropping the missile in such cases.
This is mainly groundwork for a tangential bit of a forthcoming
levitation fix.
It's possible to ask for help on the first wish attempt, even though
the prompt hasn't been adjusted to mention that yet, so the one message
which is composed dynamically needs to have its phrasing tweaked a bit
more if the user happens to do that.
Also, allow help to be requested even when the cmdassist option is
toggled off. Now that option just controls whether the prompt string is
augmented for retry attempts.
