Discussion:
[slashem] Bug or intentional design - contents of locked chest are shown
(too old to reply)
Janis Papanagnou
2022-07-07 23:32:54 UTC
Permalink
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
Pat Rankin
2022-07-08 18:37:23 UTC
Permalink
On Thursday, July 7, 2022 at 4:32:57 PM UTC-7, Janis wrote:
[...]
Post by Janis Papanagnou
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.
B. R. 'BeAr' Ederson
2022-07-08 21:38:41 UTC
Permalink
Post by Pat Rankin
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!)===
Janis Papanagnou
2022-07-09 01:14:58 UTC
Permalink
Post by B. R. 'BeAr' Ederson
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.
Post by B. R. 'BeAr' Ederson
[...]
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
B. R. 'BeAr' Ederson
2022-07-09 05:39:16 UTC
Permalink
Post by Janis Papanagnou
Post by B. R. 'BeAr' Ederson
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
Post by Janis Papanagnou
Post by B. R. 'BeAr' Ederson
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...)
Post by Janis Papanagnou
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!)===
Janis Papanagnou
2022-07-11 19:09:12 UTC
Permalink
Post by B. R. 'BeAr' Ederson
Post by Janis Papanagnou
Post by B. R. 'BeAr' Ederson
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).
Post by B. R. 'BeAr' Ederson
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.
Post by B. R. 'BeAr' Ederson
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?
Post by B. R. 'BeAr' Ederson
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.
Post by B. R. 'BeAr' Ederson
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
B. R. 'BeAr' Ederson
2022-07-11 20:50:58 UTC
Permalink
Post by Janis Papanagnou
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.
Post by Janis Papanagnou
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!)===
Janis Papanagnou
2022-07-12 10:38:04 UTC
Permalink
Post by B. R. 'BeAr' Ederson
Post by Janis Papanagnou
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
B. R. 'BeAr' Ederson
2022-07-12 17:26:46 UTC
Permalink
Post by Janis Papanagnou
Post by B. R. 'BeAr' Ederson
Post by Janis Papanagnou
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!)===
Janis Papanagnou
2022-07-13 21:33:52 UTC
Permalink
Post by B. R. 'BeAr' Ederson
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.)
Post by B. R. 'BeAr' Ederson
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
B. R. 'BeAr' Ederson
2022-07-14 18:22:17 UTC
Permalink
Post by Janis Papanagnou
Post by B. R. 'BeAr' Ederson
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]
Post by Janis Papanagnou
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.)
Post by Janis Papanagnou
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.)
Post by Janis Papanagnou
(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!)===
Janis Papanagnou
2022-07-15 14:08:56 UTC
Permalink
Post by B. R. 'BeAr' Ederson
Post by Janis Papanagnou
(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" :-)
Post by B. R. 'BeAr' Ederson
[locked container]
Post by Janis Papanagnou
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).
Post by B. R. 'BeAr' Ederson
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.)
Post by B. R. 'BeAr' Ederson
Post by Janis Papanagnou
(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
B. R. 'BeAr' Ederson
2022-07-15 16:48:44 UTC
Permalink
On Fri, 15 Jul 2022 16:08:56 +0200, Janis Papanagnou wrote:

[Container (un)locking interaction between player character and shopkeeper]
Post by Janis Papanagnou
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!)===
Loading...