Some random thoughts about weights in various roguelikes...

I like to have weights of items displayed, so that you always
have an indication of the haptic experience and the expectable
effects. (There's always been some emphasis or attention to
support senses; various visible effects and acoustic effects
to name some.) Some variants show the weight of items or you
can configure the game to show them.

I like to see the weight, in total, of individual items, and
whether they are in inventory or in a container. I wonder why
they don't show the objects' weight in Hack'EM if they are in
a container, I think in Slashem they did and that was very
convenient.

In a Gnoll game I see weights in 'lbs'. For me plain numbers
(without units) would already be okay. But if one decides to
use units I'd prefer to use some international standard like
the Metric System (instead of an anglo-american speciality).
Even though that 'lbs'-"Pound" is [now] defined, historically
we had dozens of different "Pound" units, which makes it even
a (IMO) less suited unit generally.

Janis

On Friday 9 June 2023 at 09:33:30 UTC, Janis Papanagnou wrote:
> Some random thoughts about weights in various roguelikes...
>
> I like to have weights of items displayed, so that you always
> have an indication of the haptic experience and the expectable
> effects. (There's always been some emphasis or attention to
> support senses; various visible effects and acoustic effects
> to name some.) Some variants show the weight of items or you
> can configure the game to show them.
>
> I like to see the weight, in total, of individual items, and
> whether they are in inventory or in a container. I wonder why
> they don't show the objects' weight in Hack'EM if they are in
> a container, I think in Slashem they did and that was very
> convenient.
>
> In a Gnoll game I see weights in 'lbs'. For me plain numbers
> (without units) would already be okay. But if one decides to
> use units I'd prefer to use some international standard like
> the Metric System (instead of an anglo-american speciality).
> Even though that 'lbs'-"Pound" is [now] defined, historically
> we had dozens of different "Pound" units, which makes it even
> a (IMO) less suited unit generally.
>
> Janis

Sir, Gnollhack can show or hide weights of objects (shown by default), and if shown, then the weights can be expressed in British Imperial System or in Système International Metrique Decimal (British by default).

In the interface for Microsoft Windows, and via emulators for Apple Macintosh and for Linux, those choices are accessed via the 'O' options command for the current game, or via configuration data set for future games.

In the interface for Google Android Linux and for Apple IOS (IPad tablets or IPhone mobile telephones), they are accessed via the menu for options and settings (a green symbol located near the top right of the screen).

In both types of interface the variables are called 'Detailed weights' and 'Metric system', and they are Boolean, meaning that they can only be either 'on' or 'off', without any further values or arguments. No other systems for measuring weights are offered, only British Imperial, International Metrique Decimal, or else no weights shown.

As You correctly inform, different regional or historical systems of units frequently have or had different values for units with similar names, such as 'league', 'mile', 'pound', 'ounce', 'area', 'alqueire', 'arroba', 'fanega' and a long list of others, which force the need of expressing the region and the historical time in which that unit is or was used, and working with conversion tables or even with entire books detailing each unit and its accepted standard values.

Fortunately, players of Gnollhack have at their disposal a rich list of options and settings for improving in the game.

Thanks for the information concerning GnollHack! - One question...

On 09.06.23 21:09, CSS Dixieland wrote:
>
> Sir, Gnollhack can show or hide weights of objects (shown by
> default), and if shown, then the weights can be expressed in British
> Imperial System or in Système International Metrique Decimal (British
> by default).

Are the numbers used for Imperial vs. Metric the same or calculated
by the factor (~0.4536) from Real Life, or is an approximation (say,
0.5) used?
(I am asking because it might be irritating to have crooked values.
Personally I'd be satisfied with integral numbers based on some
elementary unit of "1".)

Being exact with weight measurement of items (i.e. reflecting their
known nature) might be an issue in case of quantization being used
for derived quantities; in Nethack (and derived variants) there's a
burden state adjusted at fixed weight values. - Given the Real Life
orientation with units in GnollHack I suppose the burden state and
[reduced] speed effects are a linear function of the carried weight?

