Apply user-contributed patch to make do_vision() handle FILE_PREFIX
correctly. It was putting that value into the filename buffer, then
overwriting it with the ordinary filename instead of appending.
Deletion of just-made vis_tab.h when creation of vis_tab.c fails would
have failed too if FILE_PREFIX had been working.
The patch was against 3.4.3 and didn't apply cleanly to current code,
but it is a staightforward fix, although the file deletion case was
buggy (failed to clear "vis_tab.c" from buffer before reconstructing
"vis_tab.h" via appending stuff). FILE_PREFIX seems to be Amiga-only
so I've only tested the usual case where it isn't defined.
Mentioned in the newsgroup: picked up items have stopped merging with
compatible stacks in inventory.
The commit 0c51555849 by me on January 5
|
| fix #H6713 - unpaid_cost: object not on any bill
|
| Stealing a shop object from outside the shop with a grappling hook
| would result in that item being left marked 'unpaid' after the shop's
| bill was treated as being bought and not yet paid for. This led to
| "unpaid_cost: object wasn't on any bill" every time inventory was
| examined. The problem was caused by handling the shop robbery after
| removing the object from the floor but before adding it to inventory,
| so it couldn't be found to have its unpaid bit cleared.
|
inadvertently caused that. The effect was actually deliberate but it
wasn't intended to be so widespread. Handle extract/bill/addinv/rob
sequencing differently instead of overriding inventory merging.
Stealing a shop object from outside the shop with a grappling hook
would result in that item being left marked 'unpaid' after the shop's
bill was treated as being bought and not yet paid for. This led to
"unpaid_cost: object wasn't on any bill" every time inventory was
examined. The problem was caused by handling the shop robbery after
removing the object from the floor but before adding it to inventory,
so it couldn't be found to have its unpaid bit cleared.
When investigating this I came across a more severe bug: if the hero
had never entered the shop, the shopkeeper's bill wasn't initialized
properly and add_one_tobill() could crash while attempting to execute
bp->bo_id = obj->o_id;
because 'bp' was Null.
When polymorphed into an iron golem (or gremlin with 2/3 chance),
triggering a rust trap would give "a gush of water hits <you or some
body part>" and then give a second "a gush of water hits you" when
dealing with golem or gremlin effects. That made it seem as if the
trap was hitting twice. This removes the redundant messages. (Rust
trap against monster iron golem or gremlin didn't have them.)
If mimics were genocided before loading a special level which
contained mimics with specific appearances, whatever random monsters
took their place also end up having their intended appearance.
monst->cham uses NON_PM rather than 0 to mean "not a shapechanger".
Implement the suggestion that hero's current god not uncurse a worn helm
of opposite alignment when prayer result is fix-worst-cursed-item or
uncurse-all-cursed-items since doing so makes it easy for hero to switch
to another god. The second boon will still uncurse non-worn helms of
opposite alignment since that has no effect on how easy or hard it is
for the hero to change alignments. (The first boon only applies to worn
items plus luckstones and loadstones; non-worn helms aren't applicable.)
Newsgroup discussion mentioned that it was possible to open the castle
drawbridge with musical notes even while confused. There was already
some handling for confusion: improvisation treats magical instruments
as their mundane equivalents. This takes if farther: when stunned
or confused or hallucinating you'll always improvise instead of being
given a chance to choose notes. Being stunned now behaves the same
as being confused in regards to magical instruments (possibly/probably
it should prevent playing music altogether). Hallucination gives
different feedback at start but still allows magical playing.
Excess verbosity for multi-shot throwing/shooting by monsters.
The Green-elf shoots 2 elven arrows.
You are almost hit by the 1st elven arrow. The 1st elven arrow misses.
You are almost hit by the 2nd elven arrow. The 2nd elven arrow misses.
Just give one or the other of the miss messages. If it reaches the
hero's location, give the first. If it lands somewhere else, give the
second. (It might be possible to get both if hero is displaced and
the monster thinks he/she is behind his/her actual location. I'm not
sure.)
Also, only say "you are almost hit" if it is true: the dieroll nearly
got past your armor. Otherwise, say "The Nth arrow misses you."
More fallout from allowing W/T on accessories and P/R on armor without
combining them outright. If poly'd into verysmall or nohands critter,
'W' yields "don't even bother" before even prompting what to wear, but
'P' would prompt for an accessory and then wear armor if that was what
got picked. Now 'P' will still prompt, in case it's for an accessory,
but picking a piece of armor no longer wears that armor.
'W' still doesn't even prompt, so won't allow accessories as well as
no armor. I'm not sure whether that should be changed.
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 '"'.
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.)
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'.
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.
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.
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.
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.
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.
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.
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....
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.
To test, use 'stty -icrnl'
There's far too much gold just laying around on the floor.
Didn't previous adventurers grab most of it?
This should incentivize gold detection and digging out vaults,
selling stuff to the shopkeeps, and making it harder to donate
for protection.
Most radical reduction on the first few levels, for dlevel 1,
average amount of gold was 80, is now 10, for dlevel 2, 95->15
Does not change the amount of gold deposited by mineralize,
in the vaults, or contained in chests and large boxes.
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.)
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.
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.
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.
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.)
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.
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.
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
Add a new boolean option herecmd_menu. If this is on, and using
a windowport that supports mouse, clicking on your character pops
up a menu of actions doable in that location. Basically this is
nothing new, as almost all of the same actions were done before
on the mouse click.
You can also pop up the context menu with the #herecmdmenu
extended command
Accidentally caused by my grappling hook fix 2 months ago, attempting
to jump over water made hero enter that water and drown (or crawl out).
hurtle_step() was originally intended to be used for recoil while
levitating, but it is used in other situations where not levitating
and behavior for the two circumstances should be different.
This doesn't fix things properly, just gets jumping working again.
It was possible to arbitrarily boost strength (up to its race-specific
limit) by wearing a ring of sustain ability, becoming weak from hunger
(but not actually losing strength due to Fixed_abil), removing the ring,
eating enough to stop being Weak, then repeat as desired. I think you
could substitute polymorph for wearing ring, and rehumanize for removing
ring and get similar results, although that would be more tedious.
My first attempt to fix this was a lot more complicated. This one puts
the temporary strength loss in ATEMP(A_STR) where it carries over from
normal form to polymophed form and back. Fixed_abil doesn't prevent the
loss any more, nor its recovery.
One side-effect of the change is that the possibility of dying when
becoming weak from hunger (if Str gets down to 3, further attempts to
lower it take away HP instead of Str) no longer exists. Using ATEMP()
instead of directly manipulating ABASE() means that current strength is
less but underlying base strength does not actually drop any more.
Originally by Ray Chason for 3.4.3, based on the Qt windowport by
Warwick Allison. The look and feel is mostly the same.
Some improvements over the Qt 3 interface are:
* Panes are resizable
* Full support for IBMgraphics, and walls and corridors are drawn with
graphical primitives for a continuous appearance no matter what the font
says
* Lots of irritating glitches fixed
* Menus support proportional fonts correctly
Adding this because the old Qt windowport cannot be compiled on Qt4,
even with Qt3 compatibility stuff.
TODO:
- background map glyphs
- status hilites
- menucolors
Always find traps when using the rogue's quest Key to lock or unlock a
trapped door or chest provided that the Key is not cursed (for rogues)
or is blessed (for non-rogues). When a trap is found, the player is
given the opportunity to disarm it, and doing so will always succeed.
(It isn't disarmed automatically; the player may prefer to leave traps
in place, presumably hoping to set up a dangerous bones file. Or he
or she may be unaware of the guaranteed success and be too timid to
risk trying to disarm the trap.)
TODO: make #untrap of a door or chest while carrying that Key always
find traps (with same bless/curse requirements as above). And maybe
change its #invoke property from untrap to detect unseen/secret door
detection since current invoke power would become redundant.
Also, move a bunch of new artifact abilities from the fixes section to
the new features section in fixes36.1.
If the key is wielded and touching skin (that is, you're not
wearing gloves), it will give heat-related messages like
minesweeper, counting the undetected traps around player.
When hitting a monster with the Cleaver, you swing it in an
arc, possibly hitting the monsters to the left and right of
the targeted monster.
Based on code by Fredrik Ljungdahl
I've sometimes seen
, and basic NetHack features.
as the last line of the features section from '#version'. I thought
it was due to the way feature phrases were split into individual words
by makedefs, but it turned out to be due to inserting pattern matching
method at run-time. That dynamic options update had a second problem:
if the final phrase "and basic NetHack features" was split across two
lines, the run-time substitution didn't find it and the pattern matching
entry ended up being left out. This fixes both problems, but if future
dynamic entries become more complex, the phrase-splitting/word-wrapping
being done by makedefs may need to be moved into nethack.
Also, add entries for XLOGFILE and PANICLOG to makedefs' options and
re-order a couple of existing ones alphabetically (a failry hopeless
endeavor).
