NitroHack 4.0.0 release

[Daniel Thaler]

Hi everyone!

This is the initial public release of NitroHack, a fork of NetHack.

The website for NitroHack is http://nitrohack.org, where you can also
find screenshots and downloads.

Change log:

Back end features:
- NitroHack network protocol
NitroHack supports network play without telnet or ssh over its own
protocol. The protocol is based on JSON and should make it very
easy to implement a browser-based NitroHack client (TODO!).

- New save game format
The old format was mostly just a dump of the data structures
from memory onto disk.
The new format has 2 sections:
1) A log of the initial random seed and every game action
performed afterward. This allows a perfect reconstruction of
the game.
2) A binary save appended after the log. It uses a fixed-width,
fixed-endian architecture and compiler independent format, but
is otherwise a direct descendant of the old save format. This
format was kept mostly so that bones files could be created in
it, but it is also used in the savegames for slightly improved
loading speed.
The log file is written continuously, so the "INSURANCE" option
and the recover utility are gone - a crashed game can always be
restored by replaying the log. After the game ends, the log
marked as closed and kept.

- Built in game replay viewing (aka new and improved ttyrec)
The reason for keeping logs of finished games. Once there was a
way to reconstruct the state of the game at any point it would
have been silly not to use it for game viewing.
Since the replay mode is based on abstract game commands rather
than directly recorded screen output, it is completely feasible
to replay a that was played on a unix tty in a windows tile port
or vice versa.
A viewer for games is built into the new nethack UI. You can
perform commands that don't affect the game state (like view
inventory) while viewing a game replay.

- New options code
Options changed ingame are written back to the options file,
which you are not supposed to edit by hand any more. The options
have moved to ~/.config/NitroHack/NitroHack.conf (for game
options) and ~/.config/NitroHack/curses.conf for the options of
the curses UI.
Logs of active and completed games are also under
~/.config/NitroHack/

- Birth options
Want to play without Elbereth? It is now possible to do so without
recompiling. ELBERETH, REINCARNATION, SEDUCE and bones files have
become a new kind of option: birth options, which can only be set
before the character is created.

- Full separation of user interface code from game code.
The core game code has moved into a library (libnitrohack.so or
nitrohack.dll). The game library exposes an API of exactly 23
functions and is largely OS independent. The display code is part
of the OS/platform dependent executable and must provide a list
of callbacks (windowprocs) to the game. There is no shared global
state between the two.
This was a prerequisite for the network protocol, which encodes
the api calls and callbacks almost literally.
With this change, the days of multiple window port binaries are
over. It now makes much more sense to have separate programs, for
example nitrohack-curses and nitrohack-qt.
The NitroHack network server is technically a UI port and uses
the same mechanisms.

- rewritten input system which allows safe key (re)mapping
The came core never, ever requests a key from the UI. All
interactions happen on an abstract level: The ui sends commands
to the core as a string ("wait", "move", etc.), the game may
request a direction or a position (etc) in return.
This allows the UI to perform key mapping safely, because it
is never necessary to guess what context some request for input
occurs in.

- All-new curses based text mode UI
All the old window ports became obsolete due to the extensive API
changes.
A new UI based on curses (ncurses on unix, pdcurses on windows)
has been written. It is a significant upgrade compared to the old
tty port in terms of usability and features:
* unicode display, with customizable display chars
* configurable keymap, with a configuration dialog
* full arrow key and function key use
* multiple visible message lines
* improved status
* permanent inventory display (if your terminal is wide)
* Inventory menu with item actions
* real line editing

- Layered drawing
The game core provides a set of display items for each location
to the UI, rather than a single display char. For example a
monster on an item on a trap can be represented logically.
The curses UI displays the alternatives by blinking between them
(unless you disable blinking in the options).

- Mersenne twister random number generator
An OS independent RNG with known state was required in order to
make game logs replayable. The mersenne twister is the best
choice.

- Re-runnable game core.
Several of the main data structures have been made const, all
others are carefully re-initialized when a game is started or
loaded.
This makes it possible to have a main menu for starting games,
viewing the top ten or changing options.
Previously this was not possible, as the altered global state
from one game would have affected a second, so exiting was the
only option.

- No more level files and no more lock files.
All levels are now kept in memory at all times. This makes a lot
of locking unnecessary. It also allows viewing of levels you are
not currently on.
The only remaining locking is of active game logs via OS
mechanisms which are not based on files: fcntl on UNIX and
LockFile on Windows.
(For a game where all levels have been visited, this change could
result in up to 5 Mb of extra memory use! The horror!!)

- No more support for antique systems and compilers
Support for everything that belongs in a computer history museum
has been removed: BE, DOS, Classic Mac, Atari, VMS, etc ...
The list of supported compilers has likewise been reduced to gcc,
clang and msvc (and probably Intel's compiler, too).
This allowed the removal of lots and lots of crufty code and
compat macros.

- Code cleanups
The number of "#ifdef FOO" has been cut down from 1938 to just 51
That makes the code much more readable, because the indentation
isn't being interrupted every couple of lines. To this end almost
all compile options that didn't become birth options were enabled
unconditionally or removed.
All functions have been converted to use standard prototypes
rather than K&R declarations. Ugly things like prototype widening
and the follow-on #defines went away.
Tools like git diff can now correctly show what function a line
or change is in.
All instances of the keyword "register" have been removed -
optimizing compilers handle this for us. Likewise NEARDATA which
only made sense on 16-bit computers.

- New build system: Cmake
On Linux you get safe parallel builds with pretty colorized
output, on Windows the generated Visual Studio 2010 project
builds without problems.


Game features:
- Autopickup rules
Real rule sets that control what gets picked up replace the
pickup list + exceptions system. Rules can match based on the
name, object type and BUC status.
The following example rule set picks up all food as well as
lizard corpses, but no other corpses:
1. IF name matches "*lizard*" AND type is "food": < GRAB
2. IF name matches "*corpse*" AND type is "food": LEAVE >
3. IF type is "food": < GRAB
Rules are evaluated in order until a matching rule is found. If
no rule matches, the item is left behind by default.

- Character history tracking
NitroHack will automatically track the following items
(with a turn timestamp) for use in your ascension posts:
* new depth reached
* new experience level reached
* wishes with the exact wish text
* killed a unique monster
* lifesaved
* crowning
* artifact gifts
* basic quest status
* major oracle consultations
* performed the invocation
* gained/lost the amulet of yendor (only shown if the amulet is
identified)
You can view your heroic deeds with #history

- Dungeon overview + dungeon annotations
This change was inspired by the "Dungeon Map Overview 3" patch
(by Hojita Discordia) as found in UnNetHack.
You can now #annotate a level to name/describe it.
#overview / Ctrl+O will show a menu of all the levels you remember
including your annotations and significant features (shops,
altars, ...)
You can select a level from the overview menu to view your memory
of it.

- Dump log
Inspired by Jukka Lahtinen's dumplog patch.
When you die, a dump log containing the following information
will be created:
* Final (ascii) screenshot
* Player stats
* Full inventory, including listings of the contents of
containers
* Player attributes
* Known spells
* Skills
* Conducts
* Vanquished opponents
* Final messages
* dungeon overview
* heroic deeds

- sorted loot
based on code by Jukka Lahtinen and Patric Müller in UnNetHack.
Item types are sorted based on:
1) item name
2) enchantment
3) BUC
4) erodeproofing
5) erosion
6) greasedness

