In a shop I picked up a locked chest and got this information:

Unpaid Tools
U - a chest 11 zorkmids
Unpaid Bagged/Boxed items
> - a wand {7} 178 zorkmids
> - a gem {1} 2667 zorkmids

* - Total: 2856 zorkmids

Is that an intentional design decision to reveal the contents or a bug?

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 7, 2022 at 4:32:57 PM UTC-7, Janis wrote:
[...]

Is that an intentional design decision to reveal the contents or a bug?

It looks like a bug to me. NetHack 3.4.3 had that same bug if
you use 'Iu'.

That's fixed in more recent versions. However, a different bug
can be used to reveal the same information. If you use 'p' to
buy unpaid stuff and request itemized billing then the unseen,
unpaid contents of a container will be shown item by item.

Despite being known for a long time, it still hasn't been fixed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 8 Jul 2022 11:37:23 -0700 (PDT), Pat Rankin wrote:

a different bug
can be used to reveal the same information. If you use 'p' to
buy unpaid stuff and request itemized billing then the unseen,
unpaid contents of a container will be shown item by item.

Despite being known for a long time, it still hasn't been fixed.

IMHO, this isn't a bug. Rather an opportunity-feature available to those thinking outside the box. (Pun intended.) ;-)

A shopkeeper can be assumed to know the content of each container, that
was inside the shop from the beginning. (Locked or not.) Therefore, any customer should be able to acquire truthful information about the box
content. To preserve future business, shopkeepers shouldn't lie when
asked. (Depending on charisma and wisdom of the customer, shopkeepers
could be likely to refuse an answer, though.) Itemized billing of the
content would therefore be plausible. Purchasing part of the container
content does /not/ permit leaving shop with unpaid items. (Including the container itself.) Without a means to open the container (or without
buying the whole set), consenting to the offered price of single items
inside the container is either a waste of money or an investment.

When buying a locked container, a shopkeeper should only pay the worth
of an empty one. When reselling such a container (or a locked container
dropped by a monster), the shopkeeper shouldn't know anything about the
content and therefore charge randomized fantasy prices for "a box of
unknown content". - Or sth. like that...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08.07.2022 23:38, B. R. 'BeAr' Ederson wrote:

A shopkeeper can be assumed to know the content of each container, that
was inside the shop from the beginning. (Locked or not.)

Not necessarily. He could have obtained it without key from another
person. As a shopkeeper I'd like to know the contents, and force the
lock open to see; to adjust price for best profit, and also because
customers typically want to know what they buy. I think knowing the
contents is thus crucial for a shopkeeper.

Options are to sell only empty containers, or only open containers;
removing a bit of game-play variance from the games. It depends what
we want here, focus on more realism or most interesting game-play.

[...]

When buying a locked container, a shopkeeper should only pay the worth
of an empty one. When reselling such a container (or a locked container dropped by a monster), the shopkeeper shouldn't know anything about the content and therefore charge randomized fantasy prices for "a box of
unknown content". - Or sth. like that...

Boxes are cheap, so it seems not appropriate to charge just for the
container, given the huge price of the magical items that you find
typically in containers.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 9 Jul 2022 03:14:58 +0200, Janis Papanagnou wrote:

On 08.07.2022 23:38, B. R. 'BeAr' Ederson wrote:

A shopkeeper can be assumed to know the content of each container, that
was inside the shop from the beginning. (Locked or not.)

Not necessarily. He could have obtained it without key from another
person. As a shopkeeper I'd like to know the contents, and force the
lock open to see; to adjust price for best profit, and also because
customers typically want to know what they buy. I think knowing the
contents is thus crucial for a shopkeeper.

Your reasoning from the first part of your paragraph contradicts that
of the second part. (= Shopkeeper might not know vs. shopkeeper would
avert not knowing with all means imaginable.) Both are valid, though.
With game mechanics, each path can be followed or a mix from both. I
suggested a mix:

Containers created inside shops during level creation ("stock items"
of the shop) have their content known to the shopkeeper. The chain of
reasoning being around the lines from the second half of your paragraph:
A shopkeeper would badly want to know the /exact/ value of each item in possession. When purchasing locked containers, (s)he'd usually insist
on temporarily open said container. If the seller does not comply, the shopkeeper would pay only as much as the container value, assuming the
content being total junk. (But, nevertheless, hoping otherwise.)