Janis

On Friday 9 June 2023 at 20:18:09 UTC, Janis Papanagnou wrote:
> Thanks for the information concerning GnollHack! - One question...
> On 09.06.23 21:09, CSS Dixieland wrote:
> >
> > Sir, Gnollhack can show or hide weights of objects (shown by
> > default), and if shown, then the weights can be expressed in British
> > Imperial System or in Système International Metrique Decimal (British
> > by default).
> Are the numbers used for Imperial vs. Metric the same or calculated
> by the factor (~0.4536) from Real Life, or is an approximation (say,
> 0.5) used?
> (I am asking because it might be irritating to have crooked values.
> Personally I'd be satisfied with integral numbers based on some
> elementary unit of "1".)
>
> Being exact with weight measurement of items (i.e. reflecting their
> known nature) might be an issue in case of quantization being used
> for derived quantities; in Nethack (and derived variants) there's a
> burden state adjusted at fixed weight values. - Given the Real Life
> orientation with units in GnollHack I suppose the burden state and
> [reduced] speed effects are a linear function of the carried weight?
>
> Janis

Excellent question, Mister Janis Papanagnou. The calculating function rounds the results presented to the player, but not so grossly as just declaring one pound to be equal to 0.5 Kilogrammes. The internationally accepted value for exact conversion is to take one pound as equal to 453.59237 grammes (or 453592.37 milligrammes, or 453592370 microgrammes).

One ounce (the sixteenth fractional part of one pound) is taken as 28.349523 125 grammes (or 28349.523125 milligrammes, or 28 349523.125 microgrammes, or 28349 523125 nanogrammes). In both units, pound and ounce, we are referring to the Avoirdupois scale, not to the Troy scale. As an example, an apple weighs in the game 5 ounces, which has been rounded to 142 grammes. Five ounces is about the average weight of an apple in the real world, thus so far the game emulates the real world as much as reasonably possible. You can perceive that the original system of units was the British, giving the integral number of five ounces for an apple. If the original system had been the Metrique Decimal, the corresponding integral number for an apple would probably have been programmed as of 150 grammes.

However, the game does not emulate the real world exactly. For one thing because in the real world not every apple weighs exactly 5 ounces (indeed, it would be difficult to find an apple weighing EXACTLY 5 ounces). Nor of course 142 grammes, nor 150 grammes, nor any other value. The value programmed into the game is only an average abstraction, for convenience.

And besides that, there is also the problem of emulating natural processes and representing them mathematically, without excessively deep immersion into irrational numbers such as Pi, which probably go to infinity (hundreds of millions of decimal places have been calculated for Pi and there seems to be no end, thus the task as been parked as very likely an impossibility).

For example, in the real world increments or decrements are often gradual, without abrupt changes of state at specific boundaries of transition (except in the probabilistic world of sub-atomic particles and discrete energy packets, but I am not going to explain Quantum Theory here). In real life, a halterophilist does not feel significant difference between 87 pounds and 88 pounds, but in the virtual world of Gnollhack (or of any other computer game) changes are abrupt at specific points. In the game that I am playing, my hero is now carrying a weight of 513 ounces, rounded to 15 Kilogrammes (I am used to work with the two systems, to me it does not matter which one is used), and he is 'unencumbered'. The level of unencumbrance goes in Gnollhack up to 87 pounds, rounded to 39 Kilogrammes. In the game, the hero feels 'unencumbered' if carrying 86 pounds and fraction, almost 87 pounds. But when reaching or slightly passing 87 pounds, he SUDDENLY feels 'encumbered' (other words can be used, the game uses 'burdened'). Certainly that is not at all what happens in the real world, in which the feeling of weight increase is gradual, not abruptly felt at a specific point (and nothing felt just a little before that point). No game that I know addresses this issue of reproducing the real world exactly. It would complicate programming, and in my view, it would be unnecessary.

In a serious simulation yes, strenuous programming efforts are made for approaching the real world very closely, because even slight differences in calculated results are cumulative, and the final result, after millions of iterations, might be significantly different. But not in a game. Important as it is for us dungeoners, after all it is just a game, not a highly critical application.