- Miscellaneous changes, in no particular order
* You can use adjust to split stacks (Sam Dennis)
* Top ten saves 10000 entries by default
* Unexplored locations, stone and dark rooms are all logically
different in the drawing code (but only dark rooms are shown
differently by default)
* object class symbols are shown in menu headers
* you may choose to always show uncursed status in the options
(Pasi Kallinen)
* you will be prompted to quiver if firing with an empty quiver
(Jukka Lahtinen)
* thrown or fired items will always be picked up automatically
if you set pickup_thrown in the options (Roderick Schertler)
* reading spellbooks early is allowed (Alex Smith)
* naming of monsters, items & item types via menu (from NAO)
* Improved the died while helpless descriptions (Pasi Kallinen)
* monster targeting with m when a position is requested
(inspired by Pasi Kallinen's patch)
* Very long message history (20k messages)
* Removing armor and accessories will always trigger a prompt,
even if there is only one possible choice.
* Open doors when the player walks into them (AceHack)
* extinct species are shown together with genocided species
(based on a patch by Jukka Lahtinen)

- Fix about 10% of all known NetHack bugs
C343- 2 Wielded silver arrows don't cause silver damage on some
silver-haters. (Alex Smith)
C343- 7 When a steed pushes a boulder into a pool, the message
misuses "you". (Alex Smith)
C343- 8 Plural of Nazgul is Nazgul - not Nazguls. (Patric Müller)
C343- 12 You can't use '>' to enter a pit. (Patric Müller)
C343- 15 You can get a message that an invisible monster looks
much better. (Alex Smith)
C343- 18 Scaring a mimicking mimic gives an incorrect "turns to
flee" message. (Alex Smith)
C343- 30 Cursed scroll of destroy armor on cursed armor doesn’t
always interact correctly. (Alex Smith)
C343- 50 A sleeping steed may answer a #chat. (Alex Smith)
C343- 54,-55 "Ulch" message fixes. (Alex Smith)
C343- 74 Entering a long running, un-interruptible command after
stoning starts will kill you. (Patric Müller)
C343- 88 Polymorphing a statue into a boulder can leave an
incorrect display. (Alex Smith)
C343- 94,SC343-8 Probing a re-anmiated statue may cause a panic.
(Patric Müller)
C343-100 Game may crash if thrown potion hits bars before a
monster. (Patric Müller)
C343-109 There is a grammar error in the Tourist leader's
greeting. (Alex Smith)
C343-111 Grammar of some graveyard sounds messages is wrong in
some cases. (Alex Smith)
C343-116 Grammar error in messages related to choking on gold.
(Patric Müller)
C343-123 Plural of "mother-in-law" is incorrect. (Alex Smith)
C343-136 A samurai quest guardian message uses "ninja" where
"ronin" is intended. (Patric Müller)
C343-160 The name "leather spellbook" is misleading. (Alex Smith)
C343-171 Silver weapon damage message is sometimes missing when
hero is polymorphed. (Patric Müller)
C343-179 If a potion of acid is destroyed by water, the game may
crash. (Patric Müller)
C343-189 Temple donations and protection lost to gremlin attack
interact incorrectly. (Patric Müller)
C343-211 Engraving under water gives a poorly worded message.
(Patric Müller)
C343-218 Applying a wielded cream pie can crash the game.
(Patric Müller)
C343-222 It's possible to end up wielding a cockatrice corpse
when no longer polymorphed. (Arthur O'Dwyer)
C343-231 Time is distorted while sinking into lava.
C343-235 Casting spell of protection gives incorrect message if
hero is swallowed or in rock. (Patric Müller)
C343-248 You can’t put candles in a candelabrum while underwater
(Sgeo)
C343-252 There is a typo in the quote from "The Count of Monte
Cristo." (Patric Müller)
C343-258 Grammar error in samurai quest: "wakarimasu?" instead of
"wakarimasu ka?" (Patric Müller)
C343-259 "Dr. Dolittle" is spelled incorrectly. (Patric Müller)
C343-270 Dying in a shop while wielding two weapons may cause a
warning message. (Patric Müller)
C343-275 If a lit, wielded, candle or potion of oil burns out,
the game may crash. (Patric Müller)
C343-276 If a figurine auto-transforms while wielded or worn, the
game may crash. (Patric Müller)
C343-298 Kicking at "empty space" uses no time.
C343-318 Opening or closing the castle drawbridge using music
takes no time. (Alex Smith)
C343-324 Bisecting a long worm with 1hp crashes the game.
(Patric Müller)
C343-356 Wearing an amulet of restful sleep confuses internal
sleep state bookkeeping. (L's "Gremlin's Curse")
C343-386 Pearl rings can rust. (Alex Smith)
C343-398 The game may crash if a wielded potion of polymorph is
drunk. (Alex Smith)
C343-399 Messages referring to a named vault guard have
grammatical errors. (Alex Smith)
SC343-12 Calling high priests on Astral reveals their identity.
SC343-20 Hangup save while picking up gold in a shop may
duplicate the gold. (Patric Müller)
My sources for these fixes were UnNetHack, AceHack, the Patchdb.

What didn't change:
The game mechanics of NitroHack remain identical to those of NetHack.
All the behavior of items and monsters, scoring, difficulty etc. is
unchanged.
I do believe that there are several things that could be done here, but
I wanted to do all these fundamental things first.

[BanMido]

On 1/16/2012 10:47 AM, Daniel Thaler wrote:
> Hi everyone!
>
> This is the initial public release of NitroHack, a fork of NetHack.
>
> The website for NitroHack is http://nitrohack.org, where you can also
> find screenshots and downloads.
>
> Change log:

> [...]

Wow, those are substantial changes! How much time did all this effort take?

> I do believe that there are several things that could be done here, but
> I wanted to do all these fundamental things first.

Indeed.
I wonder what other NetHack variant developers think about this project.

[Krice]

On 16 tammi, 08:54, BanMido <smartrefere...@gmail.com> wrote:
> Wow, those are substantial changes!

Epic changes when you think how difficult it is to work with
Nethack's source code. This is different from typical
forks and could break the barrier that I think was there
when Dev Team abandoned Nethack.

[Patric Mueller]

Daniel Thaler <dan...@invalid.address.com> wrote:
> Hi everyone!
>
> This is the initial public release of NitroHack, a fork of NetHack.
>
> The website for NitroHack is http://nitrohack.org, where you can also
> find screenshots and downloads.

Cool work, you have added some great features.

> Change log:
>
> Back end features:
> - NitroHack network protocol
> NitroHack supports network play without telnet or ssh over its own
> protocol. The protocol is based on JSON and should make it very
> easy to implement a browser-based NitroHack client (TODO!).

When asking for the password for the public server you should add a
note that the password will be sent without any encryption over the
net.

There is no possibility to watch running games on the public server
(yet)?

> - Birth options
> Want to play without Elbereth? It is now possible to do so without
> recompiling. ELBERETH, REINCARNATION, SEDUCE and bones files have
> become a new kind of option: birth options, which can only be set
> before the character is created.

You could add conduct tracking to these birth options (great name for
this BTW).

> - Layered drawing
> The game core provides a set of display items for each location
> to the UI, rather than a single display char. For example a
> monster on an item on a trap can be represented logically.
> The curses UI displays the alternatives by blinking between them
> (unless you disable blinking in the options).

The blinking between different categories of display characters is an
interesting solution to the limitations of the ASCII display.

> - Dump log
> Inspired by Jukka Lahtinen's dumplog patch.
> When you die, a dump log containing the following information
> will be created:

You're missing an xlogfile like log. Without this you're public server
won't be able to participate in the next Junethack!

While trying NitroHack on a Windows 7 64bit, both local and remote
games had problems with numpad. I got "bad command" when trying to use
the even numbers. With NumLock off, the "Count: 444" stuff worked
flawlessly.

When playing local on this system, the game froze after showing the
tombstone and I couldn't find the dumplog of the crashed game so I
suppose it crashed while trying to write the dumplog.

Bye
Patric

--
NetHack-De: NetHack auf Deutsch - http://nethack-de.sf.net/

UnNetHack: http://apps.sf.net/trac/unnethack/

[Patric Mueller]

BanMido <smartre...@gmail.com> wrote:
> On 1/16/2012 10:47 AM, Daniel Thaler wrote:
>> Hi everyone!
>>
>> This is the initial public release of NitroHack, a fork of NetHack.
>>
>> The website for NitroHack is http://nitrohack.org, where you can also
>> find screenshots and downloads.
>>
>> Change log:
>> [...]
>
> Wow, those are substantial changes! How much time did all this effort take?

The first commit was on March 31st 2011. If you go to
https://github.com/DanielT you can see an activity graph for
NitroHack.

>> I do believe that there are several things that could be done here, but
>> I wanted to do all these fundamental things first.
>
> Indeed.
> I wonder what other NetHack variant developers think about this project.

I've been following it from the start as he forked his from my Vanilla
NetHack git repository so I got a notice at the beginning.

I dislike adding a new curses UI (instead I would rather already have
seen a working web client, would be way cooler then yet another curses
UI) and the cmake building seems a bit fragile (I didn't succeed in
installing it in a custom directory for example, but I don't have lots
of cmake experience) but this is not something that would be IMO an
obstacle to an eventual merger of code from NitroHack into UnNetHack.

Currently, most of the work done is in regards to internal structure
and interfaces outwards, not gameplay changes. So in general it
shouldn't be too hard integrate that.

The feature I like most is the possibility of a web client. I wanted
to tackle that myself (that's why there is no official
UnNetHack graphical UI client yet) but if somebody else does the work
(and probably even better than I could) I won't complain about that.


There are some things missing that shouldn't be missing when playing
on public server. For example as far as I can see, you can't watch
in-progress games or send mails to the player (but it doesn't use
dgamelaunch, so this is understandable). BTW, Tome4 has an in-game IRC
client, now that's interactive.

[Patric Mueller]

You think the reason that there is no widely accepted successor to
Vanilla NetHack is that the code is too complex and too spaghetti and
therefore the other forks are ...?

What exactly is this barrier you mention and how is it an obstacle to
a non-official vanilla successor?

[Daniel Thaler]

On 16.01.2012 12:36, Patric Mueller wrote:
> Daniel Thaler<dan...@invalid.address.com> wrote:
>> Hi everyone!
>>
>> This is the initial public release of NitroHack, a fork of NetHack.
>>
>> The website for NitroHack is http://nitrohack.org, where you can also
>> find screenshots and downloads.
>
> Cool work, you have added some great features.

Thanks!

>> Change log:
>>
>> Back end features:
>> - NitroHack network protocol
>> NitroHack supports network play without telnet or ssh over its own
>> protocol. The protocol is based on JSON and should make it very
>> easy to implement a browser-based NitroHack client (TODO!).
>
> When asking for the password for the public server you should add a
> note that the password will be sent without any encryption over the
> net.

It is now changed.

> There is no possibility to watch running games on the public server
> (yet)?

That's right, it's not there yet.

>> - Birth options
>> Want to play without Elbereth? It is now possible to do so without
>> recompiling. ELBERETH, REINCARNATION, SEDUCE and bones files have
>> become a new kind of option: birth options, which can only be set
>> before the character is created.
>
> You could add conduct tracking to these birth options (great name for
> this BTW).

I think I got the name from angband.
I also intend to do more with conducts - currently the server is
entirely unaware of them for example.

>> - Layered drawing
>> The game core provides a set of display items for each location
>> to the UI, rather than a single display char. For example a
>> monster on an item on a trap can be represented logically.
>> The curses UI displays the alternatives by blinking between them
>> (unless you disable blinking in the options).
>
> The blinking between different categories of display characters is an
> interesting solution to the limitations of the ASCII display.
>
>> - Dump log
>> Inspired by Jukka Lahtinen's dumplog patch.
>> When you die, a dump log containing the following information
>> will be created:
>
> You're missing an xlogfile like log. Without this you're public server
> won't be able to participate in the next Junethack!

I'll have to look into it.

> While trying NitroHack on a Windows 7 64bit, both local and remote
> games had problems with numpad. I got "bad command" when trying to use
> the even numbers. With NumLock off, the "Count: 444" stuff worked
> flawlessly.

I guess it shows that I tested the windows build on a notebook without a
numpad :-)

> When playing local on this system, the game froze after showing the
> tombstone and I couldn't find the dumplog of the crashed game so I
> suppose it crashed while trying to write the dumplog.

- Daniel

[BanMido]

On 1/16/2012 6:14 PM, Patric Mueller wrote:
> BanMido<smartre...@gmail.com> wrote:
>> On 1/16/2012 10:47 AM, Daniel Thaler wrote:
>>> Hi everyone!
>>>
>>> This is the initial public release of NitroHack, a fork of NetHack.
>>>
>>> The website for NitroHack is http://nitrohack.org, where you can also
>>> find screenshots and downloads.
>>>
>>> Change log:
>>> [...]
>>
>> Wow, those are substantial changes! How much time did all this effort take?
>
> The first commit was on March 31st 2011. If you go to
> https://github.com/DanielT you can see an activity graph for
> NitroHack.

Thanks for the pointer Patric.

That is almost a year worth of work, thanks for the effort mate! I
really hope something good and substantial comes out of it.

[Daniel Thaler]

On 16.01.2012 13:44, Patric Mueller wrote:
> I dislike adding a new curses UI (instead I would rather already have
> seen a working web client, would be way cooler then yet another curses
> UI)

The curses UI was required in order to validate that the internal API
made sense and debug the interaction. Going straight to a web client
would have been extremely difficult.

> There are some things missing that shouldn't be missing when playing
> on public server. For example as far as I can see, you can't watch
> in-progress games or send mails to the player (but it doesn't use
> dgamelaunch, so this is understandable).

The server code is extremely raw - none of it even existed a month ago.
I have all sorts of features on my TODO there.

- Daniel

[Krice]

On 16 tammi, 15:14, Patric Mueller <bh...@bigfoot.com> wrote:
> You think the reason that there is no widely accepted successor to
> Vanilla NetHack is that the code is too complex and too spaghetti and
> therefore the other forks are ...?

Other forks have been minor, right? This fork is more like an
inspiration for birth control.

> What exactly is this barrier you mention and how is it an obstacle to
> a non-official vanilla successor?

It's there, trust me. I'm sure Linley ran into it in Crawl,
Dev Team in Nethack and I had my own experiences with Kaduria,
which I then rewrote to C++/OOP to climb over that wall.
It wasn't easy, I can tell you that much.

[Patric Mueller]

Krice <pau...@mbnet.fi> wrote:
> On 16 tammi, 15:14, Patric Mueller <bh...@bigfoot.com> wrote:
>> You think the reason that there is no widely accepted successor to
>> Vanilla NetHack is that the code is too complex and too spaghetti and
>> therefore the other forks are ...?
>
> Other forks have been minor, right?

Certainly not because they are held back by "too complex code". Just
look at Slash'Em and Vulture's. The first has features en masse and
the second has a UI with lots of bling-bling.

They are minor because the NetHack community didn't accept them as a
successor, or because they didn't find a big audience of non NetHack
roguelike player, or because they didn't even want to appeal to a
large audience.

> This fork is more like an inspiration for birth control.

If simpler code and numbers of variants would be automatically ensure
popularity, Angband would be way more popular than NetHack.

>> What exactly is this barrier you mention and how is it an obstacle to
>> a non-official vanilla successor?
>
> It's there, trust me. I'm sure Linley ran into it in Crawl,
> Dev Team in Nethack and I had my own experiences with Kaduria,
> which I then rewrote to C++/OOP to climb over that wall.
> It wasn't easy, I can tell you that much.

You're not explaining anything.

[GaryOlson]

On Jan 15, 11:17 pm, Daniel Thaler <dan...@invalid.address.com> wrote:
> Hi everyone!
>
> This is the initial public release of NitroHack, a fork of NetHack.
>

> The website for NitroHack ishttp://nitrohack.org, where you can also

> find screenshots and downloads.
>
> Change log:
>

You read a Scroll of Immense Change and Code Simplification. You feel
impressed, awed, and immeasurably humble. Would you like to download a
copy of NitroHack and Play (y/n)?

How can one say No to this question?

Thanks for all the hard work.

Gary Olson

[Corey]

To: GaryOlson
Re: Re: NitroHack 4.0.0 release
By: GaryOlson to rec.games.roguelike.nethack,rec.games.roguelik
e.development on Mon Jan 16 2012 06:25 pm

I see great things for this version.
a client/server nethack can go far.
think of the advanced clients that could come around from this.
Earth and Beyond and World of Warcraft are advance examples of this type of
system.

[Jonadab the Unsightly One]

Wow. Is that changelog real? It's not April first. Maybe it's real.

I have GOT to give this a try...

(To compile it, I needed to install a minor dependency, and while I
had Synaptic running I went ahead and had it install all the available
updates, which included a kernel update, so now I need to reboot; long
story short, I haven't got to try it out yet. But I will, oh, yes.
Just going from the changelog, it looks to be exactly what the nethack
community needs and has been lacking: a fork that's conservative
about gameplay changes and thus can be readily accepted as a
straightforward upgrade from vanilla. Not that the existing forks are
all bad, but the ones I'm familiar with are all clearly _variants_.
This one looks much more like it has the potential to be the fork that
eventually obviates and takes the place of the codebase it was forked
from.)

[Jonadab the Unsightly One]

On Jan 16, 7:44 am, Patric Mueller <bh...@bigfoot.com> wrote:

> I dislike adding a new curses UI

If a NetHack fork is going to amount to anything, it inevitably
has to have a TTY version. Otherwise it's just not NetHack-ey
enough to really catch on.

> (instead I would rather already have seen a working web client,

Admittedly, that would be a rather nifty enhancement.
Depending on how it's implemented, ASCII versus tiles
(or different tile aspect ratios, or entirely custom tiles for
that matter) could be accomplished simply by pointing to
a different external stylesheet.

(Plus, then we could unofficially call it WebHack.)

> There are some things missing that shouldn't be missing
> when playing on public server. For example as far as I can
> see, you can't watch in-progress games or send mails to
> the player (but it doesn't use dgamelaunch, so this is
> understandable).

With the changelog being as substantial as it is, I can
definitely see why they wanted to go ahead and do
a release before getting around to such things.

But yeah, it'll eventually need better public-server support.

> BTW, Tome4 has an in-game IRC client, now that's interactive.

Many multiplayer games have in-game chat. NetHack,
by virtue of its turn-based nature and the fact that you
have the dungeon entirely to yourself (modulo NPCs),
can live without this, because the player can use #
and then just type whatever, pause, and hit escape;
observers can send scrolls of mail (once implemented).
The main reason I can think of to add in-game chat
would be so multiple observers can kibitz among
themselves.

[Jonadab the Unsightly One]

On Jan 16, 8:14 am, Patric Mueller <bh...@bigfoot.com> wrote:
> You think the reason that there is no widely accepted successor to
> Vanilla NetHack is that the code is too complex and too spaghetti and
> therefore the other forks are ...?

I don't know about the OP, but my opinion would be that the
other forks I'm familiar with all fall into one of two categories:
either it's clearly a variant, not a vanilla NetHack fork (the
biggest of these being SLASH'EM, but there are several
other really notable ones) or else they exist mainly to
provide a wonky non-standard interface (e.g., enormous
isometric tiles). This being NetHack, the majority of
players are never going to agree on any one such.

> What exactly is this barrier you mention and how is it an
> obstacle to a non-official vanilla successor?

My take would be that a _variant_ is never going to be
a clear successor for _vanilla_. Thus, UnNetHack and
SporkHack and NetHack Brass and so forth may be
interesting for a player who has got bored with vanilla
and wants to play a variant, but they're _not_ going to
replace vanilla NetHack it its role as the default
starting-point roguelike for people who've not seriously
played a roguelike before. As for SLASH'EM, it's
just plain too hard to replace vanilla for beginners.

[Jonadab the Unsightly One]

On Jan 16, 7:44 am, Patric Mueller <bh...@bigfoot.com> wrote:
> the cmake building seems a bit fragile

I did notice that some of the error messages are less informative than
would be ideal. For example, it tends to complain that variables are
not set when what it really means is you need to install
dependencies. An experienced *nix admin should be able to track down
such things, but better messages about exactly what is needed would
not go amiss.

Also, the dependency on Jansson should be advertised in the build
instructions, along with instructions on where to get it (source, at
least), as it's not a particularly common library. Debian, for
example, doesn't appear to include it at all in stable. Worse, a
quick web search mostly turns up the DJGPP port. Yeah, thanks Google,
that'll sure help. (DJGPP, for those who don't know, is a DOS port of
gcc and a number of other common *nix utilities, from the days of
sixteen-bit hardware; it was nice to have in its day, but the idea
that people might still be using it is kind of painful. I thought it
had been wholly obviated by cygwin and/or mingw32 some time ago,
except for those very few people still using DOS as such.) The only
Debian-related references to Jansson that I can find are for Sid, and
I haven't yet managed to find the upstream site either.

[Patric Mueller]

Jonadab the Unsightly One <jonadab.the...@gmail.com> wrote:
>
> Also, the dependency on Jansson should be advertised in the build
> instructions, along with instructions on where to get it (source, at
> least), as it's not a particularly common library. Debian, for
> example, doesn't appear to include it at all in stable. Worse, a

It's not called stale, erm, stable for nothing. That's the curse of more
advanced features, you get more dependencies. ;-)

