Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Autosquelch -- the next generation

20 views

Skip to first unread message

David T. Blackston

unread,

Aug 29, 2000, 1:12:13 AM8/29/00

Hi all,

Ironically enough, the recent flames on this newsgroup got my
creative juices flowing and I am about ready to release the
next version of my autosquelch patch. I've developed it
for V291, but it seems likely to me that other versions
would be easy to write. It combines some of the best features
of the other two versions of the patch. Here's how it stands so
far. Any constructive criticisms are welcome.

If you need definitions of the two previous patches, please
refer to my page at
http://www.cs.berkeley.edu/~davidb/angband/
for their descriptions.

In order to preserve game balance as much as possible, no items
are squelched on generation. I try to make this transparent to
the user by maintaining the following properties.

1: Any pile of items will always be sorted so that the
non-squelched items are on top of the squelched items.
When the player walks over the pile, the squelched items
are removed from the game (just as in the second version
of the patch). This sorting is accomplished by one pass
through the pile, so it is relatively efficient. The only
downside to this approach is that all the piles must be
resorted whenever the squelch menus have been accessed
because changes made in the menus must be reflected in the
piles. This doesn't seem to take too long, though.

2: If all of the items in a pile are to be squelched, then
the pile is represented as a purple '.' character. This is
a gross hack, and I'm not proud of it, but it has the very nice
effect of mimicing the play style of the first patch. These
purple '.'s can be effectively ignored. As before, when
one of these piles is walked over all of the items are removed
for free.

3: I've included another bit, the silent_squelch bit, that allows
the user to decide whether he wants to see the "(Squelched)" messages
when he passes over a pile. This bit has one more function. If the
bit is off and an artifact whose base type is squelched is encountered
then the artifact survives the squelching (No message to that effect
is printed, though). This mimics the artifact behaviour of the
second patch. If the bit is on when the artifact is encountered
the artifact is removed and the user never sees it. This mimics the
agreed upon "proper behaviour" of the first version of the patch.

4: The squelch-on-identification part of the patch works in exactly
the same fashion as before. If it ain't broke...

There are a couple of other things I want to do with this patch before
releasing it, but this should give you the flavor of where I'm heading
with it. Basically, it has the same balance behaviour as the second
version of the patch while allowing the user the convenience of playing
with a style similar to the first version.

Regards,

Dave

David T. Blackston

unread,

Aug 29, 2000, 3:00:00 AM8/29/00

In article <8ofgnd$48i$1...@agate.berkeley.edu>,
David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote:
>
>Hi all,

Sorry to follow up on my own post, but James Sager had a great
idea that he sent me in an email last night, and I've already
changed the implementation a little because his idea is so
clearly good. Thanks James. In any case, without further
adieu...

>In order to preserve game balance as much as possible, no items
>are squelched on generation. I try to make this transparent to
>the user by maintaining the following properties.
>
>1: Any pile of items will always be sorted so that the
>non-squelched items are on top of the squelched items.

This property is the same. The key difference is that I have
added a flag so that it is now the user's choice whether he/she
wants squelched items to be destroyed when he/she walks over a pile.

If the user chooses not to destroy squelched items, then I can see
absolutely no effects to play balance of this scheme. It does make
the interface easier in that the user can more quickly locate
areas of the dungeon with "interesting" items, but as has been pointed
out before this can also be done in the current game with the
extended look command. In effect the user is gaining no play advantage
from this scheme (though he/she is gaining an advantage in ease of
use).

If the user chooses to destroy squelched items then they are removed
from the game as soon as the user walks over the pile. This is
done with no messages to the user. I have decided to allow artifacts
to survive this purging because I view this process as giving the
user a number of free "destroys" upon encountering a pile and
artifacts would survive that. I don't think that this can be exploited
for artifact farming in a useful way, though, as it is more efficient
to simply destroy all wearable items and see what survives rather than
fiddle with the menus a lot.

It should be pointed out here that the only interaction that the user
can have with squelched items is to look at them. The user at this point
cannot do anything but look at them. If the user want to pick up a
squelched item, he must unsquelch it before he can get it.

The automatic destruction option does have some small balance effects,
but these have been discussed before and are no different than the
balance effects of the second version of the patch.

>This sorting is accomplished by one pass
>through the pile, so it is relatively efficient. The only
>downside to this approach is that all the piles must be
>resorted whenever the squelch menus have been accessed
>because changes made in the menus must be reflected in the
>piles. This doesn't seem to take too long, though.
>

This still holds.

>2: If all of the items in a pile are to be squelched, then
>the pile is represented as a purple '.' character. This is
>a gross hack, and I'm not proud of it, but it has the very nice
>effect of mimicing the play style of the first patch. These
>purple '.'s can be effectively ignored.

This also still holds.

>3: I've included another bit, the silent_squelch bit, that allows
>the user to decide whether he wants to see the "(Squelched)" messages
>when he passes over a pile.

With the above changes, this bit no longer serves a purpose and has been
removed. It's too bad -- I liked the ominous sound of the silent_squelch
bit... ;-)

>4: The squelch-on-identification part of the patch works in exactly
>the same fashion as before. If it ain't broke...

This still holds as well. As has been noted in past threads, this also
has some very minor balance issues, but I don't think that they're
dealbreakers.

>
>There are a couple of other things I want to do with this patch before
>releasing it, but this should give you the flavor of where I'm heading
>with it. Basically, it has the same balance behaviour as the second
>version of the patch while allowing the user the convenience of playing
>with a style similar to the first version.
>

For the interested, here are the other things I want to add before
making the patch available.

1: I want to add the ability to save/load squelch values in a .prf file.

2: I am probably going to add another bit that will tell if the player
has ever seen a flavored item of a given type before. If he hasn't then
the name of the item will appear as "......" on the squelch menus. This
will eliminate some of the spoilerish aspects of the menus. This bit
will last beyond death (like monster memory), so once a player has seen
everything all future games with the same save file will have the full
memories.

Regards,

Dave

Jason Willoughby

unread,

Aug 30, 2000, 2:28:09 AM8/30/00

David T. Blackston, a beast of pure hatred with purpose malign, wrote:
>>3: I've included another bit, the silent_squelch bit, that allows
>>the user to decide whether he wants to see the "(Squelched)" messages
>>when he passes over a pile.

> With the above changes, this bit no longer serves a purpose and has been

> removed. It's too bad -- I liked the ominous sound of the silent_squelch
> bit... ;-)

<g>

James W Sager Iii

unread,

Aug 30, 2000, 3:00:00 AM8/30/00

Excerpts from netnews.rec.games.roguelike.angband: 30-Aug-100 Re:
Autosquelch -- the next.. by Jason Willo...@gate.ne

Why does this make me laugh?

Why does doom bat make me laugh?

Sounds like a new nerf toy.
Da-da Doom bat!

Almost as cool as flail snails!
woot flail snails!

0 new messages