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

[Guest]

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

 

[Guest]

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.

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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.

 

[Guest]

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.

 

[Guest]

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

 

[Guest]

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

 

[Guest]

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