> quick web search mostly turns up the DJGPP port. [...]

I think you misread the domain.

http://www.digip.org/jansson/ is the right place to go.

[Karl Garrison]

On Jan 16, 12:17 am, Daniel Thaler <dan...@invalid.address.com> wrote:
> Hi everyone!
>
> This is the initial public release of NitroHack, a fork of NetHack.
>

> The website for NitroHack ishttp://nitrohack.org, where you can also

> find screenshots and downloads.
>
> Change log:

<snip>

I would call that nothing short on an epic feat. One comment about
the interface, though: the "jumping" of the permanent inventory window
to make room for messages is distracting. I would probably prefer to
have these transient messages overlap something else than to push down
the inventory list.

Oh, and magenta borders for transient pop-up windows? Who would
choose such a color? ;-)


--
Karl Garrison
kgar...@pobox.com

[Daniel Thaler]

On 17.01.2012 16:43, Karl Garrison wrote:
> Oh, and magenta borders for transient pop-up windows? Who would
> choose such a color? ;-)

A nod to the work of a guy called Karl Garrison :-)

[Janis Papanagnou]

On 17.01.2012 14:15, Jonadab the Unsightly One wrote:
> Just going from the changelog, it looks to be exactly what the nethack
> community needs and has been lacking: a fork that's conservative
> about gameplay changes and thus can be readily accepted as a
> straightforward upgrade from vanilla. Not that the existing forks are
> all bad, but the ones I'm familiar with are all clearly _variants_.
> This one looks much more like it has the potential to be the fork that
> eventually obviates and takes the place of the codebase it was forked
> from.)

Janis


PS (if unclear): I meant to say; what you formulated hit the mark.

[Patric Mueller]

Jonadab the Unsightly One <jonadab.the...@gmail.com> wrote:

> On Jan 16, 7:44 am, Patric Mueller <bh...@bigfoot.com> wrote:
>
>> I dislike adding a new curses UI
>
> If a NetHack fork is going to amount to anything, it inevitably
> has to have a TTY version. Otherwise it's just not NetHack-ey
> enough to really catch on.

I think you mix up ASCII[*] map display and a TTY version. In Vanilla
several ports are display the map with ASCII even though it's really a
GUI and the rest of the interface is also using real GUI elements.

I don't think a tty version is really needed anymore these days as
long as you have an ASCII map for feeling like an hardcore player and
(actually IMO more important) that you have the possibility to play
online via a public server (including community features like watching
running games and talking to players).

[*] If we're nitpicking, IBMgraphics and DECgraphics already aren't
really ASCII anymore, but I think we know what we mean by "ASCII".

[Jonadab the Unsightly One]

On Jan 17, 10:34 am, Patric Mueller <bh...@bigfoot.com> wrote:
> I think you misread the domain.
> http://www.digip.org/jansson/ is the right place to go.

Oh. Ah. So I did.

Man, how did I misread _that_ as _that_? Maybe I should get my eyes
checked.

Anyway, I'll have to look into that.

[Jonadab the Unsightly One]

On Jan 17, 4:07 pm, Patric Mueller <bh...@bigfoot.com> wrote:

> I think you mix up ASCII[*] map display and a TTY version. In Vanilla
> several ports are display the map with ASCII even though it's really a
> GUI and the rest of the interface is also using real GUI elements.
>
> I don't think a tty version is really needed anymore these days

> long as you have an ASCII map for feeling like an hardcore player

I can't say I really agree with this.

> (actually IMO more important) that you have the possibility to play
> online via a public server (including community features like watching
> running games and talking to players).

That's important too. Given that the Nitro source is available,
I'm relatively sure somebody will see that it happens. (The dev
himself made positive noises about it upthread, so it may even
be built right into a future release.)

> [*] If we're nitpicking, IBMgraphics and DECgraphics already aren't
> really ASCII anymore,

IBM used to call their character set "Extended ASCII".

But...

> but I think we know what we mean by "ASCII".

Yeah.

I still think the terminal UI _is_ worth having, though.

Not that it needs to be the only UI, of course. Quite the
contrary. In fact, with Nitro's UI separated out from the
rest of the code, it should be easier than ever before for
various people to implement various different UIs to suit
different people's tastes -- and they could all be used to
play the same game, even on the same public server(s).

Even better, with the network protocol being the way it is,
it should be possible for a person using one UI to watch a
public-server game played by a person using a different
UI (and different UI settings) entirely. No more hunting
around for transliterative fonts so you can watch games
where people are using the other kind of graphics without
seeing a bunch of cyrillic characters or whatever.

And I agree that a web-based UI would be nice to have,
particularly if it's well implemented and doesn't require
any plugins.

[Patric Mueller]

Jonadab the Unsightly One <jonadab.the...@gmail.com> wrote:
>

> Just going from the changelog, it looks to be exactly what the nethack
> community needs and has been lacking: a fork that's conservative
> about gameplay changes and thus can be readily accepted as a
> straightforward upgrade from vanilla. Not that the existing forks are
> all bad, but the ones I'm familiar with are all clearly _variants_.

You make it sound like it's bad to be a variant. If you compare the
different vanilla NetHack versions with each other, they are more
different than some of the variants that have existed.

Do you know AceHack and if you do what is with AceHack that
disqualifies it from being a straightforward upgrade?

> This one looks much more like it has the potential to be the fork that
> eventually obviates and takes the place of the codebase it was forked
> from.)

What do you need an upgrade for when you don't change anything?

[Jonadab the Unsightly One]

On Jan 17, 10:34 am, Patric Mueller <bh...@bigfoot.com> wrote:
> > Debian, for example, doesn't appear to
> > include it at all in stable. Worse, a
>
> It's not called stale, erm, stable for nothing.

I don't want to upgrade my OS every six months, but
you'll notice I'm not advocating Windows XP, either.

There were admittedly a couple of years where I found
Debian stable to be completely unusable (say, in early
2005), because its versions of absolutely everything
were so thoroughly antiquated that you couldn't install
new versions of anything, even things that supported
three-version-old libraries. Coming out during this
time is probably the key factor that made Ubuntu so
popular so quickly. It was also about then that I
wrote an Uncyclopedia article about Debian, to the
effect that it was a repository of "stable" software,
with "stable" meaning that the software was so old
it was no longer under active development or in
widespread use. I think I even claimed that Debian
contained Netscape 3, which was an exaggeration
even then. (I believe Woody actually did contain
Netscape 4, though.)

Currently, though, Squeeze is less than a year old,
and it had relatively recent versions of most major[1]
libraries at that time, and you can install the latest
versions of almost any application you want (including
fast-moving ones like Firefox) if you are so inclined.

> That's the curse of more
> advanced features, you get more dependencies. ;-)

I don't mind having to compile the library from source.
I'm a computer geek. I can do stuff like that. And when
you're downloading the first public release of something
right after it's announced, you expect some of that.
I didn't intend to complain about the fact that NitroHack
depends on Jansson. That wasn't what I meant.

---
[1] I define a "major" library as one that is used by a
lot of software in widespread deployment -- especially
software that is installed by default in many distros.
Cairo, for example, is a major library. GTK is even
more major. glibc, of course, is in a class by itself.

[Janis Papanagnou]

On 17.01.2012 22:07, Patric Mueller wrote:
>
> I don't think a tty version is really needed anymore these days as

> long as you have an ASCII map for feeling like an hardcore player [...]

(I'd disagree.)

BTW, how does a (say) "tiled" version implement effects like 'colors'
and (say for pets) 'standout' character attributes? - Just curious...

Janis

[Janis Papanagnou]

On 17.01.2012 23:26, Patric Mueller wrote:
> Jonadab the Unsightly One <jonadab.the...@gmail.com> wrote:
>>
>> Just going from the changelog, it looks to be exactly what the nethack
>> community needs and has been lacking: a fork that's conservative
>> about gameplay changes and thus can be readily accepted as a
>> straightforward upgrade from vanilla. Not that the existing forks are
>> all bad, but the ones I'm familiar with are all clearly _variants_.
>

> You make it sound like it's bad to be a variant. [...]

You misread/misinterpreted what he wrote, I fear.

>> This one looks much more like it has the potential to be the fork that
>> eventually obviates and takes the place of the codebase it was forked
>> from.)
>
> What do you need an upgrade for when you don't change anything?

Erm.. - "...when you don't change *anything*" - ??? I suspect
you meant to ask; "...when you don't change any game-play feature"?

But the point was about a reliable, extensible, and flexible code
architecture base (as a prerequisite for a source code base for a
new version and new variants).

Janis

[Jonadab the Unsightly One]

On Jan 17, 4:40 pm, Jonadab the Unsightly One

<jonadab.theunsightly...@gmail.com> wrote:
> >http://www.digip.org/jansson/ is the right place to go.

> Anyway, I'll have to look into that.

Sorted. Jansson compiles and installs very quickly and easily.
I then found one other dependency that needed to be installed
(the dev package for libncursesw), and had to delete the build
directory and start over after getting it installed (because I
don't know the cmake equivalent of make clean), but then
build and install proceeded without further incident, bringing
me to the following point:

nathan@warthog:/opt/nitrohack/nitrohack-data$ ls -l
total 3440
-rw-r--r-- 1 root root 56159 Jan 17 18:27 libnitrohack_client.so
-rw-r--r-- 1 root root 2574540 Jan 17 18:27 libnitrohack.so
-rw-r--r-- 1 root root 4979 Jan 15 11:03 license
-rw-r--r-- 1 root root 587654 Jan 17 18:27 nhdat
-rwxr-xr-x 1 root root 171684 Jan 17 18:27 nitrohack
-rwxr-xr-x 1 root root 97162 Jan 17 18:27 nitrohack_server
nathan@warthog:/opt/nitrohack/nitrohack-data$ ./nitrohack
./nitrohack: error while loading shared libraries: libnitrohack.so:
cannot open shared object file: No such file or directory
nathan@warthog:/opt/nitrohack/nitrohack-data$

*That* problem was resolved by creating symlinks in /usr/lib
pointing to the .so files (both of them) in the directory where
they were installed (/opt/nitrohack/nitrohack-data in my case,
because I didn't think /root/nitrohack/nitrohack-data was a
real good idea, so I changed it at the ccmake stage).

With so symlinks in place, nitrohack runs and displays
the main menu.

Before I get serious about playing it I'm going to finish
up my current game on NAO (seeing as how I'm on the
plane of air, currently), but after that...

[Jonadab the Unsightly One]

On Jan 17, 6:46 pm, Jonadab the Unsightly One

Did I write "air"? I meant earth.

[Jonadab the Unsightly One]

On Jan 17, 6:19 pm, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

> BTW, how does a (say) "tiled" version implement effects like 'colors'

Since there are entirely different tiles for different monsters
and objects, it's !colors that isn't really implemented.

> and (say for pets) 'standout' character attributes? - Just curious...

The Qt build uses a little Valentine-heart overlay for pets.
However, some tile versions don't support this, e.g.,
Ebonhack. I don't know what the MS WIndows build does.

Personally, I found playing with a tileset to be very helpful
when I was first playing the game, because it reduced the
number of things I had to memorize right away. Later,
when I'd learned most of the basics, playing with character
graphics became easy (from a UI perspective; I have not
yet reached the point where I think NetHack is easy to
actually _win_).

[Jonadab the Unsightly One]

On Jan 17, 5:26 pm, Patric Mueller <bh...@bigfoot.com> wrote:

> You make it sound like it's bad to be a variant.

No, I didn't mean it like that. It's good to have
variants. Variants are good. I've played around
with a couple of them already, and I'm very new
to the game. I intend to play more variants as
time goes on. I like having variants around.

I just mean no single variant is likely to take the
place of vanilla.

> Do you know AceHack

Haven't gotten around to that one yet.

> What do you need an upgrade for when you
> don't change anything?

Bug fixes and UI improvements?

I don't mean that _nothing_ should be changed
in terms of gameplay, though. Some change is
good. I just mean that, for the mainline codebase,
changes should be conservative and carefully
considered. Some of the things that eventually
made it into vanilla NetHack started out in variants.
But not every change that variants experiment with
makes it in to vanilla.

There has to be a vanilla codebase from which
the various variants branch out, that's all I'm saying.

Of course the "birth options" in NitroHack could
potentially be (ab)used to allow multiple variants
to coexist within a single version of the game...

[Daniel Thaler]

On 18.01.2012 00:46, Jonadab the Unsightly One wrote:
> nathan@warthog:/opt/nitrohack/nitrohack-data$ ./nitrohack
> ../nitrohack: error while loading shared libraries: libnitrohack.so:

> cannot open shared object file: No such file or directory
> nathan@warthog:/opt/nitrohack/nitrohack-data$

Congratulations, you found a bug.

There is a little shell script that gets created whose only purpose is
to set up LD_LIBRARY_PATH before running nitrohack; unfortunately it got
generated wrong.

I have now fixed that, so your suffering will prevent others from
experiencing the same problem.

- Daniel

[Pat Rankin]

[crosspost to the rec.games.roguelike.development dropped]

On Jan 16, 6:25 pm, GaryOlson <garyolson....@gmail.com> wrote:
> [...] Would you like to download a copy of NitroHack and Play (y/n)?

>
> How can one say No to this question?

Easy: just use one of the platforms supported by nethack
that have been cavalierly dismissed as obsolete. Continuing to
support ancient systems and buggy compilers is one of nethack's
strengths, not a weakness that needs to be expunged in order to
brag about how the amount of conditional code has been reduced.

[Jason Cannon]

Just gave it a try. Doesn't look like I'll be giving up my tty vanilla
just yet, but from looking at the changelog it has a lot of features I
like.

A few questions:
--Since it will eventually have built in server support, were you
planning on having an automatic updater?
--As a few have mentioned above, will it be possible to play something
like sporkhack using birth options, or to somehow integrate variants
into the Nitrohack system?
--Since I can't edit the options file by hand, how would I go about
reassigning a symbol, such as putting boulders to 0 and ghosts/shades
to 9?
Also, as mentioned above, num_pad needs some work on windows before it
will be comfortable to use.

[Janis Papanagnou]

With all due respect; I think this rather must be: "Continuing to
support ancient systems and buggy compilers *was* one of nethack's
strengths". Even as a strong proponent of Nethack I would say that
"is" would be the appropriate tense if there would be some releases
(at least bugfix releases for the ~500 reported bugs) still published.
Also the part "*Continuing to support* [ancient systems ...]" looks
like a strange formulation in that light.

Janis

[Pasi Kallinen]

I think Atari, OS2 and Amiga are pretty much dead by now.
(And outside Big Corps, VMS isn't exactly alive either)

--
Pasi Kallinen
pa...@alt.org
http://bilious.alt.org/ -- NetHack Patch Database

[Patric Mueller]

Jason Cannon <jason...@gmail.com> wrote:
>
> --As a few have mentioned above, will it be possible to play something
> like sporkhack using birth options, or to somehow integrate variants
> into the Nitrohack system?

Because variants usually involve more changes to the core code than
you can comfortably customize by just toggling options, I don't think
this is reasonable. In the worst case you would end up with
essentially several binaries compiled into one program.

But because of the even more strict separation of game engine and
client code, it should be possible to have one client being able to
talk to different nitrohack-derived servers or at least port any
client to a nitrohack-variant with not much more effort than a
recompile as long as there are no incompatible or conflicting
client-server-protocol changes in the variants.

[Daniel Thaler]

On 18.01.2012 03:11, Pat Rankin wrote:

Why would one even want to support ancient systems in new software?
And conversely, why should a person with an ancient system want to run
new software on it?
Supposing someone maintains an Atari or a C64 in a working condition,
they would probably want to run period appropriate software on it. After
all, running such a machine now is the computing equivalent of a
renaissance reenactment.

[Patric Mueller]

Note: I'm being an advocatus diaboli here.

I'm excited and thrilled about the work Daniel has done, too. But I
think for completely different reasons than most of you posting in
this thread.

And because I want to understand why many of you feel that it is
important that NitroHack is different in those parts that I don't
think are important, I'm being a bit of a nuisance.

Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 17.01.2012 23:26, Patric Mueller wrote:
>> Jonadab the Unsightly One <jonadab.the...@gmail.com> wrote:
>
>>> This one looks much more like it has the potential to be the fork that
>>> eventually obviates and takes the place of the codebase it was forked
>>> from.)
>>
>> What do you need an upgrade for when you don't change anything?
>
> Erm.. - "...when you don't change *anything*" - ??? I suspect
> you meant to ask; "...when you don't change any game-play feature"?

When you don't change anything that is relevant to players (relevance
in regards to code I discuss further down).

