Simplifying the container system

Toggle sidebar Toggle sidebar
G

Guest

Guest
Archived from groups: rec.games.roguelike.nethack (More info?)

For some time now, I've been annoyed with the clumsiness of constantly
moving items in and out of containers in order to protect them (or
decrease encumbrance) when not in use. I'd like to propose the
following simplification for your approval.

Instead of having to specifically put items into (oilskin) sacks and
bags of holding, just treat all unworn, unwielded items in the
inventory as being granted the same protection and/or weight reduction
as if they were inside the container being carried. IIRC, all three
give protection from fire, cold, electricity, theft, and cursing to
their contents; oilskin sacks, of course, give waterproofing.

Unfortunately, I don't have the slightest clue about how to make the
required changes to the source code. You could fit what I know about C
into a matchbox without taking the matches out first. Please, O wise
and benevolent source divers, kindly grant me insight into your arcane
art.
 
Archived from groups: rec.games.roguelike.nethack (More info?)

Lars Kecke wrote:
> So picking up a /oc or a boT will just destroy your inventory,
> getting your boH cursed will give you a chance of objects
> disappearing when you try to use your ?oRC, picking up a cursed boH
> will make you stressed (and lets items disappear) and having your
> two-handed weapon cursed will render you unable to interact with
> your inventory at all. Bad idea.

I'm sorry if my language was too vague; my suggestion was to "treat all
unworn, unwielded items in the inventory as being granted the same
>>>protection and/or weight reduction<<< as if they were inside the
container being carried". To be explicit, the only effect the
container would have on other items in inventory would be that which I
have mentioned. That means no malfunctions from trick bags and cancel
wands, as well as no problem from having your hands 'dual-welded', so
to speak. To deal with the issue of a cursed holding bag, just set
them to behave like ordinary sacks when cursed.
 
Archived from groups: rec.games.roguelike.nethack (More info?)

> So you want all the benefits of containers with none of their
> drawbacks? (I'm referring to gameplay drawbacks here, rather than
> interface hassles.) If so, it'd be easier just to remove containers
> altogether and simply create Magical McGuffins (grey stones, perhaps)
> that, while carried, nullify bad inventory-affecting effects or alter
> object weights.

Perhaps you're right. Do you have any suggestions for making it easier
to automatically retrieve and stow items in containers without
compromising the gameplay drawbacks?
 
Archived from groups: rec.games.roguelike.nethack (More info?)

Taramnos wrote:
> For some time now, I've been annoyed with the clumsiness of constantly
> moving items in and out of containers in order to protect them (or
> decrease encumbrance) when not in use. I'd like to propose the
> following simplification for your approval.
>
> Instead of having to specifically put items into (oilskin) sacks and
> bags of holding, just treat all unworn, unwielded items in the
> inventory as being granted the same protection and/or weight reduction
> as if they were inside the container being carried.

So picking up a /oc or a boT will just destroy your inventory, getting
your boH cursed will give you a chance of objects disappearing when you
try to use your ?oRC, picking up a cursed boH will make you stressed
(and lets items disappear) and having your two-handed weapon cursed will
render you unable to interact with your inventory at all. Bad idea.

Lars
 
Archived from groups: rec.games.roguelike.nethack (More info?)

"Taramnos" <taramnos@gmail.com> writes:
> Lars Kecke wrote:
> I'm sorry if my language was too vague; my suggestion was to "treat all
> unworn, unwielded items in the inventory as being granted the same
> >>>protection and/or weight reduction<<< as if they were inside the
> container being carried". To be explicit, the only effect the
> container would have on other items in inventory would be that which I
> have mentioned. That means no malfunctions from trick bags and cancel
> wands, as well as no problem from having your hands 'dual-welded', so
> to speak. To deal with the issue of a cursed holding bag, just set
> them to behave like ordinary sacks when cursed.

So you want all the benefits of containers with none of their
drawbacks? (I'm referring to gameplay drawbacks here, rather than
interface hassles.) If so, it'd be easier just to remove containers
altogether and simply create Magical McGuffins (grey stones, perhaps)
that, while carried, nullify bad inventory-affecting effects or alter
object weights.

--
: Dylan O'Donnell http://www.spod-central.org/~psmith/ :
: "Nothing matters very much, and few things matter at all." :
: -- A.J. Balfour :
 
Archived from groups: rec.games.roguelike.nethack (More info?)

On Wed, 16 Mar 2005, Lars Kecke wrote:

