If you often play Nethack online, e.g. on alt.org, I'd be very
interested in your feedback. The server is currently "experimental"
i.e. things might not be fully working yet.
Thanks, and Merry Christmas,
Jack
--
Jack Whitham
ja...@cs.york.ac.uk
best. xmas present. ever.
Works. One thing, try setting autopickup to just gold. Most people do that.
--
Rob Cypher
Livejournal: http://robcypher.livejournal.com
Myspace: http://www.myspace.com/robcyphercollective
Facebook: http://www.facebook.com/robcypher
YouTube: http://www.youtube.com/robcypher
Twitter: http://www.twitter.com/robcypher
Music Reviews: http://apps.facebook.com/visualcdrack/people/1713595594
Book Reviews: http://apps.facebook.com/facebookshelf/people/1713595594
Movie Reviews: http://apps.facebook.com/dvdshelf/people/1713595594
TV Reviews: http://apps.facebook.com/livingsocial-tv/people/1713595594
Video Game Reviews: http://apps.facebook.com/videogamerack/people/1713595594
RATINGS GUIDE: ***** - essential **** - must have *** - worth a look
** - for fans only * and under - Crap
WARNING - THE SHROOMERY IS FULL OF RACISTS. Proof is presented here: http://robcypher.livejournal.com/68904.html
Thanks for trying it out. I changed the default settings as suggested.
--
Jack Whitham
ja...@cs.york.ac.uk
Cool.
Now make it work with the Vulture's Eye front end. That would be real
cool,because sound is included, and it is a much better tileset.
Or Noe Gnud, where the player chooses the tileset.
Pretty slick idea for implementation, especially as it preserves the
ability to watch others' games. I've never been anti-tiles for nao
(although paxed and I are in agreement that the game itself stay
fairly vanilla, at least in terms of not introducing game behavior
changing things). We just haven't had a good option for something like
tiles yet.
For use on a server like nao, we'd have to consider filtering out
tilehack games to telnetted in users (although the reverse shouldn't
be necessary).
Again, pretty cool implementation.
-drew
I've tried it out (Firefox 3.0.1 on OS X 10.5.6 Intel Macbook).
Unfortunately, the player icon (wizard with colored border around it
from health point patch) is consistently two tiles to the left of the
actual position, where another wizard icon without a border appears.
Also, I need to set numberpad to =off in order to be able to use the
controls.
My pet peeve is messages appear one at a line, forcing you to
alternatively hit escape and the key you really wanted to press, and
always bear possible default actions in mind. Tiles on OS X natively
solves this problem nicely by displaying messages in a separate
window.
Thank you for making tiles available online.
Thanks for trying it. I think I should test it with your version of Firefox.
While I was testing it, I did find some bugs like the one you described,
but I thought I'd eliminated them.
> Also, I need to set numberpad to =off in order to be able to use the
> controls.
That's probably true on any laptop. It's hard to know whether it is best
to have numberpad=on by default or not. Not sure how best to fix this...
> My pet peeve is messages appear one at a line, forcing you to
> alternatively hit escape and the key you really wanted to press, and
> always bear possible default actions in mind. Tiles on OS X natively
> solves this problem nicely by displaying messages in a separate
> window.
It's a good idea to have a message history. I will think about this and
see if I can come up with a way to do it without losing compatibility
with the ASCII version of the game.
Thanks again,
It might be a good idea to check the existing work that's already done by
few separate window ports:
http://www.nongnu.org/nhproxy/
http://www.nongnu.org/nethack-el/
Basically both nethack proxy and nethack-el make nethack output specially formatted
text (elisp in the case of nethack-el) instead of escape codes, and let the client
decipher it. Both of them implement the window port docs as per the doc/window.doc
in the NetHack source tarball.
The negative side to this is that TTYRECs are not watchable except with the special
client.
There's also the TelnetTiles patch: http://bilious.homelinux.org/?123 that embeds
the tile glyph numbers into the data stream; it uses an unused(?) escape code
(ESC '[' glyph_number 'z') for that, making both the special client and traditional
text-based displays work.
Personally, I'd go for the TelnetTiles route, and extend the console codes
to include all the necessary information for windowing, while still keeping
it compatible with text terminals.
I've been toying with this a bit, but as I don't play with tiles, making a special
client feels like too much effort.
--
Pasi Kallinen
pa...@alt.org
http://bilious.homelinux.org/ -- NetHack Patch Database
>Jack Whitham <ja...@perugia.cs.york.ac.uk> wrote:
>> TJR <tilmi...@googlemail.com> wrote:
>>
>>> My pet peeve is messages appear one at a line, forcing you to
>>> alternatively hit escape and the key you really wanted to press, and
>>> always bear possible default actions in mind. Tiles on OS X natively
>>> solves this problem nicely by displaying messages in a separate
>>> window.
>>
>> It's a good idea to have a message history. I will think about this and
>> see if I can come up with a way to do it without losing compatibility
>> with the ASCII version of the game.
>>
>
>It might be a good idea to check the existing work that's already done by
>few separate window ports:
>
>http://www.nongnu.org/nhproxy/
>http://www.nongnu.org/nethack-el/
>
Is there one that allows the use of the Vulture's Eye front end/tiles
set-up?
I mean if one really wants to get down to it, that little 'engine' is
the best step-by-step event manager for nethack I have yet seen, as that
is what it really boils down to. Everything that happens is a console
update event. Vulture's Eye simply uses each event to make a sound play
or render a graphic at a specific location.
Is that not all this amounts to?
Is there an online java "DOS Box" that we could simply run whatever
NetHack flavor we want to in? A remote client, as it were...
I mean it is not like there is some process always going on or some
graphic texture that has to be constantly calculated and updated.
This should be simple.
Characters... tiles...
I find it funny that some folks declare a difference.
It is like the dopes that insist that tube amps are better than modern
amps.
Thanks. I wasn't aware of these. I did look for previous attempts to
implement "Tilehack" before I started hacking on this (mostly in order
to learn "AJAX", tbh). But I didn't find TelnetTiles or the more
recent Remote Tiles project: http://code.google.com/p/nethack-remote-tiles/
TelnetTiles/Remote Tiles appear to work in quite a similar way to my
Tilehack, as I also encode tile numbers with escape sequences. TelnetTiles
has the additional feature that the client will attempt to guess which
tile to use based on ASCII input if that's all that's available.
On the other hand, Tilehack runs entirely in a web browser with
Javascript, and doesn't ever need to guess what the tiles should look
like. Remote Tiles appears to be Java (an applet perhaps).
I think compatibility with regular clients is very important, both for
ttyrec and for live viewing. I didn't try to add an entirely new
window system for this reason. Better, I think, to extend "win/tty"
in a minor way than entirely replace it.
I hope I will be able to prototype the following on my server in the
next week or so:
- Messages appear in a separate window like in "nethack-el" - if you're
using the special client. If you're not, they appear as usual: --More--
- Tiled games can be viewed via regular Telnet... and played back with
regular ttyplay.
The key to both of these is I think to output the regular
ASCII/DECgraphics codes, but to include hints to specify exactly which
tiles should be used and which text should be considered as a "message".
These hints can then be stripped out by "stripgfx.c" in dgamelaunch
if the terminal doesn't support them, and by "ttyrec" too. Result: tile
support with complete backward compatibility.
Thanks for your suggestions,
vtiles_put_glyph() is rather weird. is it _really_ outputting an
escape code?
>
> I think compatibility with regular clients is very important, both for
> ttyrec and for live viewing. I didn't try to add an entirely new
*snip*
> - Tiled games can be viewed via regular Telnet... and played back with
> regular ttyplay.
>
> The key to both of these is I think to output the regular
> ASCII/DECgraphics codes, but to include hints to specify exactly which
> tiles should be used and which text should be considered as a "message".
> These hints can then be stripped out by "stripgfx.c" in dgamelaunch
> if the terminal doesn't support them, and by "ttyrec" too. Result: tile
> support with complete backward compatibility.
>
If you require hints that have to be stripped out by
dgamelaunch/ttyplay, then it's not compatible with regular terminals.
Escape codes that a text terminal does not understand are (or
at least _should be_) ignored by the terminal. If you're using
any other kind of hinting, then it won't be compatible.
> These hints can then be stripped out by "stripgfx.c" in dgamelaunch
> if the terminal doesn't support them, and by "ttyrec" too. Result: tile
Actually, adding game-specific stuff into dgamelaunch is something I'm
trying to avoid, as it should be able to run other game servers too.
If I can think of a good way to make stripgfx.c configurable, so it's
not NetHack-specific, I'll rather do that.
In the current version, not exactly. But of course it can easily do
so. The current codes have the advantage of being quite short, with only
three bytes required for each tile. The tile number is base-64 encoded.
> Escape codes that a text terminal does not understand are (or
> at least _should be_) ignored by the terminal. If you're using
> any other kind of hinting, then it won't be compatible.
I have been experimenting with codes that draw normal ASCII output if
the terminal doesn't support tiles. I find that "xterm", "kvt" and
even the Windows shell are sensible and ignore codes that aren't
recognised - "gnome-terminal", however, prints them out :(. The form
I am using is
printf("\e[%dz%c", tile_number, ascii_character);
This is a minimum of 5 bytes per tile, typically 7. The tile terminal
ignores the character following the code, while a regular terminal
ignores the tile number and only prints the character.
In this arrangement, there is more overhead. More bandwidth is needed,
but regular terminals can ignore the tile hints and display the ASCII
output. As you say, no changes are needed to dgamelaunch or ttyrec
in order to do this. I could upload a new "vtiles" patch if this
would be useful to you.
I have also looked at implementing a message window, like nethack-el, as
suggested elsewhere in this thread. But I find that it's impossible to
do this without losing compatibility with normal clients, simply because
normal clients need to have a --More-- prompt as only one line is
available for messages. A message window client must not have --More--
because that would force the player to press a key to advance to the
next message, negating the main benefit of having a message window in the
first place.
So, it comes down to a choice of "GUI features" or "compatibility with
regular terminals". In general you cannot have both: users of regular
terminals cannot spectate games played by users of "tile terminals".
As a special case, graphical tiles *do* work both ways, provided that
the regular terminal isn't brain-damaged.
--
Jack Whitham
ja...@cs.york.ac.uk