Receive my Salute of Respect, Sir. 🫡

On 10.06.23 01:52, CSS Dixieland wrote:
> [...]
>
> However, the game does not emulate the real world exactly. [...]

Oh, please note, that was neither my assumption nor intention...

>
> And besides that, there is also the problem of emulating natural
> processes

....and this also not. (In short: just to get closer, without cost
or effort.)

> and representing them mathematically, without excessively
> deep immersion into irrational numbers such as Pi, which probably go
> to infinity (hundreds of millions of decimal places have been
> calculated for Pi and there seems to be no end, thus the task as been
> parked as very likely an impossibility).

A lot of things are quantized in roguelikes, I am well aware of that.
(As far as I recall former releases of Nethack didn't even include a
floating-point library; everything was done with integer arithmetic,
i.e. quantified. - Not sure about contemporary releases.)

I was just focusing on the weight issue. You can base it on integer
arithmetic (as I previously said, based on an atomic unit of 1 and
integral multiples for heavier items). There would not necessarily
be an informal scale (unburdened/burdened/stressed/...) necessary,
although for informative purposes you can make a projection of the
internal weights to these descriptions. But the speed reduction does
also not necessarily depend on these descriptions, rather it could be
derived from the actual "exact" weight. While this is not reflecting
Real Life it would still be more accurate than making speed be based
on the few informal burden-levels. The fact that the movement system
is also quantified in integral units at some point doesn't matter; it
would still reflect the speed degradation better if it's based on the
weight numbers.

>
> For example, in the real world increments or decrements are often
> gradual, without abrupt changes of state at specific boundaries of
> transition [...]. [...] Certainly that is not at all what happens in
> the real world, in which the feeling of weight increase is gradual,
> not abruptly felt at a specific point (and nothing felt just a little
> before that point). No game that I know addresses this issue of
> reproducing the real world exactly.

The intention was not "reproducing the real world exactly". (IMO it
could have been made just a bit "better" without loss or effort.)[*]

> It would complicate programming, and in my view, it would be unnecessary.

In your final statement I disagree. As I described the approach above
the programming would not become more complicated (it's at best even
simpler to calculate the speed gradually based on weight instead of
using an extra calculated informal burden state value). Well, but yes,
it can be argued whether it's necessary - What is really necessary? -,
but if it's even a simpler (yet more accurate) model, a quantization
of finer granularity (using weight units instead of burden states)
would make game mechanics yet more realistic without additional cost.

(All of that of course just in my book, mileages may probably vary.)

Janis

[*] After all it was only a question about GnolllHack's implemented
degree of change, not really a feature request. I am playing variants
that rely on legacy functionality; and I don't mind the implementation.
But if a new variant decides to make the weight system more complicated
(by introducing lbs/kg and conversions) it could have of course also
streamlined the depending factors. That's why I was curiously asking.

On Fri, 9 Jun 2023 11:33:24 +0200, Janis Papanagnou wrote:

> Some random thoughts about weights in various roguelikes...
>
> I like to have weights of items displayed

+1

> In a Gnoll game I see weights in 'lbs'. For me plain numbers
> (without units) would already be okay.

Units are handy for messages and NPC interaction. If a shopkeeper (for
instance) advertises a product, "it weights xxx <insert weight units>"
sounds more natural than "it weights xxx".

> But if one decides to use units I'd prefer to use some international
> standard like the Metric System (instead of an anglo-american
> speciality). Even though that 'lbs'-"Pound" is [now] defined,
> historically we had dozens of different "Pound" units, which makes it
> even a (IMO) less suited unit generally.

Real-world units induce real-world expectations. That quite often doesn't
work well with game mechanics. (A dragon scale mail weights only twice
as much as some small amulet??) It, IMHO, is therefore better to stick
with fictional units. (Like zorkmids for coin.)

