<Someone> noticed the leftover zeromextra, this removes it.
Using memset() on a possibly failed mextra allocation was inapprorpriate,
so replace the newmextra() macro with a function.
Prevent a crash in christen_monst() if mextra was not initialized.
Note: The CVS repository was tagged with NETHACK_PRE_MEXTRA
prior to application of this patch to allow easy withdrawal if necessary.
Adds a new mextra structure type that has a set
of pointers to various types of monster structures
including:
mname, egd, epri, eshk, emin, edog
Replaces the mextra bits in the monst structure
with a single pointer called mtmp->mextra of type
(struct mextra *).
The pointer can be null if there are no additional
structures attached. The mextra structure is not
adjacent to the monst structure.
Reduces the in-memory footprint of the monst that
has no other structures attached, at the cost
of adding 6 extra long ints per monster to
the save file
The new mextra structure has the mextra fields
independent of each other, not overlapping as was
the case with previous NetHack versions.
This patch doesn't do anything to capitalize on
that difference however.
Consolidates vault.h, epri.h, eshk.h, emin.h and edog.h
into mextra.h
Adds a macro for checking for whether a monster has
a name:
has_name(monst)
This fixes the magic trap panic
expels() -> spoteffects() -> dotrap() ->
domagictrap() -> tamedog()
because the monst no longer varies in size so no
replacement is required.
From a bug report: the Call command's
prompt is careful not to include "of <deity>" when asking what name to give
a high priest on the Astral level, but the resulting rejection message of
"the <unique monster> doesn't like to be called names" did not, resulting
in feedback of "the high priest of <deity>" and giving away which temple it
is from afar.
A cased missed by "alteration of shop-owned objects" patch in April.
If Sting or Orcrist is created in a shop using an unpaid weapon, update the
bill to reflect that weapon's increase in value. No new fixes entry needed.
> clear stale prompt
[...]
> Can someone who understands the relevant windowing code fix ^R in getpos()?
I still don't understand why it wasn't working as expected, but moving
the existing cursor positioning after flush_screen() instead of before now
makes ^R work ok during getpos(). It doesn't restore the top line text so
isn't a transparent redraw but it now displays a prompt string there instead.
Likewise after typing '?' for help so that it should be move evident that
nethack is still waiting for you to move the cursor somewhere.
Also add support for ^L in numpad mode. I almost never use that and
didn't think of it the first time around.
From the newsgroup: applying various types of tools (example was a
mirror; figurine is another case) and then typing <ESC> at the "In what
direction?" prompt would leave the prompt displayed. User complained that
he tried to answer the no longer valid prompt--even though the cursor had
correctly moved back to the '@' on his map--and ended up walking into lava
instead. Suggested fix in the newsgroup was to use pline("Never mind.")
the way many commands already do, but it's simpler and more robust to clear
the message window before getdir() returns. Callers can issue Never_mind
feedback on a case by case basis as before; I haven't added any here.
Perhaps getpos() should get passed an extra argument telling it to issue
that message; then a dozen or so pline(Never_mind) calls could be removed.
I also was annoyed that ^R gave me the command assist display instead
of redrawing the screen with the prompt intact. This fixes it for getdir().
The corresponding fix for getpos() doesn't work correctly; it successfully
redraws the screen but leaves the cursor at the end of the 2nd status line,
despite the fact that it is followed by an existing cursor position call.
Can someone who understands the relevant windowing code fix ^R in getpos()?
(Easiest test case is probably just ^T in wizard mode.) I have't added an
entry for ^R to the fixes file since it isn't fixed yet. And I didn't look
to see whether yn_function() ought to handle ^R too; it might be used in
contexts where map redraws don't make sense.
Several places were not using safe_qbuf or anything equivalent to avoid
overflowing a QBUFSZ buffer. Add more uses plus one special case. For
the current max lengths returned by xname(), I think this is
sufficient. This addresses a reported buffer overflow for a
"thoroughly rusty thoroughly corroded helm of opposite alignment", plus more.
Follow suit with what <Someone> did for the object name buffers,
so that this sort of statement can work correctly:
pline("%s hits %s.", Monnam(mtmp), mon_nam(mtmp2));
Change the code involved to use a new #define for the field, like other
overloaded uses of corpsenm. Also remove one check for this field from
potion.c: there are no blessed potions from sinks.
Although the overlay stuff is destined to be
removed someday, this patch just makes the
use of STATIC_DCL, STATIC_OVL consistent
in the trunk.
[As a side pointless experiment, I was able
to build a working 8086 port of 3.4.2 after
this change that worked correctly in limited
testing right up until it came time to enter
Ft. Ludios., where it couldn't allocated the
required amount of memory.]
> "A cloud of sangria gas billows from the chest.
> You stagger and your vision blurs."
> When I see the gas billowing from the chest, I'm not yet
> hallucinating. Shouldn't the gas have a normal colour, then?
> Only after my vision blurs should the gas assume a fake colour, I
> think.
>
This makes all unique monsters resist being given a name. Aside
from the Oracle, the four high priests are the only monsters affected
that weren't already being covered by the old tests. They might as well
decline to receive names too.
This also fixes a longstanding quirk that prevented you from
calling a type of object something if the representative sample of it
had been picked up while blind and you hadn't explicitly examined your
inventory since regaining sight. There's not much point in requiring
an extra 'i' command or use of '?' or '*' at the "what do you want to
call?" prompt, particularly since that makes gameplay be slightly
different depending on whether perm_invent is available and in use.
I was about to add a message referring to your steed and discovered
that the name handling for that is somewhat messy. Simplify it by using
the pet name handling routine.
The link is no longer valid. I found another
link, http://tultw.com/bios/latin.htm
but this doesn't seem like something we
want to direct maintenance effort towards.
So this removes the link altogether.
<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.
I'm surprised that no one has noticed this one yet. When
wielding two weapons, naming either of them caused two-weapon
combat mode to stop (unless the weapon already had another name
which was long enough to be overwritten by the new name without
allocating a replacement object).
From the newsgroup: creating Sting via naming didn't produce
intrinsic warning (orc detection) if it was already wielded at the
time. (Un- and re-wielding it sufficed as a workaround.)
One from <Someone>'s list: there's no particular reason for
the High Priest of Moloch in the temple on the sanctum level in
Gehennom to have his identity concealed when he's detected from
a distance. I also changed the concealment of the Astral Plane
to stop when you're adjacent to the priest, since #chat--among
other things, such as simply entering the temple--provides other
means of identifying which temple it is once you're there.
Files patched:
include/extern.h
src/do_name.c, pager.c
