Add a bc sanity check. It seems to work ok--in other words, not
trigger--under normal punishment. I don't have any test cases to
exercise its warnings.
This dragged in a couple of minor bc changes that were pending. I
should have cleared those out before tackling the sanity checking.
Make being trapped in/on/over floor block Levitation and Flying, the
way that being inside solid rock already does, and the way levitating
blocks flight.
Blocked levitation still provides enhanced carrying capacity since
magic is attempting to make the hero's body be bouyant. I think that
that is appropriate but am not completely convinced.
One thing that almost certainly needs fixing is digging a hole when
trapped in the floor or tethered to a buried iron ball, where the
first part of digactualhole() releases the hero from being trapped.
If being released re-enables blocked levitation, the further stages
of digging might not make sense in some circumstances.
I recently realized that being held by a grabbing monster is similar
to being trapped so should also interfere with levitation and flying.
Nothing here attempts to address that.
Save files change, but in a compatible fashion unless trapped at the
time of saving. If someone saves while trapped prior to this patch,
then applies it and restores, the game will behave as if the patch
wasn't in place--until escape from trap is achieved. (Not verified.)
Changes to be committed:
modified: doc/fixes36.1
modified: src/ball.c
I looked up the original bug report that led to bug page C343-20
"When dying immediately on entering a level, the map may show you dying on the previous level."
It was received public report U891:
> When one is being punished and goes down a staircase and dies because the
> ball and chain fell on their head, one gets the message about their death
> while the old level is still being displayed. I wasn't sure whether this
> was a bug or not because on one hand it wouldn't make much sense to
> generate a new level if the character is going to die anyway. However,
> that being said it does make a difference if the character is about to go
> down into a level where one cannot leave bones files, ie medusa or the
> first level of the mines (if i remember correctly). So, if your character
> dies from this does the bones file get left on the level you were on
> (which is still displayed at the time of death) or the level you died as
> soon as you got to (but was never displayed)? Thanks!
Pat had remarked in response: "So this is just a display issue; game play works as intended
(for the program; I imagine you weren't planning to get killed."
A debug trace in wizard mode 3.6.1 beta shows that the relevant code path is this:
NetHack.exe!done(int how) Line 908
NetHack.exe!losehp(int n, const char * knam, char k_format) Line 2678
NetHack.exe!drag_down(...) Line 823
NetHack.exe!goto_level(d_level * newlevel, char at_stairs, char falling, char portal) Line 1316
NetHack.exe!next_level(char at_stairs) Line 1157
NetHack.exe!dodown(...) Line 954
NetHack.exe!rhack(char * cmd) Line 3416
NetHack.exe!moveloop(char resuming) Line 464
NetHack.exe!main(int argc, char * * argv) Line 104
This patch clears the display for the situation in drag_down(),
so the old level is not shown.
Fixing up mis-indented block comments, but hit some files that hadn't
had the earlier mixture of tab replacement, etc, so it's bigger than I
expected. If I get to it, they'll be another round of this tomorrow.
Mostly && and || at end of the first half of a continued line rather
than at the start of the second half. The automated reformat got
confused by comments in the midst of such lines.
foo ||
bar
was converted to
foo
|| bar
but
foo ||
/* comment */
bar
stayed as is.
Some excluded code [#if 0] was also manually reformatted, but this is
mainly stuff that can be found via regexp '[&|?:][ \t]*$' (with a lot
of false hits for labels whose colon ends their line).
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
Something I've had in mind for a long time and finally gotten around
to implementing: when you fill in the last pit or hole of a sokoban level,
it's considered to be completed so luck penalties for unsokobanish things
(breaking a boulder, dropping everything and squeezing onto a boulder's
spot, reading a scroll of earth) stop being assessed and most Sokoban-
specific movement restrictions (against pushing boulders diagonally,
squeezing diagonally between boulders, floating over a pit or hole without
falling in, digging of new holes by monsters) are lifted. Teleporting,
level teleporting, and phasing through walls are still prohibited when in
the sokoban branch of the dungeon. (Keeping the non-phasing one in place
prevents taking a shortcut to the final prize in order to bypass the
treasure zoo monsters.)
This adds level.flags.sokoban_rules, defines Sokoban macro to access
it, and replaces most In_sokoban(&u.uz) tests to check it instead. It
gets set when a sokoban level is pre-mapped at the end of level creation,
and if it is set then whenever a trap is deleted, the flag gets cleared
if there are no more pits or holes present on the level.
Wielding a bow while kicking arrows gave a shooting bonus. Also,
From a bug report: applying a
polearm to hit at range never caused a pudding to split because the attack
gets treated as throwing. Likewise, confuse monster effect (hands glowing
red) didn't kick in for applied polearms.
<Someone> reported the longstanding behavior that when dragging, the chain
does not always remain directly between the player and the ball. This occurs
when the player zigzags. Added a check to the simple drag code to try to
keep the chain directly between the player and the ball. But, don't do this
if the player is walking thru rock or if it would move the chain into rock.
- [fixed in trunk] iron-ball-pulling yourself out of a bear trap
- [fixed in trunk] Hitting your foot with a bullwhip
- [fixed in trunk] Hooking yourself with a grappling hook
- [fixed in trunk] Being thwacked by an iron ball chained to you
- [fixed in trunk] A crystal ball exploding on being applied
- [fixed in trunk] Hitting yourself with your pick-axe
- [fixed in trunk] Molten lava (entering or being splashed)
- [fixed in trunk] Getting squished in a pit under a boulder
- [fixed in trunk] Kicking something that makes you go "Ouch!"
This patch introduces a change to yname() and Yname2() that avoids the
possessive "your" for the hero's normal, fully identified artifacts.
Quest artifacts still get the possessive, as do all other objects and all
objects not in the hero's possession. shk_your()/Shk_Your() are used in
many places with a specific, generalized name for the object, so I didn't
introduce the artifact behavior there, although I did change them to append
a space, which simplified some other code. Through added use of yname(),
there may be some places that used to just say "corpse" that will now be more
descriptive via yname()'s use of cxname(). I'm sure <Someone> will point
out any such places that are too onerous, although nothing obviously is.
I took the opportunity to inspect many uses of "your" and even Your(). Two
new functions are also introduced, yobjnam() and Yobjnam2(), which work
like aobjnam() and yname() combined, because I found that many uses of
aobjnam() were preceeded by "your" and I couldn't generally provide the
desired behavior for artifacts (or future artifacts) without a combined
function. In some cases, this change allowed better sharing of code.
rust_dmg() still takes a string as input which is sometimes initialized
from xname() and often prepends "your" to it. Currently, this isn't a
problem since there currently are no normal, armor artifacts. If/when any
are introduced, rust_dmg() will need to be addressed.
The patch is for the trunk only. A lot of research was required and I
didn't feel the upside was there for repeating it in the 3.4.3 branch.
Prevent burying a ball from ending your punishment.
When you bury the ball, internally NetHack Punishment
ceases, but a new trap type of TT_BURIEDBALL immediately
kicks in (acting similar to TT_INFLOOR in some ways).
You can eventually work the ball free (or teleport, etc.),
but that will just return you back to normal Punishment.
<email deleted>
> comments: When dieing from an iron ball landing on your head, the death is
> listed as: "Crunched in the head by an iron ball"
> However no other deaths start with a capital letter.
Fixing some iron ball/teleds stuff:
-- If the player can pass through walls, ignore all checks for walls, or else
things will behave weirdly.
-- Instead of using the kludge "if the distance is >2 it must be a teleport",
pass a parameter indicating whether they crawled or teleported onto the new
space. This fixes a special case, where the player moved one space and the
ball didn't move, but the chain moved through solid rock. This is acceptable
if teleporting and unacceptable if dragging.
This also required some rearrangement of teleds() so that u.ux,u.uy
are set after placing the ball, not before. I'm still not sure the pit
filling line is in the right place; anyone know?
-- add some comments so I can look at the code in a month and still know what
I did.
Most of this patch is just adding the new parameter.
statement that could be followed by ';' anywhere. However, with the goto
there, my compiler complains every time it's used:
"ball.c", line 402: warning: statement not reached
"ball.c", line 434: warning: statement not reached
"ball.c", line 442: warning: statement not reached
"ball.c", line 449: warning: statement not reached
"ball.c", line 452: warning: statement not reached
"ball.c", line 457: warning: statement not reached
"ball.c", line 479: warning: statement not reached
"ball.c", line 498: warning: statement not reached
None of the current uses care about an excess statement, but is there a
way to satisfy both desires?
Well, this proved rather annoying. Problems included:
-- the solid rock problem that was noticed
-- teleporting to a spot two spaces away but on the other side of solid rock
could also leave the chain in solid rock
-- in one place I said chainx instead of ballx, which could cause problems with
teleporting
-- the teleport code moved the player before moving the ball, violating the
assumption that the player hasn't been moved yet (which only caused problems
after I added the solid rock fix).
Ball movement still isn't quite right, though the cases are really rare. I
may fix them later.