What do you care as a player if the network feature is no longer
telnet based but http/json based? If the former worked for you, there
is probably no incentive to switch.

Or differently asked: What problems of Vanilla NetHack are solved by
NitroHack that haven't been solved by the other variants? (It might be
beneficial to tell what the problems of Vanilla are, I'm not sure that
we all see the same problems)

> But the point was about a reliable, extensible, and flexible code
> architecture base

I'm not sure if you got the bit about "code simplification" wrong.

The gameplay code didn't get changed significantly. There where small
changes because of the changed display architecture and there were
superficial[*] changes like dropping of #ifdefs and changing function
headers to modern conventions.

[*] Not my wording, Daniel says so in his own changelog.

For example the triplication of code for the three similar but
different cases "player attacking monster", "monster attacking
player", and "monster attacking monster" is still there
(uhitm.c/mhitu.c/mhitm.c).

The myth of the hard to comprehend, pre-ANSI-C NetHack code is just
that, a myth. If you only know Java, Python or PHP, yes, then it is
hard to understand, but then every bit of C code with pointers is hard
to understand.

If you didn't understand the code of NetHack, you don't understand the
code of NitroHack as well.

The gameplay code is as extensible and flexible as the vanilla code as
it *is* basically vanilla code. And we all know that vanilla code is
extensible and flexible because of all the variants that are out
there.


As for reliability, at least the gameplay code should be as reliable
as AceHack's and UnNetHack's. No wonder, about 90% of those bugfixes
have been attributed to Alex Smith and me. :-)

The newly written code, display archicture, the new load-save
mechanisms, etc., is probably not as reliable as Vanilla's (you can't
beat decade-old code that has been in used all the time) but I'm sure
many bugs will quickly be ironed out. If people play it and report the
bugs.

> (as a prerequisite for a source code base for a new version and new variants).

New versions and variants that don't get played because they are not Vanilla?

With any change in gameplay you *will* upset some vanilla players.

This has happened before and we've seen it in this group several
times.

People *will* get variant paranoia when they play anything that is not
Vanilla. People will go "eww, it never did that in NetHack!" or "urks,
this is way harder than NetHack" even though it did and in fact it
isn't.

[Daniel Thaler]

On 18.01.2012 03:31, Jason Cannon wrote:
> Just gave it a try. Doesn't look like I'll be giving up my tty vanilla
> just yet, but from looking at the changelog it has a lot of features I
> like.
>
> A few questions:
> --Since it will eventually have built in server support, were you
> planning on having an automatic updater?

The point of the server protocol is to eventually allow tiles clients to
play on public servers. It will also make implementing a web client easier.

> --As a few have mentioned above, will it be possible to play something
> like sporkhack using birth options, or to somehow integrate variants
> into the Nitrohack system?

I think many people don't appreciate how large the changes in UnNetHack
etc actually are. Birth options are meant to control minor gameplay
variations with little impact on the overall code.

> --Since I can't edit the options file by hand, how would I go about
> reassigning a symbol, such as putting boulders to 0 and ghosts/shades
> to 9?

I suppose I wasn't clear about that. The options you get with 'O' don't
need to be changed by editing the file any more. For the display
characters you will need to edit unicode.conf, which maps things to
unicode letters. On Linux it is in ~/.config/NitroHack/; on Windows you
should look in C:\Users\<username>\AppData\Roaming\NitroHack\
The lines in that file have the format <name> <color> <code point>:
"boulder" 7 25c6
"ghost" 7 0020
could become
"boulder" 7 0030
"ghost" 7 0039

- Daniel

[Patric Mueller]

Daniel Thaler <dan...@dthaler.de> wrote:
> On 18.01.2012 03:31, Jason Cannon wrote:
>
>> --As a few have mentioned above, will it be possible to play something
>> like sporkhack using birth options, or to somehow integrate variants
>> into the Nitrohack system?
>
> I think many people don't appreciate how large the changes in
> UnNetHack etc actually are. Birth options are meant to control minor
> gameplay variations with little impact on the overall code.

I protest about large changes in UnNetHack and want that to be changed
to "natural evolution". ;-)

>> --Since I can't edit the options file by hand, how would I go about
>> reassigning a symbol, such as putting boulders to 0 and ghosts/shades
>> to 9?
>
> I suppose I wasn't clear about that. The options you get with 'O'
> don't need to be changed by editing the file any more. For the display
> characters you will need to edit unicode.conf, which maps things to
> unicode letters. On Linux it is in ~/.config/NitroHack/; on Windows
> you should look in C:\Users\<username>\AppData\Roaming\NitroHack\
> The lines in that file have the format <name> <color> <code point>:
> "boulder" 7 25c6
> "ghost" 7 0020
> could become
> "boulder" 7 0030
> "ghost" 7 0039

Oh, only Unicode codepoints? Not Unicode strings of display width 1?

For example there are very few codepoints for "small letter q" with
additional accents but with combining characters you can almost have
as many different q's as you like.

[The Wumpus]

Awesome. For so long - after the seeming retirement of the devteam - the task of cleaning up and streamlining the source has seemed a tragedy of the commons. Congratulations on your fantastic achievement.

[Pasi Kallinen]

In rec.games.roguelike.nethack Daniel Thaler <dan...@dthaler.de> wrote:
> On 18.01.2012 03:31, Jason Cannon wrote:
>> Just gave it a try. Doesn't look like I'll be giving up my tty vanilla
>> just yet, but from looking at the changelog it has a lot of features I
>> like.
>>
>> A few questions:
>> --Since it will eventually have built in server support, were you
>> planning on having an automatic updater?
>
> The point of the server protocol is to eventually allow tiles clients to
> play on public servers. It will also make implementing a web client easier.
>

A small note here: It's possible to use tiles when playing on nethack.alt.org,
if you use the ebonhack frontend. (You also need to turn on vt_tiledata on NAO,
because otherwise ebonhack cannot distinguish between some glyphs)

[Jonadab the Unsightly One]

On Jan 17, 9:11 pm, Pat Rankin <r.pat.ran...@gmail.com> wrote:
> just use one of the platforms supported by nethack
> that have been cavalierly dismissed as obsolete.

Realistically, most of those _are_ obsolete, in the sense
of not having been supported by their own vendors for
a good number of years now (in most cases, at least
ten years, which is pretty near the upper limit on hardware
life expectancy in all but the most exotic circumstances).

There are a couple of them on the list that might be
arguable in this regard (e.g., VMS was still being actively
maintained less than ten years ago and was still supported
by the vendor rather more recently). Most of them are not.

They haven't just been "cavalierly dismissed" as obsolete.
They are, in fact, *highly* obsolete.

Now, I will be the first to admit that there are sometimes
very good reasons for using an obsolete system. (I myself
continued to use DOS 6.22 regularly until very late 1998
and occasionally until more like 2002, and at work I
supported some DOS-based software, and DOS in a VM,
until 2005.) But let's call these systems what they are:
legacy systems, maintained to support legacy software
that for one reason or another can't be upgraded yet.

> Continuing to support ancient systems and buggy
> compilers is one of nethack's strengths,

Up to a point, I would tend to agree. I don't like dropping
a system that only just recently became obsolete, for
example, because people need time to plan and implement
their upgrades. Sometimes it's not convenient to upgrade
until you replace the hardware. That can be several years.

But there's a limit to how long you can keep _upgrading_
really old systems. At some point it is what it is and you
keep it around to run the software it already has, but you
also need a modern system -- something with an operating
system that has received an update in the last decade --
if you want to run new software.

Apple made it very clear in early 2000 that Classic was
EOL, so Mac users have now had eleven full years to
gradually plan and implement their transition. (Granted,
many of them didn't start until after Adobe released the
Carbon version of Photoshop, but that's been a good
long while now, too.) This doesn't mean people have
to throw out their old Classic systems, but at some
point you can no longer view it as a viable substitute
for a modern computer. You keep it around mostly
for nostalgia, maybe, or to run really old software.

VMS, as I said, is more arguable.

If you're a BeOS user, my condolences. What
happened there was a major shame. Although,
I'd be kind of surprised if getting the *nix build
of NitroHack to build on BeOS required very
much more than porting the libraries on which
it depends. The code itself should, in theory,
not need a lot of changes. Probably. (This
would give you only a tty port, not a BeOS
native GUI version, though.)

As for obsolete compilers, I really don't see
the point, when you can just install gcc; if you
compile software on anything like a regular basis,
you need to do that anyway. Users who don't
compile software on a regular basis are probably
better served, in most cases, downloading a binary
that somebody else built.

> not a weakness that needs to be expunged
> in order to brag about how the amount of
> conditional code has been reduced.

Code maintainability does matter. A codebase
as old as nethack's probably could do with a
great deal of refactoring, unless I've missed my
guess. There's also the small matter of needing
to test any changes you make on those systems;
at this point most of them are no longer readily
available to test on.

Exactly where (or when) to draw the line is
arguable, but there are good reasons to draw
the line eventually.

[Jochen Spieker]

* Jukka Lahtinen:

> Patric Mueller <bh...@bigfoot.com> writes:
>
>> I think you mix up ASCII[*] map display and a TTY version. In Vanilla
>> several ports are display the map with ASCII even though it's really a
>> GUI and the rest of the interface is also using real GUI elements.
>

> I disagree.
> I play on Linux tty with the IBMGraphics option, and last time I tried
> it in a terminal window, it didn't look the same.
> (Yeah, some tweaking probably could bring the same font to the terminal
> window, but I prefer tty anyway.)

I think Patric referred GUI versions that are not running inside a
terminal, either VT or terminal emulators like xterm or gnome-terminal.

But either way: I disagree as well. I would prefer a "tty version"
running inside some terminal over a GUI version showing ASCII anytime. I
use GNU screen to permanently run a few applications and attach to that
session from several places. This doesn't work without a tty version.

J.
--
I cannot comprehend the idea of chemical and biological weapons.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>

[Doug Freyburger]

Daniel Thaler wrote:

> Pat Rankin wrote:
>
>> Easy: just use one of the platforms supported by nethack
>> that have been cavalierly dismissed as obsolete. Continuing to
>> support ancient systems and buggy compilers is one of nethack's
>> strengths, not a weakness that needs to be expunged in order to
>> brag about how the amount of conditional code has been reduced.

I actually help maintain a database on a VMS host. It's been over a
year since I logged in but it's still out there. I even help maintain a
database on a DGUX host. Both groups are hosed if they experience a
hardware failure. But both are ancient production systems with no games
loaded. The last time I had a VMS system as my primary login point the
only game on it was ADVENT.

Vanilla's portability was its strength but it means a different list
of systems now. Supporting Windows, Mac, several Linux distros and a
demonstration port to one of the UNIX systems is plenty of be called
portable today.

> Why would one even want to support ancient systems in new software?

I call DOS mode in Windows ancient. DOS mode in Windows is the way I
play vanilla now. I keep it on a USB stickwith my resumes and similar
private files. So I guess ancient is relative.

> And conversely, why should a person with an ancient system want to run
> new software on it?
> Supposing someone maintains an Atari or a C64 in a working condition,
> they would probably want to run period appropriate software on it. After
> all, running such a machine now is the computing equivalent of a
> renaissance reenactment.

At one point I had a Mac with a PC emulator with Windows 4 loaded in it.
Inside that Windows image I had the MyZ80 emulator with CP/M loaded. On
my CP/M "computer" I loaded some ancient accounting package and I
started it. I didn't actually use the accounting package for anything so
I was doing it like Renn Faire. I bet even with all of those levels of
emulation it ran the accounting package faster than on the original
hardware.

But see above for work I still do on a VMS and a DGUX system. Those
aren't reenactments. They do real live corporate work on those systems.
I've long since recommended they move to current systems but they keep
paying the consulting bill.

[Daniel Thaler]

On 18.01.2012 15:51, Patric Mueller wrote:
> Oh, only Unicode codepoints? Not Unicode strings of display width 1?
>
> For example there are very few codepoints for "small letter q" with
> additional accents but with combining characters you can almost have
> as many different q's as you like.

Internally, NitroHack uses unicode strings.
The config format doesn't support that though, because I found that more
than one character in the string doesn't work in most builds of ncursesw
(it seems to depend on the version or the configure flags) and isn't
supported at all in pdcurses.
If your ncursesw has CCHARW_MAX > 1, I'll extend the config format for
you ;-)