Several sources on the Internet discuss fictional unit systems. The
first decision should probably be, whether just a single unit shall be
used or if a complex scaling system of several units will work better.
In Nethack and its variants, a single unit (IMHO) should suffice.

Dealing with fraction of the base unit isn't really catchy. Apart from
the weight of zorkmid gold pieces, the base unit therefore has to be
comparable to the lightest objects in the game: gems.

Fictional (and medieval) units often base on "real" world objects. The
best fitting fictional weight units I read on the Internet carry such
a reference: "pebble" or "grain". Short form for the former could be
"pb", short form for the latter either "gr" or "gn". Native English
speakers likely have even better suggestions, especially when including
Old English in the search for a suitable term.

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"? =
===============================================================--(Oops!)===

On 10.06.23 06:44, B. R. 'BeAr' Ederson wrote:
> On Fri, 9 Jun 2023 11:33:24 +0200, Janis Papanagnou wrote:
>
>> Some random thoughts about weights in various roguelikes...
>>
>> I like to have weights of items displayed
>
> +1
>
>> In a Gnoll game I see weights in 'lbs'. For me plain numbers
>> (without units) would already be okay.
>
> Units are handy for messages and NPC interaction. If a shopkeeper (for
> instance) advertises a product, "it weights xxx <insert weight units>"
> sounds more natural than "it weights xxx".

I didn't think of that; currently it probably wouldn't matter - are
there variants that verbalize talk about weights? -, but for possible
extensions it certainly makes sense.

>
>> But if one decides to use units I'd prefer to use some international
>> standard like the Metric System (instead of an anglo-american
>> speciality). Even though that 'lbs'-"Pound" is [now] defined,
>> historically we had dozens of different "Pound" units, which makes it
>> even a (IMO) less suited unit generally.
>
> Real-world units induce real-world expectations. That quite often doesn't
> work well with game mechanics. (A dragon scale mail weights only twice
> as much as some small amulet??) It, IMHO, is therefore better to stick
> with fictional units. (Like zorkmids for coin.)

I agree. Even the relative values are sometimes strange in relation of
one item to another, more so if you can compare with Real Life units.
It's anyway amazing how much loot these adventurers in roguelikes can
carry! ;-)

>
> Several sources on the Internet discuss fictional unit systems. The
> first decision should probably be, whether just a single unit shall be
> used or if a complex scaling system of several units will work better.

> In Nethack and its variants, a single unit (IMHO) should suffice.

I agree. (In GnollHack it's probably just done to support players of
more cultures [after having introduced a real life unit].)

>
> Dealing with fraction of the base unit isn't really catchy. Apart from
> the weight of zorkmid gold pieces, the base unit therefore has to be
> comparable to the lightest objects in the game: gems.

I agree.

>
> Fictional (and medieval) units often base on "real" world objects. The
> best fitting fictional weight units I read on the Internet carry such
> a reference: "pebble" or "grain". Short form for the former could be
> "pb", short form for the latter either "gr" or "gn". Native English
> speakers likely have even better suggestions, especially when including
> Old English in the search for a suitable term.

I think that 'pebbles' would indeed (for a couple reasons) be an
excellent idea for a weight unit. (There's also other historic units
that they said were derived from real life units, like the carat.[*])

Janis

[*] The (as quite constant assumed) weight of the carob tree seeds.

Yes, Mister Papanagnou, Your information about integer arithmetic calculations versus floating point calculations is correct, but it is to be expected that it had to be so, considering the reality of the times. There were a few experimental dungeon games for computer in the 1970s, though the game that became seminal (to the extent of even giving its own name to the whole genre, often known as 'Rogue-like' games) was the game called Rogue, released in 1980. Successor dungeon games were more or less inspired on Rogue, but not directly derived from it in terms of source code, because the code of Rogue was proprietary and could not be legally copied.

This is a non-exhaustive list of the most important microprocessors released in the 1980s or shortly before, which shows the hardware for which most of those successor games were programmed:

1979: Zilog Z-8000 of 16 Megabytes of 16 bits.

