This patch alters wiz_identify so that it displays an
inventory menu with all items shown identified
without actually identifying them.
You can just press ^I (or whatever the wiz_identify command
is) a second time, while the menu is displayed to actually identify
them (tested with TTY menus only).
Add new_mname/free_mname functions to make monster name handling be
more like the other extended data and to hide mextra details a bit more.
Add some casts where int and unsigned are being intermixed. Simplify
christen_monst(); it ought to be changed to have type `void' but I wanted
to avoid modifying another ten or so files.
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.
Further discussion in the newsgroup pointed out a case not involving
<ESC> where the "In what direction?" prompt remained displayed after it was
no longer applicable: throwing something where there's no monster target
in the line of fire. You don't get any hit or miss message in a case like
that, so the last message (the prompt) stays in view. I don't think there
are any cases where getdir()'s caller deliberately wants to leave the old
prompt up, so just clear it unconditionally as soon as the user answers.
> 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.
<Someone> complained that his compiler was giving these
warnings:
cmd.c:2119: warning: declaration of `expl' shadows a global declaration
dungeon.c:292: warning: declaration of `rand' shadows a global declaration
exper.c💯 warning: declaration of `exp' shadows a global declaration
files.c:278: warning: declaration of `basename' shadows a global declaration
hack.c:1102: warning: declaration of `expl' shadows a global declaration
pickup.c:2081: warning: declaration of `select' shadows a global declaration
role.c:1060: warning: declaration of `conj' shadows a global declaration
Since "weapons and spell skills" is grammatically suspect and
"weapons and spells skills" sounds odd, change to "weapon and spell skills"
in both the Guidebook and the game's online descriptions. The #enhance
command itself uses "current skills" and doesn't need any alteration.
Per <Someone>'s request, make the game's description of the ``#enhance''
command be the same as in the Guidebook by mentioning spell skills.
Combining weapons plural with spell singular isn't right, but I'm not
sure which way to change that so am leaving it alone. On the other hand,
the poor grammar used to describe the ``#conduct'' command is easy to fix.
- can shift into fog clouds, vampire bats, and vampire lords into wolves
- after being "killed" in shifted form, they transform back rather than get
destroyed, and you must take them on in vampire form to defeat them
- can deliberately shift into fog clouds to pass under closed doors
This is a foundation patch for patches to follow.
- use a full short index for mon->cham field.
- The current system of providing CHAM_XXX values
was limited to the 3 bits allocated in the bitfield and invalidated
save/bones if the field was expanded.
- The current system didn't provide an easy backwards change
if multiple monster types wanted to use the bit, there was a one
to one mapping: For instance, if you wanted a CHAM_VAMPIRE,
and you wanted vampires, vampire lords, and Vlad to use it, you
would have to have CHAM_VAMPIRE, CHAM_VAMPIRE_LORD,
and CHAM_VLAD defined to achieve that with the one-to-one backward
mapping.
- This new way just uses the mon[] index in the mon->cham field and
eliminates the need for CHAM_XXX (CHAM_ORDINARY is still used).
- no longer requires the cham_to_pm mappings
This patch increments editlevel making existing save and bones files useless.
Add polywarn() code to grant the ability to detect certain monster
types while polymorphed into other specific monster types.
If you polymorph into a vampire or vampire lord, you are able to
sense humans.
And just for fun, if you polymorph into a purple worm, you are able to
sense shriekers :-)
Give more information about your attributes in debug mode
via Control-X.
I'd like to see some way of getting bits of this info to the
player during the game (from the Oracle or something),
but this patch keeps it limited to debug mode.
<Someone> drew attention to the silly message in the newsgroup
Since I'm not sure if the act of polymorphing has a sound,
I opted to use a new usmellmon() routine to put out a
message based on the smell of the resulting monster
under those circumstances.
Not every monster has a recognizable smell, so no
message at all is given in that case.
olfactory(youmonst.data) will determine whether
you are capable of detecting smells.
There is lots of room for enhancement, and some of the
existing smell-related messages in the source should perhaps
be checking olfactory(youmonst.data) too, but this patch
doesn't go that far.
Implement the patch sent by <email deleted>
to make responding with '?' at the "what direction?" prompt ask again
after giving the `cmdassist' direction display. I did it slightly
differently than was done in the submitted patch but the result is the
same except that it also suppresses the message about how to disable
cmdassist in this case.
> The new ^V wizmode menu is nice, but it is rather misleading; most of
> the levels it lists are "you can't get there from here". Would it be
> possible either to make it only list levels that can be reached
> directly, or alternatively to allow you to reach the ones you
> ordinarily couldn't (maybe by forcefully changing u.uz.dnum to yoink
> you into the right branch, and even summarily issuing you with an
> Amulet if you ask to teleport to the endgame).[...]; being able to bamf
> quickly to Minetown from DL 1, for example, would be damn useful in > testing stuff.
Allow fairly free roaming of the dungeon via the wizard mode teleport menu.
the message history saver needs the windows to stick around until save
is completed. This usually the case, but end_of_input() was calling
exit_nhwindows prematurely. This is actually an old bug (calling it early,
but wasn't harmful until other recent changes).
I wrote to the devteam early last week:
> Given my understanding of travel, it's supposed to be somewhat intelligent,
> and "convenient", and should, therefore avoid walking into water, lava,
> traps, or other things that distant movement would avoid, even if you're
> right next it. Unless... the travel destination is the "bad" location
> next to you when the travel starts.
To that end...
- add a context (iflags in 3.4.3 to maintain savefile compat) flag to
differenciate the first travel step from later steps, to allow the
detection of the final sentence, above.
- several changes to set/reset the travel1 flag as needed
- add code to findtravelpath to treat the first step specially if it's
the only step, allowing forced travel into a "bad" location
- correct the "don't travel over traps" code, which was getting confused
because hero's starting location was being avoided
- add code to avoid traveling into water and lava, duplicating
checks used for non-travel running
- fix some strange "guess" travel behavior: avoid zigzag paths when there's
a more direct path (even though the number of moves is the same)
- trunk change adds a new DISP_ALL tmp_at type, and uses it in some debug
code for travel, debug changes not added to the 3.4.3 branch
There was a great deal of inconsistency in
different menus on how headings were displayed.
This allows the user to select what they like best.
I was motivated to do this, because I wasn't satisfied
with the appearance of ATR_INVERSE in the menus
on win32tty, and several of them specified it.
Introduce a new set of functions to manage delayed killers in the trunk, used
in addressing the various reports of delayed killer confusion. Since existing
delayed killers are related to player properties, the delayed killers are
keyed by uprop indexes. I did this to avoid adding yet another set of
similar identifiers.
- the new delayed_killer() is used for stoning, sliming, sickness, and
delayed self-genocide while polymorphed. Some other timed events don't
use it (and didn't use the old delayed_killer variable) because they
use a fixed message when the timeout occurs.
- A new data structure, struct kinfo, is used to track both delayed and
immediate killers. This encapsulates all the info involved with
identifying a killer. The structure contains a buffer, which subsumes the
old killer_buf and several other buffers that didn't/couldn't use killer_buf.
- the killer list is saved and restored as part of the game state.
- the special case of usick_cause was removed and a delayed killer list
entry is now used in its place
- common code dealing with (un)sliming is moved to a new make_slimed function
- attempted to update all make dependencies for new end.c -> lev.h
dependency, sorry if I messed any up
+ Separate the two uses of flags.soundok.
+ Player-settable option is now called "acoustics".
+ Deafness is now handled as a full-fledged attribute.
+ Check for deafness in You_hear(), rather than caller.
+ Check for deafness in caller, rather than verbalize(),
because gods can speak to characters in spite of deafness.
+ Since changes are being made to prop.h, reorder it to the
same order as youprop.h and enlightenment.
There are still some extraneous checks and missing checks
for deafness, which will be followed up in a future patch.
Because of the size of this patch and its savefile incompatibilities,
it is only being applied to the trunk code. Portions of this patch
were written by Michael Allison.
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
This is an initial round of SAFERHANGUP hangup changes. It introduces
SAFERHANGUP, provides the core framework, and enables it for UNIX.
Window-port changes are provided for win/tty, win/X11 and win/gnome. Qt
changes should be forthcoming after having Warwick look at them.
window.doc is updated so windowport maintainers have an clue what needs to
be done to support SAFERHANGUP.
<email deleted> wrote:
> If more monsters fall through a trap door than can fit on the
> level below, when you go down the stairs, you get the following
> message:
> "Program in disorder - perhaps you'd better #quit.
> rloc(): couldn't relocate monster"
> This message seems to appear once for every monster-too-many that
> fell through the hole. I originally found this while
> intentionally completely filling a level with black puddings
> (there was a trap door I didn't know about). I also confirmed it
> in a wiz-mode test using gremlins and water.
[confirmed: moveloop -> deferred_goto -> goto_level ->
losedogs -> mon_arrive -> rloc -> impossible]
This patch:
- causes rloc() to return TRUE if successful,
or FALSE if it wasn't.
- adds code to mon_arrive() in dog.c to deal with
the failed rloc()
- allows the x,y parameters to mkcorpstat() to
be 0,0 in order to trigger random placement of the
corpse on the level
- if you define DEBUG_MIGRATING_MONS when you build cmd.c
then you'll have a debug-mode command #migratemons to
store the number of random monsters that you specify
on the migrating monsters chain.
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.]
the cmdassist message shows all the valid directions even if you are
polymorphed into a grid bug. I noticed this when I typed a diagonal
direction as a grid bug and got the dialog, telling me the key I just typed
was valid, but it wasn't. Limit the keys to those valid for grid bugs.
This is derived from the proposed patch and feedback to it. This applies
the last-position cache behavior without an option, making the behavior
more like it is for interfaces with a mouse, where holding the mouse still
acts the same way as the travel cache. The code is not #ifdef'd either.
This allows the use of the right mouse button to
look at things on the screen when the
'clicklook' option is set.
Concept came from a patch for 3.4.0
that I saw referenced on r.g.r.n
[see http://www.steelskies.com/nethack.php]
but the implementation is different.
Unix code does not always go thru hangup() when EOF is encountered.
There is a similar end_of_input() that is sometimes called instead, which
was missing a test of program_state.something_worth_saving.
The number_pad option can now optionally hold a value
{0,1, 2 } for {off, on, DOS-mode} but plain number_pad and
!number_pad in config files still work as before.
When number_pad:2 is set, iflags.num_pad_mode is set to 1
which triggers the following behaviour:
> '5', M('5') and M('0') are mapped in rhack()
>in cmd.c, only when they are entered as a command. When used as a
>number, like in the 'n' command, no mapping takes place. '0' is
>already mapped to 'i' by the core. The
>only difference [<Someone>] left in (deliberately) is when you press Ctrl-0;
>this used to map to C('i'), which is an invalid command; now
>keep it '0' (which is interpreted as 'i' by the core.)
> The `prompt' buffer in tty_yn_function still only holds QBUFSZ
> characters. But fixing the tty incarnation wouldn't be good enough;
> all the other interfaces would need to handle it too. I think it
> should be fixed in the core instead. Prompt strings simply should
> not be allowed to become so lengthy.
Another step in the fight against prompt sting buffer overflows.
The goes after the ones that may not have been found yet.
This makes yn_function a real core function and removes
the #define yn_function macro.
The yn_function validates the prompt string buffer being
passed prior to calling (*windowprocs.win_yn_function)(),
and if necessary, truncating it and adding "...".
This won't help if the overflow occurs in the core in
a buffer that is still QBUFSZ in size, but it will help if
a BUFSZ buffer is being passed to one of the query
functions.
Another fix to address the complaints about two-handed weapons being
rendered useless by 3.4.1's change to require free hands in order to apply
containers. Some players now fear to wield two-handed weapons because a
curse would make accessing their bag impossible, which is doubly nasty if
that's where they have scrolls of remove curse or potions of holy water
intended to deal with cursed items. The same situation applies for cursed
one-handed weapon combined with cursed shield, so some are now claiming
that 3.4.1 has made two-weapon combat be even more attractive than before.
This implements #tip, a new command that causes a container at the
current location or carried in inventory to have its contents emptied
onto the floor. Hero's hands don't need to be free at the time but tipping
a floor container requires limbs; tipping an inventory container doesn't
need hands or even limbs. The contained items don't pass through inventory
during the process, so don't cause objects (loadstones, crysknives, scrolls
of scare monster?) to go through their special handling unless it's part of
normally dropping to the floor. Tipping a bag of tricks behaves the same
as applying it (one monster is released, and it only becomes empty if
that happened to be the last charge) and items tipped out of a cursed bag
of holding have their normal cursed bag chance (1/13) of being destroyed.
Tipping an inventory container while levitating or during unskilled riding
behaves similar to normal drop--from a height, so some fragile items break.
Players have wanted this feature to get gray stones out of chests or
heavy corpses out of ice boxes but I didn't care much about that; losing
access to your bag is more significant. I'm pretty sure that there was a
user patch to do something like this floating around at one time, but I
couldn't find it when I looked, so I implemented #tip totally from scratch.
Bug? Extended commands which lack meta-key shortcuts are not listed
in the help files displayed by the '?' command....
Prevent burying a ball from ending your punishment.
When you bury the ball, internally NetHack Punishment
ceases, but a new trap type of TT_BURIEDBALL immediately
kicks in (acting similar to TT_INFLOOR in some ways).
You can eventually work the ball free (or teleport, etc.),
but that will just return you back to normal Punishment.
- Move the code for keystroke handling into its own source file.
- Compile and link it as a dynamic link library.
- Dynamically load the keystroke handler at runtime
- Add support for specifying a different handler in defaults.nh
so that internationalization issues can be dealt with without
rebuilding nethack, just supply alternative handlers in HACKDIR.
The following exported functions need to be present in
the keystroke handler .dll:
ProcessKeystroke - returns an ascii value to NetHack
NHkbhit - allows peeking to see if a key/mouse press is waiting
SourceWhere - returns location for souce code for a keystroke handler
SourceAuthor - returns author information for a keystroke handler
KeyHandlerName - returns the full or short name of the keystroke handling dll.
- Version change from 3.4.x
- timed_delay feature ignore in makedefs
- several flags from iflags to flags
- use offsets from mons array entries in save file rather than storing
the ptr and calculating the distance from beginning of array
I don't know whether there were any other odd situations besides moving
onto known traps being caused by the out of date value in flags.run; several
places do check to see whether it's 8.
Provide a way to have a port-specific debug-mode commands
if PORT_DEBUG is defined at build time.
Add a win32 keystroke checking routine to assist debugging
of international keyboards.
Fix a problem with the way NetHack was handling
international keyboards by letting ToAscii() come
up with an input character based on the virtual key,
and the shift and caps lock state.
