PatR [Sat, 23 Dec 2017 23:19:27 +0000 (15:19 -0800)]
flags.sortloot
This should maximize save file compatibility between 3.6.1 and 3.6.0,
at the risk of breaking save files for folks using post-3.6.0 git
sources. (It's unlikely that many in that situation are using a
configuration which will be affected, so probably nobody will notice.)
PatR [Thu, 21 Dec 2017 18:04:18 +0000 (10:04 -0800)]
fix #H6628 - secret doors display as wrong wall
A relatively recent change to make secret doors within horizontal walls
become horizontal doors after discovery was making some secret doors
that should have remained vertical become horizontal too. While still
hidden, they got displayed as horizontal wall segments in the midst
of vertical walls. Example was the "Catacombs" (minend-3) variant of
mines' end. The hidden door on the east wall of the entry room was
shown as horizontal, while another one on the west wall of that same
room was correctly vertical. This fix uses different criteria to
decide horizontal vs vertical, partly because I couldn't understand
how the previous code was supposed to work.
Hidden doors now seem to display as correctly oriented walls and once
discovered seem to become correctly oriented doors. I tested by
checking quite a few special levels (and some regular ones)--but not
all--with '#terrain d'. Plus some searching to unhide secret doors
while using a custom symbol set that displayed closed horizontal doors
(S_hcdoor) as '=' and vertical ones (S_vcdoor) as '"'.
PatR [Fri, 15 Dec 2017 00:39:21 +0000 (16:39 -0800)]
rehumanizing while Unchanging
When hero poly'd into paper golem "burns completely" he is rehumanized
even if he has the Unchanging attribute. A comment states that that is
intentional, but there was no explanation given to the player. Report
that "your amulet of unchanging failed" when rehumanization despite
Unchanging happens. (Don't ask me how or why it fails; I don't know.)
PatR [Fri, 15 Dec 2017 00:22:36 +0000 (16:22 -0800)]
fix #H6610 - completely burnt paper golem
When a monster killed a paper golem with a fire attack, the player was
told that the golem "burns completely" yet it might still leave some
blank scrolls as 'corpse'. The fix for that was one-line, but several
other death-by-fire situations which didn't report "burns completely"
were also leaving scrolls: fireball spell or scroll of fire or other
fire explosions (if any), also wand of fire. Fire trap and poly'd
hero with fire attack were already suppressing 'corpse'.
PatR [Wed, 13 Dec 2017 01:53:54 +0000 (17:53 -0800)]
self-genocide's "you feel dead inside"
It seems to me that the reaction to "you feel dead inside" when you're
polymorphed into an undead creature at the time would be "so what else
is new?". Vary the "dead" when current form is something which gets
reported as "destroyed" rather than "killed" when killed. That happens
for things flagged as non-living. Now undead "feel condemned inside"
and golems "feel empty inside". Neither of those are ideal but they're
more interesting than "feel dead inside".
After becoming dead inside, give a reminder about that during
enlightenment and if you restore a saved game in that condition. It
was the latter that set this in motion: I wanted to confirm that
restoring with u.uhp == -1 didn't give "you aren't healthy enough to
survive restoration" when polymorphed. (It doesn't; the game resumes
and you'll die if/when you rehumanize.)
Alex Smith [Sat, 9 Dec 2017 14:12:40 +0000 (14:12 +0000)]
Add an instance flag for being inside parse()
Some windowports that are currently being written by third parties
need more information about the engine than they currently have.
Two specific reported problems: a) needing to know whether a
putstr() call relates to a count (so that it can be placed in a
different part of the user interface from the message area); b)
needing to know whether a request for a character relates to
command input (some hangup handling routines need this so that
they can determine what behaviour is potentially exploitable).
Knowing whether or not you're inside parse() fixes both of them.
This would be cleaner to do by changing the windowport API, but
that'd break existing windowports, which isn't really ideal.
Setting a globalish variable that the windowport can inspect, but
can ignore if it prefers, means that existing windowports will
continue to work fine, but new windowports will have more
information and thus more flexibility in how they handle command
entry.
PatR [Sat, 9 Dec 2017 08:36:19 +0000 (00:36 -0800)]
fix #H6597 - genocide exploit
Self-genocide (own role or race) while polymorphed sets u.uhp to -1
so that you'll be killed during rehumanization. I found a couple
of places which were testing (u.uhp < 1) without checking polymorph
state, and one of those was where monster movement decides whether or
not to attack. This bug seems to have been present since start of
the second cvs repository, so has been around for quite a long time
without anybody letting on that they'd noticed. So it probably isn't
a very effective exploit, although it would certainly make ascending
without wearing armor become much more feasible.
There are bound to be other places which examine u.uhp directly
instead of '(Upolyd ? u.mh : u.uhp)' but I only checked m*.c.
PatR [Sat, 9 Dec 2017 07:06:25 +0000 (23:06 -0800)]
fix #H5590 - pets not shown on dumplog map
When ascending or escaping from the dungeon, adjacent pets are moved
onto the 'mydogs' list so that they can be included in the score and
mentioned as being with hero in the final messages. But keepdogs()
was caled to do that before the known portion of the map was drawn
in the dumplog file, so adjacent pets were missing. Defer that until
after the map has been dumped so that pets will still be present.
PatR [Fri, 8 Dec 2017 22:12:35 +0000 (14:12 -0800)]
fix #6598 - monster briefly rendered as hero
When swapping places with a pet, the hero's coordinates are changed
before some tests which might disallow the swap, and if the pet was
a hidden mimic or was trapped and became untame, the attempt to draw
the revised pet or former pet would actually draw the hero and have
that mistake be visible during the message about not swapping. That
last bit only occurred when the pet couldn't move diagonally (due to
being a grid bug or to being unable to squeeze through a tight space).
Also, spoteffects for arriving at a new location took place even
though the hero hadn't changed position.
Alex Smith [Wed, 6 Dec 2017 18:49:08 +0000 (18:49 +0000)]
TDTTOE: Discourage generating elf corpses on sleeping gas traps
These are elven /adventurers/, so they get sleep resistance at
experience level 4 (not immediately), and so there's an outside
chance they'll be killed by a sleeping gas trap. This commit
reduces the probability, though.
PatR [Tue, 5 Dec 2017 11:38:23 +0000 (03:38 -0800)]
more #adjust (#H6571)
Make the suggested change that only adjusting something into its own
slot be the way to collect/merge compatible stacks with it, instead
of any #adjust without a split count. This removes the previous
special case for a count that matches the stack size. Having to
know the exact count was not a burden on the player, but being able
to move things around without merging with other stacks makes more
sense than the original behavior or the hack to work-around that
behavior.
PatR [Fri, 1 Dec 2017 03:15:45 +0000 (19:15 -0800)]
address #H6552 - #adjust behavior
The report stated that '#adjust a c' after '#adjust 1a b' moved all
the original 'a' to 'c' instead of leaving the one in 'b' alone.
That's true, but it is also the intended behavior. Splitting off
with a count explicitly avoids gathering compatible stacks (but
does merge into the destination if compatible, instead of swapping).
Moving a whole stack gathers compatible ones and puts the whole
merged group into the destination.
But that leaves a gap in functionality: there's no way to get the
don't-collect-other-stacks without splitting; there ought to be.
So, allow the player to specify full count to move a stack from one
slot to another without collecting compatible stacks (the behavior
when no count is given) or splitting (the behavior when count is
less than full amount). In the example above, if 'a' started with
5 doodads and had 4 left after splitting one to 'b', '#adjust 4a c'
will move those 4 (all of 'a') to 'c' without merging 'b' into them.
The method is a bit obscure but it's also something which doesn't
come up very often.
PatR [Sun, 26 Nov 2017 01:01:06 +0000 (17:01 -0800)]
more explosion vs u.ustuck
Fix a FIXME (poly'd hero hit by explosion while holding a monster
which is also hit by that explosion takes double damage even if the
held monster got killed) and an incorrect comment.
Add a FIXME about grabbers (monster or hero) who are outside the
explosion radius but holding someone who is inside.
Alex Smith [Fri, 24 Nov 2017 00:42:42 +0000 (00:42 +0000)]
Some traps on early depths were triggered already
The hero isn't the only adventurer seeking the Amulet. It's clear
from various other events in the game that others have been there
beforehand. As such, we can expect many of the traps on the first
few levels to already have been triggered repeatedly by questing
adventurers.
This commit allows for the creation of adventurer corpses in
early-game traps, together with a small amount of cursed junk
(i.e. a miniature bones pile) and any items created by the trap
itself. On dungeon level 1, this is guaranteed for the vast
majority of harmful traps, in order to avoid near-unavoidable
deaths in the very early game due to not having enough max HP to
survive a trap hit.
Wizard mode testing shows that this case doesn't trigger very
often; maybe once a game on average. (Traps are rare on filler
levels, at least early on, and many types of trap would leave no
evidence, e.g. a teleportation trap won't kill people on its own
square.) As a result, the balance impact from the actual items
here is likely to be minimal (it may help out ranged combat roles
slightly but they could do with the boost). The main change,
therefore, is to reduce the number of unfair very early deaths
(replacing them with fairer "you shouldn't have investigated
what created that corpse!" deaths).
PatR [Fri, 24 Nov 2017 00:37:20 +0000 (16:37 -0800)]
fix #H6489 - explosion double damage to ustuck
Report asked why u.ustuck takes double explosion damage, and concocting
a reason uncovered several inconsistencies. Grabber takes double damage
for reaching into hero's spot, but only when that spot is within the
explosion's radius and only if hero isn't engulfed. Poly'd hero takes
double damage if holding a monster which is hit by the explosion.
There are still multiple bugs here: if the hero is grabbing a monster
which gets killed by the explosion, the fact that one was held is
forgotten by the time damage is inflicted upon the hero. Just a messy
detail that I opted not to get bogged down in. But much messier is
that grabber might be outside the explosion radius reaching into that
to hold grabbee, in which case no damage is inflicted. Handling that
for out-of-range monster holding exploded hero shouldn't be very tough,
but handling it for out-of-range hero holding exploded monster could be
hard. Anyway, it's more headache than I intend to tackle.
Alex Smith [Sun, 19 Nov 2017 16:16:00 +0000 (16:16 +0000)]
Balance fix to level drain and potions of restore ability
Right now, the punishment for being hit more than twice by a level
drainer pre-Quest is disproportionate; grinding back up to level
14 from level 13 takes a long time, and yet isn't particularly
difficult, just slow, and a potion of full healing will only
regain one of the lost levels (as only half the lost levels can
be regained this way).
Meanwhile, potions of restore ability are currently automatically
blanked by almost all spoiled players; they don't do anything that
doesn't have more convenient sources (unicorn horn or the spell),
so they're only useful in the very early game for getting poison
resistance.
This commit aims to fix both problems, by allowing potions of
restore ability to restore lost experience levels, in addition to
lost attribute points; an uncursed potion restores one lost level
(with multiple potions making it possible to hit the cap), a
blessed potion restores all of them. That gives players an
incentive to keep them around rather than blanking them. (Notably,
the spell and tool were not changed the same way; for restoring
levels, you need to use the potion.)
PatR [Sat, 18 Nov 2017 07:38:28 +0000 (23:38 -0800)]
impossible fixup
For USE_OLDARGS, the varargs calls in pline.c actually need to pass a
fixed number of arguments (padded with dummies for unused ones) when
using a compiler which checks argument usage for consistency.
pline.c used to be the only core source file which needs VA_PASSx()
handling, but it looks like calls to config_error_add() in files.c now
need it too. (If there were any calls to panic() in end.c, they would
need it as well, but there aren't.)
PatR [Sat, 18 Nov 2017 00:05:35 +0000 (16:05 -0800)]
options processing: ascii_map vs tiled_map
Toggling either ascii_map or tiled_map with the X11 interface switches
the map window from one style to another, but it was only working as
intended when done via the 'O' command. Setting ascii_map via initial
options only worked if tiled_map was explicitly cleared. This fixes
that.
Alex Smith [Thu, 16 Nov 2017 16:42:16 +0000 (16:42 +0000)]
Less misleading message when impossible() is called
Telling people to #quit due to something going wrong internally is
probably a bad idea; the game might or might not be corrupted, but
even if it is, most players will want to play on rather than lose
their game entirely.
Instead, advise saving and reloading; this will fix the underlying
cause of many impossible()s (which are normally related to
inconsistent internal structures; the save file format has much
less redundancy, therefore less chance of inconsistency, than the
in-memory format).
PatR [Tue, 14 Nov 2017 23:31:26 +0000 (15:31 -0800)]
vomiting while fainting
From a beta-tester running 3.6.0:
|You faint from lack of food.
|You suddenly vomit!
The latter has already been changed to "You vomit" (it's given at the
end of a multiple-message vomiting countdown so wasn't "sudden") but is
still odd if your stomach is so empty that you're subject to fainting.
Give an alternate message in that case:
|Your stomach heaves convulsively!
Vomiting while unconscious (when that's due to something other than
fainting from hunger) should pose a risk of choking to death, but I'm
going to pretend that this hasn't occurred to me....
Pasi Kallinen [Tue, 14 Nov 2017 13:57:18 +0000 (15:57 +0200)]
TTY: Treat carriage return as newline
Before this change, more-prompts and input text -prompts could not
be accepted with carriage return. Now, just like in menus, carriage
return is treated the same as a newline.
Alex Smith [Mon, 6 Nov 2017 01:28:48 +0000 (01:28 +0000)]
Intentionally spoil foodpois mechanics when it happens
One of the huge strengths of NetHack is that there's a lot of
mechanical content in it; you can continue learning about the game
more or less continuously, and when you die, it's usually possible
to figure out what you did wrong and avoid that for future games.
There are two parts to this: a) a death should only happen if the
player didn't play perfectly, b) the nature of the problem should
be clear.
FoodPois status meets a) just fine, but not b); food poisoning
mechanics tend (based on my research) to actively give the wrong
impression to new players. (Normally, something along the lines of
"corpses are sometimes randomly dangerous", which is insidious in
the sense that it'll cause players to leave them as a last resort
and thus never discover what they're doing wrong.) The easiest way
to fix this is to explain what the rule is explicitly.
Additionally, this should hopefully go some way towards changing
the incorrect perception many people who haven't played (any/much)
NetHack have that the game is arbitrarily cruel... It's important
to get the "everything happens for a reason" attitude across from
an early stage, by tying it to an event like this that's commonly
seen by new plyers.
Experienced players should not be affected much if at all by this
change, because they hardly ever get food poisoning anyway.
(Note: there are actually two main mechanics related to food
poisoning, one widely applicable, one much more subtle. The message
here is focused mainly on the common case, but doesn't actually
contradict the rare case, and attentive players may be able to
deduce both mechanics from the one message. Most likely, players
will hit the common case, see the message, learn the common case,
and some time later hit the rare case, get the message again, and
read it more carefully this time.)
PatR [Sat, 4 Nov 2017 23:04:46 +0000 (16:04 -0700)]
fix #H6391 - artifact #invoke for charging
Latent bug: if a non-role-specific artifact which could be invoked
for charging existed, it would never work as if blessed because the
test for no-role was wrong. Caused when 3.3.0 changed the Role_if()
predicate and artilist[] array to use monster index numbers (PM_foo)
instead of role letters; the non-role value changed from '\0' to
NON_PM (-1) but the test for non-role didn't.
No fixes36.1 entry; there aren't any artifacts which were affected.
Alex Smith [Wed, 1 Nov 2017 15:22:28 +0000 (15:22 +0000)]
Don't use a plain %s when writing to a buffer
My compiler was understandably concerned about a potential buffer
overflow here. I don't think the string could get long enough to
cause that to happen, but it's hard to be certain. It's much safer
to limit the length of the string so that it fits in the buffer, as
done here, and if there really wasn't a problem the change will
cause no harm at all. (If there was, the string will be truncated
rather than corrupting memory. This code is in showing the
config-file version of a status highlight, something where
truncated text will probably be obvious to the user.)
Alex Smith [Wed, 1 Nov 2017 14:55:40 +0000 (14:55 +0000)]
It's OK for pets to oscillate near the player
This change was coded by FIQ, who suggested it by email.
The main change here is related to monster anti-oscillation code.
When a monster believes it's stuck in an AI loop, it looks for an
alternative strategy. That applies to pets too. However, if the
pet is currently near the player, we can typically assume that it's
there because it wants to be there, and an oscillation is not
because it's stuck but because it's already in the best possible
place. This commit causes pets to be "allowed" to stay near the
player, rather than running the wrong way down a corridor because
it's the only way to do something different than what they're
currently doing.
If the pet is far from the player, we use the old behaviour unless
the pet is leashed or the player tried to call it with a whistle
or the like, in order to avoid the risk of a genuine AI loop trying
to get back to the player. (Whistling happens rarely enough that it
won't cause AI loops of its own - the player isn't going to whistle
every turn - and it makes flavour sense that a pet might interpret
it as "you're going in the wrong direction!".)
Pasi Kallinen [Tue, 31 Oct 2017 19:18:21 +0000 (21:18 +0200)]
X11: Fix renaming at player selection
Due to the new player selection dialog I did, it was possible
to rename your character - but this didn't rename the lock files
and tried to load a save from the wrong name.
This is a bit of a hack, but seems to work and didn't seem to
cause problems for the tty.
PatR [Sat, 28 Oct 2017 21:12:50 +0000 (14:12 -0700)]
fix #6284 - empty perm_invent
Report was for tty, but X11 exhibited the same behavior. With the
perm_invent option enabled, when the permanent inventory window is
displayed, it would be empty if not carrying anything. For tty, that
meant a naked "(end) " selection prompt. Put a separator line of "Not
carrying anything" into the menu so that it won't be completely empty.
The selection prompt is still present but it is attached to something.
(The behavior is different from !perm_invent, where you get that same
text via pline without any menu at all.)
PatR [Sat, 28 Oct 2017 08:18:25 +0000 (01:18 -0700)]
fix #H6338 - naming mimicked potion
Player tried to #name a potion on the floor and got prompted to call a
stream of fluid (sink feedback) instead of a potion. A mimic posing
as an object is represented by a partially initialized object when
examining its map location. #name for floor object uses the same data
as look_at.
obj->fromsink overloads obj->corpsenm which is set to NON_PM (-1) even
when creating a non-init'd object. 'fromsink' was only being forced to
0 when creating an init'd object (unlike leash which has its overload
of corpsenm set properly regardless of caller's request to init). So
docall() treated a mimicked potion as a sink stream.
The fix is straightforward but has pointed out another bug which is
harder to fix. Examining a floor object next to you sets that obj's
dknown flag as if you had seen it up close (a new feature in 3.6.0).
But a mimicked item is discarded as soon as it's been looked at, so
looking again from a non-adjacent spot will give different feedback
since the previously set dknown will be unset when replaced by a new
fake object. So you can use '/' and ';' to recognize mimics without
provoking them into motion. Best fix: mimicking an object should use
a fully initialized one which is tracked via monst->mextra, but that
will break save file compatibility. Possible hack: change monst->
mappearance into a mask which uses N bits for object type (instead of
full 'int') and one of the other bits to track obj->dknown. Examining
an adjacent object probably ought to set bknown for priests, so bknown
and blessed/uncursed/cursed would need to be tracked too.
Pasi Kallinen [Thu, 26 Oct 2017 18:56:43 +0000 (21:56 +0300)]
Fix door orientation in des-files
Doors in des-files were always generated vertically.
This wasn't visible unless you had separate symbols for
closed vertical and horizontal doors, or used tiles.
PatR [Thu, 26 Oct 2017 02:13:21 +0000 (19:13 -0700)]
strbuf cleanup
The expression '*cp-- = cp[-count]' is not valid C. There's no sequence
point between the two references to 'cp', and the decrement side-effect
could occur before or after cp[-count] is resolved.
The functions were also using ANSI-style argument definitions. The rest
is just reformatting.
It seems to me that the strbuf structure ought to have an allocation
size field in addition to the current length field. Otherwise a string
which gets shortened will forget about the extra length available for
later expansion, potentially resulting in unnecessary reallocation.
Bart House [Sat, 21 Oct 2017 20:41:29 +0000 (13:41 -0700)]
Win32TTY: Fix using a console font with wide glyphs
Added support to detect when the current console font has glyphs
that are too wide and will cause rendering errors in the console.
If detected, we warn the user and change the code page to 437
and the font to Consolas. At exit, if we had changed the font
and code page then we will restore to the original font and code page.
Bart House [Tue, 3 Oct 2017 04:11:30 +0000 (21:11 -0700)]
Win32GUI: Gather raw_print text and display it all in single dialog
Defined strbuf_t and related routines to support dynamically sized
strings. Modified strip_newline() to strip the last newline in a string
instead of the first.
Simplified splash window code using new strbuf_t.
Prior to exiting game, re-enable getreturn and call wait_synch() in
case there is buffered raw prints that must be displayed to user.
PatR [Tue, 24 Oct 2017 21:29:38 +0000 (14:29 -0700)]
description of #therecmdmenu
The extended command added to test handling for adjacent mouse clicks
had a description which was too long. In the list from '#?', white
space for column alignment got squeezed out to make it fit (at least
for tty, where it ended up looking awful).
The new description isn't a complete sentence any more, but I don't
think anyone will care.
PatR [Tue, 24 Oct 2017 21:17:25 +0000 (14:17 -0700)]
more achievement tracking
The code that checked for and complained about having more than one
'prize' object on the mines' end or sokoban end level uses static
counters and would complain if you used #wizmakemap to recreate the
level. (Or if a game got far enough that either of those levels was
created and then started over--I'm not sure what state support for
that has reached.) So re-init those counters each time any special
level gets created; that's sufficient for what they track.
I also changed several variables in sp_lev.c from global to file
scope since they aren't used anywhere else.
PatR [Tue, 24 Oct 2017 07:37:21 +0000 (00:37 -0700)]
more fix for #H5056 - achievement tracking
The followup message about the fix for #5056 was trapped by the spam
filter so didn't reach us for a while.
xlogfile has an extra field to track various achievements made during
the game it logs, two of which are fully exploring the gnomish mines
and fully exploring sokoban. Those are accomplished by finding the
special 'prize' item on the final level of their branch: luckstone
for mines and bag of holding or amulet of reflecition for sokoban.
3.6.0 had a bug where any item of the target type found anywhere in
the dungeon resulted in achieving the relevant goal. A post-3.6.1 fix
for that required that the item be found on the end level of the branch
and attempted to require that it an item explicitly placed there by the
special level loader, but the latter aspect had a bug which meant that
random items of the appropriate type placed on final level would count
as the prize. Chance of extra luckstones on mines' end is fairly high,
so potential for false completion of the achievement was also high.
The second complaint was that since the achievement was only recorded
if the special prize item was found on final level, then if a monster
took it to another level then the achievement became impossible. (Not
true, the player could take it back, drop it, and pick it up again, but
that is admittedly a pretty silly hoop to jump through.) On the other
hand, if a monster removed the item before the hero found it, then a
case could be made that the hero hadn't really fully explored the
level. However, this fix records the achievement no matter where the
hero picks up the item. The final level must be entered--otherwise no
monster could possibly acquire and transport the item--but it isn't
guaranteed to have been fully explored. Big deal....
The prize could also be acquired in bones data. Before the second
portion of this fix, that wouldn't have mattered. But now it does, so
clear the prize indicator when saving bones unless it happens to be the
same level where that item is created (impossible for sokoban, where no
bones are left; not sure offhand about mines' end). The former prize
stone or bag or amulet becomes an ordinary one of its type.
This can all be done in a much cleaner fashion once we give up on the
current save file compatability. Putting obj->o_id values into new
context.mines_prize and context.soko_prize, plus a hack to mkobj() to
not reuse those two values if the o_id counter ever wraps back to 0,
would cover most of the details. Adding an achievement tracking flag
to lev_comp's object handling for use by the special level loader
would cover most of the rest.
PatR [Sat, 21 Oct 2017 23:02:48 +0000 (16:02 -0700)]
more #adjust: '$' and '#' handling
The recent fix to prevent #adjust from letting the player move things
into slot '-' (if compactify() reduced any sequence of consecutive
letters to x-y, introducing dash into the string of characters that
could be chosen from) was triggering a complaint about mixing &&
and || without parentheses. Fixing that was trivial, but I ended up
making a much more substantial change.
If the '#' overflow slot is in use, you can move something into it
even when you no longer have all 52 regular slots in use. (When it
isn't already in use, you can't access it. Previously you could swap
from '#' to any letter but not vice versa.) If you manage to get
gold in multiple slots or in some slot other than '$', you can move
or merge it into the '$' slot. And when that situation isn't present
(if even possible--I had to force it with a debugger to test), then
gold will no longer be listed among the inventory letters to adjust.
(That became an issue when GOLDINV came into use, but either nobody
ever noticed or at least never reported. "Adjust what? [$abd]",
then pick '$' and be told you can't adjust gold. Prior to GOLDINV,
'$' wasn't included in the list of candidates.)
PatR [Sat, 21 Oct 2017 01:31:07 +0000 (18:31 -0700)]
boulder pickup: contradictory message sequence
Poly'd into a giant with a full inventory that already contains at
least one boulder, moving onto a boulder (that can't be pushed due
to a wall or other obstacle) yielded
You try to move the boulder, but in vain.
However, you can easily pick it up.
You are carrying too much stuff to pick up another boulder.
You see here a boulder.
The second and third statements contradict each other. Make the
code that dishes out the second message smarter. If autopickup is
set for it and you will pick up the boulder:
However, you easily pick it up.
If autopickup is not set for it but would have worked if it was:
However, you could easily pick it up.
If your inventory is full and you have a boulder (or are in Sokoban)
However, you easily push it aside.
That last one is instead of "however, you can squeeze yourself into
a small opening" that you'd get if not a giant and not carrying much.
Pasi Kallinen [Fri, 20 Oct 2017 13:15:02 +0000 (16:15 +0300)]
Prevent adjusting items to the dash inventory letter
The #adjust command allowed, due to compactified buf, putting
items into the '-' inventory letter, which is usually reserved
for "empty hands", zeroobj. This caused problems down the line
when user was allowed to pick that letter for dropping.
PatR [Fri, 20 Oct 2017 06:08:46 +0000 (23:08 -0700)]
fix #H6285 - speaking vs strangulation
Reading a scroll while blind is permitted if you know its label, but
message is "as you pronounce the words, the scroll vanishes" unless
you are poly'd into a form which can't make sounds, in which case you
"cogitate" rather than "pronouce". Switch to the cogitate variant if
you are suffering from strangulation.
Casting spells didn't even have the distinction; you could cast them
without regard to speech capability. Check for that. Unlike with
scrolls, now you can't cast if you can't speak (or grunt or bark or
whatever) instead of having a variant description of the action, so
this is a bigger change.
PatR [Tue, 17 Oct 2017 05:19:35 +0000 (22:19 -0700)]
X11 role selection: gender-specific role names
A wishlist/TODO item: when "female" is highlighted, change "caveman"
to "cavewoman" and "priest" to "priestess". If it gets toggled to
"male", change them back.
PatR [Sat, 14 Oct 2017 09:09:43 +0000 (02:09 -0700)]
fix #6187 - attempting to eat inedible artifact
Rearrange the tests for edibility of non-food so that touching an
artifact won't happen unless the object could be eaten.
Add a bit of bulletproofing for rust monsters trying to eat a
rustproofed item and spitting it out. Wishing for rustproof iron
ring, cursing it, wearing it, and attempting to eat it as a rust
monster would remove the rustproofing and spit it onto the floor,
ignoring the cursed state as far as taking it off goes. That was
an issue in 3.4.3 and probably in 3.6.0, but in current code the
'rustproof' part of the wish would be ignored for an item which
isn't subject to erosion damage, so hero-as-rust monster will
successfully eat the ring instead of spitting it out.
PatR [Sat, 14 Oct 2017 00:56:25 +0000 (17:56 -0700)]
X11 player selection compile warnings
This eliminates nearly 40 warnings, most by suppressing complaints of
used function arguments but a few for unused local variables. There's
also some reformatting thrown in....
There are still 18 warnings about uses of XtSetArg(), about assigning
const to non-const.
Pasi Kallinen [Fri, 13 Oct 2017 19:41:33 +0000 (22:41 +0300)]
X11: add new player selection dialog
The dialog shows the player's name, race, role, gender, and
alignment in a single window, similar to the Qt4 dialog.
Also allows randomizing the character selection.
Use the dialog by setting OPTIONS=player_selection:dialog
PatR [Thu, 12 Oct 2017 22:21:00 +0000 (15:21 -0700)]
options: ascii_map vs tiled_map
X11 supports both ascii map and tiled map and is able to switch back
and forth during play. 'O' shows both of them as boolean options, but
toggling ascii_map did nothing since tiled_map retained whatever value
it had at the time. For core options handling, make toggling either
ascii_map or tiled_map also set the other one to the opposite value,
so ascii on forces tiled off and vice versa.
PatR [Thu, 12 Oct 2017 00:29:55 +0000 (17:29 -0700)]
X11 default resources - macro expansion
The X11 interface reads file NetHack.ad (after cd'ing to the playground
directory, where 'make install' puts a copy) and feeds the contents to
X Windows for use as default resources to override the compiled in
defaults. When use of #define was introduced into NetHack.ad (back in
September, 2016) this was severely hobbled and startup spit out a lot
complaints to stderr about invalid resource values. This implements
rudimentary macro expansion for '#define name value' within the data
stream that's fed to X, getting back decent default values and
eliminating the invalid value complaints.
PatR [Tue, 10 Oct 2017 22:56:18 +0000 (15:56 -0700)]
context menu tweaks
Fix several warnings about using 'void *' for a function pointer and
a couple of unused variables. Add a_nfunc for 'int NDECL((*func))'
alternative for union anything. Make the enum list of union anything
types actually match the alternatives (field a_uchar was missing from
enums, enum mask32 had no corresponding a_mask32 field).
Add another command, #therecmdmenu, so that the context menu for an
adjacent spot can be tested without mouse support. It revealed that
you could get an empty menu if nothing applicable was at target spot.
Add a few adjacent actions: lock/unlock door if carrying suitable
implement, search door for traps, examine known trap (door/ceiling,
not door), #untrap known trap, mount saddled critter, remove saddle.
Make "kick door" be the last choice for closed door instead of first.
Add one 'here' action: dismount.
Both #herecmdmenu and #therecmdmenu interact strangely with ^A, but
differently from each other. I didn't make any attempt to solve this.
projects / nethack / log