Test generation of every object, both via des.object and obj.new.
Expose FIRST_OBJECT and LAST_OBJECT numbers to lua.
Add lua nh.int_to_objname, a function to convert integer value to
object base name and class.
Allow creating new nethack lua object by specifying id and class.
The previous commit caused air elementals to become almost totally
nonthreatening in the endgame (even the buffed ones on the Plane of
Air). This commit fixes that (whilst still leaving them somewhat
weaker than they were before against characters with good AC), by
doubling the damage of home-plane air elementals.
The damage of the other home-plane elementals was doubled too,
because they were mostly nonthreatening previously. On Fire, this
has no real effect as almost any character would be fire-resistant
by this point. On Earth, it makes the elementals more of a threat,
when they previously weren't.
However, it made Water too difficult (albeit more fun, because it
became important to avoid letting water elementals swam you). As
such, water elementals are made slightly slower to compensate.
(My own playtesting indicates that 6 is slightly too fast, but 4 is
too slow, so I'm hoping that 5 is the correct value.)
Skip the terminal period only if there is true punctuation at the end of
the engraving, not degraded text. This feels a bit janky because the
way engravings are malloced and structured uses this manual offset to
access the space allocated for text. I used a macro to unify all those
accesses so that it will be harder to screw it up if something changes
in that respect, since repeating (ep + 1) as a magic number across
engrave.c seems quite brittle.
Using extended #name for an object on the floor (for example)
wasn't updating the permanent inventory to reflect the updated
object type name if there was also one in inventory.
These are often an important part of a character's build. There's
no purpose in listing them in disclose because the player generally
already knows what spells and skills they had and doesn't need them
identified, but they're useful when looking at someone else's game
or reminiscing over a past game.
This adds a "reroll" option that lets players reroll their
character's attributes and starting inventory. Although I generally
think doing this makes the game worse, a) some players are going to
do it regardless and b) if a player is going for a challenge game,
rather than to win, it may be required. So in the absence of an
option like this, players repeatedly start and quit games instead,
creating a large number of junk logfile entries and generally
causing problems for other players on the same shared machine
(because repeatedly reloading the game is very CPU-intensive).
This should in theory be windowport-agnostic (although in practice
it may not be). Tested on tty, X11 and curses; on tty and X11 it
works fine (although X11 treats the change in attributes as
something that needs a status highlight), on curses it is slightly
jankier in terms of what other windows are drawn in the background
(but still plays correctly and I suspect this is a pre-existing
bug).
To form a complete implementation, we will need to consider the
following:
- Should there be a delay on a) starting the game and/or b)
rerolling? If so, what should it be (maybe configurable via
sysconf?)
- Should we take more steps to discourage players from rerolling?
It would be bad if players see the option exists and turn it on
just because it exists, or (worse) treat it as condoning the
particular style of play.
- Should we take steps to detect that players are rerolling
manually and a) tell them to use the option instead, b) tell them
that this is not an intended way to play (and may make the game
less enjoyable and/or prevent them getting the practice they need
to eventually win)?
Breaks save and bones files.
This doesn't implement inventory rerolling, just adds the
infrastructure: it's now possible to call u_init_inventory_attrs
multiple times and the starting inventory/attributes replace those
from the previous call rather than compounding.
For example, being hit by the bounce of a wand of fire means that
the main character could take damage twice in a turn, which would
kill even through saving grace; and scrolls and potions could burn
up after that and finish off the last HP, even if the wand only hit
once. This commit changes it to track all damage done during the
turn, and prevent HP dropping below 1 from damage until the next
player action or the next turn boundary, whichever comes first.
This fixes a couple of bugs: a long-standing bug in which writing a
scroll by label could fail even if you've already seen a scroll with
that label (due to the game not tracking whether or not you've seen a
scroll if it doesn't have a name); and a somewhat newer bug in which
spellbooks auto-identified by Wizard knowledge were marked as having
been encountered (rather than as known but not encountered).
Breaks save file compatibility, but not bones files.
Issue reported by chappg: on arboreal levels, when an object was
located at a stone location treated as a tree location, examining
the object would report it as embedded in stone.
The Ranger quest has arboreal levels where STONE becomes TREE, and
items that would become embedded in stone will be in trees instead.
(Sometimes kicking a tree would drop fruit onto an adjacent tree,
effectively embedding it. For testing, it's easier just to poly
into a xorn, walk onto the tree spot, and drop something.) The item
description code for farlook and quicklook wasn't checking for that.
The fix also corrects another bug: an item located at a normal tree
location would just be described as itself with no mention of the
tree at all. Attempting to walk onto it would report the terrain
and not let you move there (assuming not in xorn form), like trying
to walk into a wall.
Fixes#1462
There was only one point in the code at which this caching was
being done, and it was incorrect: it's possible for the result of
near_capacity to change during a monster turn because monster
actions can change either inventory weight or carry capacity.
The bug was particularly relevant in cases where a character
polymorphed into a slow weak monster gets attacked by a monster
that moves at normal speed: due to the polyform being slow, the
normal-speed monster gets in a lot of attacks and causes a
rehumanization, but due to the polyform being weak, it was
burdened at the start of the monster turn, and so when that
penalty is (due to the bug) applied to the next turn it can
mean that the character misses the next turn too, and may end up
dying as a result.
Several window ports that support perm_invent were
using a call back to the core display_inventory()
function.
While calling from the window port back to core functions
is arguably not ideal in the first place, it was recently
brought to light that code NetHack-3.7 code changes to
display_inventory() actually caused it to stop repopulating
the perm_invent window as intended under certain circumstances.
For now, provide an alternative function, repopulate_perminvent(),
that hopefullshould still work the way it did previously.
There will likely be some additional changes after this to
further improve things, at some point.
For now though, this
Resolves#1454
Using 'i'+menu choice for suit+'T' to try to take off a suit that is
covered by a cloak (or shirt covered by suit and/or cloak) wouldn't
do anything. It should report that you need to take off the outer
garment first and then not take the chosen item off.
There is probably a simpler fix. It took me a long time to figure
where things were going wrong and them cobble this together.
A big chunk of the diff for invent.c is just identation, surrounding
a one-line change there.
In the context-sensitive menu when picking an item of armor from an
inventory listing, distinguish between wear-this-armor from could-
wear-this-armor-if-something-else-wasn't-already-worn-in-its-slot.
> Perhaps related: when a wand of sleep hits a disguised already-sleeping
> mimic (about which it is a separate question if they should go into
> disguise when sleeping, is it supposed to be automagic or conscious
> effort for them? but I digress), the mimic is not revealed (should it?)
> but the message says "hits a mimic".
Adjust restrap() so that a revealed mimic won't disguise itself while
sleeping. This seems to be in keeping with mimic lore.
Also, normal shop sounds (chime of register etc.) will wake a
mimic up from indeterminate sleep.
Closes#1441
Issue reported by Umbire: a gas spore that got swallowed and killed
didn't die but exploded anyway, with the explosion affecting the map
instead of being contained in the swallower.
There was code to handle that but it wasn't being executed. This fix
feels unclean but seems to work.
I couldn't reproduce the survival of the gas spore but since that
isn't wanted I won't worry about it.
Fixes#1434
Don't record hallucinated monsters as having been seen up close or as
photographed.
Treat a tourist's starting pet has having been photographed prior to
bringing the camera and dog or cat into the dungeon.
No extra points to tourist when first long worm tail is photographed.
EDITLEVEL is incremented again, for extra context to track starting
pet.
More details in https://github.com/NetHack/NetHack/issues/1430
track photographed monsters using a distinct bit
also adds a pair of new context fields to track the total number of monsters seen up close,
and the total number of monsters photographed.
So, if somebody wants to add unique end-of-game disclosure statements for tourists that relate to
those, the groundwork should be there.
NOTE: This increments EDITLEVEL, so existing save and bones files will become outdated.
Fixes#1430
Add some basic spellcasting stuff to the tutorial: read a spellbook,
cast a spell. If the hero doesn't have enough energy, just adds
a note saying so.
Remove/restore the known spells when entering/leaving the tutorial.
The blindness overhaul branch was created before towel weight got
changed, then unintentionally put the old weight back when it was
finally merged.
Increase weight to towel from 2 to 5 again.
Fixes#1416
Part 4 of implementing wish spreading. (This is now a complete
implementation, although the details are likely to change - but it
makes sense to commit something with the right balance properties,
and then tweak it based on feedback from playtesting.)
This helps to make the Amulet of Yendor feel special, and restores
approximately the same average number of wishes per game as existed
prior to the nerf to wands of wishing.
Placing the wish in allmain helps to avoid the wish happening at an
awkward place in the game's control flow, and is simpler than
testing every possible mechanism for gaining items for bugs (message
order is a common issue when trying to place it in addinv-related
functions, and this also avoids issues with the wished-for item
immediately invalidating an assumption that was made by the calling
code).
It is possible that this would be better as an invoke effect,
although I like the impact of picking up the Amulet and immediately
being given a wish.
This causes the difficulties to get out of sequence, but we agreed
that this is a less important rule than keeping monster IDs stable.
Breaks save and bones files, because it changes monster IDs.
These two types of monster were extreme outliers in terms of where
they appeared versus how lethal they were (3-4 times as deadly as
other monsters that appeared at similar depth, based on statistics
from actual play), so their generation depth has been manually
modified.
Breaks save and bones files (because monster type IDs have to be
sorted numerically by difficulty, and changing difficulties thus
changes the IDs, but the IDs are used to identify the monsters in
save files).