- Daniel

[Jonadab the Unsightly One]

On Jan 18, 11:00 am, pa...@alt.org (Pasi Kallinen) wrote:

> A small note here: It's possible to use tiles when playing
> on nethack.alt.org, if you use the ebonhack frontend.

This however has some rather significant limitations.

[Jonadab the Unsightly One]

On Jan 18, 12:32 pm, Doug Freyburger <dfrey...@yahoo.com> wrote:

> I actually help maintain a database on a VMS host. [snip]

> But both are ancient production systems with no games loaded.

Even if they did have games loaded, they probably wouldn't
be doing regular updates to more recent versions.

You don't do software updates on extremely old systems,
because if you keep doing updates sooner or later one of
them breaks something, and then you're up the proverbial
tributary. You maybe *think* you have the original media
for all the software that it had installed, but there's always
some little thing that you (or a former sysadmin) had
downloaded, some extra feature or update that was installed,
or one of the discs is no good any more, or something. It's
too risky. When you're maintaining a legacy system that
hasn't been supported by the vendor for years and years,
you keep things exactly as they are, change nothing, and
hope the hardware doesn't develop problems, because
replacement parts can be rather pricey, if they're even
available.

If you try to do otherwise, you invariably mess something
up and have to replace the system with something more
modern.

The exception is if the old system is emulated, but in that
case the host system is typically more modern, and you
can just install new software on that.

> Vanilla's portability was its strength but it means a different list
> of systems now. Supporting Windows, Mac, several Linux distros
> and a demonstration port to one of the UNIX systems is plenty of
> be called portable today.

There's also the increasing popularity of mobile device apps.
(This does not invalidate your point, of course; rather the
reverse, if anything.)

> I guess ancient is relative.

Somewhat. At the very least, "ancient" is context-sensitive.
An "ancient blog post" is one thing; "ancient software" is
another, rather older thing. An "ancient law" that has long
since ceased to be relevant to society but remain on the
books is older yet. The "ancient near east" is beyond that.


Besides, if you really wanted nethack to run on absolutely
positively every ancient system ever, you'd have to make
it run on the z-machine version 3.

http://www.gnelson.demon.co.uk/zspec/index.html

When it comes to portability to obscure systems, everything
else is just fooling around.

[Jonadab the Unsightly One]

On Jan 17, 8:05 pm, Daniel Thaler <dan...@dthaler.de> wrote:
> Congratulations, you found a bug.

I think I may possibly have found another one:
When performing certain non-movement actions
(e.g., unlocking a chest), the direction inputs for
up and down seem to get swapped.

Either that or I'm losing my mind.

[Daniel Thaler]

I was about to say yes, but testing reveals that you aren't.
Translating the symbolic direction constants from the key bindings into
actual z values was getting done the wrong way round ... oops.

The fix is in the repo and it looks like I'll be updating the binaries
on the weekend, as I've also fixed a crash-bug.

- Daniel

[Jorgen Grahn]

On Wed, 2012-01-18, Pat Rankin wrote:
> [crosspost to the rec.games.roguelike.development dropped]
>
> On Jan 16, 6:25 pm, GaryOlson <garyolson....@gmail.com> wrote:
>> [...] Would you like to download a copy of NitroHack and Play (y/n)?
>>
>> How can one say No to this question?
>
> Easy: just use one of the platforms supported by nethack
> that have been cavalierly dismissed as obsolete. Continuing to
> support ancient systems and buggy compilers is one of nethack's
> strengths

IMO it *was* a strength back in the mid-1990s. Quality software
covered Unix, VMS, Windows, Mac, Amiga and Atari ST. At least that was
how I felt.

Now? No, I cannot honestly say I think AmigaOS support is something I
desire. Portability to all modern Unixes (on any hardware), plus
whatever other people use, is enough for me.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Janis Papanagnou]

On 18.01.2012 19:48, Jonadab the Unsightly One wrote:
>

> Besides, if you really wanted nethack to run on absolutely
> positively every ancient system ever, you'd have to make
> it run on the z-machine version 3.
>
> http://www.gnelson.demon.co.uk/zspec/index.html
>
> When it comes to portability to obscure systems, everything
> else is just fooling around.

And I, reading that, thought you've meat Zuse's Z3 machines. LOL.
Man, *that* would qualify as ancient, 1941!

Janis

[Fabrizio J Bonsignore]

On Jan 17, 7:07 pm, Jonadab the Unsightly One

<jonadab.theunsightly...@gmail.com> wrote:
> graphics became easy (from a UI perspective; I have not
> yet reached the point where I think NetHack is easy to
> actually _win_).

[When I bought this DOS game for $2 in 1992 I thought it was useless.
When I found LEX GEP VEN ZEA, I thought the game was garbled. When I
confronted the first ghost I thought it was an indexing bug that lost
a character. When the ghost reappeared with my name I thought the
buffer had overflood. When I found the first non maze level I thought
developers did not care finishing a custom level. When the Wizard was
chasing me I thought: that monster must be broken! When the game told
me I had ascended I stashed the game because I thought half game was
not included in the floppy. NOW I wonder how I managed to come out of
it alive, though some patience later...]

Shouldnt the old bones and save format had been included in the save
file as well, like in RIFF files? A conversion utility? Would be a
matter of just synthesizing attributes for missing elements or playing
with an underdeveloped character... It would make for lossy backward
compatibility.

Danilo J Bonsignore

[Janis Papanagnou]

On 18.01.2012 13:10, Patric Mueller wrote:
>
> Note: I'm being an advocatus diaboli here.

Fine, so I take what you wrote with a good grain of salt. :-)

> When you don't change anything that is relevant to players (relevance
> in regards to code I discuss further down).

The point was; what base do you use to build new variants on?
Based on NH343? Or one of Unnethack, or Sporkhack; which one?
For a long-term lasting decision, one with basic architectural
improvements, compared to one or the other variant with their
"featuritis"? It would be fine to merge both; the game-play of
one of the variants - again, which one? - with the architecture/
interface changes.

> Or differently asked: What problems of Vanilla NetHack are solved by
> NitroHack that haven't been solved by the other variants? (It might be
> beneficial to tell what the problems of Vanilla are, I'm not sure that
> we all see the same problems)

I see problems of various sorts; for one the game-play related
(which are partly, though differently, addressed by Spork and Un),
and the interface/architecture issues. Only few issues mentioned
as game-play improvements and interface improvements haven't been
discussed in the past 15 years (or so) and were well known since
then. (I agree that people see different problems. In addition,
some people see only one type of problems.)

> The gameplay code didn't get changed significantly.

(Did it change at all in Nitro?)

> For example the triplication of code for the three similar but
> different cases "player attacking monster", "monster attacking
> player", and "monster attacking monster" is still there
> (uhitm.c/mhitu.c/mhitm.c).

Still bad. The whole NH code base, the kernel, needs improvement.
Nitro hasn't touched the game-play kernel, as far as I see.

> The myth of the hard to comprehend, pre-ANSI-C NetHack code is just

> that, a myth. [...]

The point is not restricted to pre-ANSI-C. The point is about C in
general, and about Nethack code specifically. If you say that NH is
not hard to comprehend then I have to assume that your focus had
been on the newer/better or on the more simple and regular pieces
of code; yes there's a range of different code quality, depending
on where you look into.[*]

> If you didn't understand the code of NetHack, you don't understand the
> code of NitroHack as well.

Probably.

> The newly written code, display archicture, the new load-save
> mechanisms, etc., is probably not as reliable as Vanilla's (you can't
> beat decade-old code that has been in used all the time) but I'm sure
> many bugs will quickly be ironed out. If people play it and report the
> bugs.

Agreed.

Janis

[*] YMMV. (Just for the record; I have been programming in C since
around 1985, with code of various quality, still doing C++ nowadays,
including "C++" code that actually is more like C than anything OO.)

[Janis Papanagnou]

On 19.01.2012 01:11, Fabrizio J Bonsignore wrote:
>
> [When I bought this DOS game for $2 in 1992 I thought it was useless.
> When I found LEX GEP VEN ZEA, I thought the game was garbled. When I
> confronted the first ghost I thought it was an indexing bug that lost
> a character. When the ghost reappeared with my name I thought the
> buffer had overflood. When I found the first non maze level I thought
> developers did not care finishing a custom level. When the Wizard was

> chasing me I thought: that monster must be broken! [...]

It seems like you hadn't read the Guidebook at that time. :-)

Janis

[Fabrizio J Bonsignore]

On Jan 18, 11:46 am, Jonadab the Unsightly One

<jonadab.theunsightly...@gmail.com> wrote:
>
> But there's a limit to how long you can keep _upgrading_
> really old systems.  At some point it is what it is and you
> keep it around to run the software it already has, but you
> also need a modern system -- something with an operating
> system that has received an update in the last decade --
> if you want to run new software.
>

[You forgot emulators ! What about Nethack micro for Atari emulation
on an Atari DS cartridge? Such things happen...]

Danilo J Bonsignore

[Martin Read]

Pat Rankin <r.pat....@gmail.com> wrote:
> Easy: just use one of the platforms supported by nethack
>that have been cavalierly dismissed as obsolete. Continuing to
>support ancient systems and buggy compilers is one of nethack's

>strengths, not a weakness that needs to be expunged in order to
>brag about how the amount of conditional code has been reduced.

It is, indeed, one of Nethack's strengths, and I respect and admire the
decision you and the rest of the DevTeam have made regarding keeping
that strength intact as best you can.

However, I equally think that it would be insane for the solitary or
very-small-team maintainer(s) of a typical Nethack variant to even
try to keep it running on any of those ancient systems and buggy
compilers, unless they personally have appropriate access to them. In
those circumstances, it is assuredly more honest and brave to say "no,
I'm not interested in making my variant work on those systems and
compilers".
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"

[Jonadab the Unsightly One]

On Jan 18, 7:33 pm, Fabrizio J Bonsignore <synto...@gmail.com> wrote:

> [You forgot emulators ! What about Nethack micro
> for Atari emulation on an Atari DS cartridge? Such
> things happen...]

Not at all. If you run the old software in emulation,
then you don't need to install new software on the
old system (within said emulation), because you can
either install the new software on the host system
(which is presumably more modern) directly or
simply emulate a more recent system to run the
more recent software.

The existence of emulators does not in any way
necessitate installing new software on old systems.
Rather, it enables you to run old software on a
newer system, which if anything is the opposite
effect. For example, one could run the original
rogue (if a copy of it can be found) in emulation,
even though your current computer is almost
certainly not compatible with the OS that rogue
originally ran under. (What did the first version
run on, anyway, 36-bit DEC hardware?)

[Martin Read]

Jonadab the Unsightly One <jonadab.the...@gmail.com> wrote:

[rogue]

>(What did the first version run on, anyway, 36-bit DEC hardware?)

I would have guessed either a PDP-11 (16-bit) or an early VAX (32-bit),
since it was written on BSD UNIX in 1980.

[Capt. Cave Man]

On Wed, 18 Jan 2012 12:47:47 +0100, Daniel Thaler <dan...@dthaler.de>
wrote:

>Why would one even want to support ancient systems in new software?

One of NetHack's world records is for how many different platforms one
can play the game on. I am surprised (flabbergasted even) that you are
unaware of NetHack's history.

It would be a sin to move toward something that would not fit on a
Timex Sinclair bare bones box... and play. I still want someone to
get it up on a PSP. Hell, a set-top DVD player should be able to play it
using the remote for an interface.

[Capt. Cave Man]

On Wed, 18 Jan 2012 12:47:47 +0100, Daniel Thaler <dan...@dthaler.de>
wrote:

>And conversely, why should a person with an ancient system want to run
>new software on it?

I want to play NetHack on my Alpha. I want to play it on my old Power
Mac. I want to play it under Mame emulator for DOS, and for a lot of the
other processors it emulates. Now THAT would be a cool project!

Upright arcade interface with NetHack. Put THAT in your bar and suck
quarters with it!

I have a graphing calculator I once thought might be cool if I could
bring up a NetHack session on it.

You have no idea. It is an obsession. It is like hoarding.
I collect slide rules, calculators, and computing devices, hard drives,
and versions of NetHack for those devices.

NetHack FOREVER and ON EVERYTHING!

That all I have to say about it (so far) Hehehehehehehe :-)

[Pat Rankin]

On Jan 18, 5:37 pm, Martin Read <mpr...@chiark.greenend.org.uk> wrote:

> Pat Rankin <r.pat.ran...@gmail.com> wrote:
>>     Easy:  just use one of the platforms supported by nethack
>> that have been cavalierly dismissed as obsolete.  Continuing to
>> support ancient systems and buggy compilers is one of nethack's
>> strengths, not a weakness that needs to be expunged in order to
>> brag about how the amount of conditional code has been reduced.
>
> It is, indeed, one of Nethack's strengths, and I respect and admire the
> decision you and the rest of the DevTeam have made regarding keeping
> that strength intact as best you can.
>
> However, I equally think that it would be insane for the solitary or
> very-small-team maintainer(s) of a typical Nethack variant to even
> try to keep it running on any of those ancient systems and buggy
> compilers, unless they personally have appropriate access to them. In
> those circumstances, it is assuredly more honest and brave to say "no,
> I'm not interested in making my variant work on those systems and
> compilers".

I don't disagree with any of that, but it doesn't change my
answer to why someone might respond "no" to "do you want to download
nitrohack?"

I've played and maintained and actively developed nethack for
over 20 years now, 98% of that on VMS (with a smattering of SunOS,
Ultrix, NeXTstep, and MacOSX, primarily to test whether building
from source worked--the last one is the only one of those I still
have access to). That includes the past 8 years (despite repeated
inaccurate assertions that development is dead and dev-team no
longer exists and so forth), and as recently as last month.

As it happens, the Alpha I've been using was disconnected
from the net four weeks ago. It's still running, but I can't get
to it anymore (unless I go there in person, but there wouldn't be
much point as far as nethack goes). So at the moment I'm stuck
using MacOSX on a laptop. Lack of expertise with the tools, small
screen, and cramped keyboard all conspire to make even simple things
take much longer than they should....

[Capt. Cave Man]

On 19 Jan 2012 01:37:04 +0000 (GMT), Martin Read

<mpr...@chiark.greenend.org.uk> wrote:

> In
>those circumstances, it is assuredly more honest and brave to say "no,
>I'm not interested in making my variant work on those systems and
>compilers".