1979: Motorola 68000 of 16 Megabytes of 16 bits at 8 Megahertz (in Apple, using a version of Unics operating system). Made of 70 000 elements, it multiplied two numbers of 16 bits in less than four microseconds.

1979: Intel 8088 of 1 Megabyte of 8 bits (at this time Intel Corporation was late in the competition).

1980: National 16032 of 16 Megabytes of 32 bits.

1981: Intel 80186 of 1 Megabyte of 16 bits (Intel was beginning to catch up with other competitors).

1981: Hewlett-Packard Superchip of 64 Megabytes of 32 bits. Composed of 450 000 elements with MOS transistors, it could multiply two numbers of 32 bits in less than two microseconds.

1982: Intel 80286 of 16 Megabytes of 32 bits (incorporated to IBM 'Personal Computer', AT series).

1982: Motorola 68010 of 64 Megabytes of 32 bits.

1984: Intel 80386 SX of 4 Gigabytes of 16 bits (with the success of the 'Personal Computer' of IBM, Intel had established a strong presence in the microprocessor industry).

1984: Intel 80386 DX of 4 Gigabytes of 32 bits (incorporated to IBM 'Personal Computer', to Compaq 386, and to various other microcomputers).

1984: Motorola 68020 of 4 Gigabytes of 32 bits at 16 Megahertz.

1987: Motorola 68030 of 4 Gigabytes of 32 bits at 32 Megahertz (an improvement over the 68020, which also put Motorola as a strong player in the microprocessor industry).

1989: Intel 80486 DX (with integrated mathematic co-processor) and 80486 SX (with separate mathematic co-processor) of 4 Gigabytes of 32 bits at 32 Megahertz.

1989: Motorola 68040 of 4 Gigabytes of 32 bits at 40 Megahertz.

I do not think necessary to give the list of the most important microprocessors that were released in the 1990s, because by the 1980s dungeon games ('Rogue-likes') were already firmly established.

As You mention, the first implementations of such games used integer arithmetic calculations. Later, one implementation after another began using floating point, as it became available in the hardware. It was of course possible to do floating point calculations by cumbersome software methods, and it was in fact done so for critical applications, but to my knowledge, it was not done for games. It is enormously easier to do floating point calculations in the hardware, once such hardware became available, therefore game programmers introduced floating point only when hardware engineers had introduced floating point. Which is, I presume, perfectly understandable.

The procedure that You have delineated is in theory feasible, but I am not going to implement it.

As I have made clear, in my view only critical applications such as aeronautical traffic control, or other potentially dangerous activities, need to emulate the real world very closely, because an error may have catastrophic consequences. Or for scientific or military purposes, but not just for games, with the possible exception of war 'games' introducing an enormous quantity of variables, seriously used by military commands for trying to determine the probable outcome of a real military conflict.

You are certainly free to disagree with me, Sir, and very free to do YOUR OWN IMPLEMENTATION.

Most dungeon games are open source, meaning that You can obtain and modify the source. Using a different programming language if You prefer, taking the source just as a procedural guide for Your own implementation. Be sure to study carefully the licence or other related legal documents if You decide to do it, especially if You wish to offer Your implementation for distribution in public servers.

For me, Nethack and its derivatives are well as they are. I do not deny that Your idea would improve the game, for it surely would improve it, but I am of the view that the result is not worth the effort of programming with so much detail, and I am widely considered a perfectionist. I have some reason to suppose that most programmers will probably agree with my position. There are many thousands of lines in each of the various source codes, and just a tiny error may have fatal consequences.

Programming errors (endearingly known as 'bugs') may be difficult to detect.. Virtually every game (and most other non-critical applications) is released to the public with some undetected errors in it, with the hope that feedback from users, or the analysis of logs sent to the programming team after a crash, will help in diagnosing the problem and eventually correcting it. This is considered perfectly natural, that is why the first releases are clearly labelled as alpha or beta 'pre-releases'.

Players obtain a non-commercial game for free, and it is expected from them to help in detecting, simply by playing the game, any programming errors that might have passed so far undetected. Most certainly it is so with a game of enormous complexity, such as Nethack and every one of its derivatives. It cannot be in another manner. After all, enthusiast players are the best beta testers.

