[PATCH] command 'X' and (un)locking confirmation

Archived from groups: rec.games.roguelike.nethack (More info?)

Hello,

here is a small patch that does two changes into the game interface.

First change is that X is changed to mean #twoweapon and an extended
command #explore (meta-x) is added for entering the explore mode. This
part of the patch is covered by the macro X_TWOWEAPON in config.h.

The second change is controlled by CONFIRM_LOCKING macro in config.h.

This introduces a new option 'confirm_locking' and changes the old
option 'confirm' to 'confirm_attack'. The default for confirm_locking is
on so by default the game behaves just like without the patch except for
the name change of the 'confirm' option.

If the option confirm_locking is off then (un)locking a door or a lonely
container is no longer confirmed. If the location however has multiple
(un)lockable containers then the confirmation is asked to facilitate the
selection of which container the user want's to (un)lock.

--- CUT HERE !!! ---
diff -bruNX ignore.txt ..\official/changes ./changes
--- ..\official/changes Thu Jan 1 00:00:00 1970
+++ ./changes Mon Aug 22 18:30:44 2005
@@ -0,0 +1,32 @@
+Changes to the section 4 Commands in NetHack Guidebook
+
+Change the command X to read as follows:
+
+---
+X Toggle two-weapon combat on or off. Note that you must use
+ suitable weapons for this type of combat, or it will be au-
+ tomatically turned off.
+---
+
+Add the following:
+
+---
+#explore
+ Enter explore (discovery) mode, explained in its own section
+ later.
+
+M-x #explore
+---
+
+
+Changes to the section 9.4. Customization options in NetHack Guidebook
+
+
+Change option 'confirm' to 'confirm_attack'. Add the following:
+
+---
+confirm_locking
+ Have the game confirm if a door or a lonely container is (un)locked
+ (default on).
+---
+
diff -bruNX ignore.txt ..\official/include/config.h ./include/config.h
--- ..\official/include/config.h Mon Dec 8 01:39:14 2003
+++ ./include/config.h Mon Aug 22 17:48:44 2005
@@ -351,6 +351,17 @@
/*#define GOLDOBJ */ /* Gold is kept on obj chains - Helge Hafting */
/*#define AUTOPICKUP_EXCEPTIONS */ /* exceptions to autopickup */

+#define CONFIRM_LOCKING /* Confirmation messages for (un)locking
doors or
+ * containers if only one container in the location
+ * if confirm_locking is set in the options.
+ * Default is on.
+ * Can be set during the game.
+ */
+
+#define X_TWOWEAPON /* X command is changed to twoweapon; meta-x and
+ * #explore is for entering the explore-mode.
+ */
+
/* End of Section 5 */

#include "global.h" /* Define everything else according to choices
above */
diff -bruNX ignore.txt ..\official/include/flag.h ./include/flag.h
--- ..\official/include/flag.h Mon Dec 8 01:39:14 2003
+++ ./include/flag.h Mon Aug 22 17:49:42 2005
@@ -175,6 +175,9 @@
uchar bouldersym; /* symbol for boulder display */
boolean travel1; /* first travel step */
coord travelcc; /* coordinates for travel_cache */
+#ifdef CONFIRM_LOCKING
+ boolean confirm_locking; /* ynq question for (un)locking */
+#endif
#ifdef WIZARD
boolean sanity_check; /* run sanity checks */
boolean mon_polycontrol; /* debug: control monster polymorphs */
diff -bruNX ignore.txt ..\official/src/cmd.c ./src/cmd.c
--- ..\official/src/cmd.c Mon Dec 8 01:39:14 2003
+++ ./src/cmd.c Mon Aug 22 17:39:42 2005
@@ -1439,7 +1439,12 @@
{'W', FALSE, dowear},
{M('w'), FALSE, dowipe},
{'x', FALSE, doswapweapon},
+#ifdef X_TWOWEAPON
+ {'X', FALSE, dotwoweapon},
+ {M('x'), TRUE, enter_explore_mode},
+#else
{'X', TRUE, enter_explore_mode},
+#endif
/* 'y', 'Y' : go nw */
{'z', FALSE, dozap},
{'Z', TRUE, docast},
@@ -1481,6 +1486,9 @@
{"dip", "dip an object into something", dodip, FALSE},
{"enhance", "advance or check weapons skills", enhance_weapon_skill,
TRUE},
+#ifdef X_TWOWEAPON
+ {"explore", "enter the explore mode", enter_explore_mode, TRUE},
+#endif
{"force", "force a lock", doforce, FALSE},
{"invoke", "invoke an object's powers", doinvoke, TRUE},
{"jump", "jump to a location", dojump, FALSE},
diff -bruNX ignore.txt ..\official/src/lock.c ./src/lock.c
--- ..\official/src/lock.c Mon Dec 8 01:39:14 2003
+++ ./src/lock.c Mon Aug 22 17:54:30 2005
@@ -294,13 +294,29 @@