After the purchase, a shopkeeper would use the first opportunity to take
a glimpse at the content, using either a method available to him (key
in stock or the like) or paying the first customer - with the means for
opening the container - to temporarily open it. When the player arrives
in a shop, the shopkeeper therefore knows his/her stock item values.

This assumption /has/ to be false for items added to the shop /after/
level creation. Because the player would (at least: might theoretically)
know, that the shopkeeper would have no means to learn about the content
of the container since first entering the level. Therefore, I suggested
a different way of reasoning for such containers:

When buying a locked container, a shopkeeper should only pay the worth
of an empty one. When reselling such a container (or a locked container
dropped by a monster), the shopkeeper shouldn't know anything about the
content and therefore charge randomized fantasy prices for "a box of
unknown content". - Or sth. like that...

Boxes are cheap, so it seems not appropriate to charge just for the container, given the huge price of the magical items that you find
typically in containers.

It is up to the player to sell locked boxes for just the container value.
In most circumstances, this would be ridiculous. Therefore, the player
wouldn't do it. But /if/ the player did it, anyways, or if a monster
dropped a locked container, the situation would change, dramatically.
Now, my suggested "fantasy prices" apply: Even after just buying a
container for few zm from a player, the price of re-acquiring it (for
the same player character!) would be astronomical. The shopkeeper (in
an attempt to not selling at loss) would charge, as if the container
"of unknown content" would be filled to the brim with dilithium crystals. (Maybe, shopkeepers should refer to this as selling a "treasure chest",
or the like...)

Options are to sell only empty containers, or only open containers;
removing a bit of game-play variance from the games. It depends what
we want here, focus on more realism or most interesting game-play.

IMHO, there are more options (as described above), adding to both:
realism /and/ interesting game-play.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09.07.2022 07:39, B. R. 'BeAr' Ederson wrote:

On Sat, 9 Jul 2022 03:14:58 +0200, Janis Papanagnou wrote:

On 08.07.2022 23:38, B. R. 'BeAr' Ederson wrote:

A shopkeeper can be assumed to know the content of each container, that
was inside the shop from the beginning. (Locked or not.)

Not necessarily. He could have obtained it without key from another
person. As a shopkeeper I'd like to know the contents, and force the
lock open to see; to adjust price for best profit, and also because
customers typically want to know what they buy. I think knowing the
contents is thus crucial for a shopkeeper.

Your reasoning from the first part of your paragraph contradicts that
of the second part. (= Shopkeeper might not know vs. shopkeeper would
avert not knowing with all means imaginable.)

Erm, no.

"A shopkeeper can be assumed to know the content of each container"

"Not necessarily." - This was a direct comment on your statement.

"As a shopkeeper I'd like to know the contents [...]" etc.
This is a point in a yet undecided discussion that I lead to the
undecided decision when I finally subsumed:
"It depends what we want here, focus on more realism or most
interesting game-play.". - Of course you may disagree here (see below).

Both are valid, though.
With game mechanics, each path can be followed or a mix from both.

That's what I tried to contemplate on.

I suggested a mix: [...]

For game-play anything is possible. I was (and still am) undecided.
The question for me would be; is any more complex (or "reality-proof") algorithm worth the [game-play] outcome?

IMHO, there are more options (as described above),

Sure. I wrote about a couple possible and obvious ones that are easy
to define ("to make plausible") and implement (i.e. without too much
special code and case differentiation), not about all existing options.

adding to both: realism /and/ interesting game-play.

It depends. The factors influence each other.
And what's worth to implement? - The crucial question, IMO.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 11 Jul 2022 21:09:12 +0200, Janis Papanagnou wrote:

Erm, no.

"A shopkeeper can be assumed to know the content of each container"

"Not necessarily." - This was a direct comment on your statement.

We are still talking across: My "can be assumed" has the meaning "it
is /possible/ to assume". - And with this possibility, it is not a
given, that what Pat labeled as a "bug" really /has/ to be regarded
as such.

Your "not necessarily" therefore doesn't made/make any sense in that
context. You, though, probably read my "can be assumed" as "can be
/safely/ assumed". - Which opens an altogether different chain of
reasoning and discussion.

For game-play anything is possible. I was (and still am) undecided.
The question for me would be; is any more complex (or "reality-proof") algorithm worth the [game-play] outcome?

My comment to Pat was meant to approach the problem from the opposite direction: If there is some current inconsistency, that justifies a
to-do for code adjustments, why not consider an explanatory in-game environment? In the result, adjusting the code would result in padding
out this explanation, instead of just removing the current behavior
by "fixing it" as a bug.