Thanks for your thorough reply.

On 10.06.23 14:02, CSS Dixieland wrote:
> Yes, Mister Papanagnou, Your information about integer arithmetic
> calculations versus floating point calculations is correct, but it is
> to be expected that it had to be so, considering the reality of the
> times. There were a few experimental dungeon games for computer in
> the 1970s, though the game that became seminal (to the extent of even
> giving its own name to the whole genre, often known as 'Rogue-like'
> games) was the game called Rogue, released in 1980. Successor dungeon
> games were more or less inspired on Rogue, but not directly derived
> from it in terms of source code, because the code of Rogue was
> proprietary and could not be legally copied.

I think what you wrote is partly not quite accurate or even wrong.
I'm too lazy to look up every detail again; what I say is (partly)
from memory (so take that with a grain of salt if you like)...

WRT rogue; developed at Berkeley and distributed with BSD Unix, it
spread extremely fast. (A _commercial_ DOS version was later ported
and sold, separately. You were probably referring to that version.)

Many years ago I collected some information that you find here:
http://rogue.gridbug.de/

It's unlikely that the reason for not using FP was lack of processor
features. After all we linked FP libraries to the programs where we
wanted them. My personal _thought_/_opinion_ at that time was that
since the game is widely discrete (in time and space models) there's
no need to use FP, thus saving space - which was precious and rarer
at that time! In the source code I could see at some places strange
routines handling with integers in a complex way to implement the
counterpart of a [simple] FP function (ISTR, e.g., an integer sqrt()
function).

> [snip processor history]
>
> I do not think necessary to give the list of the most important
> microprocessors that were released in the 1990s, because by the 1980s
> dungeon games ('Rogue-likes') were already firmly established.
>
> As You mention, the first implementations of such games used integer
> arithmetic calculations. Later, one implementation after another
> began using floating point, as it became available in the hardware.
> It was of course possible to do floating point calculations by
> cumbersome software methods, and it was in fact done so for critical
> applications, but to my knowledge, it was not done for games. It is
> enormously easier to do floating point calculations in the hardware,

If you have a FP library it's just function calls, it's not difficult.

You don't address the FP hardware directly from your source code. The
compiler creates code to call functions or to use FP opcodes supported
by the CPU or later by the (nowadays typical) FP co-processors. ISTR
that I could omit linking some "lib???.a" if I had not used the 'float'
data type in a C program. That way we could reduce the executable size.

> once such hardware became available, therefore game programmers
> introduced floating point only when hardware engineers had introduced
> floating point. Which is, I presume, perfectly understandable.

I used always (also around 1980) FP in programming where appropriate.
(In a fully discrete game it would not be necessary, but if it solves
an implementation task it's easy to use. In some places they _should_
have used FP but didn't; e.g. the first arcade tennis games for TV
could be held in a ping-pong stable state without doing anything; a
negative and certainly undesired effect of rough quantification.)

>
> The procedure that You have delineated is in theory feasible,

(Not only in theory.)

> but I am not going to implement it.

(Erm... - no one asked you to do so. - I also wasn't even aware that
you are a programmer/maintainer of some variant; if that's what you
imply here. - I was merely discussing features.)

> [...]
>
> You are certainly free to disagree with me, Sir, and very free to do
> YOUR OWN IMPLEMENTATION.

(Wow! - Why are you shouting? - I find it always amazing when lacking
arguments result in strawman arguments and non-topical red herrings.
We should probably stop our discussion since you appear to have got
offended by my disagreement to one of your statements? - It wasn't
intended, be assured.)

>
> Most dungeon games are open source, meaning that You can obtain and
> modify the source. Using a different programming language if You
> prefer, taking the source just as a procedural guide for Your own
> implementation. [...]

In reply to a maintainer of a variant - who showed the same counter
reflex - I already said that I'm not inclined to publish yet another
variant; I think we already have more than necessary. And I have other
priorities than adding one more variant to that huge roguelike zoo.