Never heard of an emulator?

The master of all hardware (CPU) emulators: MAME

http://mamedev.org/

[Capt. Cave Man]

On Wed, 18 Jan 2012 17:38:10 -0800 (PST), Jonadab the Unsightly One
<jonadab.the...@gmail.com> wrote:

>For example, one could run the original
>rogue (if a copy of it can be found) in emulation,
>even though your current computer is almost
>certainly not compatible with the OS that rogue
>originally ran under. (What did the first version
>run on, anyway, 36-bit DEC hardware?)

Well, I could likely dig up the first PC platform version.

[Capt. Cave Man]

On 19 Jan 2012 01:44:27 +0000 (GMT), Martin Read

<mpr...@chiark.greenend.org.uk> wrote:

>Jonadab the Unsightly One <jonadab.the...@gmail.com> wrote:
>[rogue]
>>(What did the first version run on, anyway, 36-bit DEC hardware?)
>
>I would have guessed either a PDP-11 (16-bit) or an early VAX (32-bit),
>since it was written on BSD UNIX in 1980.

I'd bet it was 16 bit.

[Benjamin A. Schmit]

Must have meant that, too – the Z3 AFAIR was the first Turing-complete
computer, and therefore probably the first one that NetHack could
technically run on (provided it fits its memory, which it actually
doesn't). If you go back to that model, you're surely not fooling
around! ;-)

Benjamin


--
Seek freedom and become captive of your desires.
Seek discipline and find your liberty.
-- Frank Herbert, Dune Chronicles

[Daniel Thaler]

On 19.01.2012 03:40, Capt. Cave Man wrote:
> NetHack FOREVER and ON EVERYTHING!

You are correct about that.

Nothing I do affects your ability to play NetHack 3.4.3 on anything.
I merely have no intention of supporting systems that are so old that
the impose a disproportionate maintenance or code quality burden.

[Capt. Cave Man]

On Thu, 19 Jan 2012 12:07:57 +0100, Daniel Thaler <dan...@dthaler.de>
wrote:

It is ASCII. ANYTHING capable of displaying an ASCII array should be
able to run something as small as NetHack code.

You should code a baseline engine and ATTACH all of your add-on
'enhancements' such that they can be removed or the package be compiled
without them, if they are something that keeps this from running on
nearly everything. So all your net use code, etc. should be compile
config toggle switch for the user to DECIDE whether to include them or
not.

THAT would be the way to recode things.

Otherwise, it isn't "nitrohack", it essentially would be ExpungeHack.

What should be expunged is anything that would keep it from running on
the most basic machine capable of displaying an ASCII array.

Hell, I should almost be able to play it on the LCD screen of my G15
gaming keyboard! I should certainly be able to play it on the G19
keyboard! Heheheh! I just thought of another platform! Cool!
Thanks! That would be cool to be at a computer console doing work, but
be able to play NetHack in the little screen in the center of the
keyboard.

I mean, I even wanted to see the NH engine as a decision engine for a
graphical based gaming front end.

Don't change too much.

[Jonadab the Unsightly One]

On Jan 18, 9:35 pm, Capt. Cave Man

<ItIsSoEasyACaveManCanD...@upyers.org> wrote:

>   One of NetHack's world records is for how many different platforms one
> can play the game on.

Umm, like I said earlier, NetHack has nothing on Zork in this regard.

The thing is, though, Zork was never actively maintained (post-
release)
and upgraded with any new features. It just was (and is) what it was.

[Jonadab the Unsightly One]

I believe I may have discovered another bug, albeit
a purely cosmetic one.

If your inventory won't fit in the permanent inventory
window (at the right), the note at the bottom says
something like "(4 more omitted)". It counts funny.

For example, currently my inventory (if I use the
inventory command) looks like this (with trailing
whitespace stripped):
Inventory:

