The call to hmon() in flooreffects() was passing a boolean where int
is expected. The 'thrown' argument may have once been a boolean, but
it is 'int' for as far back as the repository history goes.
Reported directly to devteam, player threw a troll corpse into lava and
then later got messages about it reviving and burning to death. Items
thrown, kicked, or dropped into lava were being subjected to fire damage
(so scrolls burned up, potions boiled, non-fireproofed flammable weapons
and armor eroded), but corpses and a lot of other stuff not subject to
erosion remained unaffected. This makes things that are made out of
wood, cloth, flesh and other flammable stuff burn up (when in lava, not
when hit by fire).
With menustyle set to "full" or "partial", using 'D' when not
carrying anything gave no feedback. (Modes "traditional" and
"combination" give "you have nothing to drop" via ggetobj().)
Also, there's no need to reset in-progress armor removal, lock
picking, or trap setting if you don't actually drop anything.
The inventory they're set to operate on or with stays intact.
When travel fails to reach its destination, it remembers the target
spot to use as default next time. But that spot is only meaningful
on the current level. Discard last travel destination when moving
to a different level.
Also, discard unlocking context when changing level unless the
context is for a container being brought along (after having been
picked up since you can't unlock a carried box). Previously, a
door pointer on the new level could happen to match the last one
being unlocked on the old level.
Discard trap setting context when changing level even if the trap
object is brought along.
Somehow the code for applying a touchstone got inserted in between
two sections of code for applying a trap (ages ago; probably since
touchstone was first introduced however many versions back), so
clean that up.
Reported directly to devteam 7-Jan-2016, two issues with cursed
potion of levitation:
1) the go-up-stairs effect for cursed potion still let you choose
not to escape the dungeon if it occurred on level 1 stairs. I've
left that as-is; perhaps there's a gate across the entrance.
2) both the go-up-stairs and bonk-head-on-ceiling effects were
skipped if the hero was already levitating. I don't know whether
that was intentional but there was no comment explaining why, so
I've changed it to happen regardless of whether already levitating.
In the process, I changed the head-bonk case to do more damage when
a helmet is worn:
old: no helmet 1..10 hp, any helmet 1 hp damage;
new: no helmet 1..10 hp, soft hat 1..6 hp, hard helmet 1..3 hp.
Also, not in the report: when you aren't already levitating you
get the "you float up" message, but for cursed potion there was
never any corresponding "you float down" message because you ended
up not levitating. Now you'll levitate for 1 turn and float down
on the next, landing in a trap if one is present.
Change the sortloot option to use qsort() instead of naive insertion
sort. After sorting, it reorders the linked list into the sorted
order, so might have some subtle change(s) in behavior since that
wasn't done before.
pickup.c includes some formatting cleanup.
modified:
include/extern.h, hack.h, obj.h
src/do.c, do_wear.c, end.c, invent.c, pickup.c
Globs on the floor used different criteria (anything goes) than globs
in inventory (mostly requiring same ownership when in shops and same
curse/bless state--other stuff generally isn't applicable) when
deciding whether two globs should merge. That was okay as long as
the globs on the floor were from being left behind when a pudding or
ooze was killed, but not if the player had picked some up, dipped
them in holy or unholy water, and dropped them again. This changes
things so that globs on the floor use the same criteria as globs in
inventory when deciding whether to coallesce.
Also, my earlier fix was modifying globs in the mergeable() test (to
make bknown and rknown match) rather than during actual merge, which
would be a problem if the merger didn't take place for some reason.
Suppress the "you climb/fly up the stairs/ladder" message if the
'verbose' option is off (unless punishment is going to augment the
message by "with great effort").
Reported directly to devteam: teleporting or polymorphing a sink when
dropping the relevant ring into it was suppressed if the hero couldn't
see it happen.
Being unable to see the sink transform or vanish shouldn't stop that
from happening. Since the hero is known to not be levitating (because
of the sink), it can be assumed that he can feel the transformation or
vanishment (is that a real word?), so use the same messages regardless
of blindness.
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.
Fix a couple of instances of a mis-indented block comment which happens
to be immediately preceded by an end-of-line comment. Change a couple of
| if (condition)
| something;
| else {
| other_stuff;
| }
to have braces around the 'then' part. Remove some gratuitous 'register'
declarations.
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.
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!
- honor blindness and hallucination
- honor ability to see one of the mergees
- provide audible feedback if appropriate
- merging inside pack gets special-cased so player knows something
different/unusual is happening
Changes to be committed:
modified: include/extern.h
modified: src/bones.c
modified: src/do.c
modified: src/files.c
modified: src/music.c
modified: src/restore.c
modified: src/save.c
modified: sys/share/pcmain.c
modified: sys/share/pcsys.c
modified: sys/share/pcunix.c
In order to get level file locking correctly again post 3.4.3
with the newer compilers for windows, I had to funnel close()
calls to an intercepting routine.
I had two choices:
1. Surround every close() in at least 9 source files with messy:
#ifdef WIN32
nhclose(fd);
#else
close(fd);
#endif
OR
2. Replace every close() with nhclose() and
deal with the special code in the nhclose()
version for windows, while just calling
close() for other platforms (in files.c).
It is also possible, although not done in this commit,
to
#define nhclose(fd) close(fd)
in a header file for non-windows, rather than funnel
though a real nhclose() function in files.c.
* don't let player wish for multiple globs
* use newsym() to clean up merged globs on floor
* food effects should match original corpse effects
* tidy up remaining crash when merging in place
When a gas cloud that deals damage is created, it uses
a poison cloud glyph instead of the cloud glyph.
(A bright green '#', or a bright-green recolor of the
cloud tile)
The plane of fire has random "stinking clouds", or
fumaroles, centered on lava pools.
Also make poison cloud glyph override lava, pool and
moat glyphs.
flooreffects() covers most dropped/thrown/etc. cases, and the hooks in
invent and mon handle "deathdrops" along with picking up items.
still need to check putting into/removing from containers
Reported by Alex, the probabilites shown in the comment about the effect
of the mysterious force have been wrong ever since they were added 20 or
so years ago. Lawfuls and neutrals are much more likely to go down just
one level rather than 2 or 3.
Bug report included a pointer to a fix; this patch is a superset.
Gold pieces dropped on an altar by the player got their bknown flag set,
which is incorrect since bless/curse doesn't apply to coins. If a
monster (in reported case, a slain temple priest) dropped gold there too
then the two stacks wouldn't merge. For the normal !GOLDOBJ config, the
problem goes away as soon as the gold gets picked up. I didn't test for
GOLDOBJ but think two inventory slots containing gold can result.
The superset part is to not break agnostic conduct by dropping gold
on an altar since no information is revealed when doing that.
[This was one of the very last patches checked into the old cvs repository,
where the somewhat out of date message above was accidentally omitted.]
Changes to be committed:
modified: src/do.c
From the email sent by ais523 earlier:
> You aren't charged for digging a pit below an unpaid boulder
> (causing the boulder to fill the pit).
This finally eliminates all direct increases of `oeroded` and `oeroded2`
and moves them all to go via `erode_obj()`. They are still manipulated
directly in a few places, but not to erode objects.
This now merges the `fire_damage()` function to a common codepath, used
for items on lava and burning oil, but fire needs more work. There is
still a duplication between `destroy_item()` and `fire_damage()`; the
two codepaths should eventually be merged in some manner so that there
is only one codepath to say "an object was affected by fire". This path
might require some parameters, such as whether the fire will just erode
objects or burn them outright, but that can happen another day.