In both of my previous messages I tried to roughly sketch an environment,
where the "bug" would in fact be a game-diversity increasing "feature".

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11.07.2022 22:50, B. R. 'BeAr' Ederson wrote:

On Mon, 11 Jul 2022 21:09:12 +0200, Janis Papanagnou wrote:

Erm, no.

"A shopkeeper can be assumed to know the content of each container"

"Not necessarily." - This was a direct comment on your statement.

We are still talking across: My "can be assumed" has the meaning "it
is /possible/ to assume". - And with this possibility, it is not a
given, that what Pat labeled as a "bug" really /has/ to be regarded
as such.

Your "not necessarily" therefore doesn't made/make any sense in that
context. You, though, probably read my "can be assumed" as "can be
/safely/ assumed". - Which opens an altogether different chain of
reasoning and discussion.

Well, as a non-native speaker I probably miss details of connotation
and meaning. Nonetheless I cannot follow the logic of your thought;
an assumption is always possible to make, and an assumption is also
always just a possibility - that means in both interpretations, meta
and direct, the "possibility" fact doesn't add to the interpretation
of the concrete assumption. So my focus on the _concrete_ assumption
"assume that shopkeeper knows content" (a hypothesis) is not a given.
I was trying to say here with "not necessarily" that the hypothesis
may be correct or not, depending on the context of design and logic.
Sorry it that formulation was confusing or even semantically wrong.
As a non-native speaker I'll therefore better abstain from further
elaborations if what I write makes no sense to you or generally.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 12 Jul 2022 12:38:04 +0200, Janis Papanagnou wrote:

On 11.07.2022 22:50, B. R. 'BeAr' Ederson wrote:

On Mon, 11 Jul 2022 21:09:12 +0200, Janis Papanagnou wrote:

Erm, no.

"A shopkeeper can be assumed to know the content of each container"

"Not necessarily." - This was a direct comment on your statement.

We are still talking across: My "can be assumed" has the meaning "it
is /possible/ to assume". - And with this possibility, it is not a
given, that what Pat labeled as a "bug" really /has/ to be regarded
as such.

Your "not necessarily" therefore doesn't made/make any sense in that
context. You, though, probably read my "can be assumed" as "can be
/safely/ assumed". - Which opens an altogether different chain of
reasoning and discussion.

Well, as a non-native speaker I probably miss details of connotation
and meaning. Nonetheless I cannot follow the logic of your thought;
an assumption is always possible to make, and an assumption is also
always just a possibility - that means in both interpretations, meta
and direct, the "possibility" fact doesn't add to the interpretation
of the concrete assumption. So my focus on the _concrete_ assumption
"assume that shopkeeper knows content" (a hypothesis) is not a given.
I was trying to say here with "not necessarily" that the hypothesis
may be correct or not, depending on the context of design and logic.
Sorry it that formulation was confusing or even semantically wrong.
As a non-native speaker I'll therefore better abstain from further elaborations if what I write makes no sense to you or generally.

IIRC, we are German native speakers. Maybe in German the differences
in meaning will be clearer.

I wrote with the following German connotation in mind:
"Es w�re m�glich anzunehmen, dass der H�ndler den Inhalt jedes Containers kennt." (= Introduction of a general thought-model.)

You probably read:
"Man kann ziemlich gesichert davon ausgehen, dass der H�ndler den Inhalt
jedes Containers kennt. (= Axiom.)

As long as you argue against the axiom while I read, that you will not
accept the general though-model as a basis for discussion (because a
simple example "proofs" the model to not being able to work), we are
doomed to misunderstanding...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12.07.2022 19:26, B. R. 'BeAr' Ederson wrote:

IIRC, we are German native speakers.

(Wasn't aware of that. - BeAr/B.R. sounded like initials
as they are typically used in the US.)

Maybe in German the differences in meaning will be clearer.
[...]

Thanks for the [German] explanation.