> Taramnos wrote:
> > For some time now, I've been annoyed with the clumsiness of constantly
> > moving items in and out of containers in order to protect them (or
> > decrease encumbrance) when not in use. I'd like to propose the
> > following simplification for your approval.
> >
> > Instead of having to specifically put items into (oilskin) sacks and
> > bags of holding, just treat all unworn, unwielded items in the
> > inventory as being granted the same protection and/or weight reduction
> > as if they were inside the container being carried.
>
> So picking up a /oc or a boT will just destroy your inventory, getting
> your boH cursed will give you a chance of objects disappearing when you
> try to use your ?oRC, picking up a cursed boH will make you stressed
> (and lets items disappear) and having your two-handed weapon cursed will
> render you unable to interact with your inventory at all. Bad idea.

Plus the obvious problems when you have more than one container in your
inventory: do your items go in the BoH which is in the oilskin sack or in
the oilskin sack, itself in the BoH ? In which BoH do your items go ? Does
your first BoH goes into the second one ?

Well, that may be doable but will surely dramatically change the behaviour
of containers such as allowing BoH in BoH, /oc in BoH and no more trouble
with cursed BoH. Too many gameplay changes in a bad way imho.

Actually not, that will not be doable: how do you do if you want to drop a
container ?

Hypocoristiquement,
Jym.
 
Archived from groups: rec.games.roguelike.nethack (More info?)

"Taramnos" <taramnos@gmail.com> writes:
[attribute, please]
> > So you want all the benefits of containers with none of their
> > drawbacks? (I'm referring to gameplay drawbacks here, rather than
> > interface hassles.) If so, it'd be easier just to remove containers
> > altogether and simply create Magical McGuffins (grey stones, perhaps)
> > that, while carried, nullify bad inventory-affecting effects or alter
> > object weights.
>
> Perhaps you're right. Do you have any suggestions for making it easier
> to automatically retrieve and stow items in containers without
> compromising the gameplay drawbacks?

Three additions that would go some (not all) of the way towards that:

a) an inventory slot (similar to the quiver) for 'primary container';
b) a 'stowtypes' option (and 'autostow_exceptions') to specify items that,
whenever they enter your inventory, get automatically put into
whatever container is in the above slot;
c) the ability to apply commands like 'quaff', 'read', or 'drop'
directly to items in containers, and have the game automatically
extract them for you (taking the same amount of time as if you'd
done it manually, in the same manner as A-removing inner layers of
armour). This means that you'd need to be able to call up nested
submenus in the inventory-menu code, which would be Tricky.

Of course, you add / and ( to your stowtypes at your own risk.

--
: Dylan O'Donnell http://www.spod-central.org/~psmith/ :
: "Nothing matters very much, and few things matter at all." :
: -- A.J. Balfour :
 
Archived from groups: rec.games.roguelike.nethack (More info?)

"Taramnos" <taramnos@gmail.com> was moved to say:

>For some time now, I've been annoyed with the clumsiness of constantly
>moving items in and out of containers in order to protect them

Which give me YANI ... a trolley. If an iron ball (chained to you)
can be dragged around, then why not a box on wheels into which things
could be placed for easy transport. Presumably, a trolley could carry
a much greater weight of items than a sack, and a character could tow
a heavy trolley with less effect on encumbrance than carrying those
same items.

Stairs? You need to puch the trolley down the stairs ahead of you,
otherwise it will fall on you and hurt.

Water? Forget it, this trolley is on wheels, not floats.

Well?

--

JPD


SGFN
 
Archived from groups: rec.games.roguelike.nethack (More info?)

Dylan O'Donnell wrote:
> "Taramnos" <taramnos@gmail.com> writes:
> [attribute, please]
>>
>>Perhaps you're right. Do you have any suggestions for making it easier
>>to automatically retrieve and stow items in containers without
>>compromising the gameplay drawbacks?
>
> Three additions that would go some (not all) of the way towards that:
>
> a) an inventory slot (similar to the quiver) for 'primary container';
> b) a 'stowtypes' option (and 'autostow_exceptions') to specify items that,
> whenever they enter your inventory, get automatically put into
> whatever container is in the above slot;
> c) the ability to apply commands like 'quaff', 'read', or 'drop'
> directly to items in containers, and have the game automatically
> extract them for you (taking the same amount of time as if you'd
> done it manually, in the same manner as A-removing inner layers of
> armour). This means that you'd need to be able to call up nested
> submenus in the inventory-menu code, which would be Tricky.
>
> Of course, you add / and ( to your stowtypes at your own risk.

And, I think, people would immediately complain about that "risky feature".

Janis
 
Archived from groups: rec.games.roguelike.nethack (More info?)

On 3/16/05 5:13 PM, Dylan O'Donnell wrote:

> Three additions that would go some (not all) of the way towards
> [making containers easier to use without compromising gameplay]:
>
> a) an inventory slot (similar to the quiver) for 'primary container';