Coins '$'
$ - $ 432 gold pieces {4}
Weapons ')'
v - ) a dagger named LockBane {10}
K - ) a crude dagger {10}
Armor '['
a - [ an uncursed +2 pair of leather gloves (being worn) {10}
b - [ an uncursed +1 robe (being worn) {15}
L - [ a +0 orcish helm (being worn) {30}
Comestibles '%'
f - % an uncursed food ration {20}
g - % an uncursed apple {2}
h - % an uncursed orange {2}
i - % 2 uncursed fortune cookies {2}
k - % 7 food rations {140}
p - % a tripe ration {10}
N - % a cream pie {10}
R - % a tin {10}
U - % a tin {10}
Scrolls '?'
P - ? a scroll of identify {5}
W - ? a scroll called earth {5}
Potions '!'
C - ! a bubbly potion {20}
J - ! a clear potion {20}
O - ! a brown potion {20}
Q - ! a brilliant blue potion {20}
Rings '='
M - = a jade ring named b.C {3}
V - = a topaz ring named b.U (on left hand) {3}
Wands '/'
m - / a wand called striking {7}
S - / a wand of light {7}
Tools '('
z - ( a blindfold {2}
Gems '*'
B - * 2 white gems {2}

However, the permanent inventory in the window at the right
looks like this (trailing whitespace stripped again):
Inventory:
Coins '$'
$ - $ 432 gold pieces {4}
Weapons ')'
v - ) a dagger named LockBane {10}
K - ) a crude dagger {10}
Armor '['
a - [ an uncursed +2 pair of leather gloves (being worn) {10}
b - [ an uncursed +1 robe (being worn) {15}
L - [ a +0 orcish helm (being worn) {30}
Comestibles '%'
f - % an uncursed food ration {20}
g - % an uncursed apple {2}
h - % an uncursed orange {2}
i - % 2 uncursed fortune cookies {2}
k - % 7 food rations {140}
p - % a tripe ration {10}
N - % a cream pie {10}
R - % a tin {10}
U - % a tin {10}
Scrolls '?'
P - ? a scroll of identify {5}
W - ? a scroll called earth {5}
Potions '!'
C - ! a bubbly potion {20}
J - ! a clear potion {20}
O - ! a brown potion {20}
Q - ! a brilliant blue potion {20}
Rings '='
M - = a jade ring named b.C {3}
V - = a topaz ring named b.U (on left hand) {3}
Wands '/'
m - / a wand called striking {7}
(5 more omitted)

If you compare the two, only three actual inventory
items are omitted (err, well, 4 items in 3 stacks): a
wand of light, a blindfold, and 2 white gems. Does
the number 5 include the headings for Tools and
Gems, or does it just miscount by two?

[Doug Freyburger]

Jonadab the Unsightly One wrote:
>

> Umm, like I said earlier, NetHack has nothing on Zork in this regard.
>
> The thing is, though, Zork was never actively maintained (post-
> release)
> and upgraded with any new features. It just was (and is) what it was.

A few years ago I enountered a zip file of the ADVENT sources. In
Fortran. I downloaded the Fortran compiler extention to "gcc" and it
compiled. I played a game to confirm it worked. Yes it did.

[GaryOlson]

On Jan 18, 12:48 pm, Jonadab the Unsightly One

Wow, you just made me feel nostalgic and deja vu at the same time.
Been years since I read that document. Almost made me wish I was back
at University. Oh, but then I would be
stuck with Adventure on the green screen. Sigh....

Gary Olson

[GaryOlson]

Not naturally such things do not happen, no sir. That takes a special
kind of tool and spellbook.

Gary

[Capt. Cave Man]

On Thu, 19 Jan 2012 06:06:29 -0800 (PST), Jonadab the Unsightly One
<jonadab.the...@gmail.com> wrote:

>On Jan 18, 9:35 pm, Capt. Cave Man
><ItIsSoEasyACaveManCanD...@upyers.org> wrote:
>
>>   One of NetHack's world records is for how many different platforms one
>> can play the game on.
>
>Umm, like I said earlier, NetHack has nothing on Zork in this regard.

Zork is lame. "You see here a door..."

Please, exit through it.

>
>The thing is, though, Zork was never actively maintained (post-
>release)

BECAUSE IT WAS AND IS STUPID.

>and upgraded with any new features. It just was (and is) what it was.

Virtually nothing. I could have done better in basic. Hell, it would
probably be able to be implemented in a spreadsheet.

Your claim is about a NON program. Of course 400 bytes fits and runs
on anything.

But the stupid CRAP pales in comparison to ANY RPG ever. Then or
since.

MS Flight Simulator was a record holder for sales too for decades, but
I'm sure you'll have something that you'll claim refutes that one too.

[Patric Mueller]

Jonadab the Unsightly One <jonadab.the...@gmail.com> wrote:
>

> The existence of emulators does not in any way
> necessitate installing new software on old systems.
> Rather, it enables you to run old software on a
> newer system, which if anything is the opposite

> effect. [...]

Not necessarily. Sometimes it might be easier to replace hardware by
buying a mainstream system and let an emulator run on top of it. That
doesn't mean that this system doesn't get any updates.

For example in the Amiga community, after the hardware developers
finally went down, there were others that developed PPC hardware that
could run old 68k software on it with a builtin emulator and even
nowadays there are AmigaOS derived/inspired successors that can run
those old programs (some of them *are* still getting updates)
seamingless (like former OSX versions could run PPC binaries).


If vanilla still were up to date, including ancient features like
menucolors, statuscolors, pickup_thrown, etc. ... I would probably
still use the Amiga version for local play (and of course also for
online play if this were possible).

IMO the Amiga UI versoin is still the best mix between an mostly ASCII
map display and an unobtrusive GUI.

So I would also install any updates, if there were any.

Bye
Patric

--
NetHack-De: NetHack auf Deutsch - http://nethack-de.sf.net/

UnNetHack: http://apps.sf.net/trac/unnethack/

[Jonadab the Unsightly One]

On Jan 19, 10:52 pm, Capt. Cave Man

<ItIsSoEasyACaveManCanD...@upyers.org> wrote:
> Zork is lame. "You see here a door..."

> Virtually nothing. I could have done better in basic.

> Of course 400 bytes fits and runs on anything.

Either you're just trolling, or you've never actually
made a serious attempt to play Zork. (Granted,
it's not the best example of the genre, just the
oldest.) The most important difference between
Zork and Rogue is determinism: Rogue (and
subsequently NetHack) relies heavily on random
generation, so that the game is different each
time. Zork is in a number of ways a much better
game than Rogue the first time through, but the
whole thing is hand-crafted; it is not intended to
be played over and over and over again (well,
not after you finally _win_ anyway).

It would certainly be possible to implement a
roguelike game for the z-machine (actually, I'd be
rather surprised if it hasn't been done already), but
I'm pretty sure NetHack 3.anything won't fit, or at
least, not without a lot of custom optimization.
The lack of random-access writable secondary
storage is the biggest hurdle. (The z-machine
is designed to run on systems that don't have
a disk, so it can use a cartridge drive or a tape
drive or whatnot, depending on platform.) The
limited amount of writable memory could also be
a problem: a program of nethack's complexity
could fit (at least in z8, if not z5; probably not in
z3), but it would have to be designed from the
ground up to be miserly with writable memory
and leave everything in read-only memory that
can be. NetHack wasn't designed that way,
because by the time NetHack came along it
was generally assumed that computers had
disk drives.

Today, it is generally assumed that computers
have multiple gigabytes of RAM, so NitroHack
can do things that NetHack could not do twenty
years ago, like, for example, keep all the levels
in memory while playing (to prevent trickery,
among other reasons) and write actions to disk
as they happen (so that recovery in the event of
a crash or power outage is easy and automatic).

Technology does gradually advance over time.

[Capt. Cave Man]

On Sat, 21 Jan 2012 07:23:02 -0800 (PST), Jonadab the Unsightly One
<jonadab.the...@gmail.com> wrote:

> The
>limited amount of writable memory could also be
>a problem: a program of nethack's complexity
>could fit (at least in z8, if not z5; probably not in
>z3), but it would have to be designed from the
>ground up to be miserly with writable memory
>and leave everything in read-only memory that
>can be. NetHack wasn't designed that way,
>because by the time NetHack came along it
>was generally assumed that computers had
>disk drives.

I played NetHack on an XT with no 'disk drive'. That is if your
ambiguous term choice refers to hard disks. Nethack was certainly around
before they were.

It fit on a 720kB floppy (likely smaller as well) and loaded on a DOS
with far less than that available. After that, it is run on the machine.

[Capt. Cave Man]

On Sat, 21 Jan 2012 07:23:02 -0800 (PST), Jonadab the Unsightly One
<jonadab.the...@gmail.com> wrote:

>
>Today, it is generally assumed that computers
>have multiple gigabytes of RAM, so NitroHack
>can do things that NetHack could not do twenty
>years ago,

That is so silly. The program does not require that (multiple
Gigabytes of RAM), and I can safely say that without even looking.

Oh boy, it logs moves and has network hooks and controls. Big deal.
Not.

I'll bet it would run on an old 386 with windows 3.11 on it or an early
version of RedHat, as long as it had its network tools working.

[Patric Mueller]

Capt. Cave Man <ItIsSoEasyAC...@upyers.org> wrote:
> On Thu, 19 Jan 2012 12:07:57 +0100, Daniel Thaler <dan...@dthaler.de>
> wrote:
>
>>On 19.01.2012 03:40, Capt. Cave Man wrote:
>>> NetHack FOREVER and ON EVERYTHING!
>>
>>You are correct about that.
>>
>>Nothing I do affects your ability to play NetHack 3.4.3 on anything.
>>I merely have no intention of supporting systems that are so old that
>>the impose a disproportionate maintenance or code quality burden.
>
> It is ASCII. ANYTHING capable of displaying an ASCII array should be
> able to run something as small as NetHack code.

It's more than that. You need at least a minimal terminal for the tty
version and this *is* the most basic UI version (not necessarily the
simplest version because of lots of compatibility kludges).

> You should code a baseline engine and ATTACH all of your add-on
> 'enhancements' such that they can be removed or the package be compiled
> without them, if they are something that keeps this from running on
> nearly everything. So all your net use code, etc. should be compile
> config toggle switch for the user to DECIDE whether to include them or
> not.
>
> THAT would be the way to recode things.

Maybe in the 80s where computer memory was more precious than human
life time.

The bare NetHack engine isn't even that small, it was quite large for
the 80s and the early 90s. Just remember that the DOS version had to
jump through really ugly hoops to get it running in 640KB.

> Otherwise, it isn't "nitrohack", it essentially would be ExpungeHack.
>
> What should be expunged is anything that would keep it from running on
> the most basic machine capable of displaying an ASCII array.

"ExpungeHack" because it contains anything you think that's not part
of the bare NetHack engine?

[Patric Mueller]

Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 18.01.2012 13:10, Patric Mueller wrote:
>>
>> Note: I'm being an advocatus diaboli here.
>
> Fine, so I take what you wrote with a good grain of salt. :-)
>
>> When you don't change anything that is relevant to players (relevance
>> in regards to code I discuss further down).
>
> The point was; what base do you use to build new variants on?
> Based on NH343?

NetHack 3.4.3 is an unmaintained piece of code (sorry, even if the
DevTeam has a bugfixed 3.4.4 or a further developed 3.5.0, the actual
state of Vanilla to everybody else is "unmaintained"), full of known
bugs that aren't fixed.

If you use it as a base (and really want to improve the code base
instead of just trying out some ideas) you would need to get as many
bugfixes from bilious, SporkHack, UnNetHack, AceHack and maybe even
Slash'Em. This is easier because all of the variants are using public
source code repositories and this is actually what Daniel did.

> Or one of Unnethack, or Sporkhack; which one?

Or AceHack. Well, it depends on what you want to do.

*Warning*: Extremely concise summary of the variants changes
following. Might be highly inaccurate and subjective.

I'd say that SporkHack isn't the ideal base as Derek mostly changed
the game play and only fixed the worst bugs as fixing bugs would have
been "the DevTeam's job" as he put it. But lots of the game play
changes in SporkHack are worth considering when doing a fork.

Slash'Em is out of question, in addition to its own bugs, it has
mostly the same bugs as Vanilla and added lots of stuff, many features
being buggy and/or inconsistent.

AceHack, in a nutshell, has lots of bugfixes and dramatically changed
the tty interface, making the interface and the game more resilient to
user mistakes (like not being able to hit floating eyes). Although,
some would say it made the game less nethacky.

The developer of AceHack stated that he intends to merge NitroHack and
AceHack, which is not a bad thing but means that the current code of
AceHack is more in flux than usual. Probably not the best time right
now to fork of from AceHack until the dust has settled.


UnNetHack, has also lots of bugfixes (actually NitroHack, AceHack,
NAOHack and UnNetHack have at least fixed the same crash bugs because
of shared code, some less important bugfixes are also shared).

It has an improved tty UI, some additional content (although not going
overboard as Slash'Em does) like an additional race, more variety with
levels, or some new rooms (e.g. instrument shops or dilapidated
armouries) and added features for offline and online use (like the
HTML dumplogs or the IRC notification features.


I'd say that NitroHack and AceHack are visually further away from
vanilla's tty version, NitroHack currently having exactly and AceHack
mostly vanilla's game play. UnNetHack is visually more like vanilla
and its game play is not as far from vanilla as Slash'Em's or
SporkHack's.

UnNetHack and AceHack have some really advanced features like
autoexploring or showing prizes automatically when walking over them
in a shop.

Overall, I'd say AceHack and NitroHack have in parts more
revolutionary changes of NetHack (in game play terms they are more
conservative than the DevTeam itself), whereas UnNetHack and SporkHack
have more evolutionary changes and Slash'Em is Slash'Em.

But even with small evolutionary changes you can veer away quite a bit
from the origin. I wouldn't be surprised if internally UnNetHack is as
far away from vanilla as AceHack and NitroHack but for that I'd have
to closely examine the source code.

Which of those versions is better suited for your needs depends on
what you want to do. I can only say what I would have done if AceHack
or NitroHack already existed when I started UnNetHack. If NitroHack
would have already existed for a while I'd probably used it as a base.

Although that would have come at the cost of not being able to use GUI
ports with ease and more work for integrating existing patches (and
maybe not being able to use some patches at all).

> For a long-term lasting decision, one with basic architectural
> improvements, compared to one or the other variant with their
> "featuritis"? It would be fine to merge both; the game-play of

You still haven't played any variants? I don't think you can then
fairly judge the changes in forks and dismiss them as "featuritis".

By only reading about the changes you can't get how it feels playing.
I made this mistake myself several times thinking that some feature in
a variant wasn't necessary.

> one of the variants - again, which one? - with the architecture/
> interface changes.
>
>> Or differently asked: What problems of Vanilla NetHack are solved by
>> NitroHack that haven't been solved by the other variants? (It might be
>> beneficial to tell what the problems of Vanilla are, I'm not sure that
>> we all see the same problems)
>
> I see problems of various sorts; for one the game-play related
> (which are partly, though differently, addressed by Spork and Un),

For the time being NitroHack solves *no* game-play related problems.
Daniel said on IRC that he'll eventually wants to change stuff but not
before he has got his code more stable first.

> and the interface/architecture issues. Only few issues mentioned
> as game-play improvements and interface improvements haven't been
> discussed in the past 15 years (or so) and were well known since
> then. (I agree that people see different problems. In addition,
> some people see only one type of problems.)

This "well-known" is something else than "implemented and
play-tested".

Talk is cheap and we've seen this several times.

How many times has scoring been discussed in RGRN? There have been
several proposals, some more, some less elaborate. But what difference
does it make if there is never any code to use it? Even if there is
code as patches on bilious that doesn't change much as long as they
don't get applied and play-tested.

Sometimes you have to take a stand. Sometimes you to take
responsibility by actually implementing something.


Why don't we already have a already have a successor to NetHack 3.4.3?

I don't think the DevTeam is really to blame. They are under no
obligation to release a new version and frankly, if you look at the
releases since 3.3.0, it's unlikely that 3.5.0 would have been
significantly different from 3.4.3.

But if vanilla players don't play variants and don't give feedback,
how are variant developers going to know what changes to keep and what
change to throw out again?

I guess this has been impeding the development of a successor more
than the silence of the DevTeam.

>> The gameplay code didn't get changed significantly.
>
> (Did it change at all in Nitro?)

Not yet.

[Corey]

To: Patric Mueller
Re: Re: NitroHack 4.0.0 release
By: Patric Mueller to rec.games.roguelike.nethack on Sat Jan 21 2012 11:47 pm

nethack versions move so slow because it's a hobby.
s

[Janis Papanagnou]

On 21.01.2012 17:37, Capt. Cave Man wrote:
>
> I played NetHack on an XT with no 'disk drive'. That is if your
> ambiguous term choice refers to hard disks. Nethack was certainly around
> before they were.
>
> It fit on a 720kB floppy (likely smaller as well) and loaded on a DOS
> with far less than that available. After that, it is run on the machine.

Hmm.. - are you sure? I seem to recall that at least the NH 3.0.9 Atari
version to have filled a 1.44 MB floppy completely, but memories are faint.

Janis

[Capt. Cave Man]

I ran it (maybe it was 'hack', before it became nethack) on a diskless
(hard drive) XT with an integrated amber display and floppy drive, and
the XT came out years before the 1.44 hit the scene. Whatever was out at
that time. I think it was 3.0

There were others as well. What was it? Rogue? I can't remember any
more. I played about three different ASCII based games at the time.

[Jonadab the Unsightly One]

On Jan 21, 5:47 pm, Patric Mueller <bh...@bigfoot.com> wrote:

[Regarding which nethack or variant codebase to
use as a starting point for new variants...]

> If you use it as a base (and really want to improve the code
> base instead of just trying out some ideas) you would need
> to get as many bugfixes from bilious, SporkHack, UnNetHack,
> AceHack and maybe even Slash'Em.

Indeed. This is one reason the NitroHack release excites
me: it appears to have made a really good start on that.

> I'd say that SporkHack isn't the ideal base as Derek mostly changed
> the game play and only fixed the worst bugs as fixing bugs would have
> been "the DevTeam's job" as he put it. But lots of the game play
> changes in SporkHack are worth considering when doing a fork.

Of particular interest in SporkHack is the move from boolean
intrinsics (particularly resistances) to the ability to be a little
more or less cold resistant -- cumulatively. I haven't played
enough SporkHack to be certain whether I think this is worth
importing into other variants and/or vanilla, but I fully intend
to play enough SporkHack at some point to form an opinion
on that.

> Slash'Em is out of question,

Slash'Em is what it is. Again, it may have some ideas
that are worth looking at, but as a whole it is not suited
to being a starting point for (most) other variants. If
nothing else, it's too hard for most players -- as if plain
old NetHack isn't hard enough.

(Actually, I have thought about a "beginner's nethack"
that keeps most of the same basic mechanics as
vanilla but does things to make the early game easier
for beginners to survive -- e.g., make the Dungeons of
Doom have more levels before Delphi and delay
introduction of various monster types until a few levels
deeper in the mine, so the player can work up to them
more gradually. Adding spoilers to the "encyclopedia
entries" is another possible step such a variant could
take. Dropping a guaranteed chest #named "starter
kit" on DL1 with some random wands and tools and
potions, a random co-aligned or unaligned artifact, an
amulet of life saving, and a blessed scroll of identify
might allow beginning players to experiment with
some items they might not otherwise get to see in
the early game. A "tile-based" version that uses
colored-ASCII-character "tiles" but has tooltips that
indicate what each tile represents might also aid the
learning process. Clearly most of these changes
would not be wanted in vanilla, but for a beginner
they might be significantly preferable to explore
mode or save scumming.)

> AceHack, in a nutshell, has lots of bugfixes and dramatically changed
> the tty interface, making the interface and the game more resilient to
> user mistakes (like not being able to hit floating eyes). Although,
> some would say it made the game less nethacky.

I suppose I should look at that one at some point. Less is
said about it in the wiki than some of the others, so I sort
of figured it was a more minor variant and hadn't gotten
around to looking at it yet. Perhaps that was a mistake.

> Which of those versions is better suited for your needs depends on
> what you want to do. I can only say what I would have done if AceHack
> or NitroHack already existed when I started UnNetHack. If NitroHack
> would have already existed for a while I'd probably used it as a base.
>
> Although that would have come at the cost of not being able to use GUI
> ports with ease

I suspect GUI clients for NitroHack may be forthcoming
eventually. Or a web-based client. Or both.

I am, of course, merely speculating, however.

[Jonadab the Unsightly One]

On Jan 21, 9:28 pm, Janis Papanagnou <janis_papanag...@hotmail.com>
wrote:

> Hmm.. - are you sure?

I've concluded that he's just trolling. If he can't figure
out that a machine that "only has a cartridge" wouldn't
have a 720K floppy drive, he's not trying to understand
or respond to what's being said. He's just trying to get
people riled.

It's no longer working, at least as far as I'm concerned.

[Capt. Cave Man]

On Sun, 22 Jan 2012 10:19:07 -0800 (PST), Jonadab the Unsightly One
<jonadab.the...@gmail.com> wrote:

>On Jan 21, 9:28 pm, Janis Papanagnou <janis_papanag...@hotmail.com>
>wrote:
>
>
>> Hmm.. - are you sure?
>
>I've concluded that he's just trolling.

I've concluded that you are a goddamned idiot. You prove that you were
not even around then, and you want to tell folks about how you know how
it had to be run?

I was there. I played it every night. There was no 1.44MB floppy at
that time, you stupid PUTZ!

> If he can't figure
>out that a machine that "only has a cartridge" wouldn't
>have a 720K floppy drive,

You're a goddamned idiot.

> he's not trying to understand
>or respond to what's being said. He's just trying to get
>people riled.

Looks like your pathetic jabs has me riled. You dispute what I say?
THEN YOU RESPOND TO ME! You retarded motherfucker!

>
>It's no longer working, at least as far as I'm concerned.

Your fucking brain no longer works, if it ever did.

[Capt. Cave Man]

And on that note, dipshit, I had an Atari as well, and I DID also have a
floppy drive with that too!

Your brain "only has a cartridge".

[Daniel Thaler]

So here it is, the first bugfix release.

Unfortunately there were lots of bugs, and some of them affected the
save format. Saves from 4.0.0 will not load on 4.0.1 (there is an
outside chance that a game that didn't encounter any bugs will load on
4.0.1, but don't count on it)

In order to allow people to finish their games on nitrohack.org, the
site has both versions running in parallel. The new client and server
use a different port, so this should just work automatically.

Changes:
Alex Smith (3):
Fix reversal of up and down ladders
Fix off-by-one error in farlooking traps
Merge branch 'master' of https://github.com/DanielT/NitroHack

Daniel Thaler (57):
create the unix socket as world writeable
server: better log messages for auth failures
fix a crash in the final disclosure if creating the dump file fails
fix a crash when displaying a remote top ten list
don't reenable the cursor unconditionally when leaving a menu
only add log entries about new connections if any data is received
completed games should be marked as done, not crashed
make the filename buffers in dgn_main.c large enough to hold paths
Warn players about plain text password trnasmission
fix race in unix socket auth
The shell script should set LD_LIBRARY_PATH to LIBDIR, not BINDIR
don't retry sending connect and disconnect commands
fix a potential crash bug in cmd_display_objects when handling
lots of items
fix inverted up/down at direction prompts
call nonl(), so that ^J and return have distinct key codes
reduce the number of screen updates by using wnoutrefresh
fix the replay status display when the widow frame is disabled
replay timetest uses gettimeofday instead of clock_gettime
put location info under the inventory in the sidebar
don't use MSG_NOSIGNAL, mask SIGPIPE explicitly instead
fix '<' and '>' as targets for travel and teleport
allow ESC when choosing a travel destination
fix multi-move commands g and G
update the saveinfo utility to work with the current save format
start a new line in the message area for every action
show "Bad command" in the message area rather than in a dialog
Fix ^J vs return on windows, too
add pdcurses' alternate names for the even keypad keys to the
default keymap
improve shift+<hjkl> cursor movement at the edge of the map
fix secondary accel keys in menus
improve the key binding dialog slightly
don't count headings when showing "X more omitted"
fix an error in the binary save format which could cause crashes
show fewer error messages if a binary save has the wrong format
correct directory separator for Windows
change save parsing so that toggling autopickup doesn't break saves
increase the length of the basename array in dgn_main, too
fix topten on windows
fix: go up/down without suitable stairs should not use a move
accept command input when multi > 0
implement server messages
make ist possible to dismiss menus with space
relax server side command parsing for better forward compatibility
fix carrying containers up or down stairs
generate a log message for an improbable client/server
communication error
catch SIGSEGV on the server in order to report an error before
exiting
allow cancelling farlook with ESC
limit the number of times the client will attempt to resend a command
zero out the struct sigaction used to ignore SIGPIPE
don't show a useless second message after server errors
don't attempt to save the game after sigsegv
make it possible to view running games (but not "live")
Move version information into the public header
return the server version in the authentication response
be paranoid about the json parsing mode
update nsis script to make record and logfile writable on windows
bump the version number of the debs

- Daniel

[Janis Papanagnou]

On 21.01.2012 23:47, Patric Mueller wrote:

> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>
>> The point was; what base do you use to build new variants on?
>> Based on NH343?
>
> NetHack 3.4.3 is an unmaintained piece of code (sorry, even if the
> DevTeam has a bugfixed 3.4.4 or a further developed 3.5.0, the actual
> state of Vanilla to everybody else is "unmaintained"), full of known
> bugs that aren't fixed.

We agree in this point.

> [...]

>> Or one of Unnethack, or Sporkhack; which one?
>
> Or AceHack. Well, it depends on what you want to do.

(I don't know that one.)

> [...]

>
> Which of those versions is better suited for your needs depends on
> what you want to do. I can only say what I would have done if AceHack
> or NitroHack already existed when I started UnNetHack. If NitroHack
> would have already existed for a while I'd probably used it as a base.

We seem to agree here as well.

> Although that would have come at the cost of not being able to use GUI
> ports with ease and more work for integrating existing patches (and
> maybe not being able to use some patches at all).

Wasn't the [modified] interface done for the sake to ease GUI development?
Sure you cannot use it with code that is using the, umm.., existing, erm..,
"interface". But my question for the decision would be; which has the most
flexible code architecture for that purpose.

But, of course, Nitro came "too late", so we have a couple variants already
that are based on Vanilla.

>
>> For a long-term lasting decision, one with basic architectural
>> improvements, compared to one or the other variant with their
>> "featuritis"? It would be fine to merge both; the game-play of
>
> You still haven't played any variants? I don't think you can then
> fairly judge the changes in forks and dismiss them as "featuritis".

First; be assured that the quoted term "featuritis" was not meant to be
disrespectful. I used it to make two factors apparent; one is the focus
on the game features (including balance issues), the other more subtle
one was the (in the IT world well known) competition - which leads to
branches, and away from a common base for any New Vanilla. You may
disagree, but based on my (limited) IT developing experience I think
the first step is to "fix" the architecture, then come the features on
top of it. This all, of course, if supposed that development of Vanilla
can be considered effectively dead already.

Just BTW. I have played (or rather tested) Un and Spork (I even posted
about it here, but probably you don't remember since it was some time
ago).

>
> By only reading about the changes you can't get how it feels playing.
> I made this mistake myself several times thinking that some feature in
> a variant wasn't necessary.

Again, that was not my point. I'd rather assumed that every feature,
specifically in Spork and Un, had been carefully considered by their
designers.

> [...]

> For the time being NitroHack solves *no* game-play related problems.
> Daniel said on IRC that he'll eventually wants to change stuff but not
> before he has got his code more stable first.

Yes.

> [...]

> Why don't we already have a already have a successor to NetHack 3.4.3?
>
> I don't think the DevTeam is really to blame. They are under no
> obligation to release a new version and frankly, if you look at the
> releases since 3.3.0, it's unlikely that 3.5.0 would have been
> significantly different from 3.4.3.
>
> But if vanilla players don't play variants and don't give feedback,
> how are variant developers going to know what changes to keep and what
> change to throw out again?

I've got the feeling that quite many players want some common base to
play and discuss. Variants deviate (and distract) from that path. I
think that is the reason why variants are (supposedly) not played as
much as Vanilla, and that's probably the reason why you get not as much
feed-back as you would like. Honestly, I don't think that your variant
(or Spork) is inferior to Vanilla; as far as I've seen both are better.

But, again, "which one" could/should we foster as a New Vanilla base?
AFAIR someone wrote that Derek doesn't maintain his variant any more.
Will you maintain UnNethack in, say 3 years? All seems to boil down to
having a canonical code-base and some Devteam or developer community we
can rely on.

>
> I guess this has been impeding the development of a successor more
> than the silence of the DevTeam.

You are right where you wrote above that the Devteam is not to blame;
rather the opposite is the case, given what they have done for us all
for many years. A big "Thanks for all the fish! - but now it's time to
leave..." (or so).

(WRT impeding factors I seem to have a (slightly?) different weighing.)

Janis

[Jonathan Ellis]

"Janis Papanagnou" <janis_pa...@hotmail.com> wrote in message
news:jfk7o5$jn9$1...@news.m-online.net...

Except...

WHAT DevTeam? Where are they? Do they still post in this group? Do they
still identify themselves as Nethack Dev Team?

Or should we accept their (unspoken) resignation?

Will anybody stick their head above the parapet, declare themselves the new
maintainer or devteam, and dare to actually call their next version "Nethack
3.5.0" or "Nethack 4.0.0"?

I know that this happened at least twice, and possibly more, with Angband,
so maybe it can happen with Nethack. Maybe it *needs* to. Obviously I can't
do it myself because I have neither ability, time or inclination to write
code or maintain a game (and I'm still reasonably happy playing the current
version)...

-- Jonathan.

[Janis Papanagnou]

On 24.01.2012 00:24, Jonathan Ellis wrote:
>
> WHAT DevTeam? Where are they? Do they still post in this group? Do they
> still identify themselves as Nethack Dev Team?

As far as I've been told most of them are not that busy WRT Nethack
development, currently[*]. At least Pat Rankin occasionally posts here.
It's indeed a very good question whether "they still identify themselves
as Nethack Dev Team"; an authoritative statement[**] would certainly be
appreciated by the community.

> Or should we accept their (unspoken) resignation?

That's what I'd assume after so many years of silence.

> Will anybody stick their head above the parapet, declare themselves the new
> maintainer or devteam, and dare to actually call their next version "Nethack
> 3.5.0" or "Nethack 4.0.0"?

Don't know. In the past, at least, there have been some folks asking for (or
even demanding) that option.

> I know that this happened at least twice, and possibly more, with Angband,

(I don't know about the Angband history and evolution.)

> so maybe it can happen with Nethack. Maybe it *needs* to. Obviously I can't
> do it myself because I have neither ability, time or inclination to write
> code or maintain a game (and I'm still reasonably happy playing the current
> version)...

That's true for most people. But I think that, e.g., the variant developers
would have appreciated to build their system upon a fixed version instead of
fixing themselves a lot of the bugs that are reported to be officially fixed.

Janis

[*] For debatable values of "currently".

[**] Coupled with public access to all the reported and implemented source
code fixes would be even better.

[Edoardo Spadolini]

On 18 Gen, 03:11, Pat Rankin <r.pat.ran...@gmail.com> wrote:
> [...] Continuing to
> support ancient systems and buggy compilers is one of nethack's
> strengths, not a weakness that needs to be expunged in order to
> brag about how the amount of conditional code has been reduced.

This is why every feature added since 2004 hasn't compromised
portability!

[Capt. Cave Man]

Yep. I little, character based game should be a little, character based
game.

It is (or should be) like a credo or something.

[Rob Cypher]

On Mon, 16 Jan 2012 05:17:07 +0000 (UTC), Daniel Thaler
<dan...@invalid.address.com> wrote:

>Hi everyone!
>
>This is the initial public release of NitroHack, a fork of NetHack.

Is there a GUI version due? Too used to graphics to go back to ASCII.

[Daniel Thaler]

On 27.01.2012 08:49, Rob Cypher wrote:
> Is there a GUI version due? Too used to graphics to go back to ASCII.

It's planned, but not yet in progress.

[Capt. Cave Man]

On Fri, 27 Jan 2012 18:00:18 +0100, Daniel Thaler <dan...@dthaler.de>
wrote:

>On 27.01.2012 08:49, Rob Cypher wrote:
>> Is there a GUI version due? Too used to graphics to go back to ASCII.
>
>It's planned, but not yet in progress.

I get a crash whenever I forget and use the escape key during play. At
the start menu, it exits the game, but in-game it crashes in Windows7.

In a menu or inventory screen, etc. I should use the enter key to clear
the screen, but sometimes I instinctually use escape. That's with 4.01.
Also had one at the tombstone screen, because I hit the escape key.

You should also change that start-up / menu screen so that those big
yellow letters have the nitrohack version in there somewhere (at the base
of one of the letters). I have no way of knowing if I have the most
recent release or not. I looked around for files that would declare it
too. Maybe I didn't look hard enough.

Is this thing giving a greater occurrence of food rations? I noticed
that, but it may have been simple happenstance in that one game (now
dead).

[Patric Mueller]

Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 21.01.2012 23:47, Patric Mueller wrote:
>> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>
>> Although that would have come at the cost of not being able to use GUI
>> ports with ease and more work for integrating existing patches (and
>> maybe not being able to use some patches at all).
>
> Wasn't the [modified] interface done for the sake to ease GUI
> development?

Yes, but that doesn't mean that GUI development with vanilla is hard,
just that NitroHack made the UI abstraction better and introduced
builtin client/server support.

Remember that there already existed a server and client implementation
for vanilla/Slash'Em called nhproxy that worked on the current UI
interface.

But NitroHack made network support easier and probably also better by
completely separating client and server code. For example with
vanilla's UI abstraction layer, you can't get a complete list of what
is at a given location unless you access the global level object. But
that is of course not possible over the network. I don't know how
nhproxy solved that, maybe they didn't at all which would mean that
you couldn't show different images if the player stands on a fountain
or the floor as you would get the glyph for the player.

> Sure you cannot use it with code that is using the, umm.., existing, erm..,
> "interface".

You don't need to put quotes around the word "interface". :)

It is an interface and it is quite good at what is wants to do, that
is, abstracting away the inner working of what essentially one could
call the NetHack gaming engine. It is actually one of the better parts
of the vanilla code.

You can see that if you think about all the different GUIs that are
out there:
http://nethackwiki.com/wiki/GUI

On that page there are alone 13 ports for widely different machines
(e.g. Amigas, PCs, Unix, Android and iOS devices) or different display
interfaces (e.g. ncurses and again Android and iOS devices).

All those ports mostly add code in a new directory in win. There is
really few code that needs to be changed in src, in the main NetHack
code directory, to hook up a new GUI to the existing code.

Vanilla's GUI abstraction is not perfect, for example the whole status
line code is not abstracted. Every port has the status line code for
tty builtin and most just ignore and are doing something on their own
to display the status lines.

>> You still haven't played any variants? I don't think you can then
>> fairly judge the changes in forks and dismiss them as "featuritis".
>
> First; be assured that the quoted term "featuritis" was not meant to be
> disrespectful.

Oh, I didn't take it as disrespectful.

> I used it to make two factors apparent; one is the focus on the game
> features (including balance issues),

But any Vanilla replacing successor would do that, too, wouldn't it?

We shouldn't confuse Vanilla's slowing of development as a sign for
careful development. For the most part the DevTeam used to be rather
conservative in adding features to NetHack.

But you can't say that 3.4.3 is feature-complete. Besides the various
bugs that needs fixing you can look at NAO's version of features
missing in Vanilla. NAO's diff to Vanilla is now at a whooping 600 KB
and this only includes stuff that doesn't break bones and save
compatibility.

> the other more subtle one was the (in the IT world well known)
> competition - which leads to branches, and away from a common base
> for any New Vanilla.

This is not necessarily the case. Those branches don't need to live
singular lives.

Despite the different design goals, SporkHack, UnNetHack, NAO and
AceHack have been sharing code ever since and also NitroHack drew on
that code.

There is no single repository with a common base of the current forks
but the common base is also not just Vanilla's code. It's distributed
across the current forks. This is not an ideal situation but this is
nowadays more often the case than a centralized common repository.

> You may disagree, but based on my (limited) IT developing experience
> I think the first step is to "fix" the architecture, then come the
> features on top of it.

This is not wrong but there are a lot of issues that complicate fixing
the architecture. You would first have to agree upon that the
architecture needs fixing or which parts need fixing. You can also
easily argue that the architecture doesn't only need fixing but a
complete rewrite in a better suited language, although the way
NetHack is written, you'd need serious refactoring for that.

And usually you don't "fix the architecture" just to have the
architecture fixed. This would only result in unnecessary work. You
have certain goals you want to achieve (this may include something
abstract like "better extensibility for later code changes") and you
change the code for that.

So I don't disagree completely but I also don't agree completely. :)

> This all, of course, if supposed that development of Vanilla
> can be considered effectively dead already.

I think for anybody doing any NetHack-related coding it's the best
advice not to wait for the DevTeam.

> Just BTW. I have played (or rather tested) Un and Spork (I even posted
> about it here, but probably you don't remember since it was some time
> ago).

Oh, yes, I didn't remember that.

>> But if vanilla players don't play variants and don't give feedback,
>> how are variant developers going to know what changes to keep and what
>> change to throw out again?
>
> I've got the feeling that quite many players want some common base to
> play and discuss. Variants deviate (and distract) from that path. I
> think that is the reason why variants are (supposedly) not played as

If this is the case with the NetHack community then this is a rather
peculiar feature of it.

Looking for example at the Dungeon Crawl Stone Soup forum you see
people discussing new features in new releases without a problem. Even
though their public servers keep hosting 5 different versions DCSS (I
think the oldest is even older than NetHack 3.4.3).

Thinking that forks deviate from a common path is understandable but
that is not really the case. They are actually extending the path laid
down by Vanilla (which is normal for any fork, not only NetHack forks)
but with other projects the main branch might overtake them again
(which is no longer happening with Vanilla).

So we are left with some forks that start off where Vanilla stopped.
That's all.

> But, again, "which one" could/should we foster as a New Vanilla base?
> AFAIR someone wrote that Derek doesn't maintain his variant any
> more.

That doesn't prevent you from playing it. That only means you should
not expect bugfixes and new features from it. Which is essentially the
same situation as with Vanilla only Derek is up front about the state
of development.

> Will you maintain UnNethack in, say 3 years?

Who knows? But I'm maintaining it right now. But there won't be
another release of Vanilla.

> All seems to boil down to having a canonical code-base and some
> Devteam or developer community we can rely on.

Come on. Relying on the DevTeam? The DevTeam hasn't maintained NetHack
in 8 years. Accumulating bug reports and fixes and not releasing them
is not "maintaining". Having to "rely" on them is a joke by now.

But yes, there is a developer community. For Vanilla that means
some bugfixes and improvements for NAO but mostly it means development
happens in forks and vanilla-only players don't benefit from that
development.