We can probably reduce the assumptions, at least in Slashem...
In Slashem (not sure about Nethack) shopkeepers carry a key
(that can unlock all normal doors or lockable containers).
In that case the topic in question is probably even easier
to answer; the shopkeeper certainly will know the contents.
(If we don't further complicate the situation by additional
assumptions; Occam's razor.) In that case the simplest model
would be to have all containers sold in shops to be unlocked.
(Again not complicating the issue, e.g. by a shopkeeper with
bad intentions.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 13 Jul 2022 23:33:52 +0200, Janis Papanagnou wrote:

On 12.07.2022 19:26, B. R. 'BeAr' Ederson wrote:

IIRC, we are German native speakers.

(Wasn't aware of that. - BeAr/B.R. sounded like initials
as they are typically used in the US.)

A couple of (or rather: many) years ago, people used to call me
in this American style. What's more, bear is a direct translation
of B[joern]. I just linked both together and like(d) the result.
Phonetically, this doesn't really work. But I don't mind... ;-)

[locked container]

We can probably reduce the assumptions, at least in Slashem...
In Slashem (not sure about Nethack) shopkeepers carry a key

Now that you mention it: I think, it is true for Nethack, as well.
(I usually leave shopkeepers alive. So this fact[?] didn't really
register.)

In that case the simplest model would be to have all containers sold in
shops to be unlocked.

Would certainly work and be consistent for "stock containers" existing
in the shop since level creation. For containers dropped (by player or monsters) some steps away from the shopkeeper, keeping up the assumption
would stretch logic a bit. (At least, as long as either shopkeeper or
container are kept in direct or ESP/infravision view.)

But maybe, the new possibilities arising from more complicated approaches
are worth considering, as well. Apart from the "treasure chest" case I
already mentioned, it would be possible to create new payable interaction between player and shopkeeper: Locking any container belonging to the shopkeeper would be charged with 1 zm (for hampering access), unlocking
any container would earn 1 zm (for services rendered). Buying a locked container then, consequently, leads to a "discount" of 1 zm and selling
one to a "payment reduction" of the same amount. (In the latter case in addition to not paying for any content of the container.)

(Again not complicating the issue, e.g. by a shopkeeper with
bad intentions.)

Games featuring shopkeepers with bad intentions would probably be fun
to play. But it (most likely) can be rather difficult to create this sufficiently balanced... ;-)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14.07.2022 20:22, B. R. 'BeAr' Ederson wrote:

On Wed, 13 Jul 2022 23:33:52 +0200, Janis Papanagnou wrote:

(Wasn't aware of that. - BeAr/B.R. sounded like initials
as they are typically used in the US.)

A couple of (or rather: many) years ago, people used to call me
in this American style. What's more, bear is a direct translation
of B[joern]. I just linked both together and like(d) the result. Phonetically, this doesn't really work. But I don't mind... ;-)

I also missed the obvious "B�r" and thought it was for a pun like
"bear with me" :-)

[locked container]

In Slashem (not sure about Nethack) shopkeepers carry a key

Now that you mention it: I think, it is true for Nethack, as well.
(I usually leave shopkeepers alive. So this fact[?] didn't really
register.)

Initially it also didn't occur to me. But in Slashem with powerful
minions (and despite shopkeepers being even tougher than in Nethack)
it's not unusual to kill them on a regular basis at some point. Not
so much for the keys - a nice source anyway since keys can break in
Slashem, but there's the unbreakable keys in the aligned quests so
not really necessary to get them from shopkeepers - but for the
wands of teleport (always useful to dislocate tough monsters).

But maybe, the new possibilities arising from more complicated approaches
are worth considering, as well. Apart from the "treasure chest" case I already mentioned, it would be possible to create new payable interaction between player and shopkeeper: Locking any container belonging to the shopkeeper would be charged with 1 zm (for hampering access), unlocking
any container would earn 1 zm (for services rendered). Buying a locked container then, consequently, leads to a "discount" of 1 zm and selling
one to a "payment reduction" of the same amount. (In the latter case in addition to not paying for any content of the container.)

I forgot; are shopkeeper services implemented in Nethack? (In Slashem
it certainly fits.)

(Again not complicating the issue, e.g. by a shopkeeper with
bad intentions.)

Games featuring shopkeepers with bad intentions would probably be fun
to play. But it (most likely) can be rather difficult to create this sufficiently balanced... ;-)

Yeah, that would add a bit salt and pepper to their current quite
deterministic behavior. Balance is a factor to consider, reliability
can also be one (to not make the game-play arbitrary in a way).

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 15 Jul 2022 16:08:56 +0200, Janis Papanagnou wrote:

[Container (un)locking interaction between player character and shopkeeper]

I forgot; are shopkeeper services implemented in Nethack? (In Slashem
it certainly fits.)

Not yet implemented in Nethack. But this is one of the things I'd like to
see re-ported from Slashem. While Slashem is somewhat (hm) over-ambitious
with some of its many changes (for my taste), it still includes quite a
few very good ideas.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)