My own preference would be if some concepts/variants would converge
to one better variant and reduce the size of the zoo. But maintainers
often seem to be reluctant to give up their "baby"; I understand that.
So we see variants that differ in number and layout of levels, names
of artifacts, number of items and monsters, etc. *shrug*. </rant>

>
> For me, Nethack and its derivatives are well as they are. I do not
> deny that Your idea would improve the game, for it surely would
> improve it, but I am of the view that the result is not worth the
> effort of programming with so much detail, and I am widely considered
> a perfectionist. I have some reason to suppose that most programmers
> will probably agree with my position. There are many thousands of
> lines in each of the various source codes, and just a tiny error may
> have fatal consequences.

Reading this; you doesn't seem to be a software engineer, are you?
What you write makes no sense in the context that we were discussing;
adding, merging, refactoring, and testing code, is a regular business
of software engineers. Variant developers do that all the time. This
is no exception for the (quite primitive) change we have been talking
about in this thread.

> [ snipped some final fluffy digression about bugs/testing ]

Janis

On Saturday 10 June 2023 at 14:44:53 UTC, Janis Papanagnou wrote:
> Thanks for your thorough reply.

[snipped a lot of REALLY FLUFFY digressions, as I have more important things to do than non-sense chatting]

No, Sir, I am not wrong, I was referring to the commercial proprietary version of Rogue. I know that the University of California at Berkeley had its own distribution of the game, as it also had its own operating system (BSD), and other software.

And no, I was not shouting as if offended when I suggested that you can create your own implementation. I made the words outstanding simply for emphasis, although I suppose that if you really wanted to add another baby to the zoo, you would have already done it, in these more than forty years since the original release of Rogue.

Different programmers have different reasons for doing or not doing something. Whether because of lacking processor capabilities (the appropriate instruction set), or lacking floating point libraries, or lacking space, or even lacking willingness to tackle the problem (in spite of being "just function calls" and "not difficult"), every one has his reasons. Do not project your own reasons as necessarily valid for other programmers, even though instructions in a high level language of course do not address hardware directly. The hardware only understands low level machine code.

Sir, I am afraid that you have a subtle way of expressing your 'reasons' by insidious claims of your arguments being 'better' than the arguments of others. Or even being the 'only' arguments worth considering. My arguments are valid FOR ME, as Herre Soren Kierkegaard would have said. Whether 'straw' arguments or not, they are still valid for me. You can of course see things differently, it is pointless to discuss that.

I imagine that every one has the same counter reflex when defending what he loves. That maintainer of the other implementation, and myself, and every one else. If we have a point in which you and I can agree, it is that we have too many babies in the zoo as it is already. But every creator loves his own creature. It is understandable.

This is the end of my 'fluffy digressions' about 'software engineering' with ye. Live your life in your manner, and let others live theirs. Conversation ended. For ever.

On Friday, June 9, 2023 at 4:33:30 AM UTC-5, Janis Papanagnou wrote:
> Some random thoughts about weights in various roguelikes...
>
> I like to have weights of items displayed, so that you always
> have an indication of the haptic experience and the expectable
> effects. (There's always been some emphasis or attention to

I need the same information but I use what's available. The simplest way is to fill up on rocks, then subtract 200 - the number of rocks being carried is the overall weight. You can figure out individual weights from there.

Maybe we will have this information soon. I think it was fairly recently that we could id loadstones without picking them up. There is constant improvement.

What I'm not clear on -- there's a 3.6.7 and a 3.7.0. Aren't these two fairly dissimilar? Maybe the 3.7.0 is unofficial.

On Sunday, June 11, 2023 at 3:57:53 PM UTC-7, Yosemite Sam wrote:
[...]
> What I'm not clear on -- there's a 3.6.7 and a 3.7.0. Aren't these two
> fairly dissimilar? Maybe the 3.7.0 is unofficial.

3.6.7 is the most recently released version. 3.7 has not been
released and probably shouldn't be referred to as '3.7.0' yet
even though that will eventually be it's version number (most
likely).