count = 0;
c = 'n'; /* in case there are no boxes here */
+
+#ifdef CONFIRM_LOCKING
+ for(otmp = level.objects[cc.x][cc.y]; otmp; otmp = otmp->nexthere)
+ if (Is_box(otmp)) ++count;
+ if ((count == 1) && !iflags.confirm_locking) c = 'y';
+#endif
+
for(otmp = level.objects[cc.x][cc.y]; otmp; otmp = otmp->nexthere)
if (Is_box(otmp)) {
+
+#ifndef CONFIRM_LOCKING
++count;
+#endif
+
if (!can_reach_floor()) {
You_cant("reach %s from up here.", the(xname(otmp)));
return 0;
}
+
+#ifdef CONFIRM_LOCKING
+ if ((count > 1) || iflags.confirm_locking) {
+#endif
+
it = 0;
if (otmp->obroken) verb = "fix";
else if (!otmp->olocked) verb = "lock", it = 1;
@@ -315,6 +331,10 @@
if(c == 'q') return(0);
if(c == 'n') continue;

+#ifdef CONFIRM_LOCKING
+ }
+#endif
+
if (otmp->obroken) {
You_cant("fix its broken lock with %s.", doname(pick));
return 0;
@@ -401,11 +421,19 @@
}
#endif

+#ifdef CONFIRM_LOCKING
+ if (iflags.confirm_locking) {
+#endif
+
Sprintf(qbuf,"%sock it?",
(door->doormask & D_LOCKED) ? "Unl" : "L" );

c = yn(qbuf);
if(c == 'n') return(0);
+
+#ifdef CONFIRM_LOCKING
+ }
+#endif

switch(picktyp) {
#ifdef TOURIST
diff -bruNX ignore.txt ..\official/src/options.c ./src/options.c
--- ..\official/src/options.c Mon Dec 8 01:39:14 2003
+++ ./src/options.c Mon Aug 22 18:25:10 2005
@@ -74,7 +74,12 @@
# else /* systems that support multiple terminals, many monochrome */
{"color", &iflags.wc_color, FALSE, SET_IN_GAME}, /*WC*/
# endif
+#ifndef CONFIRM_LOCKING
{"confirm",&flags.confirm, TRUE, SET_IN_GAME},
+#else
+ {"confirm_attack",&flags.confirm, TRUE, SET_IN_GAME},
+ {"confirm_locking", &iflags.confirm_locking, TRUE, SET_IN_GAME},
+#endif
#if defined(TERMLIB) && !defined(MAC_GRAPHICS_ENV)
{"DECgraphics", &iflags.DECgraphics, FALSE, SET_IN_GAME},
#else
--- CUT HERE !!! ---

Topi
--
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell
"How come he didn't put 'I think' at the end of it?" - Anonymous
17 answers Last reply
More about patch command locking confirmation
  1. Archived from groups: rec.games.roguelike.nethack (More info?)

    Topi Linkala wrote:
    > Hello,
    >
    > here is a small patch that does two changes into the game interface.
    >
    > First change is that X is changed to mean #twoweapon and an extended
    > command #explore (meta-x) is added for entering the explore mode. This
    > part of the patch is covered by the macro X_TWOWEAPON in config.h.
    >
    > The second change is controlled by CONFIRM_LOCKING macro in config.h.
    >
    > This introduces a new option 'confirm_locking' and changes the old
    > option 'confirm' to 'confirm_attack'. The default for confirm_locking is
    > on so by default the game behaves just like without the patch except for
    > the name change of the 'confirm' option.
    >
    > If the option confirm_locking is off then (un)locking a door or a lonely
    > container is no longer confirmed. If the location however has multiple
    > (un)lockable containers then the confirmation is asked to facilitate the
    > selection of which container the user want's to (un)lock.

    Very nice work! It's great to see patches like this one that add more
    customization to the interface but which can be ignored if people want
    to. This sort of thing could be easily included in the official release
    without much debate.
  2. Archived from groups: rec.games.roguelike.nethack (More info?)

    On Mon, 22 Aug 2005 18:45:00 +0300, Topi Linkala <nes@iki.fi>
    wrote:

    >Hello,
    >
    >here is a small patch that does two changes into the game interface.
    >
    >First change is that X is changed to mean #twoweapon and an extended
    >command #explore (meta-x) is added for entering the explore mode. This
    >part of the patch is covered by the macro X_TWOWEAPON in config.h.
    >
    >The second change is controlled by CONFIRM_LOCKING macro in config.h.
    >
    >This introduces a new option 'confirm_locking' and changes the old
    >option 'confirm' to 'confirm_attack'. The default for confirm_locking is
    >on so by default the game behaves just like without the patch except for
    >the name change of the 'confirm' option.
    >
    >If the option confirm_locking is off then (un)locking a door or a lonely
    >container is no longer confirmed. If the location however has multiple
    >(un)lockable containers then the confirmation is asked to facilitate the
    >selection of which container the user want's to (un)lock.
    >

    Most excellent! Thanks for the effort. I agree that these
    could
    easily be combined into the next standard release.

    Could the #untrap command be similarly converted to 'S' (Search
    for
    traps), with the same lack of confirmation if only one
    door/container
    is available to be searched? Multiple searches for traps would
    be much
    easier with the CTRL-A command then. 'S' for savegame could
    similarly be
    changed to #save.

    The extra change would also be nice in that #untrap currently
    does not
    actually untrap. Instead it searches for a trap.


    Jove
  3. Archived from groups: rec.games.roguelike.nethack (More info?)

    Jove wrote:

    > Most excellent! Thanks for the effort. I agree that these
    > could easily be combined into the next standard release.
    >
    > Could the #untrap command be similarly converted to 'S' (Search
    > for traps), with the same lack of confirmation if only one
    > door/container is available to be searched? Multiple searches for
    > traps would be mucheasier with the CTRL-A command then. 'S' for
    > savegame could similarly be changed to #save.
    >
    > The extra change would also be nice in that #untrap currently
    > does not actually untrap. Instead it searches for a trap.

    The problem here is that there is no such thing as a known trap on large
    box, chest, statue or door. This means that currently there is no way to
    separate the finding of the trap from the disarming of the trap.

    Btw. statue traps cannot be disarmed in current version and I'm not sure
    should anything less than cancellation do that.

    I'm sure I'll find a bit in the obj structure that is unused for large
    boxes and chest to implement the found trap but what about doors. There
    is no unused bits in the rm structure and adding one would mean save
    incompatibility.

    One solution is to fiddle with the existing flag bits but I'd hate to do
    that. As a trapped door can only be closed one could use the D_ISOPEN or
    D_NODOOR bits to mark the known trap. But this would mean that every
    time that you check a door state you need first check that it's closed
    because a closed door might then have D_ISOPEN or D_NODOOR set. This
    would mean that somebody in the future wouldn't remember to do this and
    bugs creep in. Also switches couldn't be used but the existing code uses
    switch statement for doorstates only in one point in the code (when
    wizard lock is cast onto a (former) door position the message shown is
    selected using switch).

    On the other hand if the next official release is not backwards save
    compatible with the 3.4.3 version then at that point the extra bit might
    be added in and the fiddling solution is only for the interrim.

    Thoughts. Comments.

    Topi
    --
    "The whole problem with the world is that fools and fanatics are
    always so certain of themselves, but wiser people so full of doubts."
    - Bertrand Russell
    "How come he didn't put 'I think' at the end of it?" - Anonymous
  4. Archived from groups: rec.games.roguelike.nethack (More info?)

    Jove wrote:

    > Most excellent! Thanks for the effort. I agree that these
    > could easily be combined into the next standard release.
    >
    > Could the #untrap command be similarly converted to 'S' (Search
    > for traps), with the same lack of confirmation if only one
    > door/container is available to be searched? Multiple searches for
    > traps would be mucheasier with the CTRL-A command then. 'S' for
    > savegame could similarly be changed to #save.
    > The extra change would also be nice in that #untrap currently
    > does not actually untrap. Instead it searches for a trap.

    What I forgot to add is that I wouldn't add a new S command but change
    the existing search so that it has a chance to find traps on large boxes
    and chest if used in a location that has them or from adjacent doors.

    Once the trap is found one could use #untrap to handle it. #untrap
    against unfound trap would just tell that you cannot see any trap here.

    How to show that there is atrap on adoor or a container is separate
    issue but has to be solved. New tile in tiled version and color change
    in ASCII version would perhaps be the best solution but for that I'd
    need some help.

    Topi
    --
    "The whole problem with the world is that fools and fanatics are
    always so certain of themselves, but wiser people so full of doubts."
    - Bertrand Russell
    "How come he didn't put 'I think' at the end of it?" - Anonymous
  5. Archived from groups: rec.games.roguelike.nethack (More info?)

    Topi Linkala wrote:
    > Jove wrote:

    >> Could the #untrap command be similarly converted to 'S' (Search
    >> for traps), with the same lack of confirmation if only one
    >> door/container is available to be searched? Multiple searches for
    >> traps would be mucheasier with the CTRL-A command then. 'S' for
    >> savegame could similarly be changed to #save.

    > Thoughts. Comments.

    Please don't change existing commands! Add the #search command, if you
    wish, but stay away from S.

    This is the same as the Dev Team usually does. For example, when they
    changed the the male/female options to gender:male/gender:female, the
    still retained the old syntax. NatHack has almost always remained
    backward compatible, so old options files remained valid.

    In the same way, I would have liked your previous patch better if you
    hadn't changed the existing option ("confirm" -> "confirm_attack"), but
    just *added* "confirm_attack" as an alternative for "confirm", keeping
    "confirm" as a valid option.

    The Dev Team uses this way of introducing changes as well, in the next
    release the remove the documentation for the old spelling, and in a
    following release, they remove the old option. Changing it gradually
    means that less people will notice the change.

    Boudewijn.

    --
    "I have hundreds of other quotes, just waiting to replace this one
    as my signature..." - Me
  6. Archived from groups: rec.games.roguelike.nethack (More info?)

    On Tue, 23 Aug 2005 11:02:54 +0300, Topi Linkala <nes@iki.fi>
    wrote:

    >Jove wrote:
    >
    >> Most excellent! Thanks for the effort. I agree that these
    >> could easily be combined into the next standard release.
    >>
    >> Could the #untrap command be similarly converted to 'S' (Search
    >> for traps), with the same lack of confirmation if only one
    >> door/container is available to be searched? Multiple searches for
    >> traps would be mucheasier with the CTRL-A command then. 'S' for
    >> savegame could similarly be changed to #save.
    >>
    >> The extra change would also be nice in that #untrap currently
    >> does not actually untrap. Instead it searches for a trap.
    >
    >The problem here is that there is no such thing as a known trap on large
    >box, chest, statue or door. This means that currently there is no way to
    >separate the finding of the trap from the disarming of the trap.
    >

    I was unclear, sorry. There were interface-only changes
    suggested:

    - Use 'S' as a direct replacement for the #untrap command.
    - Move the save game command from 'S' to #save.

    This is enough of an improvement to stand on its own, but would
    also be further enhanced by -

    - Having the #untrap functionality automatically check,
    *without* prompting for direction, if there is only one
    door/container in position to be checked for a trap.

    As I currently misunderstand the #untrap command, standing
    over a single box/chest with no known adjacent doors could
    automatically check that single box/chest for traps. Ditto
    for checking a single adjacent known door for traps.

    The actual functionality of the #untrap command would remain
    unchanged.

    Checking doors for traps would become much easier, to the point
    of actually doing it ingame. (Does anyone routinely check doors
    for traps now? Besides Marvin.) '11S' with only one adjacent
    door would be an infinite improvement.

    I'd go so far as to move containers adjacent to doors to make
    checking the container for traps easier than: #untrap, >, y,
    #untrap, >, y, etc.

    Even using CTRL-A doesn't speed up that last sequence much.

    Thanks again for your efforts in this matter.

    Jove
  7. Archived from groups: rec.games.roguelike.nethack (More info?)

    On Tue, 23 Aug 2005 11:35:20 +0200, "Boudewijn Waijers"
    <kroisos@REMOVETHISWORD.home.nl> wrote:

    >Topi Linkala wrote:
    >> Jove wrote:
    >
    >>> Could the #untrap command be similarly converted to 'S' (Search
    >>> for traps), with the same lack of confirmation if only one
    >>> door/container is available to be searched? Multiple searches for
    >>> traps would be mucheasier with the CTRL-A command then. 'S' for
    >>> savegame could similarly be changed to #save.
    >
    >> Thoughts. Comments.
    >
    >Please don't change existing commands! Add the #search command, if you
    >wish, but stay away from S.
    >
    >This is the same as the Dev Team usually does. For example, when they
    >changed the the male/female options to gender:male/gender:female, the
    >still retained the old syntax. NatHack has almost always remained
    >backward compatible, so old options files remained valid.
    >
    >In the same way, I would have liked your previous patch better if you
    >hadn't changed the existing option ("confirm" -> "confirm_attack"), but
    >just *added* "confirm_attack" as an alternative for "confirm", keeping
    >"confirm" as a valid option.
    >
    >The Dev Team uses this way of introducing changes as well, in the next
    >release the remove the documentation for the old spelling, and in a
    >following release, they remove the old option. Changing it gradually
    >means that less people will notice the change.
    >
    >Boudewijn.

    Good points. Perhaps adding yet another option (:-) allowing
    the interface to be customized? Either -

    - as simple as new_interface on/off where on moves Save
    and eXplore Mode commands to the extended interface.

    - or a more flexible approach, such as allowing the user to
    swap meanings of [YUHJKLBN] and g[yuhjklbn] (something I've
    wanted for some time).

    Give the user the ability to move commands to extended commands
    and redefine the keys for specific commands. (I'd define ^j as
    #jump in a shot.)

    Give ordinary users the ability to customize their own
    interface and they'll surprise you, though not always pleasantly.


    Jove
  8. Archived from groups: rec.games.roguelike.nethack (More info?)

    Boudewijn Waijers wrote:

    > Topi Linkala wrote:
    >
    >>Jove wrote:
    >
    >>> Could the #untrap command be similarly converted to 'S' (Search
    >>>for traps), with the same lack of confirmation if only one
    >>>door/container is available to be searched? Multiple searches for
    >>>traps would be mucheasier with the CTRL-A command then. 'S' for
    >>>savegame could similarly be changed to #save.
    >
    >>Thoughts. Comments.
    >
    > Please don't change existing commands! Add the #search command, if you
    > wish, but stay away from S.

    If you read my next message you'd know that I'd put the search into
    search (s) not in S.

    > This is the same as the Dev Team usually does. For example, when they
    > changed the the male/female options to gender:male/gender:female, the
    > still retained the old syntax. NatHack has almost always remained
    > backward compatible, so old options files remained valid.
    >
    > In the same way, I would have liked your previous patch better if you
    > hadn't changed the existing option ("confirm" -> "confirm_attack"), but
    > just *added* "confirm_attack" as an alternative for "confirm", keeping
    > "confirm" as a valid option.

    Sorry about that. My bad. I erroneously thought that the options have to
    have differences in their names for the parsing to work but I was wrong.
    So attached to this message is a new version of the patch that doesn't
    mess with the confirm option.

    > The Dev Team uses this way of introducing changes as well, in the next
    > release the remove the documentation for the old spelling, and in a
    > following release, they remove the old option. Changing it gradually
    > means that less people will notice the change.

    --- CUT HERE !!! ---
    diff -bruNX ignore.txt ..\official/changes ./changes
    --- ..\official/changes Thu Jan 1 00:00:00 1970
    +++ ./changes Tue Aug 23 13:34:42 2005
    @@ -0,0 +1,32 @@
    +Changes to the section 4 Commands in NetHack Guidebook
    +
    +Change the command X to read as follows:
    +
    +---
    +X Toggle two-weapon combat on or off. Note that you must use
    + suitable weapons for this type of combat, or it will be au-
    + tomatically turned off.
    +---
    +
    +Add the following:
    +
    +---
    +#explore
    + Enter explore (discovery) mode, explained in its own section
    + later.
    +
    +M-x #explore
    +---
    +
    +
    +Changes to the section 9.4. Customization options in NetHack Guidebook
    +
    +
    +Add the following:
    +
    +---
    +confirm_locking
    + Have the game confirm if a door or a lonely container is (un)locked
    + (default on).
    +---
    +
    diff -bruNX ignore.txt ..\official/include/config.h ./include/config.h
    --- ..\official/include/config.h Mon Dec 8 01:39:14 2003
    +++ ./include/config.h Mon Aug 22 17:48:44 2005
    @@ -351,6 +351,17 @@
    /*#define GOLDOBJ */ /* Gold is kept on obj chains - Helge Hafting */
    /*#define AUTOPICKUP_EXCEPTIONS */ /* exceptions to autopickup */

    +#define CONFIRM_LOCKING /* Confirmation messages for (un)locking doors or
    + * containers if only one container in the location
    + * if confirm_locking is set in the options.
    + * Default is on.
    + * Can be set during the game.
    + */
    +
    +#define X_TWOWEAPON /* X command is changed to twoweapon; meta-x and
    + * #explore is for entering the explore-mode.
    + */
    +
    /* End of Section 5 */

    #include "global.h" /* Define everything else according to choices
    above */
    diff -bruNX ignore.txt ..\official/include/flag.h ./include/flag.h
    --- ..\official/include/flag.h Mon Dec 8 01:39:14 2003
    +++ ./include/flag.h Mon Aug 22 17:49:42 2005
    @@ -175,6 +175,9 @@
    uchar bouldersym; /* symbol for boulder display */
    boolean travel1; /* first travel step */
    coord travelcc; /* coordinates for travel_cache */
    +#ifdef CONFIRM_LOCKING
    + boolean confirm_locking; /* ynq question for (un)locking */
    +#endif
    #ifdef WIZARD
    boolean sanity_check; /* run sanity checks */
    boolean mon_polycontrol; /* debug: control monster polymorphs */
    diff -bruNX ignore.txt ..\official/src/cmd.c ./src/cmd.c
    --- ..\official/src/cmd.c Mon Dec 8 01:39:14 2003
    +++ ./src/cmd.c Mon Aug 22 17:39:42 2005
    @@ -1439,7 +1439,12 @@
    {'W', FALSE, dowear},
    {M('w'), FALSE, dowipe},
    {'x', FALSE, doswapweapon},
    +#ifdef X_TWOWEAPON
    + {'X', FALSE, dotwoweapon},
    + {M('x'), TRUE, enter_explore_mode},
    +#else
    {'X', TRUE, enter_explore_mode},
    +#endif
    /* 'y', 'Y' : go nw */
    {'z', FALSE, dozap},
    {'Z', TRUE, docast},
    @@ -1481,6 +1486,9 @@
    {"dip", "dip an object into something", dodip, FALSE},
    {"enhance", "advance or check weapons skills", enhance_weapon_skill,
    TRUE},
    +#ifdef X_TWOWEAPON
    + {"explore", "enter the explore mode", enter_explore_mode, TRUE},
    +#endif
    {"force", "force a lock", doforce, FALSE},
    {"invoke", "invoke an object's powers", doinvoke, TRUE},
    {"jump", "jump to a location", dojump, FALSE},
    diff -bruNX ignore.txt ..\official/src/lock.c ./src/lock.c
    --- ..\official/src/lock.c Mon Dec 8 01:39:14 2003
    +++ ./src/lock.c Mon Aug 22 17:54:30 2005
    @@ -294,13 +294,29 @@

    count = 0;
    c = 'n'; /* in case there are no boxes here */
    +
    +#ifdef CONFIRM_LOCKING
    + for(otmp = level.objects[cc.x][cc.y]; otmp; otmp = otmp->nexthere)
    + if (Is_box(otmp)) ++count;
    + if ((count == 1) && !iflags.confirm_locking) c = 'y';
    +#endif
    +
    for(otmp = level.objects[cc.x][cc.y]; otmp; otmp = otmp->nexthere)
    if (Is_box(otmp)) {
    +
    +#ifndef CONFIRM_LOCKING
    ++count;
    +#endif
    +
    if (!can_reach_floor()) {
    You_cant("reach %s from up here.", the(xname(otmp)));
    return 0;
    }
    +
    +#ifdef CONFIRM_LOCKING
    + if ((count > 1) || iflags.confirm_locking) {
    +#endif
    +
    it = 0;
    if (otmp->obroken) verb = "fix";
    else if (!otmp->olocked) verb = "lock", it = 1;
    @@ -315,6 +331,10 @@
    if(c == 'q') return(0);
    if(c == 'n') continue;

    +#ifdef CONFIRM_LOCKING
    + }
    +#endif
    +
    if (otmp->obroken) {
    You_cant("fix its broken lock with %s.", doname(pick));
    return 0;
    @@ -401,11 +421,19 @@
    }
    #endif

    +#ifdef CONFIRM_LOCKING
    + if (iflags.confirm_locking) {
    +#endif
    +
    Sprintf(qbuf,"%sock it?",
    (door->doormask & D_LOCKED) ? "Unl" : "L" );

    c = yn(qbuf);
    if(c == 'n') return(0);
    +
    +#ifdef CONFIRM_LOCKING
    + }
    +#endif

    switch(picktyp) {
    #ifdef TOURIST
    diff -bruNX ignore.txt ..\official/src/options.c ./src/options.c
    --- ..\official/src/options.c Mon Dec 8 01:39:14 2003
    +++ ./src/options.c Tue Aug 23 13:36:48 2005
    @@ -75,6 +75,9 @@
    {"color", &iflags.wc_color, FALSE, SET_IN_GAME}, /*WC*/
    # endif
    {"confirm",&flags.confirm, TRUE, SET_IN_GAME},
    +#ifdef CONFIRM_LOCKING
    + {"confirm_locking", &iflags.confirm_locking, TRUE, SET_IN_GAME},
    +#endif
    #if defined(TERMLIB) && !defined(MAC_GRAPHICS_ENV)
    {"DECgraphics", &iflags.DECgraphics, FALSE, SET_IN_GAME},
    #else
    --- CUT HERE !!! ---

    Topi
    --
    "The whole problem with the world is that fools and fanatics are
    always so certain of themselves, but wiser people so full of doubts."
    - Bertrand Russell
    "How come he didn't put 'I think' at the end of it?" - Anonymous
  9. Archived from groups: rec.games.roguelike.nethack (More info?)

    Jove <invalid@invalid.invalid> writes:
    > Good points. Perhaps adding yet another option (:-) allowing
    > the interface to be customized?

    I really like the idea of each user being able to remap action X in
    context Y to key Z (with the possible exceptions of contexts like
    #name where actual text entry is taking place). Nethack isn't Quake,
    but the latter's "bind" idiom might be a useful model.

    However, I think it's a good idea to stop short of changes that make
    actions automatic (since new players may not think to perform those
    actions) or which add prompting before potentially dangerous actions
    (since new players may not know the danger). Changing interface is
    safe; changing gameplay requires delicate attention to balance issues,
    across the entire spectrum of player skill.

    It does seem a shame to dedicate keys to things like 'S'ave and
    e'X'plore, while #name, #untrap and #twoweapon go begging. Backward
    compatibility, I scoff at thee. Precedent: 'Q' is now 'Q'uiver, and
    #quit has been banished to the land of extended commands. If it's okay
    to do that for the single most important command for a new user to be
    able to figure out, it's okay to do it other places.
  10. Archived from groups: rec.games.roguelike.nethack (More info?)

    Jove <invalid@invalid.invalid> wrote:
    >
    > Good points. Perhaps adding yet another option (:-) allowing
    > the interface to be customized? Either -
    >
    > - as simple as new_interface on/off where on moves Save
    > and eXplore Mode commands to the extended interface.
    >
    > - or a more flexible approach, such as allowing the user to
    > swap meanings of [YUHJKLBN] and g[yuhjklbn] (something I've
    > wanted for some time).
    >
    > Give the user the ability to move commands to extended commands
    > and redefine the keys for specific commands. (I'd define ^j as
    > #jump in a shot.)
    >
    > Give ordinary users the ability to customize their own
    > interface and they'll surprise you, though not always pleasantly.

    There's 2 patches I know which do these, one by Jason Dorje Short,
    one by Stanislav Traykov.

    Stanislav's "Dynamic Key Bindings" can be found here:
    http://nh.gmuf.com/dynkey-343.diff

    Unfortunately I can't find Jason's patch right now, but I do
    remember it's in patchhack, so somewhere in http://patchhack.sf.net/

    --
    Pasi Kallinen
    paxed@alt.org
    http://bilious.homelinux.org/ -- NetHack Patch Database
  11. Archived from groups: rec.games.roguelike.nethack (More info?)

    On Tue, 23 Aug 2005 18:45:02 GMT, Douglas Henke
    <henke@kharendaen.dyndns.org> wrote:

    >Jove <invalid@invalid.invalid> writes:
    >> Good points. Perhaps adding yet another option (:-) allowing
    >> the interface to be customized?
    >
    >I really like the idea of each user being able to remap action X in
    >context Y to key Z (with the possible exceptions of contexts like
    >#name where actual text entry is taking place). Nethack isn't Quake,
    >but the latter's "bind" idiom might be a useful model.
    >
    I'm not familiar with that capability. Looks like newcomers
    could just take someone else's defaults.nh file with all the
    context sensitive commands to help them.

    But how different is that from using someone else's defaults.nh
    file now for autopickup exceptions, etc? Or reading spoilers?

    >However, I think it's a good idea to stop short of changes that make
    >actions automatic (since new players may not think to perform those
    >actions) or which add prompting before potentially dangerous actions
    >(since new players may not know the danger). Changing interface is
    >safe; changing gameplay requires delicate attention to balance issues,
    >across the entire spectrum of player skill.
    >

    Good point. Although a lot of console games seem to rely on a
    poor user interface to increase player tension. Survival horror
    games seem to particularly offend in this area. Not only can you
    not move and shoot at the same time, you can't even move and aim
    at the same time. A far cry from Doom's move in one direction,
    while shooting in another.

    Another peeve of mine with console user interfaces is that
    they're all left-handed: the direction control is under the left
    hand. After using flight controllers on the PC for years with
    the throttle under the left hand and the joystick in the right
    console game controllers just kill me.

    So yes, a seemingly unnecessarily difficult interface can add
    stress to the game, but is it really a good idea?

    The "never hit with a wielded weapon" conduct is another
    question. If the idea of the conduct is to make the game harder,
    then an "auto-attack" option, similar to the "auto-dig" option
    seems to be the perfect answer. The F(orce attack) command
    seems tailor-made for it.

    If the idea of the "never hit with a wielded weapon" conduct
    is having to beat the game interface instead of dealing with a
    more difficult game...well, that idea seems flawed. After all,
    reading a fortune engraving doesn't break illiterate conduct,
    just to make keeping illiterate conduct easier.


    >It does seem a shame to dedicate keys to things like 'S'ave and
    >e'X'plore, while #name, #untrap and #twoweapon go begging. Backward
    >compatibility, I scoff at thee. Precedent: 'Q' is now 'Q'uiver, and
    >#quit has been banished to the land of extended commands. If it's okay
    >to do that for the single most important command for a new user to be
    >able to figure out, it's okay to do it other places.

    I agree. Especially for my own favorite, the much neglected
    #jump.

    But since my argument above is based on kindness to players,
    I'll have to go along with the idea of making it optional, or
    even just phasing it in.


    --
    All the best,

    Jove
  12. Archived from groups: rec.games.roguelike.nethack (More info?)

    Douglas Henke <henke@kharendaen.dyndns.org> writes:

    > #quit has been banished to the land of extended commands. If it's okay
    > to do that for the single most important command for a new user to be
    > able to figure out, it's okay to do it other places.

    Excuse me, but I don't think #quit deserves to be called important..

    --
    Jukka Lahtinen
  13. Archived from groups: rec.games.roguelike.nethack (More info?)

    Jukka Lahtinen <jslnews@despammed.com> writes:
    > Douglas Henke <henke@kharendaen.dyndns.org> writes:
    > > #quit has been banished to the land of extended commands. If it's okay
    > > to do that for the single most important command for a new user to be
    > > able to figure out, it's okay to do it other places.
    >
    > Excuse me, but I don't think #quit deserves to be called important..

    The "terminate this application" command is the most important command
    in _any_ application, and doubly so for the user who invoked that
    application by mistake, has no idea how it works or what it is, and
    just wants out.

    My strongest memory of my inaugural day as a UNIX n00b (other than being
    given training consisting of "here's how to log in and out, and here's
    how to type `man man'") was spending a good hour figuring out how to get
    out of vi once I'd gotten in, and then another while figuring out that
    ^Z wasn't the best method, and why I couldn't log out because there were
    stopped jobs.

    #quit isn't a frequently-used command, but that isn't the same as it
    being an unimportant command.
  14. Archived from groups: rec.games.roguelike.nethack (More info?)

    On Tue, 23 Aug 2005 18:45:02 GMT
    Douglas Henke <henke@kharendaen.dyndns.org> wrote:

    >I really like the idea of each user being able to remap action X in
    >context Y to key Z (with the possible exceptions of contexts like
    >#name where actual text entry is taking place).

    Wyvern also has that,
    its called alias.
  15. Archived from groups: rec.games.roguelike.nethack (More info?)

    Douglas Henke <henke@kharendaen.dyndns.org> writes:
    > Jukka Lahtinen <jslnews@despammed.com> writes:

    > > Excuse me, but I don't think #quit deserves to be called important..

    > The "terminate this application" command is the most important command
    > in _any_ application, and doubly so for the user who invoked that
    > application by mistake, has no idea how it works or what it is, and

    Yes, but in the case of Nethack, I have heard of it confusing many newbies
    who get a wrong idea about what it does. Save is generally more important,
    or just let the character get killed if you don't want to continue the game.

    True, #quit is probably important when somebody doesn't actually want to
    play but just start random programs to see what they are. I admit I didn't
    think of that case.

    --
    Jukka Lahtinen
  16. Archived from groups: rec.games.roguelike.nethack (More info?)

    Jukka Lahtinen wrote:
    > Douglas Henke <henke@kharendaen.dyndns.org> writes:
    >> Jukka Lahtinen <jslnews@despammed.com> writes:

    > True, #quit is probably important when somebody doesn't actually want
    > to play but just start random programs to see what they are. I admit
    > I didn't think of that case.

    Those people can quit the game even before it really starts. During the
    startup sequence, you're normally getting a [ynq] prompt somewhere.

    --
    Boudewijn.

    --
    "I have hundreds of other quotes, just waiting to replace this one
    as my signature..." - Me
  17. Archived from groups: rec.games.roguelike.nethack (More info?)

    Jove wrote:

    > On Tue, 23 Aug 2005 11:02:54 +0300, Topi Linkala <nes@iki.fi>
    > wrote:
    >
    >
    >>Jove wrote:
    >>
    >>
    >>> Most excellent! Thanks for the effort. I agree that these
    >>>could easily be combined into the next standard release.
    >>>
    >>> Could the #untrap command be similarly converted to 'S' (Search
    >>>for traps), with the same lack of confirmation if only one
    >>>door/container is available to be searched? Multiple searches for
    >>>traps would be mucheasier with the CTRL-A command then. 'S' for
    >>>savegame could similarly be changed to #save.
    >>>
    >>> The extra change would also be nice in that #untrap currently
    >>>does not actually untrap. Instead it searches for a trap.
    >>
    >>The problem here is that there is no such thing as a known trap on large
    >>box, chest, statue or door. This means that currently there is no way to
    >>separate the finding of the trap from the disarming of the trap.
    >
    > I was unclear, sorry. There were interface-only changes
    > suggested:
    >
    > - Use 'S' as a direct replacement for the #untrap command.
    > - Move the save game command from 'S' to #save.
    >
    > This is enough of an improvement to stand on its own, but would
    > also be further enhanced by -
    >
    > - Having the #untrap functionality automatically check,
    > *without* prompting for direction, if there is only one
    > door/container in position to be checked for a trap.
    >
    > As I currently misunderstand the #untrap command, standing
    > over a single box/chest with no known adjacent doors could
    > automatically check that single box/chest for traps. Ditto
    > for checking a single adjacent known door for traps.
    >
    > The actual functionality of the #untrap command would remain
    > unchanged.
    >
    > Checking doors for traps would become much easier, to the point
    > of actually doing it ingame. (Does anyone routinely check doors
    > for traps now? Besides Marvin.) '11S' with only one adjacent
    > door would be an infinite improvement.
    >
    > I'd go so far as to move containers adjacent to doors to make
    > checking the container for traps easier than: #untrap, >, y,
    > #untrap, >, y, etc.
    >
    > Even using CTRL-A doesn't speed up that last sequence much.
    >
    > Thanks again for your efforts in this matter.

    I checked how #untrap works and found this:

    First it asks for direction.

    If you give a lateral direction and there is known trap there then no
    confirmation is asked and an attempt to disarm that trap is made. If
    this failed and you didn't move onto the trap then ^A will redo the attempt.

    If you give a lateral direction and there is a door there no
    confirmation is asked for the search of a trap but if one is found then
    a confirmation is asked to actually try to disarm the trap. If no trap
    was found the attempt can be repeated by ^A. If you find a trap but
    decide not to disarm it then ^A cannot be used to repeat the attempt.

    If you give a down direction while standing on a floor trap and there is
    no boxes on that spot then no confirmation is asked and an attempt to
    disarm that trap is made. If this fails ^A will redo the attempt.

    If you give a down direction while standing on a floor trap and there is
    at least one box on that spot then a confirmation is asked if you want
    to disarm the floor trap. If you want to disarm the floor trap an
    attempt is made. If you don't want to disarm the floor trap then
    everything happens as if there were no floor trap on that spot. This
    action cannot be repeated with ^A.

    If you give a down direction and there is no floor trap on the spot but
    there is one or more boxes there a confirmation is asked to check traps
    from those boxes. If answered positively a check is made if a trap is
    found and if found then a confirmation is asked for disarming. This
    action cannot be repeated with ^A.


    The last case with only one box is where I think that the confirmation
    on check is unnesessary.

    So I made a little patch (look for another post) that removes it if an
    option confirm_untrap is negated. It does not remove the confirmation if
    there is a floor trap on the location or more than one box.

    This action then becomes repeatable. So if you disable the confirmation
    and you untrap down on location that has no floor traps and only a
    single box and the attempt to find a trap fails then ^A can be used to
    repeat the attempt. If you find a trap but decide not to disarm it then
    ^A cannot be used to repeat the attempt.

    Topi

    P.S. Why is it that both door and box traps go off if you try to disarm
    them but fail? The repeated attempts until you either succeed or failed
    is not in the code as the attempt takes only one tick of time.

    Of course I know the answer and it's that there is no such thing as
    known trap on a door or a box. And probably the action takes only one
    tick of time as the devteam didn't like the idea that it takes more time
    but is uninterruptable.

    Same
    --
    "The whole problem with the world is that fools and fanatics are
    always so certain of themselves, but wiser people so full of doubts."
    - Bertrand Russell
    "How come he didn't put 'I think' at the end of it?" - Anonymous
Ask a new question

Read More

Configuration Command Prompt Video Games