which, unlike the quiver, you wouldn't have until you actually got a
container

> b) a 'stowtypes' option (and 'autostow_exceptions') to specify items that,
> whenever they enter your inventory, get automatically put into
> whatever container is in the above slot;

But then there's the issue of keeping a few of a particular type of item
(healing potions, or one each of various wands) immediately available
while stashing others, and keeping track of what's stashed and what's
not, since it seems that everything would have to be viewable from the
inventory command.

> c) the ability to apply commands like 'quaff', 'read', or 'drop'
> directly to items in containers, and have the game automatically
> extract them for you (taking the same amount of time as if you'd
> done it manually, in the same manner as A-removing inner layers of
> armour). This means that you'd need to be able to call up nested
> submenus in the inventory-menu code, which would be Tricky.

There's a "nested looting" patch that does something like that (only
with the #loot or 'a'pply commands, though), which I think would be a
great addition to the game. I really don't see the need to expand this
to other commands, though.

Actually, I don't have a problem with the way containers are handled in
the game now, except for containers not in your present inventory.

You see here a chest.
#loot
There is a chest here. Loot it? [ynq] (q) y // *
Hmmm, it seems to be locked.
#apply
What do you want to use or apply? [efk or ?*] k
In what direction? .
There is a chest here. Unlock it? [ynq] (q) y // *
You succeed in unlocking the chest.
#loot
There is a chest here. Loot it? [ynq] (q) y // *
You carefully open the chest...

Ugh. Even worse if you bother to #untrap, or don't succeed in unlocking
or looting the first time.

* All the starred "gee do you really want to do what you said you want
to do" lines are easily dispensed with. Alternatively, when #applying
the key, it could default to a container on the square, if there is one
(although then it would be necessary to retain the "Do ya really really
wanna do this?" question).

--
Kevin Wayne

"I came to Casablanca for the waters."
"Waters? What waters? We're in the desert?"
"I was misinformed."
 
Archived from groups: rec.games.roguelike.nethack (More info?)

Kevin Wayne wrote:

> Actually, I don't have a problem with the way containers are handled
> in the game now, except for containers not in your present inventory.

> You see here a chest.
> #loot
> There is a chest here. Loot it? [ynq] (q) y // *
> Hmmm, it seems to be locked.
> #apply
> What do you want to use or apply? [efk or ?*] k
> In what direction? .
> There is a chest here. Unlock it? [ynq] (q) y // *
> You succeed in unlocking the chest.
> #loot
> There is a chest here. Loot it? [ynq] (q) y // *
> You carefully open the chest...

> * All the starred "gee do you really want to do what you said you want
> to do" lines are easily dispensed with. Alternatively, when #applying
> the key, it could default to a container on the square, if there is
> one (although then it would be necessary to retain the "Do ya really
> really wanna do this?" question).

The reason for the extra enquiry is that there may be more than one
container on the square, and then you often want to open/unlock only
one. For example, there might be a bag of tricks lying on the chest you
want to loot.

You might reason that when there's only *one* container on the square,
this extra question is superfluous. However, that would mean that the
key sequence you need to type would be different for more than one or
just one container on a square. Personally, I wouldn't like that: I like
to be able to memorise the same key sequence for the same action.

Perhaps an option to do so would be nice.

--
Boudewijn Waijers (kroisos at home.nl).

The garden of happiness is surrounded by a wall so low only children
can look over it. - "the Orphanage of Hits", former Dutch radio show.
 
Archived from groups: rec.games.roguelike.nethack (More info?)

On 3/17/05 3:51 AM, Boudewijn Waijers wrote:
> Kevin Wayne wrote:
>
>>Actually, I don't have a problem with the way containers are handled
>>in the game now, except for containers not in your present inventory.
>
>> You see here a chest.
>> #loot
>> There is a chest here. Loot it? [ynq] (q) y // *
>> Hmmm, it seems to be locked.
>> #apply
>> What do you want to use or apply? [efk or ?*] k
>> In what direction? .
>> There is a chest here. Unlock it? [ynq] (q) y // *
>> You succeed in unlocking the chest.
>> #loot
>> There is a chest here. Loot it? [ynq] (q) y // *
>> You carefully open the chest...
>
>
>>* All the starred "gee do you really want to do what you said you want
>>to do" lines are easily dispensed with.
>
>
> The reason for the extra enquiry is that there may be more than one
> container on the square, and then you often want to open/unlock only
> one. For example, there might be a bag of tricks lying on the chest you
> want to loot.
>
> You might reason that when there's only *one* container on the square,
> this extra question is superfluous. However, that would mean that the
> key sequence you need to type would be different for more than one or
> just one container on a square. Personally, I wouldn't like that: I like
> to be able to memorise the same key sequence for the same action.

If your argument referred to the final 'R'emove or 'T'ake off, I'd be in
wholehearted agreement. The dead weight of the above sequence is just
too much, though. If the game could check for multiple containers on a
space and accessible locks to unlock from a particular space, the
confirmation messages would be relatively rare--because unless *you*
stack containers on the same space or move containers to within a space
of a door, the two situations are unusual (okay, stacked containers more
unusual than two locks within a 3x3 square area).

In this case, you can't really memorize the key sequence anyway, because
you may not know whether the box is locked or not (and in the case of
one that hasn't been opened, whether it's trapped or not).

The illusion of being able to do so is a major cause of Typos of
Horrendous Consequence, all the more if the key sequence you've
memorized consists of several keystrokes.

--
Kevin Wayne

"I came to Casablanca for the waters."
"Waters? What waters? We're in the desert?"
"I was misinformed."
 
Archived from groups: rec.games.roguelike.nethack (More info?)

This system would have to use an Auto-put-in-container system that
functions much like autopickup. ( choose not to stash potions, wands
ect. )
 
Archived from groups: rec.games.roguelike.nethack (More info?)

Dylan O'Donnell wrote:
>
> "Taramnos" <taramnos@gmail.com> writes:

> > Perhaps you're right. Do you have any suggestions for making it easier
> > to automatically retrieve and stow items in containers without
> > compromising the gameplay drawbacks?
>
> Three additions that would go some (not all) of the way towards that:
>
> a) an inventory slot (similar to the quiver) for 'primary container';
> b) a 'stowtypes' option (and 'autostow_exceptions') to specify items that,
> whenever they enter your inventory, get automatically put into
> whatever container is in the above slot;