The development source code for to-be-3.7 is freely available at
https://github.com/NetHack/NetHack (also at sourceforge.net
but I never remember the specific URL). It can be viewed with
a browser and is most easily accessible for download if you
use the 'git' tool. Prebuilt binaries aren't being supplied while
it is still evolving.

https://hardfought.org builds it and makes it available to play
via ssh or a web browser. They update their copy of the source
weekly (or thereabouts).

> I like to see the weight, in total, of individual items, and
> whether they are in inventory or in a container. I wonder why
> they don't show the objects' weight in Hack'EM if they are in
> a container, I think in Slashem they did and that was very
> convenient.

The option you are referring to is "invweight", and it's definitely in 3.6/hackem/evil.

In Friday, July 14, 2023 at 1:57:33 AM UTC-7, Erik L wrote:
>> I like to see the weight, in total, of individual items, and
>> whether they are in inventory or in a container. [...]
>
> The option you are referring to is "invweight", and it's definitely
> in 3.6/hackem/evil.

Presumably 3.6 refers to nethack. The option there (and still in
to-be-3.7) is "wizweight" and only available in wizard mode.

On Friday, July 14, 2023 at 7:13:44 PM UTC+2, Pat Rankin wrote:
> In Friday, July 14, 2023 at 1:57:33 AM UTC-7, Erik L wrote:
> >> I like to see the weight, in total, of individual items, and
> >> whether they are in inventory or in a container. [...]
> >
> > The option you are referring to is "invweight", and it's definitely
> > in 3.6/hackem/evil.
> Presumably 3.6 refers to nethack. The option there (and still in
> to-be-3.7) is "wizweight" and only available in wizard mode.

Ah thanks for the clarification, I see now that EvilHack got invweight from FIQhack, but it is available in normal modes too.

On Friday, July 14, 2023 at 12:13:44 PM UTC-5, Pat Rankin wrote:
> In Friday, July 14, 2023 at 1:57:33 AM UTC-7, Erik L wrote:
> >> I like to see the weight, in total, of individual items, and
> >> whether they are in inventory or in a container. [...]
> >
> > The option you are referring to is "invweight", and it's definitely
> > in 3.6/hackem/evil.
> Presumably 3.6 refers to nethack. The option there (and still in
> to-be-3.7) is "wizweight" and only available in wizard mode.

Zork didn't list weights alongside inventory items. Someone will walk past your screen and with all those numbers, think you are using a calculator.

An explanation of where the information comes from?

Seeing inside sacks without opening them?

This is best for Wizard Mode.

On 20.07.2023 21:30, Yosemite Sam wrote:
> On Friday, July 14, 2023 at 12:13:44 PM UTC-5, Pat Rankin wrote:
>> In Friday, July 14, 2023 at 1:57:33 AM UTC-7, Erik L wrote:
>>>> I like to see the weight, in total, of individual items, and
>>>> whether they are in inventory or in a container. [...]
>>>
>>> The option you are referring to is "invweight", and it's definitely
>>> in 3.6/hackem/evil.
>> Presumably 3.6 refers to nethack. The option there (and still in
>> to-be-3.7) is "wizweight" and only available in wizard mode.
>
> Zork didn't list weights alongside inventory items. Someone will
> walk past your screen and with all those numbers, think you are using
> a calculator.

(There once was a cartoon (I think on UserFriendly[*] that depicted
Nethack declared as a visual packet management system by an admin
when his boss came in.)

There's nothing wrong with numbers (or colors, or...). After all we
need some (abstract) replacement for the sensual experiences missing
in text based computer games.

>
> An explanation of where the information comes from?

From contact. If you lift a bag (known or unknown) you should get
a weight indication (including its contents). Same with individual
items.

>
> Seeing inside sacks without opening them?

No, there should have happened a haptic experience before disclosure.

Some variant (don't recall which it was) worked like that (at least
partly; don't recall the details).

Janis

[*] All these links on nethack.org are sadly broken now.