If the hero left a level that had globs on the floor or in floor
containers or being carried by monsters and stayed away for a
while, returning to the level only shrunk them by one unit of
weight. Account for all the time away. The complexity of this
has steadily grown; I hope its peak has been reached.
When carrying a glob, possibly inside a container, give shrink
feedback more often (twice in the ~500 turn cycle to shrink from
20aum to 0aum rather than just once).
I had wizweight On when testing glob changes and noticed
|Slasher drops a gold piece (0 aum).
Coins are supposed to weigh 1/100 of a unit, and the calculation
rounds rather than simply truncates any fraction, but that still
yielded 0 for quantities of 1..49. Force any non-zero stack of
gold to weigh at least 1 unit.
Also, add a check for attempting to weigh a quantity 0 or less
(of anything, not only for gold) just in case.
Don't hardcode the weight (20) of an unaugmented glob, use
objects[].oc_weight (also 20) instead.
When a glob inside a container has decayed all the way to nothing
(weight 0), take it out before updating the container's weight.
Otherwise weight() would use objects[].oc_weight instead of 0 for
that glob.
Globs never rotted away but did become tainted after a relatively
short while, which seemed like a contradiction. Change them to never
be tainted but shrink by 1 unit of weight approximately every 25
turns. An ordinary glob (one that hasn't combined with any others)
starts out weighing 20 units, so it takes about 500 turns to vanish.
That's roughly twice as long as a corpse takes to rot away.
Shrinking globs give feedback when in hero's invent or in a container
in hero's inventory, but rarely (when going from an exact multiple
of 20 weight units; that is, from integral number of N globs to
N-1 + 19/20, or if weight reduction triggers an encumbrance change).
When a glob goes away completely, there is feedback for those two
circumstances and also for seeing the glob vanish from the floor.
I haven't touched how much nutrition eating a glob confers. I have
changed formatting of glob names to use "small", "medium", "large",
"very large" instead of "small", [no adjective], "large", &c. You
still need to have at least five globs coalesced together for the
adjective to become "medium", same amount as before.
I don't think EDITLEVEL needs to be modified but have incremented it
anyway to play things safe.
Giving new_light_source '(genericptr_t) mtmp' leads to the light
source's id.a_monst being set to 'mtmp->nmon' rather than 'mtmp',
since that's what is stored in the initial byte of the monst struct.
When mtmp->nmon == 0x0 this can cause a segfault in do_light_sources.
I thought there were more places that checked for "it" and substituted
"someone" or "something". Perhaps there are and I'm just not finding
them now. Anyway, this extends x_monnam() and adds some_mon_nam() and
Some_Monnam() to do that during monster name formatting instead of
having various bits of code try fix it up after the fact. The fixups
could be fooled by monsters given the name "it" or "It"; x_monnam()
won't be.
Guard against any other places besides minimal_xname() that set up a
fake object without being aware that for boulders the corpsenm field
should be 0 rather than NON_PM. If that field is unexpectedly -1,
xname() will format it as ordinary "boulder" rather than producing
special "next boulder". An explict value of 1 is now required for
the latter.
Reported by Vivit-R with comments by several others. The prize item
in one of the closets off the Sokoban treasure zoo is sometimes
missing, most likely picked up by an elf who won't be dissuaded by
the presence of engraved Elbereth or a scroll of scare monster.
This fix prevents monsters from targetting the mines' and sokoban's
prizes for pickup (or for eating). Once the hero picks either of the
prizes up, they stop being prizes and will be ordinary monster fodder
if dropped/stolen/stashed.
One of the comments by copperwater suggested this approach as a
possible way to fix things. I had already implemented it from scratch
before noticing that. It handles the usual monster behavior toward
items, but there could easily be some unusual cases still susceptible
to taking the prize before the hero gets to it. Those are the breaks.
Fixes#603
like the leg hackery, if the baalz level gets flipped during creation
the fixup that modifies the locations in front of the eyes to allow
digging needs to deal with that too.
Because some spots in the fly's 'legs' on the Baalzebub lair level are
specified as pools in the level file, then later converted to walls in a
post-generation fixup routine, monsters can be generated on those spots
and then left walled up and inaccessible, Cask of Amontillado style.
For the love of God, makemon-tresor!
Some code already existed to relocate these monsters after generating
the level, but it depends on misorientated 'leg segments' being fixed up
in a particular way. That wasn't being triggered because it didn't
account for the possible rotation of the level; as a result, the
monsters in the leg segments wouldn't be relocated, and the leg segments
themselves would continue to have the wrong orientation.
Account for possible level rotation so that the monsters are relocated
properly (and the leg segments are 'fixed').
Reported by eakaye. Selection of equipment when creating a soldier
or watchperson can pick a polearm, but random selection among those
had a chance to choose dwarvish mattock which doesn't use polearms
skill and isn't appropriate for a human soldier or watchperson.
Not mentioned, but lance was in the same boat.
Change the selection to only pick something which uses polearms
skill, then make that moot by moving lance and dwarvish mattock out
of the midst of the polearms so that they're no longer candidates
for special case rejection.
A couple of other things which might have had a similar issue were
already ok. Giving a polearm when creating a troll selects between
a few choices rather than among all the polearms. And wishing for
"polearm" only considers items which use polearms skill.
While changing objects.h to reorder the two non-polearms, I removed
a bunch of tabs that were present in the scroll definitions.
EDITLEVEL is incremented due to objects[] reordering, so existing
save and bones files will be invalidated.
Fixes#623
Another (latent) case of an artifact possibly being generated and
immediately deleted: part of the process of a mimic disguising itself as
an item involves generating a random object, then deleting it. If this
item is a box or sack, it will generate with random contents, which will
be deleted along with the container. If artifacts are allowed as random
box contents, this can silently remove an artifact from being available
in the game.
This is effectively blocked already, since none of the artifacts
eligible for random generation are items from classes marked as valid
box contents (see boxiprobs[] in mkobj.c). Nonetheless, formally
preventing artifacts from generating as box contents will guarantee this
issue won't crop up if a randomly generated artifact tool, ring, etc, is
added in the future.
Death drops will generate a random item, which may be an artifact.
After the object is created, some rules are applied to check whether its
size matches the monster that dropped it; if it fails these checks,
the item is deleted. aosdict recently pointed out that if the death
drop was an artifact, this would permanently remove it from the game.
Use artifact_exist(..., FALSE) in various cases where potential
artifact objects are created, then immediately removed. This will
prevent artifacts from being removed from play by marking the artifact
as available to create again.
A vampire in bat form was seen via infravision or possibly telepathy,
then when it changed into fog cloud form the feedback was
|You now detect it where the vampire bat was.
The message substitutes "detect" for "see" when the new form can't
be seen and the monster name formatting yields "it" for that case.
Give a vanish message instead since that is effectively what happens.
The pull request by argrath changes weight_cap() to never return a
value less than 1 because try_lift() divides by that return value
and a 0 would trigger a crash. The code involved is used when
attempting to pull a monster out of a pit via #untrap.
I'm fairly sure that weight_cap() can never produce a value that's
less than 1 already, but have put in a variation of the PR's fix.
I've also implemented a different fix that removes the division
from try_lift(). The original code seems to have gone out of its
way to avoid calculating inv_weight() twice, but doing the latter
(for the once in a hundred games where it might happen) greatly
simplifies things by removing details of carrying capacity.
Fixes#621
Reported by G7Nation; attacking walls and such with a polearm just
gave lackluster "you miss; nobody's there" feedback.
Make applying a polearm at some non-monster locations give feedback
similar to using 'F'orcefight with melee weapons. Was
|You miss; there is no one there to hit.
now
|You uselessly attack the closed door.
Also, extend the supported locations to include dungeon furniture.
Was
|You attack thin air. ('F')
now
|You harmlessly attack the throne. ('F')
|You uselessly attack the throne. ('a')
This doesn't address #613: attempting to hit non-visible locations
with an applied polearm.
Closes#614
Reported by entrez, wielding something fragile (potion of acid
perhaps), and using F to smash it against iron bars called breaktest()
directly, then a second time indirectly through hero_breaks() via
hit_bars(). There is a random chance to resist breaking (99% for
artifacts, 1% for other items) so breaktest() might say that something
will break on the first call and that it will not break on the second
call, or vice versa. That could remove uwep from inventory then leave
it in limbo without destroying it, or destroy uwep without removing it
from inventory first triggering impossible "obfree: deleting worn obj".
whitelist the valid cases showing up
If an earlier version of clang is showing more cases (particularly
if they don't make sense), the re-enabling of the warning in
sys/unix/hints/include/compiler.2020 can be made clang-version
specific instead. I had no way to test earlier versions.
Give feedback for "<Mon> jumps onto a polymorph trap" in more
circumstances. It used to give the message if the monster could
be seen, and it would map the trap if the monster's location could
be seen. That led to some confusion when an infra-visible monster
was at a spot in the dark so the trap was accurately described but
didn't get mapped.
Map the trap if either the monster's or the trap's location can be
seen. If it isn't already known and isn't becoming known (the
infravision case), say "hidden trap" instead of "polymorph trap"
in the message. Give the "jumps onto trap" message if either the
monster can be seen or the trap's spot can be seen. When monster
can't be seen, it would normally be described as "It"; switch to
"Someone" (when humanoid) or "Something" (non-humanoid) instead.
Minor unrelated bit: the use-container action was between the 2nd
and 3rd polymorph cases. Move it, after the third one.
Engraving with a weapon which has known enchantment or with a magic
marker which has known charge count that decremented the amount did
so without updating the persistent inventory display. Report was
for curses but applied to every interface that can show perm_invent.
This includes some reformatting (mostly
if {
}
else {
}
to
if {
} else {
}
multiple times; also add some new braces after 'if' or 'else' where
one half already had those and the other didn't). And removal of
some unnecessary 'register' designators.
Plus fix up one sanity check which complained if number of charges
being used was more than a marker had, but then let the engraving
continue and decrement the count by that large amount. If that
impossible situation ever occurred, it would result in a marker
with negative charges.
Noticed when testing the "wall_angle: unknown" fix, if there is a
boulder rather than a door in the breach in a vault's walls at the
spot where the guard arrives, the guard would walk onto it, tell the
hero to drop any gold and follow, then move back. The boulder would
remain in the hero's way and couldn't be pushed because the guard was
in the boulder's way. Have the guard smash any such boulder(s) into
rocks when arriving (with no explanation for how that is accomplished,
just a message about seeing or hearing boulder(s) shatter). Later
when repairing the walls, delete any rocks or boulders at all vault
wall locations (even when no gap-to-wall repair is needed).
simpleonames() calls minimal_xname() which was setting up a dummy
object and making its corpsenm field be NON_PM. For a boulder, that
yielded "next boulder" instead of the intended "boulder".
Reported directly to devteam by entrez via email:
>
> I noticed some potential issues with (melting) ice:
>
> * Digging down into ice, or setting a land mine on the ice and
> triggering it, doesn't remove the melt_ice timeout, so it can result
> in a sequence like dig down -> pit fills with water -> freeze water
> -> freezing water tries to set melt_ice timeout -> duplicate timeout
> impossible. Or if you don't freeze the water again, melt_ice will
> run on a non-ice surface, which might at least produce strange
> messages.
>
> * Setting a land mine on ice: melting ice doesn't do anything with
> the trap, so there is still a land mine which you can trigger by
> flying over the water (the land mine's trigger is also still
> described as being 'in a pile of soil', despite being underwater at
> this point). Similar thing happens with bear traps.
>
> * Not really related to _melting_ ice, but an exploding land mine
> doesn't reset the typ from ICE to FLOOR (like normal digging does),
> so it will result in a square with a pit that is also an ice square,
> where the ice can melt under the pit and produce a combination
> pit/moat. If you then freeze the moat, the pit reappears on top of
> the ice.
Fix the vault repair issue that could lead to "wall_angle: unknown"
warning. Unlike shop repair, the original wall info isn't available
so this recreates it. The extra 'flags' field added yesterday could
be eliminated but this leaves it in place.
Fixes#606
If the hero can move to a boulder's location via m<dir>, allow travel
to do so too. You will always stop on the boulder spot rather than
keep going toward the destination because of change in visibility at
a boulder spot.
Giants should be able to see over boulders, and doing that for poly'd
hero would probably be straightforward, but when not poly'd, seeing a
giant beyond a boulder and vice versa seems like it would be a can of
giant-sized worms.
A couple of other miscellaneous changes are mixed in with this.
https://github.com/NetHack/NetHack/pull/573 by entrez
Pull request comment states:
"Moving into a position containing a warning symbol with m-<direction> to
'safely' move would still attack as though the 'm' prefix was not
specified. Ensure warning symbols are counted as 'detected' monsters
for this purpose, to avoid falling through to do_attack()."
Closes#573
triggering an impossible warning about "wall_angle: unknown" due
to the known conflict between door state and wall info which both
overlay the flags field for map locations.
Reported and diagnosed by vultur-cadens: if a shop's wall was dug
open, followed by use of locking magic to plug the gap with a door,
and then unlocking that door, the D_CLOSED door flag was left as
invalid wall_info when shop damage was repaired. Map re-display
complained. Leaving the door locked or opening it after unlocking
did not result in any complaint because the values for those door
states do not conflict with wall angle values.
The problem was reproducible and is now fixed by adding an extra
field to the shop damage structure. A similar change has been
made to the vault guard's 'fake corridor' structure but I have no
test case for that so don't know whether it makes any difference.
At least it doesn't seem to have broken anything.
Existing save and bones files are invalidated by the fixes.
Fixes#606
Microsoft has been making a recommendation that programs should switch
from using the classic low-level console API calls to virtual terminal
sequences for a couple of years.
References:
"Our recommendation is to replace the classic Windows Console API with virtual
terminal sequences. This article will outline the difference between the two
and discuss the reasons for our recommendation."
From:
Classic Console APIs versus Virtual Terminal Sequences
https://docs.microsoft.com/en-us/windows/console/classic-vs-vt
The online documentation for WriteConsoleOutputCharacter() and
WriteConsoleOutputAttribute() have this disclaimer on them:
"This document describes console platform functionality that is no longer a
part of our ecosystem roadmap. We do not recommend using this content in new
products, but we will continue to support existing usages for the indefinite
future. Our preferred modern solution focuses on virtual terminal sequences
for maximum compatibility in cross-platform scenarios. You can find more
information about this design decision in our classic console vs. virtual
terminal document."
Since NetHack started out as a terminal program, before there was a
Windows "classic" console API introduced with Windows NT, it seemed only
fitting that the Windows console port should evolve in the virtual terminal
direction.
This is a first stab at it. The performance won't be as instantaneous as
the low-level console API's. That's likely partly because of this consoletty.c
initial implementation, but it may also partly be because under the hood in
the OS, there's recognitions/translations/conversions going on. Microsoft
states it will continue to evolve the Windows Terminal and console, and
hopefully it will improve. Hopefully it isn't too slow to play. It still
attempts to take advantage of the back buffer stuff that Barton House
introduced to minimize screen updates. At this point, it can still be
recompiled without the virtual terminal support by defining NO_VT when
compiling consoletty.c, or by commenting out the definition of
VIRTUAL_TERMINAL_SEQUENCES at the top of sys/windows/consoletty.c
That's the informational news, and the negative news out of the way.
There's some good news too. Because the virtual terminal sequences
support include 24-bit color support, the Windows console under virtual
terminal sequence can provide a more pleasant set of colors to the NetHack
console interface. To that end, some color changes have been implemented
in consoletty.c now.
It makes the console port ready to accept and display 24-bit color from
the NetHack core, if that should ever happen, as well.
As usual with a first implementation, there may be some bugs. Reports
are welcome.
Revise the m<dir>-toward-boulder handling to let a hero who would be
able to squeese into the boulder's spot if it was blocked from being
pushed to do the squeeze without any pushing.
Unlike the previous changes, this might have an impact on play. It
allows squeezing under then stepping past an unblocked boulder that's
in a corridor in order to be able to push it back the other direction
where maybe there's more room to maneuver it out of the way.
Allow a hero polymorphed into a giant to move to a boulder's spot
via m<dir> no-pickup move, instead of having to push it until the
way is blocked by something and then having push failure move hero
to the spot.
Also change m<dir> when not a giant to no longer push the boulder.
No time will elapse when not moving unless hero who didn't know
that there was a boulder there learns that one is. Since no actual
push attempt gets performed, player doesn't learn whether there is
anything beyond the boulder that inhibits it from being pushed.
Three new checks:
1) boulders are expected to be at the top of their piles, or when
not on top, only other boulders are above them;
2) boulders shouldn't be located at water or lava spots;
3) verify that boulders don't have their 'next_boulder' flag still
set at times when sanity checks take place; that's only valid
during moverock() [plus its calls to boulder_hits_pool()].
The default value for obj->corpsenm is NON_PM which is -1, so the
default value of boulder->next_boulder was non-zero instead of 0
as expected. Because of that, boulder object formatting by xname()
was yielding "next boulder" when plain "boulder" was intended.
Until the boulder or one in a pile above it got pushed, then it
was explicitly reset.
