mouse support on telnet nethack.org
Ssulian
windows build. I have never seen any documentation for the mouse
functions, but they are very useful. The only drawback I have ever
seen is when messing with doors in gnometown, because the default is
to kick a locked door (which alarms the guards if it breaks the
door). It is very nice for traversing explored levels because one can
warp from one stairway to the other with one click. What I am
wondering is if there is a possibility of using a similar mouse
capability with the telnet nethack.org. Or perhaps something is in
the works?
--
S
Janis Papanagnou
> [mouse support]
> [...] It is very nice for traversing explored levels because one can
> warp from one stairway to the other with one click.
(I usually miss in such descriptions the extra effort to exactly locate
the target with the mouse - which is not a zero-time effort, rather
quite expensive ergonomic-wise -, and the switch from keyboard to mouse
and back for all the other necessary keyboard interactions; mind that
effectively all keys are occupied in Nethack - I have to see a mouse
interface to cover all that in an ergonimic way.) </rant>
Use the travel command if you're using the keyboard; that's just three
keystrokes, e.g. for the downstairs:
_ > .
Similar for other targets like thrones, portals (and other traps), and
especially altars. But mostly used for the up-/downstairs, as you ask for.
The > . part of the command works as well in case you are controlled
teleporting and have to locate the target; many people still use movement
(cursor) keys, but addressing the above standard targets is much faster.
^T > .
Very simple, very effective, very robust (error resistant), and consistent.
Umm.. - no, I don't know how it's possible to tunnel mouse controls through
a telnet interface. (But see the recent thread for tunnelling tiles, which
may have had outlined some way for mouse support, too. Don't recall.)
Janis
Dirk Zimmermann
This is possible if you build a graphic oriented application on top of
a telnet layer, or a curses emulation. It's conceptually not very hard
to do, but the details require a lot of work. Try negotiating a
connection with a telnet server by hand if you want to experience
this :) And emulating curses is not that easy either since Roguelikes
really push the envelope here (or did in the 80s when this was novel).
If you then decide to represent tiles graphically instead of drawing
ASCII letters you lack quite the information a window port has, so
it's easier to just draw the letters. There are some projects that
tried to do that but none that I know of that finished.
Afaik Slash'EM has a window-proxy system that enables just that but
I've never tried it.
--
Dirk
http://blog.dirkz.com
Jorgen Grahn
> Ssulian wrote:
>> [mouse support]
>> [...] It is very nice for traversing explored levels because one can
>> warp from one stairway to the other with one click.
>
> (I usually miss in such descriptions the extra effort to exactly locate
> the target with the mouse - which is not a zero-time effort, rather
> quite expensive ergonomic-wise -, and the switch from keyboard to mouse
> and back for all the other necessary keyboard interactions; mind that
> effectively all keys are occupied in Nethack - I have to see a mouse
> interface to cover all that in an ergonimic way.) </rant>
>
> Use the travel command if you're using the keyboard; that's just three
> keystrokes, e.g. for the downstairs:
>
> _ > .
Yes. Highly recommended.
...
> Umm.. - no, I don't know how it's possible to tunnel mouse controls through
> a telnet interface.
There are terminals with mouse support. I guess the clicking ends up
as escape sequences e.g. "left click at coordinate (23, 2)". That
would require application support and support in the terminal. Recent
versions of xterm has it; for PuTTY I don't know; Windows telnet:
fat chance.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Christophe Cavalaria
> There are terminals with mouse support. I guess the clicking ends up
> as escape sequences e.g. "left click at coordinate (23, 2)". That
> would require application support and support in the terminal. Recent
> versions of xterm has it; for PuTTY I don't know; Windows telnet:
> fat chance.
Putty supports the mouse very well indeed.
Ssulian
wrote:
> (I usually miss in such descriptions the extra effort to exactly locate
> the target with the mouse - which is not a zero-time effort, rather
> quite expensive ergonomic-wise -, and the switch from keyboard to mouse
> and back for all the other necessary keyboard interactions; mind that
> effectively all keys are occupied in Nethack - I have to see a mouse
> interface to cover all that in an ergonimic way.) </rant>
The switch is often made when smoking a cigarette.
Numerous keyboards have been trashed because of
using the keyboard while smoking. It is found that the
keyboard holds up if no keys are pressed while doing
this. The range of the mouse is rather high. One can
perform many vital operations with it. However, at
times it is necessary to pause gameplay until the
cigarette is finished due to the need to make an
operation unavailable to the mouse.
--
S
APLer
news:e91a9df1-d787-4251...@c4g2000yqa.googlegroups.com:
And then there's the problem of cigarette ash collecting on the mouse
rollers. Mice are inferior rodents and should never have evolved beyond
the Lisa IMHO.
Ray
> Ssulian <wichita...@msn.com> wrote:
>> However, at
>> times it is necessary to pause gameplay until the
>> cigarette is finished due to the need to make an
>> operation unavailable to the mouse.
> And then there's the problem of cigarette ash collecting on the mouse
> rollers. Mice are inferior rodents and should never have evolved beyond
> the Lisa IMHO.
"An yer meeces still hae rollers, yer duin' it rrong."
Join the 21st century and get an optical mouse. No rollers to foul up.
Still an inferior interface to a game as command-heavy as a roguelike,
but certainly there's no point in using the kind that can fall prey to
cigarette ash.
Bear
APLer
news:4b58960c$0$1659$742e...@news.sonic.net:
> APLer wrote:
>
>> Ssulian <wichita...@msn.com> wrote:
>
>>> However, at
>>> times it is necessary to pause gameplay until the
>>> cigarette is finished due to the need to make an
>>> operation unavailable to the mouse.
>
>> And then there's the problem of cigarette ash collecting on the mouse
>> rollers. Mice are inferior rodents and should never have evolved
>> beyond the Lisa IMHO.
>
> "An yer meeces still hae rollers, yer duin' it rrong."
>
> Join the 21st century and get an optical mouse. No rollers to foul
> up.
>
The last one I bought had only two buttons and a scroll wheel and died
inside of 6 months. You can't *get* proper three button mice in the
stores around here anymore. I'm still using an old logitech I got over
10 years ago.
> Still an inferior interface to a game as command-heavy as a roguelike,
> but certainly there's no point in using the kind that can fall prey to
> cigarette ash.
>
I would imagine the spots where the light goes in and out could be
obscured by it as well - with the same effect, but easier cleaning
perhaps.
Ssulian
> Ray <b...@sonic.net> wrote innews:4b58960c$0$1659$742e...@news.sonic.net:
> The last one I bought had only two buttons and a scroll wheel and died
> inside of 6 months. You can't *get* proper three button mice in the
> stores around here anymore. I'm still using an old logitech I got over
> 10 years ago.
It takes some practice, but the mouse wheel can become
almost as effective as a third button. I know because I
started playing netrek again a few months ago. It uses
the mouse wheel press button as torpedoes by default,
and this entails quick pressing of the button. I did not
think it would be as good, but fast forward a month or so
and I am sending off 8 torps in quick progression with
no problems.
--
S
Ssulian
> > [mouse support]
> > [...] It is very nice for traversing explored levels because one can
> > warp from one stairway to the other with one click.
>
> (I usually miss in such descriptions the extra effort to exactly locate
> the target with the mouse - which is not a zero-time effort, rather
> quite expensive ergonomic-wise -, and the switch from keyboard to mouse
> and back for all the other necessary keyboard interactions; mind that
> effectively all keys are occupied in Nethack - I have to see a mouse
> interface to cover all that in an ergonimic way.) </rant>
>
> Use the travel command if you're using the keyboard; that's just three
> keystrokes, e.g. for the downstairs:
>
> _ > .
>
> Similar for other targets like thrones, portals (and other traps), and
> especially altars. But mostly used for the up-/downstairs, as you ask for.
>
> The > . part of the command works as well in case you are controlled
> teleporting and have to locate the target; many people still use movement
> (cursor) keys, but addressing the above standard targets is much faster.
>
> ^T > .
>
> Very simple, very effective, very robust (error resistant), and consistent.
> [...]
Thank you. This is useful. Since I have never seen any
documentation on mouse features in Nethack-W, I am
kind of assuming that it makes use of normal in-game
primitives, such as this, so I should have guessed that
there was some kind of replacement in the keyboard-
based game interface.
--
S
Thomas Dickey
> There are terminals with mouse support. I guess the clicking ends up
> as escape sequences e.g. "left click at coordinate (23, 2)". That
> would require application support and support in the terminal. Recent
> versions of xterm has it; for PuTTY I don't know; Windows telnet:
> fat chance.
xterm's had that for about twenty years.
not recent...
APLer
news:7336c7e0-9c38-4243...@y23g2000yqm.googlegroups.com:
> On Jan 21, 4:34�pm, APLer <AP...@floor.tilde> wrote:
>> Ray <b...@sonic.net> wrote
>> innews:4b58960c$0$1659$742e...@news.sonic.net
>:
>
>> The last one I bought had only two buttons and a scroll wheel and
>> died inside of 6 months. You can't *get* proper three button mice in
>> the stores around here anymore. I'm still using an old logitech I got
>> over 10 years ago.
>
> It takes some practice, but the mouse wheel can become
> almost as effective as a third button.
That wasn't my point. I don't want or need a scroll button. There's
these little things on the side of windows that you can use one on
called scrollbars. There's also two keys on the keyboard. I want a mouse
with three buttons for X. X *uses* the middle or third button extensively.
A scroll wheel is a sad replacement influenced by people who never learned
how to use MS windows properly.
Ssulian
You better stop doing X or or you might go blind.
About scrollbars, in many programs they are not programmed
effectively, and one can lose grip on them by just moving from
side to side even while holding the button down. Also, a scroll
wheel is easier than targeting and clicking on something that
is only about twenty pixels wide in most cases. The keyboard
option (up and down) works okay, but isn't this whole thread
about the niceties of relying on the mouse rather than the
keyboard?
--
S
APLer
news:c65bb4d1-9a85-498e...@d1g2000yqo.googlegroups.com:
> On Jan 21, 6:34�pm, APLer <AP...@floor.tilde> wrote:
>> Ssulian <wichitajayha...@msn.com> wrote
>> innews:7336c7e0-9c38-4243-adbd-82
> 82c7d...@y23g2000yqm.googlegroups.com:
>>
>>> That wasn't �my point. I don't want or need a scroll button. There's
>> these little things on the side of windows that you can use one on
>> called scrollbars. There's also two keys on the keyboard. I want a
>> mouse with three buttons for X. X *uses* the middle or third button
>> extensively
> .
>> A scroll wheel is a sad replacement influenced by people who never
>> learne
> d
>> how to use MS windows properly.
>
> You better stop doing X or or you might go blind.
>
Hardly. MS windows is far inferior in it's interface. Most people never
see the difference as they then run X with something like gnome where
they never find out about scrolling multiple desktops for example. To
say nothing of window operations like shade and moving windows across
desktops without actually traversing the desktops themselves.
I've been exposed to MS OS's since dos 5 was current and about the time
95 came out I was already using X.
> About scrollbars, in many programs they are not programmed
> effectively, and one can lose grip on them by just moving from
> side to side even while holding the button down. Also, a scroll
> wheel is easier than targeting and clicking on something that
> is only about twenty pixels wide in most cases. The keyboard
> option (up and down) works okay, but isn't this whole thread
> about the niceties of relying on the mouse rather than the
> keyboard?
>
Niceties? hardly a relevant word to use. On the last point - or at least
what I assume you mean as we're not talking about serial protocol here,
that's *never* true. I play nethack in ansii graphics without ever using
a mouse. A mouse has very limited uses where it actually helps makes
things more efficient. Moving between fields or widgets in a window is
one.
Nope. Fail. You don't understand the alternatives. I'll give you a hint:
it's a key near the insert key in a cluster of 6 keys. And there's the
reverse. Or better yet, use lynx and then you have control on a line by
line basis and never have to use a mouse at all.
Anyways, this has drifted way off-topic. The fact is that GNU offers
several different ways to turn mouse operations into keyboards sent down
a telnet connection. I can't recall the exact methods at the moment, but
they do not require one to compile any C.
Jorgen Grahn
I never said that it recently acquired the feature, just that recent
versions have it. Though I never encountered an application that used
it until fairly recently (text-based web browsers) and only because
text selection with the mouse stopped working.
Jorgen Grahn
It depends a lot on the mouse. My old Logitech has a wheel that
doesn't scroll easily but can be pressed fairly easily. Some cheap
newer mice are the other way around -- the manufacturers don't know or
don't care that the middle button is so important to some users.
I guess you can superglue the wheel if you really need the buttom.
Patric Mueller
> On Thu, 2010-01-21, Janis Papanagnou wrote:
>> Ssulian wrote:
>>> [mouse support]
>>> [...] It is very nice for traversing explored levels because one can
>>> warp from one stairway to the other with one click.
>>
>> (I usually miss in such descriptions the extra effort to exactly locate
>> the target with the mouse - which is not a zero-time effort, rather
>> quite expensive ergonomic-wise -, and the switch from keyboard to mouse
>> and back for all the other necessary keyboard interactions; mind that
>> effectively all keys are occupied in Nethack - I have to see a mouse
>> interface to cover all that in an ergonimic way.) </rant>
>>
>> Use the travel command if you're using the keyboard; that's just three
>> keystrokes, e.g. for the downstairs:
>>
>> _ > .
>
> Yes. Highly recommended.
Unfortunately, NetHack's travel command is rather limited.
If there's an object on the dungeon feature you want to travel to, it
doesn't work and have you ever tried to select a grave? If not you'll
be surprised by the result.
It's still better than nothing, though.
> ...
>> Umm.. - no, I don't know how it's possible to tunnel mouse controls through
>> a telnet interface.
>
> There are terminals with mouse support. I guess the clicking ends up
> as escape sequences e.g. "left click at coordinate (23, 2)". That
> would require application support and support in the terminal. Recent
> versions of xterm has it; for PuTTY I don't know; Windows telnet:
> fat chance.
Yes, you are right. The program has to set a specific escape sequence
to let the terminal know that it wants to receive mouse events and
then compliant terminal sends those events encoded as other escape
sequences to the program:
http://www.xfree86.org/current/ctlseqs.html#Mouse%20Tracking
Bye
Patric
--
NetHack-De: NetHack auf Deutsch - http://nethack-de.sf.net/
NetHack for AROS: http://sf.net/projects/nethack-aros/
UnNetHack: http://apps.sf.net/trac/unnethack/
Janis Papanagnou
>
> Unfortunately, NetHack's travel command is rather limited.
>
> If there's an object on the dungeon feature you want to travel to, it
> doesn't work and have you ever tried to select a grave? If not you'll
> be surprised by the result.
Or a sink.
> It's still better than nothing, though.
It's a 99% solution. Much better than nothing. Why do I think that so?
IME, you rarely have graves or sinks as tarkets, yes occasionally, but
rarely compared to stairs and altars.
Dungeon features covered by objects is an issue. Personally, WRT stairs,
it doesn't annoy me, because I keep stairs uncovered anyway to not forget
where they were if I travel forth and back through the dungeon. Different
story with altars; on altars there is often the remains of loot from the
sacrificed victims.
Would be nice if that gets fixed. (In that mythical next release ;-)
Janis
Patric Mueller
>
> "An yer meeces still hae rollers, yer duin' it rrong."
>
> Join the 21st century and get an optical mouse. No rollers to foul up.
>
> Still an inferior interface to a game as command-heavy as a roguelike,
> but certainly there's no point in using the kind that can fall prey to
> cigarette ash.
But an optical mouse falls prey to another enemy of mice, one that is
feared by mice since eternity: Cats!
If one single piece of cat hair gets into the opening under your mouse
the cursor just jerks around because it tries evading the deadly house
cat!
Patric Mueller
> Patric Mueller wrote:
>>
>> It's still better than nothing, though.
>
> It's a 99% solution. Much better than nothing. Why do I think that so?
> IME, you rarely have graves or sinks as tarkets, yes occasionally, but
> rarely compared to stairs and altars.
I'd say it's a 90% solution. But if you need the other 10% it's
extremely annoying.
The travel command has only been added in 3.4.0 but still, it would
have been better to simply not allow to select # and |.
> Dungeon features covered by objects is an issue. Personally, WRT stairs,
> it doesn't annoy me, because I keep stairs uncovered anyway to not forget
> where they were if I travel forth and back through the dungeon. Different
> story with altars; on altars there is often the remains of loot from the
> sacrificed victims.
>
> Would be nice if that gets fixed. (In that mythical next release ;-)
For UnNetHack I've already fixed the problem with graves and sinks.
The problem with dungeon features hidden under objects proved
trickier, especially as I wasn't familiar with the display code at
all.
But with this patch travel works a bit better IMO:
http://bhaak.dyndns.org/nethack/nh343-improved-travel-v1.0.diff
Janis Papanagnou
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> Patric Mueller wrote:
>>> It's still better than nothing, though.
>> It's a 99% solution. Much better than nothing. Why do I think that so?
>> IME, you rarely have graves or sinks as tarkets, yes occasionally, but
>> rarely compared to stairs and altars.
>
> I'd say it's a 90% solution.
Are you saying that your stairs are regularily covered, or that you will
regularily travel to altars and graves? Otherwise I would not understand
the 90%. But it's subjective, anyway.
> But if you need the other 10% it's extremely annoying.
Curious; what are the 10% in your games? Covered stairs/altars, or regular
second visits to sinks and graves? - I've never felt a necessity do the
latter.
> The travel command has only been added in 3.4.0 but still, it would
> have been better to simply not allow to select # and |.
I would have just excluded the auto-selection of corridors and walls, and
thus have allowed to directly select # and |. (Which seems to be what you
have done in your patch, as far I read you comment below correctly.)
[...]
> For UnNetHack I've already fixed the problem with graves and sinks.
> [...]
OTOH, that's a minor issue for me, as I said. Targeting covered altars (or
even the rarely covered stairs) would be more interesting to fix, though.
But as I'm not that bothered by the behaviour I'll abstain...
Janis
Pat Rankin
> Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Thu, 2010-01-21, Janis Papanagnou wrote:
>>> Use the travel command if you're using the keyboard; that's just three
>>> keystrokes, e.g. for the downstairs:
>>> _ > .
>>
>> Yes. Highly recommended.
>
> Unfortunately, NetHack's travel command is rather limited.
>
> If there's an object on the dungeon feature you want to travel to, it
> doesn't work and have you ever tried to select a grave? If not you'll
> be surprised by the result.
This is somewhat misleading. That shortcut to position
the cursor at the target destination won't work; you'll have
to use movement keys to get it there. The travel command
itself has no problem with moving to some spot which has an
object on it (or at least no more problem than it has moving
to a spot without any objects on it...).
Choosing target destination via visible dungeon feature
has been around a lot longer than the travel command. It's
based on what you can see rather on what you know--or think
you know--is actually there. You can often use some other
visible feature (or features, like typing ^ multiple times to
cycle through visible traps) to get the cursor closer before
resorting to specific movement to arrive at the final spot.
Janis Papanagnou
> [...]
> Choosing target destination via visible dungeon feature
> has been around a lot longer than the travel command. It's
> based on what you can see rather on what you know--or think
> you know--is actually there. You can often use some other
> visible feature (or features, like typing ^ multiple times to
> cycle through visible traps) to get the cursor closer before
> resorting to specific movement to arrive at the final spot.
I remember one additional effect WRT "visible dungeon feature" addressing
that bothered me; I travelled across a specific level many times, but
accidentally a mimic was generated, and the mimic appeared as stairs, or
rather; it was generated to appear as stairs in case one cannot perceive
its original form. Needless to say the cursor was located at the mimic.
I could of course cycle through to the real stairs, but in the heat of
typing I didn't notice that the mimic had been selected and travelled in
the wrong direction. The really unexpected behaviour was that I saw the
mimic by ESP as _mimic_, not as stairs, but the cursor selected it anyway.
I suppose this qualifies as bug.
Janis
Ssulian
wrote:
I do not know mimic. I do not know ESP. We were talking about the
travel command, what are you talking about?
--
S
Janis Papanagnou
Pat briefly explained how the travel command works and how it relies on the
"cursor" code which is driven by visibility factors. The implementation has
a flaw that I explained above, which is reproducable; to do that you need,
for example, ESP and a mimic that is capable of mimicing stairs.
It's already past 6 a.m. hereabouts and I've got tired. Good night.
Janis
Patric Mueller
> Patric Mueller wrote:
>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>> Patric Mueller wrote:
>
>> But if you need the other 10% it's extremely annoying.
>
> Curious; what are the 10% in your games? Covered stairs/altars, or regular
> second visits to sinks and graves? - I've never felt a necessity do the
> latter.
Graves, no. But sinks usually get a second or third visit for ring ID.
It's the annoyance factor that something that should just work,
doesn't work and I'll usually fall once per game victim to this
surprising and inconsistent UI behaviour.
(In fact the problem goes deeper than that. The same code is used for
picking an object/monster with ; or /. There is no reason why there
are no accelerator keys for objects [with monsters there would be a
clash with vikeys]).
>> The travel command has only been added in 3.4.0 but still, it would
>> have been better to simply not allow to select # and |.
>
> I would have just excluded the auto-selection of corridors and walls, and
> thus have allowed to directly select # and |. (Which seems to be what you
> have done in your patch, as far I read you comment below correctly.)
Yes, and selecting covered dungeon features at the expense of not
being able to select traps and magic portals anymore and a mimic
mimicking a selectable dungeon feature doesn't get selected.
Janis Papanagnou
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>> Patric Mueller wrote:
>>> The travel command has only been added in 3.4.0 but still, it would
>>> have been better to simply not allow to select # and |.
>> I would have just excluded the auto-selection of corridors and walls, and
>> thus have allowed to directly select # and |. (Which seems to be what you
>> have done in your patch, as far I read you comment below correctly.)
>
> Yes, and selecting covered dungeon features at the expense of not
Why was that restriction necessary?
Janis
Patric Mueller
> On Jan 23, 3:04�am, Patric Mueller <bh...@bigfoot.com> wrote:
>> Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>>> On Thu, 2010-01-21, Janis Papanagnou wrote:
>>>> Use the travel command if you're using the keyboard; that's just three
>>>> keystrokes, e.g. for the downstairs:
>>>> � �_ �> �.
>>>
>>> Yes. Highly recommended.
>>
>> Unfortunately, NetHack's travel command is rather limited.
>>
>> If there's an object on the dungeon feature you want to travel to, it
>> doesn't work �and have you ever tried to select a grave? If not you'll
>> be surprised by the result.
>
> This is somewhat misleading. That shortcut to position
> the cursor at the target destination won't work; you'll have
> to use movement keys to get it there. The travel command
> itself has no problem with moving to some spot which has an
> object on it (or at least no more problem than it has moving
> to a spot without any objects on it...).
Re-reading what I wrote I see how it could be misunderstood. Although
in context it should have been obvious that I meant the shortcut keys
one can press instead of the movement keys when using the travel
command.
Pressing a '|' won't put the cursor on the next grave as one most
probably would suspect but most times just selects the next vertical
wall.
> Choosing target destination via visible dungeon feature
> has been around a lot longer than the travel command. It's
> based on what you can see rather on what you know--or think
> you know--is actually there. You can often use some other
> visible feature (or features, like typing ^ multiple times to
> cycle through visible traps) to get the cursor closer before
> resorting to specific movement to arrive at the final spot.
But that defeats the purpose of the travel command as a UI
convenience. If I first have to check some arbitrary conditions before
using it, it's value is severely decreased.
The program knows that the stairs are there, it knows that the player
has already seen the stairs, but it doesn't select the stairs via '>'
because there's an object on top of it. That's just usability fail.
Patric Mueller
They are technically not implemented as a type of dungeon floor.
Which also means that they aren't mentioned in include/rm.h in the
list of IS_DUNGEON_FEATURE() macros and so I simply forgot to consider
them.
Patric Mueller
I've updated the patch:
http://bhaak.dyndns.org/nethack/nh343-improved-travel-v1.1.diff
Traps and magic portal are selectable again, as are mimics posing as
dungeon features.
Unfortunately it's not solved in an elegant way, but it works.
Richard Bos
> But that defeats the purpose of the travel command as a UI
> convenience. If I first have to check some arbitrary conditions before
> using it, it's value is severely decreased.
It's NetHack. You have to check that your move is the right one before
_all_ moves, and you have all the time in the world to do it in. If a
limit of the travel command makes it more likely that you'll look before
you leap, in NetHack that is a feature, not a bug.
Richard
Kent Paul Dolan
>> [...]
I think I'd like to disagree.
When a mimic is mimicking a stairway, from the point
of view of the dungeon level, that mimic, _to_ that
level, _is_, for the moment, a stairway.
[This means "logically". Granted in advance that it
is _very_ unlikely to work like that in the dungeon
level features code.]
It would be pointless, and an exploit, for a mimic
imitating a stairway to be easily detected by the
travel command refusing to travel to it, especially
so when the player has not yet located the
corresponding stairway.
Whatever information your "protection from
shapechangers" provides about a mimic mimicking a
stairway, letting you ignore just _what_ that mimic
is mimicking, say a stairway, as opposed, say, to
the usual boulder, is giving you undeserved
protection from making a careless mistake you should
be able to make. It should be the case that you
need confirm _what_ a mimic is mimicking before
risking a travel command.
FWIW
xanthian.
Kent Paul Dolan
> I've updated the patch:
> http://bhaak.dyndns.org/nethack/nh343-improved-travel-v1.1.diff
> Traps and magic portal are selectable again,
Okay.
> as are mimics posing as dungeon features.
Did you mean that as written, or its opposite?
> Unfortunately it's not solved in an elegant way,
> but it works.
It's pretty hard to work the changes needed into the
existing structure cleanly. A flag "can look like
dungeon structure" for monsters would be a bit of
overkill considering that there is only one
instance.
xanthian.
Janis Papanagnou
A dungeon level has a POV? - The player has a POV;
"I see a mimic" or "I see something that looks like
stairs" [mimic or stairs]. And I'd like the *user
interface* to not address an 'm' if the item does
not look to _me_ like stairs.
> [...]
>
> It would be pointless, and an exploit, for a mimic
> imitating a stairway to be easily detected by the
> travel command refusing to travel to it, especially
> so when the player has not yet located the
> corresponding stairway.
Sure. But that was not what I was suggesting to fix.
And if the stairs would not yet have been detected on
that level, then nothing should be selected if there's
only a clearly visible 'm' there.
(BTW, if the stairs on the level have been located but
are covered by an object you're not able to locate the
stairs with the cursor.)
> Whatever information your "protection from
> shapechangers" provides about a mimic mimicking a
It provides its plain form, a clearly identified 'm'.
> stairway, letting you ignore just _what_ that mimic
> is mimicking, say a stairway, as opposed, say, to
> the usual boulder, is giving you undeserved
"undeserved" - why? I have the ring, I see the 'm', I
want to travel to '<'; why should the _user interface_
select the 'm'? That makes not much sense, really.
> protection from making a careless mistake you should
> be able to make. It should be the case that you
> need confirm _what_ a mimic is mimicking before
> risking a travel command.
Not sure whether I misunderstand what you're saying, or
whether you did not understand what I meant.
I had been seeing an 'm', neither a '<', '`', or, ']'.
The travel command is a user interface issue. If I see
an 'm' and not a '<' displayed, then Nethack should not
select the 'm' if I instruct the cursor to move to '<'.
The fact that the UI cursor positioning was located on the
'm' made me just *suspect* that the mimic would have been
mimicing a stair at the moment, just because I know mimics
can do that. But actually I just saw the mimic.
>
> FWIW
>
> xanthian.
Janis
Patric Mueller
> Patric Mueller wrote:
>
>> as are mimics posing as dungeon features.
>
> Did you mean that as written, or its opposite?
Mimics that are mimicking as dungeon features like sinks, stairs,
altars, etc. are selected with this patch if you press the
corresponding key ('#', '>', '<', etc) as they are in vanilla.
In version 1.0 of this patch, this didn't work.
>> Unfortunately it's not solved in an elegant way,
>> but it works.
>
> It's pretty hard to work the changes needed into the
> existing structure cleanly. A flag "can look like
> dungeon structure" for monsters would be a bit of
> overkill considering that there is only one
> instance.
Well, it's especially hard to change code if you think you understand
what it does, when in reality it works different. :)
The whole display system is rather complex, but I think I have now a
good enough understand of it.
Patric Mueller
>
> I had been seeing an 'm', neither a '<', '`', or, ']'.
>
> The travel command is a user interface issue. If I see
> an 'm' and not a '<' displayed, then Nethack should not
> select the 'm' if I instruct the cursor to move to '<'.
>
> The fact that the UI cursor positioning was located on the
> 'm' made me just *suspect* that the mimic would have been
> mimicing a stair at the moment, just because I know mimics
> can do that. But actually I just saw the mimic.
Yes, the mimic must have been mimicking stairs.
This also happens if you're wearing a blindfold and see the mimic by
telepathy. It gets still selected.
I was really puzzled by that.
It turned out that levl[tx][ty].glyph isn't really what the comment in
include/rm.h says: int glyph; /* what the hero thinks is there */
Instead in src/display.c it is stated:
glyph - What the hero remembers. This will never be a monster.
Monsters "float" above this.
That made it clear. By using levl[tx][ty].glyph the code sees the
mimicked stairs, even though the player sees the monster.
By using glyph_at(tx, ty) which accounts also for the monsters, this
would be fixed (At least, I think it does, the display code is
complex :-).
My patch also had this bug. I've updated it:
http://bhaak.dyndns.org/nethack/nh343-improved-travel-v1.2.diff