That would be great!

The thing that is the most hassle for me is when moving a
group of items from my bag to my stash or visa versa. It
requires that I search through the menu twice for the same
set of items. If I had a #transfer command it would be
easier.

#transfer
Transfer from bag? (y/n) y
n
Transfer from chest? (y/n) y
y
Transfer to bag? (y/n) y
y

now revert to the pick items routines.

You might want to #transfer to/from the ground or any
container in inventory or on the ground where you stood.
Don't apply pack accommodation limits or weight checks to
the lot but to the individual items, like you were moving
one at a time.

Another hassle is picking items from a long list with only a
vague idea of how many inventory slots were open. The
closest I can get with the current interface is to #adjust,
pick a letter and then count the number of slots I can
adjust to. Just give me a current count of open inventory
slots I can see while selecting items from list.

Just my 2z.
--
Wes
The early bird may get the worm,
but the second mouse gets the cheese.
 
Archived from groups: rec.games.roguelike.nethack (More info?)

On 3/18/05 3:56 PM, Wes Irby wrote:

> Another hassle is picking items from a long list with only a
> vague idea of how many inventory slots were open. The
> closest I can get with the current interface is to #adjust,
> pick a letter and then count the number of slots I can
> adjust to. Just give me a current count of open inventory
> slots I can see while selecting items from list.

Related to this, it's irritating that when you choose "both" (as in, put
into and take out of a stash or a bag), the program takes things out
before putting things in. Quite frequently, I'm looking to put things in
first, in order to free up inventory slots, before I take other things out.

--
Kevin Wayne

"I came to Casablanca for the waters."
"Waters? What waters? We're in the desert?"
"I was misinformed."
 
Archived from groups: rec.games.roguelike.nethack (More info?)

Kevin Wayne wrote:
> On 3/18/05 3:56 PM, Wes Irby wrote:
>
> Related to this, it's irritating that when you choose "both" (as in, put
> into and take out of a stash or a bag), the program takes things out
> before putting things in. Quite frequently, I'm looking to put things in
> first, in order to free up inventory slots, before I take other things out.

Agreed, completely, it would have some advantages.

AFAIR, it had been ten years ago that I suggested that to the Devteam;
though they did not want to change it. Their reasoning was (and still is)
unclear to me.

A changed behaviour would save me a lot of keystrokes, as I handle my
bag-inventory.

Well, no big issue, any way.

Janis
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom