Luck has a massive effect on the to-hit chance; maximum luck alone
(which almost everyone has past the midpoint of the game) gives
10 points to to-hit, so accounts for 50% chance alone, excluding all
other effects.
Multiple variants do something similar to this, so it is well tested.
This version comes from xNetHack by copperwater <aosdict@gmail.com>,
and allows the +1 or -1 luck adjustments of early game, such as full moon,
to have an effect.
The safe armor enchantment limit is lowered by one, if the armor
is innately magical. This takes off 3-7 points of AC from
a typical ascension kit, but should not really have any effect
for early game.
Also clean up the relevant code a bit.
The earlier fix from a couple of days ago was mislabeled as #1455
but was actually #1466. It fixed picking up a thrown stack into
hero's empty quiver but broke keeping thrown items, dropped items,
and stolen items separate on the floor. This repairs that.
autoquiver when picked back up
Issue reported by ars3niy: empty quiver used to be refilled when
picking a thrown item or stack up. Bug introduced by a previous fix
(commit 593a93d254) dealing with the
post-3.6 obj->how_lost field.
As with the last time I dealt with this, there was a lot of trial
and error involved. This fixes the quiver issue without bringing
the earlier problem back. This time the problem was that how_lost
got cleared before it was used to check whether an item being picked
up had been thrown.
Dropping part of a stack and throwing another part of the same stack
may behave oddly if a monster picks both up. I am not going to try
to figure that out.
Fixes#1466
Issue reported by Tomsod: monster elves were intended to get a small
bonus to to-hit and damage when shooting arrows with bows, but the
check for that tested the arrows for skill P_BOW which never matches.
It should be -P_BOW.
[Pretty minor: +1 to-hit for any bow, another +1 to-hit if elven bow;
+1 damage for elven arrow; against hero and against other monsters.]
Fixes#1472
Pull request by umbire: the list of monsters which had lycanthrope
forms includes winter wolf but was missing winter wolf cub. Affects
cannibalism check when hero is a werewolf and eats a winter wolf cub
corpse.
One-line fix entered manually rather than using the git commit.
Fixes#1471
Running low on HP in monster form isn't the same sort of critical
problem that running low on HP while not polymorphed is, because the
character changes back when the monster form HP runs out rather than
dying. (Indeed, running out of HP in monster form is often
intentional.)
The exception is when wearing unchanging (which implies both that the
monster form is intentional and that running out of monster HP would
be fatal), so low monster-form HP is treated as a major trouble in
that case.
Inspired by <https://nethack-yanis.github.io/yanis/4724.html>.
A band-aid for monster-vs-monster aggression. Prevent monsters in
the Wizard's tower from attacking each other unless the hero is inside
the tower too, and those outside the tower from attacking each unless
the hero is outside.
Issue reported by ars3niy: assigning names to types of objects,
or clearing such, did not update persistent inventory window. Also,
the sequence
assign-a-name,
name-as-' '-to-unname,
assign-a-name again,
unname again
would result in impossible: "named object not in disco".
This fixes the impossibility. The fix for #1470 has already taken
care of the presistent inventory issue.
Fixes#1469
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.
Counting wizkits as starting inventory causes side effects (giving
you skills from them, making the wizkit items formally identified,
etc.). Some of these side effects are undesirable (because, e.g.,
it can give you skill in a weapon you're restricted in), and the
others are mostly neutral (because wizard-mode players can identify
anything they want to). As such, it's better to treat the wizkit as
something you obtain immediately after entering the dungeon, rather
than something you had all along.
Prior to this commit, Archeologists had an incredibly difficult
start, worse than was intended. This is intended to make it a bit
easier (whilst making the role more different from other roles) via
allowing them to identify scroll types earlier in the game than the
other roles are able to (they do it using a knowledge of ancient
languages that lets them read scroll labels that other roles
couldn't).
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.
The character doesn't know that an unlabeled scroll is blank until
they look at the inside of the scroll, but that could be done
either by reading or by writing.
These two enhancements were interacting with each other in weird
ways (paupers would start with no auto-IDs but force bolt, but
gain the level 1 auto-IDs upon training any skill). Change the
interaction so that paupers don't get the level 1 auto-IDs (which
wizards get to start with), but do get the level 3 auto-IDs in
skills that they manage to advance.
Pull request by huttarl: fix a typo in lspo_gold() which was causing
it to use the x coordinate for both x and y.
It appears to only be used for the Fort Ludios level (knox.lua) which
seems to be working as intended, so I'm not sure what is really going
on.
git decided to be a big hassle so I ended up just typing the one
character change and ignore the commit(s). Issue #1461 is about the
same situation.
Fixes#1460Fixes#1461
Alignment 'pious' is 20 but intemple() used that term for 14. Change
intemple() to use the term 'devout' which is 14 (see enlightenment).
Also, add a comment about verbalize() usage in priest_talk().
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.
This is helpful for if we ever allow playing multiple games in the
same session: because the arrays are not modified, they can now be
used more than once.
Issue reported by ashleyharvey in a comment to issue #1463: with the
'lootabc' option set, using the '/' command wouldn't accept a second
slash to look at things on the map (nor a question mark to type in
text to look up).
Not a bug since '//' is not documented as the way to look at the map
and '/a' works for lootabc, but '//' is useful so add support for it.
The '/' menu already uses 'y' and 'n' as unshown synonyms for looking
at the map and for looking up words. Those now only work for the
'!lootabc' setting since lootabc can't assign multiple group
accelerators to the relevant choices. Many of the other !lootabc
choice letters now work as unshown synonyms for lootabc choices, but
not all. Feeding 'i' and 'e' to the menu as group accelerators would
interfere with using them as ordinary abc choices (at least for tty).
The important part of the "don't offer while impaired" change was to
prevent offering while confused. However, it was also extended to
other status conditions: stunning seems fine, but hallucination was
problematic (both because it makes a large number of messages
inaccessible, and because hallucination is more of a long-term status
effect than the other two and players may sometimes choose to play
with it for a large portion of the game). So make the change trigger
only on stunning and confusion, not hallucination.
This also updates the changelog for the change, because while
connected to the erinys changes, it's technically separate and is
relevant even in games where erinyes are never summoned.
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.
If you write the scroll by description, you obviously know what the
label is because you specified the label (even if you didn't know
what the scroll was). When writing an unidentified scroll by type,
though, and getting lucky, you don't necessarily know the label of
the resulting scroll.
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.
This is partially for the pun, and partially because the "wish for
scrolls of charging to identify them" strategy has been nerfed in
previous commits and this offers an opportunity to discover what
scrolls of charging are without randomly encountering one.
