The CE ports use makedefs hosted on another platform,
so the version string generated at build time isn't really
appropriate.
Add a way to add information to the version string
at runtime for such ports.
To fix Magicbane's message sequencing, its code needs to be redone
substantially. These changes make that easier.
cancel_monst() let caller know whether cancellation succeeds
resist() give artifact weapons a resistance attack rating
vtense() handle monster names and "you" as subjects; checking against
object names and descriptions pointed out a couple of other
words that would have ended up being miscategorized.
>More worrying is the fact that applying a figurine over water lets
>the monster wait until its next move before it drowns (giving
>you time to teleport it to safety, or whatever) [...]
>Should there be a minliquid() check as part of make_familiar()?
Applying at the water location next to you was easy. But
applying it at your own location (triggering BY_YOU) could
end up placing the figurine at the far side of the level if
there was lots of water.
Correcting that required the ability to pass a flag from
make_familiar to makemon() telling it to not rule out
water locations as good positions. The flag had to
be passed on down to goodpos() and enexto().
The bulk of this patch is just adding an additional
argument to goodpos() in all of the callers.
Prevent #rub from wielding an item that is already being worn
(which should narrow things down to the various types of eyewear;
other tools and weapons that go through wield_tool() can't be worn).
Fix up the wield_tool message spacing in the process.
This moves wield_tool() from apply.c to wield.c. Some plural
handling for messages is included; it is feasible to try to #rub a
"pair of lenses" or a stack of N candles.
For "traditional" menu style, pickup and #loot/apply can't accept an 'm'
response to bring up a menu upon request when all items involved are of
the same class, because the prompt where that response is allowed only
gets issued when multiple classes are present.
The complaint states:
It still won't let you unwield a cursed secondary weapon while
two-weaponing, even though you can drop such a weapon without problem.
You aren't supposed to be able to two-weapon
with a cursed alternate weapon at all. It appears that there are some
checks to prevent twoweaponing if uswapwep is cursed when you try.
This patch ensures that two-weaping stops if uswapwep gets cursed
while two-weaponing. I think this means the 'A' command will never
encounter the situation now in the complaint now.
The rules in wield.c state
The secondary weapon (uswapwep):
1. Is filled by the x command, which swaps this slot
with the main weapon. If the "pushweapon" option is set,
the w command will also store the old weapon in the
secondary slot.
2. Can be field with anything that will fit in the main weapon
slot; that is, any type of item.
3. Is usually NOT considered to be carried in the hands.
That would force too many checks among the main weapon,
second weapon, shield, gloves, and rings; and it would
further be complicated by bimanual weapons. A special
exception is made for two-weapon combat.
4. Is used as the second weapon for two-weapon combat, and as
a convenience to swap with the main weapon.
5. Never conveys intrinsics.
6. Cursed items never weld (see number 3 for reasons), but they also
prevent two-weapon combat.
Building with an old version of gcc with various warnings enabled
generated a lot of noise. Most of it was due to not guarding string
literals with `const', but there were a couple of actual problems too.
Some recent newsgroup discussion claiming that a pet ki-rin was
wearing a helmet (I think poster was hallucinating) caused me to look
at some of the hat handling code. There were a couple of noticeable
problems and one latent one in code added for 3.4.1. Polymorphing
into a minotaur pushes hard helmets off hero's head, but nothing
prevented you from putting one right back on. Helmet wearing monsters
who polymorphed into minotaurs weren't affected at all. And message
handling always assumed multiple horns even though we have some singled
horned monsters, but since all those have no hands they can't wear any
armor and that potential pluralization issue wasn't noticeable.
Various damage types which wouldn't work when a cancelled monster
attacks the player were working when it attacked other monsters instead.
Besides attempting to fix that, this also makes cloaks and other magic
blocking armor ("magic cancellation factor") work for monsters similar
to the way it works for the player.
Most types of damage appear to revert to physical damage when the
attacker is cancelled; I'm not sure that's appropriate in many of the
instances. The leg-pricking case was clearly wrong, since it gives
messages about the attack failing yet still hurt the character.
This really needs a lot more testing than I have energy for. I've
tried to clean up various inconsistencies and may have made some typos
in the process.
<Someone> wrote: "Also, hobbits can't wear armour,
at least, you can't wear armour when polymorphed into a hobbit, even
though hobbits do tend to be carrying elven mithril-coats.
It's tempting to suggest adding an explicit exception in
sliparm() for elven mithril just to keep the Tolkienness."
- added a general routine for adding race-based /object
combination exceptions.
- hobbits can wear elven mithril-coats
Menu styles `partial' and `full' will let you remove any type of
item from the three weapon slots via the 'A' command, but `traditional'
and `combination' would only do that for the primary weapon slot. For
the alternate weapon and quiver slots, the item in question had to be
one which can normally be wielded or worn, otherwise when choosing the
object class letter you'd be told that it was "Not applicable." And
for wearable items, you needed to be really wearing one of that class
(besides the quivered one) or else you'd get "not wearing any amulet"
or similar.
Make sure the three instances of special fire effects stay
synchronized in the future by moving the relevant code into its own
routine.
Shouldn't fire vortices and fire elementals also yield "already
on fire"? How about ice vortices "melting"?
Fix the reported problem of getting impossible warnings for unpaid
inventory items during final disclosure if you level teleport out of
the dungeon while holding shop goods. The fix makes you trigger a shop
robbery first; that required a minor end of game change to prevent the
shopkeeper from seeming to tag along (shk would take your possessions
as if you'd died on the shop level).
use get_adjacent_loc() rather than getdir() directly for some things where
you want to ensure valid adjacent coordinates are returned
<email deleted> wrote:
>>> [...]
>>> I've noticed that the loot adjacent spot code doesn't have any
>>> isok(x,y) test, so will risk crashing if used at the edge of
>>> the screen (whether deliberately, or accidentally due to being
>>> confused or stunned when picking the direction).
>> Would this not be a problem elsewhere, such as use_leash() too?
> Yes, that looks like the same risk. getdir() doesn't validate
> that the <u.ux+u.dx, u.uy,u.dy> is safe and neither does m_at(),
> so their callers need to.
>
> I did manage to provoke a crash with #loot on the plane of earth,
> although an accidental case would be a lot less likely to happen.
Forwarded from the newsgroup: when a monster gets hit by wand or
spell of polymorph, any armor that fell off was protected from being
hit by that same zap, but a dropped weapon wasn't. Nor was the whole
dropped inventory in the case where the monster is killed by system
shock rather than transformed. Protect its entire inventory.
When Angels were introduced, they were always lawful. Somewhere along the
line, non-lawful angels were added, but is_lminion and uses of it was never
updated to address this change. Among other things, this resulted in
non-lawful angels delivering messages via #chat that are only appropriate
for lawful angels. That is addressed simply by changing the definition of
is_lminion, which must take a struct monst, not a permonst, to return valid
results. Also, non-lawful angels should summon appropriate monsters, not
lawful minions.
Incorporate a fix from <Someone> that resets the timestamp on
stinking clouds left in bones files. This does allow the cloud's ttl to
restart. Extended it to reset the player_inside flag.
Then noticed that the only placed that called in_out_region was domove().
Added calls when changing levels (which causes player_inside to be set
correctly if the cloud covers the location where the player starts on the
bones level), teleporting, and inside hurtle_step. There are still other
places that fail to call in_out_region, which others may choose to tackle.
I split out the remaining stinking cloud bug reported in the same e-mail
into a separate betabug. That one probably cannot be addressed without
changing the level file format to track the creator.
Fix the reported bug of an unskilled rider who is unable to pick
items off the floor while mounted still being able to dip into water.
There might be other actions which need similar checking; this one only
handles the dip into pool/moat case.
Instead of adding a new artifact.h to pray.c, remove the existing
ones from attrib.c, invent.c, and mkobj.c. This also updates the Unix
and VMS editions of Makefile.src; having stale dependencies in those
for other ports could cause unnecessary recompilation but can't break
anything in this case.
Noticed while testing something recently: if you're wearing
a non-cursed ring of levitation but can't remove it because of
some other cursed item, you'll never get the high priority result
of TROUBLE_LEVITATION when praying. This remedies that.
Provide more control over message handling for monsters' use
of equipment. This fixes the statue revival problem (inappropriate
feedback when monster puts on speed boots) mentioned in the earlier
"intrinsics of dead monsters" patch.
Pat added some error information to create_levelfile.
This does the same for create_bonesfile, but the
only place it is logged is in the paniclog, unless
you're in wizard mode. If bones file creation is
silently failing for someone and they aren't getting
bones files, this provides a way to diagnose why.
1) consolidate all core usage of `errno' in files.c;
2) give more feedback for any failure by create_levelfile or open_levelfile,
similar to what was being done for problems during level change;
3) include trickery info in paniclog (many instances of "trickery" seem to
be due to disk or quota problems rather than user misbehavior...).
The create_levelfile call in pcmain probably ought to be changed to use
error feedback, but in the meantime this should continue working.
Perhaps error() should be modified to update paniclog too, but I didn't
want to go through all its port-specific incarnations making changes.
- Breaking wand of digging dug through rock which should be undiggable.
Checks assumed pits would never show up in solid rock.
- Breaking wand of digging near shop walls wouldn't anger the shopkeeper
Checks assumed pits would never show up in walls, also, added a special
case to pay_for_damage to handle the case where you're falling thru and
can't be asked to pay.
- Shop walls wouldn't be restored if there are pits in the way.
Checks assumed pits would never show up in walls.
- If there was a hole outside the shop, you could kick stuff out of the
door into the hole without shopkeeper noticing. Added the missing check.
<Someone> wrote:
> Linux, Redhat 7.1 nethack 3.4.0
>
>Please see attached patch file.
>
>I'm attempting to move more stuff into the "read-only" area, in
>preparation for a port to another OS.
> [Cast a healing spell in a shop where no mimic was visible] So,
> "The small mimic looks better.". However, my picture still looks
> the same. Either the mimic should be shown, *or* I shouldn't get
> any message about the mimic healing. Both solutions seem equally
> valid to me.
If the mimic was mimicing the "strange object", then the healing causes
them to start mimicing something else with no message (the observant
player could notice however).
If the mimic was already mimicing a real object, a message similar
to this one results:
"The crude dagger seems a more vivid black than before."
Provide some command assistance for newbies, but
suppress it with !cmdassist in the config file.
If someone misinterprets the Guidebook ^D, ^T
type command notation, this will pop up some
further information to possibly assist them and
explain the notation.
Move get_saved_games() functionality to files.c
Use moved get_saved_games() functionality in Qt windowport.
[also some non-enabled perminv code in Qt windowport]
Allow single character variations in player names
to remain unique in file names by encoding rather
than substituting.
"plnam one", "plnam_one", and "plnam~one" at the
"Who are you?" prompt get unique filenames after this patch.
Pat forwarded a message from the newsgroup in March that the town guards
enforce rules even outside the town proper. Fix: On room-based town levels,
check if the location is in a room containing subrooms (roomno will often
have a subroom id instead). On the other levels (e.g. minetn-5), there are
no subrooms, so the whole level is fair game. Currently, this is valid.
If fancier towns are added in the future, more flags or use of regions may
be required to tell where the town border actually is. These checks are done
in a new in_town function.
Fix the problem [reported in the newsgroup and forwarded by <Someone>]
of blessed potions of gain level having the possibility of reducing
your experience points if you were already level 30. The random XP
value that averages "half way to next level" could be less than your
current experience if you had gotten to level 30 via such a blessed
potion or had drunk at least one of same since reaching that level.
This didn't really make any difference to game play since you weren't
losing any levels, HP, mana, or score, but it was visible to users who
enable the `showexp' option.
Fixes 2 bugs:
1) an impossible() could occur if you applied a lance against a long worm
because the code uses thitmonst to do the hitting, but didn't set bhitpos,
which is required before calling thitmonst.
Add the missing assignment.
2) applying a lance would never mark a knight as a caitiff. Added a new
check_caitiff function and called it from the 2 existing checks and in
the lance code.
The NOCWD_ASSUMPTIONS conditional code allows readonly
parts of NetHack to be separated from areas that require write-access.
This allows the recent panic log needed a prefix.
Add an optional paniclog file, controlled by a new PANICLOG macro that can
be used to log all panic and impossible messages. Helpful when people
forget to send, or didn't see, the message.
Add a param to newcham() to let it print "The oldmon turns into a newmon!"
rather than always printing this externally. Should ensure a good ordering
of the messages. Also put some special name handling in one place and
catch a couple cases where "saddled" was printed, resulting in funny messages.
- when a shopkeeper leaves the shop to chase the player, and the player
enters the shop, bill_p is set to an unusual value. bill_p needs to be set
back to a valid value if the shopkeeper re-enters the shop.
- Also, the u.ushops state needs to be updated when a shop becomes tended
again if the player is in the shop.
- introduce a new after_shk_move function to handle this
