BEangband OWNS!
James W Sager Iii
All the old school vanilla you want, with a ton of options to make the
game more ergonomic and non-frustrating.
To me its super fun again to relax with.
Thanks all who contributed!
John Abe
Franklin Bratcher
its totally optional, doesn't really affect game balance, IMHO. It simply
allows one to go ahead and delete something he/she doesn't want.
"shren" <sh...@io.com> wrote in message news:8ed9tg$skd$2...@hiram.io.com...
> Either in the /source directory of export.andrew.cmu.edu, or
> http://www.io.com/~shren/beangband-290a-win.zip. But it's just Vanilla
> 290 with two good patches.
shren
shren
> Well, I wish the autosquelch would be incorporated into stabdard angband,
> its totally optional, doesn't really affect game balance, IMHO. It simply
> allows one to go ahead and delete something he/she doesn't want.
I really think it's too early for that... very few people have played
with it. It seems ok, but time will tell.
Ben Harrison
Personally, I feel that the autosquelch code is a *horrible* idea.
It is one thing to make code which automatically has the *character*
destroy stuff that he picks up and does not like, but to have the *game*
do it, thus increasing the odds that any particular object is valuable,
is a massive gameplay imbalance.
People don't seem to realize that Angband itself is nothing but tedium
(though mesmerizing, for some reason, nonetheless). Think about it,
all you do is walk around wacking things and taking their stuff. And
people want to streamline the tedium. Why not simply give people a fully
decked out level 50 character, and remove the top 99 levels from the
dungeon? That would speed things up....
In my own personal universe, you would be able to specify, for each
"k_idx" value, if it should be picked up, destroyed, or ignored, when
you walk on it (if "aware", of course), and an option for "destroy any
identified junk" would allow any "worthless" objects to be "destroyed"
as soon as they were "identified". But they would still be *generated*,
and monsters would still drop them, forcing you to wade through the junk
to find the good stuff (and taking game time to do so, which is really
tough when playing a slow mage character).
And I really hope Robert moves beangband from "Source" to "Variant",
where it belongs, but that is a separate issue....
--- Ben ---
"Franklin Bratcher" <ach...@ticnet.com> writes:
> Well, I wish the autosquelch would be incorporated into stabdard angband,
> its totally optional, doesn't really affect game balance, IMHO. It simply
> allows one to go ahead and delete something he/she doesn't want.
>
> "shren" <sh...@io.com> wrote in message news:8ed9tg$skd$2...@hiram.io.com...
>
David T. Blackston
>
>Personally, I feel that the autosquelch code is a *horrible* idea.
>
>It is one thing to make code which automatically has the *character*
>destroy stuff that he picks up and does not like, but to have the *game*
>do it, thus increasing the odds that any particular object is valuable,
>is a massive gameplay imbalance.
>
>People don't seem to realize that Angband itself is nothing but tedium
>(though mesmerizing, for some reason, nonetheless). Think about it,
>all you do is walk around wacking things and taking their stuff. And
>people want to streamline the tedium. Why not simply give people a fully
>decked out level 50 character, and remove the top 99 levels from the
>dungeon? That would speed things up....
>
>In my own personal universe, you would be able to specify, for each
>"k_idx" value, if it should be picked up, destroyed, or ignored, when
>you walk on it (if "aware", of course), and an option for "destroy any
>identified junk" would allow any "worthless" objects to be "destroyed"
>as soon as they were "identified". But they would still be *generated*,
>and monsters would still drop them, forcing you to wade through the junk
>to find the good stuff (and taking game time to do so, which is really
>tough when playing a slow mage character).
With all due respect, I don't think you've been following
the progress of the autosquelching code. The current version
under consideration by the devteam only squelches objects
when they are walked on, just as you suggest here.
(Actually, come to think of it I don't know that I announced
the modified patch here, so if I didn't, please accept my
apologies and rest assured that any version of the patch that
I release in the future will only squelch objects when the
player walks on them.)
Even the older version of the patch did not affect the item
generation probabilities, hence the player saw no more "good"
items in any particular level. The only real balance issue that
was raised involved the user being able to tell where the useful
flavored items were more quickly than if they used the extended look
command. With the newest version everything is still generated
and placed -- "junk" items are merely destroyed for free once
they are walked on. It makes the game more fun without affecting
balance in any meaningful way (that I can think of -- I might be
wrong) and I personally think that it'd be a very useful addition
to the *ang code.
Of course my opinion is slightly biased... ;-)
>
>And I really hope Robert moves beangband from "Source" to "Variant",
>where it belongs, but that is a separate issue....
>
>--- Ben ---
>
Regards,
Dave
Franklin Bratcher
"Ben Harrison" <be...@phial.com> wrote in message
news:l8hfclc...@eel.curl.com...
>
> Personally, I feel that the autosquelch code is a *horrible* idea.
>
> It is one thing to make code which automatically has the *character*
> destroy stuff that he picks up and does not like, but to have the *game*
> do it, thus increasing the odds that any particular object is valuable,
> is a massive gameplay imbalance.
Hmm, ouch, I thought it just autosquelched what you picked up. If it
squelches item generation, forget about it. I agree there, but it would be
nice to have the cursed items, etc, squelched as your character pseudo-id's
them. Yeah, I'm a lazy bum, ;O).
Franklin Bratcher
autosquelching the item generation.
"David T. Blackston" <dav...@melody.CS.Berkeley.EDU> wrote in message
news:8edus9$aju$1...@agate.berkeley.edu...
> With all due respect, I don't think you've been following
> the progress of the autosquelching code. The current version
> under consideration by the devteam only squelches objects
> when they are walked on, just as you suggest here.
> (Actually, come to think of it I don't know that I announced
> the modified patch here, so if I didn't, please accept my
> apologies and rest assured that any version of the patch that
> I release in the future will only squelch objects when the
> player walks on them.)
>
> Even the older version of the patch did not affect the item
> generation probabilities, hence the player saw no more "good"
> items in any particular level. The only real balance issue that
> was raised involved the user being able to tell where the useful
> flavored items were more quickly than if they used the extended look
> command. With the newest version everything is still generated
> and placed -- "junk" items are merely destroyed for free once
> they are walked on. It makes the game more fun without affecting
> balance in any meaningful way (that I can think of -- I might be
> wrong) and I personally think that it'd be a very useful addition
> to the *ang code.
>
> Of course my opinion is slightly biased... ;-)
>
>
> Regards,
>
> Dave
David T. Blackston
Franklin Bratcher <ach...@ticnet.com> wrote:
>
>"Ben Harrison" <be...@phial.com> wrote in message
>news:l8hfclc...@eel.curl.com...
>>
>> Personally, I feel that the autosquelch code is a *horrible* idea.
>>
>> It is one thing to make code which automatically has the *character*
>> destroy stuff that he picks up and does not like, but to have the *game*
>> do it, thus increasing the odds that any particular object is valuable,
>> is a massive gameplay imbalance.
>
>Hmm, ouch, I thought it just autosquelched what you picked up. If it
>squelches item generation, forget about it.
As noted in my previous post, the old patch did squelch when the item
was generated, but it did not affect the probabilities at all so there
were only minor effects on balance. The newest version of the patch
only squelches when you walk on an object.
>I agree there, but it would be
>nice to have the cursed items, etc, squelched as your character pseudo-id's
>them. Yeah, I'm a lazy bum, ;O).
>
Me too. That's why the patch also does this. Please note that
this type of squelching is different from the squelching done
when you walk on an object. This type of squelching only occurs
when a weapon/armor is (pseudo)-identified. Thus cursed armor/weapon(s)
are generated with exactly the same frequency and only squelched when
the fact that they're cursed is known.
>
Regards,
Dave
Ben Harrison
"Franklin Bratcher" <ach...@ticnet.com> writes:
> Phew, good, I thought thats what it did, Ben scared me with the
> autosquelching the item generation.
>
> "David T. Blackston" <dav...@melody.CS.Berkeley.EDU> wrote in message
> news:8edus9$aju$1...@agate.berkeley.edu...
> > With all due respect, I don't think you've been following
> > the progress of the autosquelching code.
True. :-)
> > The current version
> > under consideration by the devteam only squelches objects
> > when they are walked on, just as you suggest here.
> > (Actually, come to think of it I don't know that I announced
> > the modified patch here, so if I didn't, please accept my
> > apologies and rest assured that any version of the patch that
> > I release in the future will only squelch objects when the
> > player walks on them.)
I kind of wish I had finished simplifying the "energy" code, so that
there was a consistant story about how long it should take to pick
things up, drop them, destroy them, use them from the ground, etc,
but doing that "right" is non-trivial. But meanwhile, to avoid the
patch affecting gameplay, it should probably make sure that there
is an appropriate "energy cost" to squelching.
For "semantic consistancy", I would probably suggest that the
squelching only fire during a "pickup" (that is, if auto-pickup
is true, it can happen on walking, else, it should wait for a
pickup command), but I will let others evaluate the gameplay
issues here. It may be that this *is* a good time to clean up
the "energy" issues, especially the ones involving objects on
the ground, which never did get thought about when I added the
code to interact with floor objects "for free".
In any case, it sounds like the patch is well on the way to being
something that would exist in my perfect world, and I look forward
to seeing an announcement that it has been cleaned up and playtested
and submitted to Vanilla Angband! :-)
--- Ben ---
shren
> Personally, I feel that the autosquelch code is a *horrible* idea.
> It is one thing to make code which automatically has the *character*
> destroy stuff that he picks up and does not like, but to have the *game*
> do it, thus increasing the odds that any particular object is valuable,
> is a massive gameplay imbalance.
Note that the distribution of items is still the same. It doesn't
replace icky items with good items. But I bet you knew that.
If it's tedium you're looking for, macros should be taken out. And the
rest key - why should you automatically wake up when danger comes? Nah,
you should have to hit the 5 key until your mana restores - and RNG help
you if you miss a monster wandering in.
> In my own personal universe, you would be able to specify, for each
> "k_idx" value, if it should be picked up, destroyed, or ignored, when
> you walk on it (if "aware", of course), and an option for "destroy any
> identified junk" would allow any "worthless" objects to be "destroyed"
> as soon as they were "identified". But they would still be *generated*,
> and monsters would still drop them, forcing you to wade through the junk
> to find the good stuff (and taking game time to do so, which is really
> tough when playing a slow mage character).
The autosquelcher does many things, but none of them really do anything
other than keep the dungeon less cluttered with items that you have ided
and know that you don't want (potions of slow poison), or throw things
that you id or pusedoid out of your bag automatically.
In a lot of ways, I agree with you. I don't use all of the features of
the autosquelcher. But the autosquelcher, like the autoscummer, has it's
risks. With the autoscummer, you could get a really deadly level. With
the autosquelcher, you could accidently squelch something that you needed,
like a scroll of remove curse or a potion of stat restoration. I once
starved to death using the autosquelcher because I squelched food items,
then my spellbooks got toasted, and I was running around looking for food.
Which . . . I squelched. Didn't realize what I had done untill long
after "you die."
> And I really hope Robert moves beangband from "Source" to "Variant",
> where it belongs, but that is a separate issue....
Given that it is a test version for short term use, is only just a
compilation with patches and not a variant, and that there might be a new
version every two weeks or so, I'm going to put it on a web site and give
out the link, so we don't *need* to have this discussion. It won't be in
the archive at all, it really doesn't belong there, especially with the
space issues. I can't think of any file in the archive that I'd throw out
to make room for BEangband. Not the old versions - I'm thinking about
playing them. Not any variant - a *whole* lot more work goes into them
than the two or three hours that I spend patching and compiling. Not the
graphic files, or the spoilers, or anything else... It's a compilation,
and a compilation of stuff that's already present in the archive in some
form or another. So I'll manage it myself. In summary - no version other
than the a version will be uploaded to the archive, unless requested. You
angband code gurus don't need to deal with me. *grin*
But *it* *is* *not* *a* *variant*. When I write a variant I'll be sure
to let everyone know. But this is just an experimental version so
non-compiler inclined people can try out the new patches, so we can talk
about how there's no way they'l get into 2.9.1.
Shren
Venkatesh Natarajan
>
> Personally, I feel that the autosquelch code is a *horrible* idea.
>
> It is one thing to make code which automatically has the *character*
> destroy stuff that he picks up and does not like, but to have the *game*
> do it, thus increasing the odds that any particular object is valuable,
> is a massive gameplay imbalance.
>
But there would be much fewer objects. . . I don't see
how it's doing anything that a Character can't do for himself.
> People don't seem to realize that Angband itself is nothing but tedium
> (though mesmerizing, for some reason, nonetheless). Think about it,
I actually don't completely agree with this -- things get quite
interesting, for me, as I pass 2500'.
> all you do is walk around wacking things and taking their stuff. And
> people want to streamline the tedium. Why not simply give people a fully
> decked out level 50 character, and remove the top 99 levels from the
> dungeon? That would speed things up....
>
Because it's a non-trivial task (unlike destroying objects that
one finds) in which the chance of dying on the way *to* level 50
is high.
[snip]
Venkatesh Natarajan
v...@andrew.cmu.edu
The Andrew Lorraine of alt.sports.baseball.chicago-cubs
Chris Weisiger
>
> Personally, I feel that the autosquelch code is a *horrible* idea.
>
> It is one thing to make code which automatically has the *character*
> destroy stuff that he picks up and does not like, but to have the *game*
> do it, thus increasing the odds that any particular object is valuable,
> is a massive gameplay imbalance.
Not really. Items are destroyed after being generated, so while the
ratio of good items to junk is higher, the actual number of good items
is the same (or less).
Of course, that doesn't stop me from thinking that the autosquelch
patch is a bit of a cheat, if only because it saves the character ID
scrolls/spells by dumping all the worthless swords and armors. I
wouldn't mind using it for just the worthless flavored items; they're
about as common as weapons and armor, but the player already knows what
they are, so the "cheat" aspect of the patch is minimized.
--
"Don't take life so serious, son, it ain't nohow permanent." -Porkypine
The Angband Newbie Guide: http://home4.pacific.net.sg/~jianson/tang/tang.html
VaultMania: http://home4.pacific.net.sg/~jianson/vaults/vaults.html
David T. Blackston
Chris Weisiger <jma...@inreach.com> wrote:
>Ben Harrison wrote:
>>
>> Personally, I feel that the autosquelch code is a *horrible* idea.
>>
>> It is one thing to make code which automatically has the *character*
>> destroy stuff that he picks up and does not like, but to have the *game*
>> do it, thus increasing the odds that any particular object is valuable,
>> is a massive gameplay imbalance.
>
> Not really. Items are destroyed after being generated, so while the
>ratio of good items to junk is higher, the actual number of good items
>is the same (or less).
> Of course, that doesn't stop me from thinking that the autosquelch
>patch is a bit of a cheat, if only because it saves the character ID
>scrolls/spells by dumping all the worthless swords and armors.
No it doesn't. Worthless armor and weapons are squelched only after
they've been identified or pseudoidentified. You still wither have to
use a scroll/spell of identify or wait for pseudo-id to kick in.
shren
> Ben Harrison wrote:
>>
>> Personally, I feel that the autosquelch code is a *horrible* idea.
>>
>> It is one thing to make code which automatically has the *character*
>> destroy stuff that he picks up and does not like, but to have the *game*
>> do it, thus increasing the odds that any particular object is valuable,
>> is a massive gameplay imbalance.
> Not really. Items are destroyed after being generated, so while the
> ratio of good items to junk is higher, the actual number of good items
> is the same (or less).
> Of course, that doesn't stop me from thinking that the autosquelch
> patch is a bit of a cheat, if only because it saves the character ID
> scrolls/spells by dumping all the worthless swords and armors. I
> wouldn't mind using it for just the worthless flavored items; they're
> about as common as weapons and armor, but the player already knows what
> they are, so the "cheat" aspect of the patch is minimized.
It doesn't dump something unless you *know* what it is. Once you know
what a potion of poison is, by iding it, it doesn't get generated anymore.
But a cursed whip won't get squelched until you know what it is, or unless
you squelch *all* whips. (hey, I don't like whips and daggers - I think
they make goofy dungeon weapons. I can squelch them all!) So all those
weapons of unknown status still appear in the dungeon.
Julian Lighton
David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote:
>With all due respect, I don't think you've been following
>under consideration by the devteam only squelches objects
>when they are walked on, just as you suggest here.
>
>(Actually, come to think of it I don't know that I announced
>the modified patch here, so if I didn't, please accept my
>apologies and rest assured that any version of the patch that
>I release in the future will only squelch objects when the
>player walks on them.)
With stacking and the ability to look at the contents of a stack from
a distance, (a feature from Oangband I've been missing in 2.9) squelch
on generation is just (in theory), saving you the time it takes to
check whether the stack's worth bothering with, while reducing the odds
of object compaction, which is something the game should never ever
do if it can avoid it.
--
Julian Lighton jl...@fragment.com
"Why do your people always ask if someone is ready right before you
are about to do something massively unwise?"
"Tradition" -- Babylon 5
Jonathan Ellis
Julian Lighton wrote in message ...
>In article <8edus9$aju$1...@agate.berkeley.edu>,
>David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote:
>>With all due respect, I don't think you've been following
>>the progress of the autosquelching code. The current version
>>under consideration by the devteam only squelches objects
>>when they are walked on, just as you suggest here.
>>
>>(Actually, come to think of it I don't know that I announced
>>the modified patch here, so if I didn't, please accept my
>>apologies and rest assured that any version of the patch that
>>I release in the future will only squelch objects when the
>>player walks on them.)
>
>With stacking and the ability to look at the contents of a stack from
>a distance, (a feature from Oangband I've been missing in 2.9) squelch
>on generation is just (in theory), saving you the time it takes to
>check whether the stack's worth bothering with,
this: you set this option to squelch all known item types. Now, nothing
can be generated except artifacts (which of course cannot be destroyed.)
So you can see IMMEDIATELY how many artifacts are in a vault.
Squelch on walking over the items, fine. Squelch on generation so
that you never even see the item, no.
Jonathan.
Jason Willoughby
> Which is exactly *WHY* you shouldn't squelch on generation. Imagine
> this: you set this option to squelch all known item types. Now, nothing
> can be generated except artifacts (which of course cannot be destroyed.)
So destroy them anyway. If you don't want to see daggers, there's no
reason to assume the 'thancs are excluded.
Jonathan Ellis
Jason Willoughby wrote in message ...
disenchantment resistance) that way. Or indeed - squelch daggers, and
find out that you've just missed out on one of the 'thancs early on,
just at the critical time when you need about another 7000 gold to buy a
stat potion from the BM? (The latter being a very common situation
around 1000'-1500', when I would normally prefer other weapons to the
'thancs.) No thanks. And indeed, no 'thancs... Artifacts HAVE to be
excluded from autosquelching.
Which means that weapons and armor would have to be treated
differently to potions, scrolls, staffs etc. - i.e. squelch all potions
of a certain type (e.g. death, lose stat, cure light wounds once you can
afford CCW, etc.), but squelch all weapons and armor of a certain
quality (average, cursed, "good", "excellent" depending on choice - the
latter ignoring the fact that, in ZAngband at least, a Holy Avenger with
+4 attacks can be better than most artifacts.)
And what do you do when someone turns on the autosquelch in the
early stages of the game, knowing that he can pick up nothing but good
items? People *will* scum with it, you know.
And then what happens when, as I said, you meet a vault and want to
know whether it is worth taking on the monsters there? If you can
already see what's there (or, if you squelch on generation, isn't
there), there's no reason to enter it at all. And there should be a
reason to enter vaults, if only to see what's inside: it might be
useless, or it might contain great items, or it might contain nasty
monsters, but there MUST be no way to ascertain what quality the items
are (or at least, what quality the weapons and armor are) without
entering that vault. Okay, some of the items might be known to be
useless, but there might well be a great item in there. However, if you
automatically know which one it is, it ruins the entire point of the
game. One might as well hack the *info.txt files to give all items of
the "wrong" types a level/rarity of 100/100 and all items of the "right"
type a level/rarity of 1/1... Oh, and while you're at it, give Maggot
the QUESTOR and DROP_CHOSEN flags, and a 20,000,000 experience point
reward for killing him, and get rid of the rest of the monsters. Then go
away and play something else that requires less patience. Such as
multiplayer Quake, where you can pick up enough weapons to be
ultra-powerful in a few minutes and kill the toughest monsters in the
game (the other players) in one or two shots.
Which is why I suggest that items of the "wrong" type should be
autosquelched *as you walk over them*, not before (differing from the
current "k" command in that it takes no game time and does not require a
keypress) - and weapons and armor should be squelched *as you ID or
pseudo-ID them*, not before.
Otherwise you get situations like this:
- quaff a potion of enlightenment or activate the Arkenstone...
- "Oh look, a vault".
- "But there's nothing in there at all, everything must have been
squelched."
- "So I won't bother to enter."
Or...
- "Hey, it's not worth opening up the rest of this GCV. Nothing
there but monsters, all the artifacts were in the top left corner."
Or...
"Oh look, a great empty area of the level with no items on the
ground. I'll ignore that area completely, because I'm scumming for
healing/gain stat potions/scrolls of rune of protection and I can't be
bothered to go round killing monsters for them when I can wait for them
to be generated on the ground and find them automatically."
And what happens when a "squelched" item turns up in the stores or the
black market? Do you force all items in the shop to be of good quality?
Do you force every slot in the Temple's shop to be filled up with the
"right" sort of potion? What about the Black Market - will it eventually
stock up on nothing but ego-items, potions of healing and Rings of Speed
on the grounds that everything else is squelched on generation?
Absurd, isn't it?
Jonathan.
David T. Blackston
Jonathan Ellis <jona...@franz-liszt.freeserve.co.uk> wrote:
>
>Jason Willoughby wrote in message ...
>>Jonathan Ellis, a beast of pure hatred with purpose malign, wrote:
>>> Which is exactly *WHY* you shouldn't squelch on generation.
>Imagine
>>> this: you set this option to squelch all known item types. Now,
>nothing
>>> can be generated except artifacts (which of course cannot be
>destroyed.)
>>
>>So destroy them anyway. If you don't want to see daggers, there's no
>>reason to assume the 'thancs are excluded.
> But you might well lose, for instance, Rilia (poison and
>disenchantment resistance) that way. Or indeed - squelch daggers, and
>find out that you've just missed out on one of the 'thancs early on,
>just at the critical time when you need about another 7000 gold to buy a
>stat potion from the BM? (The latter being a very common situation
>around 1000'-1500', when I would normally prefer other weapons to the
>'thancs.) No thanks. And indeed, no 'thancs... Artifacts HAVE to be
>excluded from autosquelching.
I disagree with this reasoning. If a player is choosing to exclude
daggers then there is no reason to exclude the artifct daggers from
squelching. It is their choice to squelch daggers, and they should
be willing to accept the consequences of that choice.
> Which means that weapons and armor would have to be treated
>differently to potions, scrolls, staffs etc. - i.e. squelch all potions
>of a certain type (e.g. death, lose stat, cure light wounds once you can
>afford CCW, etc.), but squelch all weapons and armor of a certain
>quality (average, cursed, "good", "excellent" depending on choice - the
>latter ignoring the fact that, in ZAngband at least, a Holy Avenger with
>+4 attacks can be better than most artifacts.)
They are treated differently in the patch. Please see the bottom of this
post.
> And what do you do when someone turns on the autosquelch in the
>early stages of the game, knowing that he can pick up nothing but good
>items? People *will* scum with it, you know.
Please tell me how it can be scummed. You don't seem to understand how
the patch works.
> And then what happens when, as I said, you meet a vault and want to
>know whether it is worth taking on the monsters there? If you can
>already see what's there (or, if you squelch on generation, isn't
>there), there's no reason to enter it at all. And there should be a
>reason to enter vaults, if only to see what's inside: it might be
>useless, or it might contain great items, or it might contain nasty
>monsters, but there MUST be no way to ascertain what quality the items
>are (or at least, what quality the weapons and armor are) without
>entering that vault. Okay, some of the items might be known to be
>useless, but there might well be a great item in there. However, if you
>automatically know which one it is, it ruins the entire point of the
>game. One might as well hack the *info.txt files to give all items of
>the "wrong" types a level/rarity of 100/100 and all items of the "right"
>type a level/rarity of 1/1... Oh, and while you're at it, give Maggot
>the QUESTOR and DROP_CHOSEN flags, and a 20,000,000 experience point
>reward for killing him, and get rid of the rest of the monsters. Then go
>away and play something else that requires less patience. Such as
>multiplayer Quake, where you can pick up enough weapons to be
>ultra-powerful in a few minutes and kill the toughest monsters in the
>game (the other players) in one or two shots.
Now you're being absurd. If you use the extended look command you
can also tell whether there are any useful flavored items in a
vault and hence whether the vault is worth entering. Autosquelch
on generation doesn't change this. Moreover, it doesn't afftect
the generation probabilities of weapons. There can still be
'cursed' items generated and placed.
>
> Which is why I suggest that items of the "wrong" type should be
>autosquelched *as you walk over them*, not before (differing from the
>current "k" command in that it takes no game time and does not require a
>keypress) - and weapons and armor should be squelched *as you ID or
>pseudo-ID them*, not before.
And the current version of the patch does _exactly_ this.
>Or...
>
> "Oh look, a great empty area of the level with no items on the
>ground. I'll ignore that area completely, because I'm scumming for
>healing/gain stat potions/scrolls of rune of protection and I can't be
>bothered to go round killing monsters for them when I can wait for them
>to be generated on the ground and find them automatically."
This is no different than if one used a potion of enlightenment and
then the extended look command to lok at the flavored items on
a level. In other words, this already exists and no-one seems to mind.
>
>And what happens when a "squelched" item turns up in the stores or the
>black market? Do you force all items in the shop to be of good quality?
>Do you force every slot in the Temple's shop to be filled up with the
>"right" sort of potion? What about the Black Market - will it eventually
>stock up on nothing but ego-items, potions of healing and Rings of Speed
>on the grounds that everything else is squelched on generation?
>
>Absurd, isn't it?
>
>Jonathan.
>
>
It would be, if this were how it worked. It really bothers me that
you took the time to write out this lengthy criticism when you clearly
haven't even bothered to look at the patch. Please read what follows
before commenting futher on the patch -- it's difficult enough to
promote this patch without people spreading misinformation about it.
First, I'll admit that the old version of the patch had one of the
problems you mentioned. Artifacts were never squelched even if
their item type was squelched and this could lead to unbalancing
situations such as the almost empty GCV. However, a one line change
to the code would have allowed artifacts to be squelched, and this
feature isn't present in the newest squelch-on-walk-over version
of the patch. For the rest of this discussion I'll focus on
squelch-on-walk-over version as this is the one that is
under consideration by the devteam.
All the other "problems" you mentioned are either already present in
the game or are just based on an incorrect understanding of what
the patch does.
There are two types of squelching in the patch and they are
handled in different menus. The squelch-on-walk-over allows the
user to specify whay item types (TVAL, SVAL) are "junk", and
whenever the user walks over a junk item it is squelched for free.
For flavored items, the user must be aware of the item before
it can be squelched. Artifacts are never squelched here as
it is assumed that the user would simply try to "k" all the
junk items on the floor and artifacts would survive this process
even if their (TVAL, SVAL) were classified as "junk".
The second type of squelching is a squelch-on-quality that
only affects weapons and armor. It allows the user to
specify a quality ("cursed", "average", "good", etc.) and
to squelch weapons/armor below that quality _once the quality
has been determined_ through identification or pseudo-identification.
This only affects items in your pack or on the ground. This
type of squelching is handled simply by the TVAL of the item.
In no cases are the object generation probabilities changed
nor are the stores affected in any way.
This patch is merely designed to streamline the process of
sorting through piles and piles of useless items. I can
think of no major balance issues that result from this change.
It simply removes some of the tedium from the game.
Regards,
Dave
Jonathan Ellis
David T. Blackston wrote in message <8ehnrr$l3e$1...@agate.berkeley.edu>...
>And the current version of the patch does _exactly_ this.
Erm, sorry. It's just that there was so much talk about people
demanding the suppression of certain items _on generation_ that I was
worried it might actually get implemented (and thought that was the way
things were heading.)
Next time I'll actually try playtesting it if anybody has a Windows
compiled version of it.
Jonathan.
David T. Blackston
Jonathan Ellis <jona...@franz-liszt.freeserve.co.uk> wrote:
>
>David T. Blackston wrote in message <8ehnrr$l3e$1...@agate.berkeley.edu>...
>
No problem. I'm also sorry about the tone of my last post. I was
just a little frustrated.
>It's just that there was so much talk about people
>demanding the suppression of certain items _on generation_ that I was
>worried it might actually get implemented (and thought that was the way
>things were heading.)
> Next time I'll actually try playtesting it if anybody has a Windows
>compiled version of it.
>
The current Vanilla patch doesn't yet have squelch-on-walk-on, but I'll
put it in in the next week and get the patch to shren so that it can
appear in the next BEAngband. (If I could compile on Windows I'd do
it myself, but I can't.)
>Jonathan.
>
Regards,
Dave
James W Sager Iii
BEangband OWNS! by "Ben Harrison"@phial.com
> destroy stuff that he picks up and does not like, but to have the *game*
> do it, thus increasing the odds that any particular object is valuable,
> is a massive gameplay imbalance.
You can look at any object from a distance and determine what it is.
There is no gameplay affect noticed through a destroyed item anyway.
Therefore nothing is changed. Alot of the bad stacking interface code
is actually improved with autosquelch.
You can look through walls and see what an item is because you can
'detect' through walls with spells. No extra information is gained, it
just increases the speed in which you sort through items IE not wasting
the players time picking through trash.
James W Sager Iii
> the progress of the autosquelching code. The current version
> under consideration by the devteam only squelches objects
> when they are walked on, just as you suggest here.
> (Actually, come to think of it I don't know that I announced
> the modified patch here, so if I didn't, please accept my
> apologies and rest assured that any version of the patch that
> I release in the future will only squelch objects when the
> player walks on them.)
UGH! Squelching on walking.
Thats a hideous thing. Why the heck would you want to maul something
that works? Is there a single good reason why you'd want squelching
when walking on objects? Riddle me this.
James W Sager Iii
> nice to have the cursed items, etc, squelched as your character pseudo-id's
> them. Yeah, I'm a lazy bum, ;O).
Nothing squelches on quality during generation.
There is squelch by name though, so if you want to destroy all rings of
protection you will destroy the ones with +s as well as -'s.
there is squelch on psuedo id though, after you determine if its good
bad average etc, if you set it up in Dave's menus as being destroyed, it
gets removed with no keypresses to yourself.
James W Sager Iii
> > > under consideration by the devteam only squelches objects
> > > when they are walked on, just as you suggest here.
> > > (Actually, come to think of it I don't know that I announced
> > > the modified patch here, so if I didn't, please accept my
> > > apologies and rest assured that any version of the patch that
> > > I release in the future will only squelch objects when the
> > > player walks on them.)
>
> there was a consistant story about how long it should take to pick
> things up, drop them, destroy them, use them from the ground, etc,
> but doing that "right" is non-trivial. But meanwhile, to avoid the
> patch affecting gameplay, it should probably make sure that there
> is an appropriate "energy cost" to squelching.
I agree with the consistancy needed for the energy code.
I disagree with the energy needed for squelching as you're only making
the nonstandardization problem harder. Before one makes it cost stuff
to autosquelch stuff, deal with the energy problem. This is not a
problem brought up by the autosquelch system, this is a problem that has
been in the code for a while, and since no one can make a good argument
why autosquelching isn't right, they bring up the energy code.
You can either ignore the item altogether or squelch it and both have
the same results, so why should it take time to squelch something?
1) Autosquelching a pseudo ided item in your backpack->
Takes 0 turns, maybe you needed to reduce weight...
Defense not really like you intended to drop your armor to get a +1
speed to get you out of a battle... No real play balance lost here.
2)Potion of healings shattering->
Since its squelched, shattered items and stuff don't have random
effects... This is the biggest one I could see, but still not anthing to
write home about.
2 more balance issues
a)keeping standards with the hacky stack code-> Since you can only see
the top item of a pile with the 'l'ook command, why should you be able
to sort through it?
This patch gives you more power in that respect, but I believe the stack
code was hacky. there is no reason you can't see a gleaming dragon armor
under a biscut.
b)Color coding and 'L'ooking outside your radius. By using
enlightenment, you can see the whole dungeon. But only 'l' lets you id
items around you. The items far away have color, so you can gues what
they are, but you can't tell what they are until you get within 1 block
of em.
Again, I think this is hacky. And the squelch code gets rid of this
stupid part of game play where you need to get kinda close to an item to
see it.
Essentially the current code kinda bandages up some weak code written earlier.
James W Sager Iii
> scrolls/spells by dumping all the worthless swords and armors. I
> wouldn't mind using it for just the worthless flavored items; they're
> about as common as weapons and armor, but the player already knows what
> they are, so the "cheat" aspect of the patch is minimized.
Cheat? i don't understand you, by saying using ID on worthless armors
and weapons, you seem to assume it squelches by quality upon creation...
Which it doesn't.
James W Sager Iii
BEangband OWNS! by "Jonathan Ellis"@franz-l
> >a distance, (a feature from Oangband I've been missing in 2.9) squelch
> >on generation is just (in theory), saving you the time it takes to
> >check whether the stack's worth bothering with,
> this: you set this option to squelch all known item types. Now, nothing
> can be generated except artifacts (which of course cannot be destroyed.)
> Squelch on walking over the items, fine. Squelch on generation so
> that you never even see the item, no.
So you really love the stacking code that was put in a couple months ago
with the ability to only look at the item on the top from afar.
Remember it wasn't long ago that piles weren't implemented, and items
got destroyed if there was no place to put them on the floor. Maybe
that was better?
I can't see how anyone things thats a good idea, it was just put in as a
hack because items used to get destroyed if there wasn't room to put
them on the floor in a nice manner.
You could see the artifacts before the autosquelch code was intitated.
In fact you're supposed to see every artifact thats in there. That is
what the detect spell does. If you want to make vaults stronger, you
should propose that vaults don't show up on detection. Maybe you don't
want artifacts to be seen a certain percentage of the time? Then add
code that makes artifacts be camoflauged a certain % of the time. You
really don't seem to have a good argument against autosquelching though.
James W Sager Iii
Why should you see artifact daggers if you don't want to see daggers at all..
this is gameplay...
I suggest you take out the primary squelch feature for any item that can
be an artifact and only allow them to be in the secondary menu. This
would solve everything.
James W Sager Iii
The squelch menu should not even have a primary squelch menu for any
item that has the ability to be an artifact.
By saying squelch everything but the artifacts, you can abuse the
autosquelcher.
look at this scenerio:
EVERYTHING IS SQUELCHED.
Then you only see artifacts on the dungeon.
By using enlightenment and the 'L'ook command you can find every artifact
because thats the only thing seen.
bad bad bad
The obvious fix is removing the items that can be artifacts from primary
squelching. Personally I never used this option anyway as I never saw
any use for it.
James W Sager Iii
> > this: you set this option to squelch all known item types. Now, nothing
> > can be generated except artifacts (which of course cannot be destroyed.)
>
> reason to assume the 'thancs are excluded.
WAIT! Julian is right! Sorry about the reeming before. heh :)
My bad. Any thing that is an artifact should not be present in the
primary squelch menu! I'll email dave about this so he sees.
David T. Blackston
James W Sager Iii <sag...@andrew.cmu.edu> wrote:
>
>The squelch menu should not even have a primary squelch menu for any
>item that has the ability to be an artifact.
>
Disagree. If I don't want to deal with broken daggers then I shouldn't have
to.
>By saying squelch everything but the artifacts, you can abuse the
>autosquelcher.
>
>
>look at this scenerio:
>EVERYTHING IS SQUELCHED.
>
>Then you only see artifacts on the dungeon.
>By using enlightenment and the 'L'ook command you can find every artifact
>because thats the only thing seen.
>
>bad bad bad
I agree that this is a bad thing, and that's why I changed the
semantics from squelch-on-generation to squelch-on-walk-on.
>
>The obvious fix is removing the items that can be artifacts from primary
>squelching. Personally I never used this option anyway as I never saw
>any use for it.
>
That's one fix, but changing the semantics is another fix that also works.
The squelch-on-walk-on semantics don't affect balance at all (as far as
I can see) and are not scummable in any way (again, as far as I can see).
Plus, it's actually easier to code these semantics than the
squelch-on-generation semantics and they allow for access to every
(TVAL, SVAL) pair.
Regards,
Dave
Lev Zakrevski
James W Sager Iii wrote:
>
> Nothing squelches on quality during generation.
>
> There is squelch by name though, so if you want to destroy all rings of
> protection you will destroy the ones with +s as well as -'s.
>
> there is squelch on psuedo id though, after you determine if its good
> bad average etc, if you set it up in Dave's menus as being destroyed, it
> gets removed with no keypresses to yourself.
First, would like to mention that I strongly support the idea of the
discussed patch, since I have found to spend about 1/3 of the playing
time
trying to destroy unwanted objects. Usually, I use some sort of
fire/acid
ball attack to reduce the number of them, but this technique is very
crude
and will destroy many useful things...
The most useful (for me) would be "squelch by name" approach. To
increase
it efficiency, without coming into cheating area, I would suggest the
following switches, which can be used with "squelch by name" method:
1) do not destroy weapons with unusual base damage (1d5 dagger, etc).
2) do not destroy unique drops.
Both switches do not give any new information to player, so I would not
consider them a cheat.
On the other side, when "squelch by name" is being used for long swords,
artifact swords with unmodified base damage should not be generated.
Also, it can be a good idea to create several predefined "squelch" sets,
which can be loaded by player (for example, level10set, level20lset,
etc)
Of course, there should be a possibility to modify them.
Hope that somebody will compile a DOS version of Angband/Zangband with
this patch... Btw, does anybody know, if Zangband development will
continue? There have been no changes in development version for a long
time...
Lev Zakrevski
David T. Blackston
The squelch-on-walk-on semantics will probably give you just
about everything you want here. Instead of acid-bolting the
pile, you walk over it and all the junk magically disappears.
I've been playing it for a while now and it seems to work pretty
well.
When I have time I do plan to add some file i/o so that squelch settings
can be saved and loaded.
Regards,
Dave
Chris Kern
the following:
> Btw, does anybody know, if Zangband development will
>continue? There have been no changes in development version for a long
>time...
Yes, a new development version should be out fairly soon.
-Chris
Chris Kern
<sag...@andrew.cmu.edu> posted the following:
>UGH! Squelching on walking.
>Thats a hideous thing. Why the heck would you want to maul something
>that works? Is there a single good reason why you'd want squelching
>when walking on objects? Riddle me this.
Of course, and if you'd been paying attention you'd know that.
Hitting "k-" * 100,000 takes up a lot of time.
-Chris
shren
> The current Vanilla patch doesn't yet have squelch-on-walk-on, but I'll
> put it in in the next week and get the patch to shren so that it can
> appear in the next BEAngband. (If I could compile on Windows I'd do
> it myself, but I can't.)
Work is hell right now but there will be a BEAngband b soon.
Ben Harrison
Well, some people would claim that a version of Angband with haggling
bonuses disabled would be a "variant", that is, that "variant" simply
means "something different from the norm", so those people would consider
"beangband" to be a variant. That being said, there is no reason you
should feel compelled to send precompiled versions of beangband to the
standard archives, since, as you point out, your "variant" is really just
a collection of "patches".
That being said, I have hopes that some clean version of auto-squelching
will make it into the standard game at some point.... :-)
--- Ben ---
shren <sh...@io.com> writes:
> > And I really hope Robert moves beangband from "Source" to "Variant",
> > where it belongs, but that is a separate issue....
>
> Given that it is a test version for short term use, is only just a
> compilation with patches and not a variant, and that there might be a new
> version every two weeks or so, I'm going to put it on a web site and give
> out the link, so we don't *need* to have this discussion. [...]
> But *it* *is* *not* *a* *variant*. When I write a variant I'll be sure
> to let everyone know. But this is just an experimental version so
> non-compiler inclined people can try out the new patches, so we can talk
> about how there's no way they'l get into 2.9.1.
Ben Harrison
Not everybody plays with the "let me look through walls" option, though
personally, I cannot imagine being such a person....
--- Ben ---
Ben Harrison
Huh?
I think people are confused.
Unless the code is broken, you are *supposed* to be able to hit "r"
when you see a pile of items to see the complete list (if using the
"easy_floor" option) or else hit "return" to see the next item (if
not using the "easy_floor" option). Or is this broken?
--- Ben ---
James W Sager Iii <sag...@andrew.cmu.edu> writes:
Ben Harrison
Make sure to do them as user pref options.
Personally, I would recommend simply having an array of "char"
of size "MAX_K_IDX", where the "char", if non-zero, says what
to do when walking on an object of that type (if aware), with
"k" being "destroy", "E" being "eat", "g" being "get", etc.
That would allow "auto-squelch" to actually be even more powerful
than it is already....
Plus, it would be easy to save in the user pref files, as, say,
"I:<num>:<cmd>".
--- Ben ---
shren
> The squelch menu should not even have a primary squelch menu for any
> item that has the ability to be an artifact.
> By saying squelch everything but the artifacts, you can abuse the
> autosquelcher.
> look at this scenerio:
> EVERYTHING IS SQUELCHED.
> Then you only see artifacts on the dungeon.
> By using enlightenment and the 'L'ook command you can find every artifact
> because thats the only thing seen.
> bad bad bad
> The obvious fix is removing the items that can be artifacts from primary
> squelching. Personally I never used this option anyway as I never saw
> any use for it.
You are making it blatantly obvious that you haven't actually USED the
autosquelching code. There's two levels of squelching.
1) Blocked generation. This is done on a type of item. I can squelch
*all* longswords, or all potions of poision (If I've ided a potion of
poison.) If I squelch all daggers, I'll *never* see any dagger in the
dungeon. If I don't, then I'll see every dagger that I would see with
normal Angband. I can squelch potions by type, but you can see from
across the screen what type a potion is, anyway.
2) Auto-removal from backpack upon identify. All this does is
automatically get rid of items that you don't want, *once you know what
they are*. If you picked up a longsword, and your pusedo id kicks on and
tells you that it's cursed, and you squelch cursed objects, then it will
automatically be destroyed. There is no substantial possibility of game
inbalance here - all it is saving you from is using the destroy command by
hand.
I think autosquelching balances game balance and tedium removal really
well. If you are playing a warrior with the good pusedoid they get, then
you could turn on autopickup and grab everything, then the crap would be
thrown out as you spot it. Autosquelching makes it concievable that
people might play with autopickup on past 500', because you can keep the
utter crap, obviously cursed (identifited wands of haste monster, potions
of lose memories) from being generated, and you can pickup all those
unidentified weapons and armor secure in the knowledge that the sucky ones
will be thrown out automatically.
Mathias has 3 small pickup options that would almost assure that you can
do this, in combination with the squelching code.
David T. Blackston
>James W Sager Iii <sag...@andrew.cmu.edu> wrote:
>
>> The squelch menu should not even have a primary squelch menu for any
>> item that has the ability to be an artifact.
>
>> By saying squelch everything but the artifacts, you can abuse the
>> autosquelcher.
>
>> look at this scenerio:
>> EVERYTHING IS SQUELCHED.
>
>> Then you only see artifacts on the dungeon.
>> By using enlightenment and the 'L'ook command you can find every artifact
>> because thats the only thing seen.
>
>> bad bad bad
>
>> The obvious fix is removing the items that can be artifacts from primary
>> squelching. Personally I never used this option anyway as I never saw
>> any use for it.
>
> You are making it blatantly obvious that you haven't actually USED the
>autosquelching code. There's two levels of squelching.
Actually, James has been one of my best playtesters, and he's
right about this peculiarity of the version of the squelch patch
within BEangband.
Currently, artifacts are never squelched even if their item type is
known. This was a conscious decision on my part, and I admit that
I hadn't thought about all of the ramifications of this choice. If
you would like to remove this from BEangband, simply replace the line
return ((sq_flag && !j_ptr->name1)? FALSE : TRUE);
from make_object() in object2.c with
return (sq_flag ? FALSE : TRUE);
and artifacts will be squelched if their item type is to be squelched.
I'm sorry about this confusion. As I've mentioned, in the next version
of the patch items will be squelched when they are walked on, so this
will no longer be a problem.
> Mathias has 3 small pickup options that would almost assure that you can
>do this, in combination with the squelching code.
I'm curious to see these. Are they documented at Thangorodrim?
Regards,
Dave
Julian Lighton
Jonathan Ellis <jona...@franz-liszt.freeserve.co.uk> wrote:
>Julian Lighton wrote in message ...
>>With stacking and the ability to look at the contents of a stack from
>>a distance, (a feature from Oangband I've been missing in 2.9) squelch
>>on generation is just (in theory), saving you the time it takes to
>>check whether the stack's worth bothering with,
>this: you set this option to squelch all known item types. Now, nothing
>can be generated except artifacts (which of course cannot be destroyed.)
> Squelch on walking over the items, fine. Squelch on generation so
>that you never even see the item, no.
No, that's "Don't do squelch-on-generation wrong." If you don't want
the game to tell you about daggers, the game should not tell you about
daggers. Period. Dagger (+0,+0)? Nope. Dagger of Westernesse?
Nope. Rilia? Nope, and mark it as generated if preserve's off.
It automates the ability to ignore daggers yourself. Not destroy.
That requires you to possibly take a turn or two to do it. It
replaces 'l'looking across the room, noticing that the objects over
there are a dagger and a potion of slime mold juice, and continuing on
your way.
--
Julian Lighton jl...@fragment.com
"It's my final stand / I make a fist out of each hand
To shadows of the past / Take a breath, and I scream attack"
-- Iron Maiden
Julian Lighton
>>> this: you set this option to squelch all known item types. Now, nothing
>>> can be generated except artifacts (which of course cannot be destroyed.)
>>
>>reason to assume the 'thancs are excluded.
>disenchantment resistance) that way. Or indeed - squelch daggers, and
>find out that you've just missed out on one of the 'thancs early on,
>just at the critical time when you need about another 7000 gold to buy a
>stat potion from the BM?
Too bad. Guess you shouldn't have squelched daggers.
> (The latter being a very common situation
>around 1000'-1500', when I would normally prefer other weapons to the
>'thancs.) No thanks. And indeed, no 'thancs... Artifacts HAVE to be
>excluded from autosquelching.
To stop people from shooting themselves in the foot? Maybe it's
because I'm a C programmer, but I see no reason to protect people from
their own stupidity. (I do think "squelching items" should be changed
to "ignoring items" though, just to make it clear.)
> Which means that weapons and armor would have to be treated
>differently to potions, scrolls, staffs etc. - i.e. squelch all potions
>of a certain type (e.g. death, lose stat, cure light wounds once you can
>afford CCW, etc.), but squelch all weapons and armor of a certain
>quality (average, cursed, "good", "excellent" depending on choice - the
>latter ignoring the fact that, in ZAngband at least, a Holy Avenger with
>+4 attacks can be better than most artifacts.)
> And what do you do when someone turns on the autosquelch in the
>early stages of the game, knowing that he can pick up nothing but good
>items? People *will* scum with it, you know.
You don't let them.
> And then what happens when, as I said, you meet a vault and want to
>know whether it is worth taking on the monsters there? If you can
>already see what's there (or, if you squelch on generation, isn't
>there), there's no reason to enter it at all.
You can already do this with the look command.
[straw men snipped]
>And what happens when a "squelched" item turns up in the stores or the
>black market?
I'd say let them be generated in the stores. It's trivial to hook in
a squelch function that won't touch shop stocking.
--
Julian Lighton jl...@fragment.com
You are in a maze of twisty little passages, all different.
Julian Lighton
David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote:
>That's one fix, but changing the semantics is another fix that also works.
>The squelch-on-walk-on semantics don't affect balance at all (as far as
>I can see)
As described previously in the thread, they do, because artifacts are
not squelched. So, if you're in a hurry, you can squelch everything
before running across a cluttered battlefield, and scoop up the
artifacts as you go.
> and are not scummable in any way (again, as far as I can see).
>Plus, it's actually easier to code these semantics than the
>squelch-on-generation semantics and they allow for access to every
>(TVAL, SVAL) pair.
Really?
The UI considerations are the same for either version.
(using 285beta, because it's what I have handy. I'm assuming a
function squelch_test(tval,sval) that does the lookup. Once again,
either version needs this, though k_idx would be just as good, if not
better, to use instead.)
/*
* Let the floor carry an object
*
* Returns -1 if the object is being ignored by the player, 0 on
* failure, and the object list index on success.
*/
s16b floor_carry(int y, int x, object_type *j_ptr)
{
int n = 0;
s16b o_idx;
s16b this_o_idx, next_o_idx = 0;
if (squelch_tester(j_ptr->tval, j_ptr->sval))
{
if (adult_preserve && artifact_p(j_ptr))
/* Hack -- Preserve artifacts */
a_info[j_ptr->name1].cur_num = 0;
return -1;
}
/* rest of function */
This would probably work cleanly first time, though it makes a bad
assumption that no code does anything with the o_idx that it returns.
(This is the case, though.)
--
Julian Lighton jl...@fragment.com
"I need someone to show me the things in life that I can't find
I can't see the things that make true happiness I must be blind"
-- Black Sabbath
Julian Lighton
>James W Sager Iii <sag...@andrew.cmu.edu> writes:
>> So you really love the stacking code that was put in a couple months ago
>> with the ability to only look at the item on the top from afar.
>
>
>I think people are confused.
>
>Unless the code is broken, you are *supposed* to be able to hit "r"
>when you see a pile of items to see the complete list (if using the
>"easy_floor" option) or else hit "return" to see the next item (if
>not using the "easy_floor" option). Or is this broken?
Probably not. I was expecting it to use 'x', just like Oangband does,
and have been generally aggravated by the lack of the feature. If all
else fails, read the instructions. :)
Why 'r'? Symmetry with looking at monsters?
--
Julian Lighton jl...@fragment.com
"An object at rest cannot be stopped!!!!"
-- The Evil Midnight Bomber What Bombs at Midnight, _The Tick_
shren
>>James W Sager Iii <sag...@andrew.cmu.edu> wrote:
>>
>>> The squelch menu should not even have a primary squelch menu for any
>>> item that has the ability to be an artifact.
>>
>>> By saying squelch everything but the artifacts, you can abuse the
>>> autosquelcher.
>>
>>> look at this scenerio:
>>> EVERYTHING IS SQUELCHED.
>>
>>> Then you only see artifacts on the dungeon.
>>> By using enlightenment and the 'L'ook command you can find every artifact
>>> because thats the only thing seen.
>>
>>> bad bad bad
>>
>>> The obvious fix is removing the items that can be artifacts from primary
>>> squelching. Personally I never used this option anyway as I never saw
>>> any use for it.
>>
>> You are making it blatantly obvious that you haven't actually USED the
>>autosquelching code. There's two levels of squelching.
> Actually, James has been one of my best playtesters, and he's
> right about this peculiarity of the version of the squelch patch
> within BEangband.
t) In Mouth: Soft Leather Boots [2]
why do I *always* do these things to myself? Oops. I assumed it
didn't. A half dozen people say something about the autosquelching patch
that isn't true, and I don't speak up until somebody comes along that
knows something I don't.
*bangs head*
I think:
The first level of squelching should squelch artifacts if you tell it
to. If you squelch all longswords, you *deserve* to miss Ringil.
The second level I'm not so sure about. Would it squelch the nice
cursed sword? Should it? I don't miss cursed artifacts because I always
k) destroy something I'm going to throw away, and when I can't destroy it
I know it's an artifact. So maybe, in the same way, the secondary
squelching should not touch artifacts. "Why is this cursed sword in my
bag?"
>> Mathias has 3 small pickup options that would almost assure that you can
>>do this, in combination with the squelching code.
> I'm curious to see these. Are they documented at Thangorodrim?
Uh, no. Send me an email and I'll send you my copy. Or send Matthias
an email and he'll probably send you a copy. Although he did note that
they don't work exactly like he'd like. Here's a quote from him:
> A pickup_home option "Auto-pickup items that match home", a pickup_inv
> "Auto-pickup items that match inventory" and a pickup_unknown
> "Auto-pickup unknown items".
His gripe is that pickup_unknown picks up staves and wands that you
don't know the charge count of. But you see how these three options plus
the secondary squelching menu could let you cruise through the dungeon
very smoothly. If you squelched the wands and staves you didn't want in
the primary squelch then stuff flows into your backpack when you want it
to and gets tossed out automatically when you know you don't.
Sorry for spelling your name wrong earlier, btw, Matthias.
David T. Blackston
Julian Lighton <jl...@fragment.com> wrote:
>In article <8ehvl0$ltv$1...@agate.berkeley.edu>,
>David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote:
>>That's one fix, but changing the semantics is another fix that also works.
>>The squelch-on-walk-on semantics don't affect balance at all (as far as
>>I can see)
>
>As described previously in the thread, they do, because artifacts are
>not squelched. So, if you're in a hurry, you can squelch everything
>before running across a cluttered battlefield, and scoop up the
>artifacts as you go.
This seems like a very minor issue, but I admit that this is an effect
on balance. In any case, this balance issue is very small compared to
the gameplay benefit of a squelching patch "done right".
>
>> and are not scummable in any way (again, as far as I can see).
>>Plus, it's actually easier to code these semantics than the
>>squelch-on-generation semantics and they allow for access to every
>>(TVAL, SVAL) pair.
>
>Really?
>
>The UI considerations are the same for either version.
>
>(using 285beta, because it's what I have handy. I'm assuming a
>function squelch_test(tval,sval) that does the lookup. Once again,
>either version needs this, though k_idx would be just as good, if not
>better, to use instead.)
The squelch code does use k_idx.
>
>/*
> * Let the floor carry an object
> *
> * Returns -1 if the object is being ignored by the player, 0 on
> * failure, and the object list index on success.
> */
>s16b floor_carry(int y, int x, object_type *j_ptr)
>{
> int n = 0;
>
> s16b o_idx;
>
> s16b this_o_idx, next_o_idx = 0;
>
> if (squelch_tester(j_ptr->tval, j_ptr->sval))
> {
> if (adult_preserve && artifact_p(j_ptr))
> /* Hack -- Preserve artifacts */
> a_info[j_ptr->name1].cur_num = 0;
>
> return -1;
> }
>
>/* rest of function */
In the first version of the patch I modified make_object. Unfortunately
I had to check every call to make_object and make sure that a failed
return was handled correctly. It was a bit of a pain (especially
for OAngband with its varied chests).
>
>This would probably work cleanly first time, though it makes a bad
>assumption that no code does anything with the o_idx that it returns.
>(This is the case, though.)
>
>--
>Julian Lighton jl...@fragment.com
>"I need someone to show me the things in life that I can't find
> I can't see the things that make true happiness I must be blind"
> -- Black Sabbath
I still am of the opinion that squelch-on-walk-on is probably the way
to go (though I'm having a little trouble getting it to interact
correctly with all of the various pickup options). The dungeon
still looks the same and the balance issues are very minor.
(FWIW squelch-on-generation also has a couple of balance issues, even
if done right. In Z, for example, you won't have potions on the ground
shattering if the type has been squelched.)
Thanks for the feedback -- I am in thesis hell right now but
once that is done I plan to put some more work into the patch.
Regards,
Dave
David T. Blackston
>David T. Blackston <dav...@melody.cs.berkeley.edu> wrote:
>> Actually, James has been one of my best playtesters, and he's
>> right about this peculiarity of the version of the squelch patch
>> within BEangband.
>
>t) In Mouth: Soft Leather Boots [2]
>
> why do I *always* do these things to myself? Oops. I assumed it
>didn't. A half dozen people say something about the autosquelching patch
>that isn't true, and I don't speak up until somebody comes along that
>knows something I don't.
> *bangs head*
>
> I think:
>
> The first level of squelching should squelch artifacts if you tell it
>to. If you squelch all longswords, you *deserve* to miss Ringil.
I agree. You should be able to fic this easily with the info
from the last post. I guess my munchkin-ish "can't miss an artifact"
streak was showing when I made that decision. As I said, I didn't think
it through carefully enough.
>
> The second level I'm not so sure about. Would it squelch the nice
>cursed sword? Should it? I don't miss cursed artifacts because I always
>k) destroy something I'm going to throw away, and when I can't destroy it
>I know it's an artifact. So maybe, in the same way, the secondary
>squelching should not touch artifacts. "Why is this cursed sword in my
>bag?"
>
If you try to squelch a cursed artifact you'll see a '(Squelch Failed)'
message and the item isn't removed. My intent here was to make this
type of squelching as close to the "k" command as possible.
>>> Mathias has 3 small pickup options that would almost assure that you can
>>>do this, in combination with the squelching code.
>
>> I'm curious to see these. Are they documented at Thangorodrim?
>
> Uh, no. Send me an email and I'll send you my copy. Or send Matthias
>an email and he'll probably send you a copy. Although he did note that
>they don't work exactly like he'd like. Here's a quote from him:
>
>> A pickup_home option "Auto-pickup items that match home", a pickup_inv
>> "Auto-pickup items that match inventory" and a pickup_unknown
>> "Auto-pickup unknown items".
>
> His gripe is that pickup_unknown picks up staves and wands that you
>don't know the charge count of. But you see how these three options plus
>the secondary squelching menu could let you cruise through the dungeon
>very smoothly. If you squelched the wands and staves you didn't want in
>the primary squelch then stuff flows into your backpack when you want it
>to and gets tossed out automatically when you know you don't.
>
> Sorry for spelling your name wrong earlier, btw, Matthias.
I'm currently having some trouble getting the squelch-on-walk-on
code to interact correctly with the various pickup options. When
I figure out how best to do this I'll notify you of the new patch.
Thanks for your interest in the patch, BTW. I'm really glad that
you've made it available to lots of people.
Regards,
Dave
shren
> to go (though I'm having a little trouble getting it to interact
> correctly with all of the various pickup options). The dungeon
> still looks the same and the balance issues are very minor.
Sounds like a good call.
shren
> Well, some people would claim that a version of Angband with haggling
> bonuses disabled would be a "variant", that is, that "variant" simply
> means "something different from the norm", so those people would consider
> "beangband" to be a variant. That being said, there is no reason you
> should feel compelled to send precompiled versions of beangband to the
> standard archives, since, as you point out, your "variant" is really just
> a collection of "patches".
I'm just worried that being fingered as a variant maintainer will cause
some mystical drain on my free time even if I never look at a computer
again.
shren
<snip> (I read all of the above and either agreed with or was informed by
it)
> Thanks for your interest in the patch, BTW. I'm really glad that
> you've made it available to lots of people.
No problem. Building a Windows Compilation with all of the neat new
patches thrown in is all I really have time to do for the Angband
community right now.
And I have, uh, sins in a past life to make up for. Sort of.
Julian Lighton
David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote:
>In article <xK5P4.3302$LM4.2...@monger.newsread.com>,
>Julian Lighton <jl...@fragment.com> wrote:
>>In article <8ehvl0$ltv$1...@agate.berkeley.edu>,
>>David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote:
>>>That's one fix, but changing the semantics is another fix that also works.
>>>The squelch-on-walk-on semantics don't affect balance at all (as far as
>>>I can see)
>>
>>As described previously in the thread, they do, because artifacts are
>>not squelched. So, if you're in a hurry, you can squelch everything
>>before running across a cluttered battlefield, and scoop up the
>>artifacts as you go.
>
>This seems like a very minor issue, but I admit that this is an effect
>on balance. In any case, this balance issue is very small compared to
>the gameplay benefit of a squelching patch "done right".
I agree, but we're disagreeing on "done rightness" is. You see at as
a free destroy, and I see it more as automated ingoring.
>>This would probably work cleanly first time, though it makes a bad
>>assumption that no code does anything with the o_idx that it returns.
>>(This is the case, though.)
>>
>In the first version of the patch I modified make_object. Unfortunately
>I had to check every call to make_object and make sure that a failed
>return was handled correctly. It was a bit of a pain (especially
>for OAngband with its varied chests).
That's why I was suggesting killing objects as late as possible in
their generation. floor_carry gets used only five times, making the
possible return problems easy to check over. (I only had my example
code return -1 instead of 0 to avoid any possible problems with the
savefile loading code.)
>I still am of the opinion that squelch-on-walk-on is probably the way
>to go (though I'm having a little trouble getting it to interact
>correctly with all of the various pickup options).
I don't immediately see what the problem is. Just purge the stack in
py_pickup, right about where it scoops up the gold.
>The dungeon
>still looks the same and the balance issues are very minor.
Squelch artifacts as well, and there shouldn't be any.
>(FWIW squelch-on-generation also has a couple of balance issues, even
>if done right. In Z, for example, you won't have potions on the ground
>shattering if the type has been squelched.)
That's a problem I hadn't thought about, though not for Angband
itself. (It's probably fairly minor, anyway.)
--
Julian Lighton jl...@fragment.com
"Nobody will ever let you know / When you ask the reasons why
They just tell you that you're on your own / Fill your head all full of lies"
-- Black Sabbath
David T. Blackston
Julian Lighton <jl...@fragment.com> wrote:
>
>I agree, but we're disagreeing on "done rightness" is. You see at as
>a free destroy, and I see it more as automated ingoring.
In the case of squelch-on-identification, it really is more of an
auto destroy as opposed to a auto-ignore, but this i minor. ;-)
>
>>>This would probably work cleanly first time, though it makes a bad
>>>assumption that no code does anything with the o_idx that it returns.
>>>(This is the case, though.)
>>>
>>In the first version of the patch I modified make_object. Unfortunately
>>I had to check every call to make_object and make sure that a failed
>>return was handled correctly. It was a bit of a pain (especially
>>for OAngband with its varied chests).
>
>That's why I was suggesting killing objects as late as possible in
>their generation. floor_carry gets used only five times, making the
>possible return problems easy to check over. (I only had my example
>code return -1 instead of 0 to avoid any possible problems with the
>savefile loading code.)
Thanks for pointing this out -- I will definitely check out this
routine. It looks like it might make for a very clean implementation.
>
>>I still am of the opinion that squelch-on-walk-on is probably the way
>>to go (though I'm having a little trouble getting it to interact
>>correctly with all of the various pickup options).
>
>I don't immediately see what the problem is. Just purge the stack in
>py_pickup, right about where it scoops up the gold.
>
It's actually sort of an annoying "bug". Here's the feature.
Situation - there are items where I'll want to pick up the first
object of an item type but squelch the remaining ones. As an example,
the first Ring of Levitation is useful in Z, but all others are "junk".
In squelch-on-generation this works well. Simply set RoL's to be squelched
and when you come across the first one you can pick it up, but all the
future ones will be squelched on generation. Everyone's happy.
In the squelch-on-walk-on semantics things get a little messy. Suppose
you're a mage with the identify spell playing with autopickup off since
you have a macro to identify things on the ground. You come across an
unidentified ring and identify it as a RoL. Yay! Unfortunately, if
you have the squelch vals set as in the previous paragraph it is
not possible to pick up the ring. If you type 'g', it gets squelched
before it can be picked up.
This can be worked around by accessing the menus a few extra times
(annoying) or by using autopickup (also annoying). What I'd really
like is for the 'g' command to perform a get-without-squelch
command so that the first item of each type can be picked up if
desired even if the item type is set to be squelched. Alternatively,
I could add a line to the identify command that asks the player
if they want to pick up the item once it has been identified, but this
also seems to be messy.
The current version of the patch also doesn't work with easy_floor,
but that's a separate issue.
In any case, I'll certainly make the patch available if I can
work out how to fix this.
>>The dungeon
>>still looks the same and the balance issues are very minor.
>
>Squelch artifacts as well, and there shouldn't be any.
>
>>(FWIW squelch-on-generation also has a couple of balance issues, even
>>if done right. In Z, for example, you won't have potions on the ground
>>shattering if the type has been squelched.)
>
>That's a problem I hadn't thought about, though not for Angband
>itself. (It's probably fairly minor, anyway.)
>--
>Julian Lighton jl...@fragment.com
>"Nobody will ever let you know / When you ask the reasons why
> They just tell you that you're on your own / Fill your head all full of lies"
> -- Black Sabbath
Regards,
Dave
shren
> you're a mage with the identify spell playing with autopickup off since
> you have a macro to identify things on the ground. You come across an
> unidentified ring and identify it as a RoL. Yay! Unfortunately, if
> you have the squelch vals set as in the previous paragraph it is
> not possible to pick up the ring. If you type 'g', it gets squelched
> before it can be picked up.
Hmm.... this may concern you, but most people arn't going to know
enough about how Squelching works to risk squelching items that they want,
thus they'll turn it off for all items that they do. The way I play, I
unsquelch everything except the cursed items with each new character, then
squelch things as I get annoyed of seeing them.
What I'm trying to say is that having the first item behave differently
from all the rest is going to be a hack no matter how you approach it.
Trying to make the code not squelch 'first items' that are in the squelch
list is going to be wobbly code and will confuse most people that don't
play the way you play.
In my opinion, nothing that you *want* should ever be in your squelch
list. Because otherwise you're gambling on exactly how the squelch code
works, which most end users shouldn't have to care about.
Oh, one squelch bug:
-You have removed the rubble.-
-There is an item underneath the rubble!-
And no item - because it got squelched, I'll bet. It made me think for
a minute before I caught it, but I'll bet most people would be, "Where's
my item? It said there was an item!"
David T. Blackston
>
> Oh, one squelch bug:
>
> -You have removed the rubble.-
> -There is an item underneath the rubble!-
>
> And no item - because it got squelched, I'll bet. It made me think for
>a minute before I caught it, but I'll bet most people would be, "Where's
>my item? It said there was an item!"
Thanks for the bug report. This won't happen in the squelch-on-walk-on
semantics, so it'll disappear by the next version. ;-)
Regards,
Dave
Ben Harrison
jl...@fragment.com (Julian Lighton) writes:
> In article <l83do35...@eel.curl.com>, Ben Harrison <be...@phial.com> wrote:
> >James W Sager Iii <sag...@andrew.cmu.edu> writes:
> >> So you really love the stacking code that was put in a couple months ago
> >> with the ability to only look at the item on the top from afar.
>
> >Unless the code is broken, you are *supposed* to be able to hit "r"
> >when you see a pile of items to see the complete list (if using the
> >"easy_floor" option) or else hit "return" to see the next item (if
> >not using the "easy_floor" option). Or is this broken?
Hmmm. Playing the game, it does, in fact, appear that the code
is broken. My guess is that it does not handle "gold" correctly,
but that is just a guess.
Robert, consider this a bug report.... :-)
> Probably not. I was expecting it to use 'x', just like Oangband does,
> and have been generally aggravated by the lack of the feature. If all
> else fails, read the instructions. :)
The "x" vs "l" key thing alone is a good reason why "x" is a bad idea
(roguelike vs original).
> Why 'r'? Symmetry with looking at monsters?
Yep.
--- Ben ---
Ben Harrison
Note that the new concept of "squelch as you step on an item"
is really just "auto-destroy" (ala "auto-pickup"). No need to
introduce a new verb (i.e. "squelch").
Somebody really should try to unify the pickup options, the
"auto-pickup =g inscriptions" code, and the squelching code....
--- Ben ---
dav...@melody.CS.Berkeley.EDU (David T. Blackston) writes:
David T. Blackston
>
>Note that the new concept of "squelch as you step on an item"
>is really just "auto-destroy" (ala "auto-pickup"). No need to
>introduce a new verb (i.e. "squelch").
True enough, but the first version of the patch really involved
a separate notion. I chose the name then to be somewhat distinctive
(and hence easy to track down on Deja-News) and I've just kept
with it.
>
>Somebody really should try to unify the pickup options, the
>"auto-pickup =g inscriptions" code, and the squelching code....
>
Agreed. I have some ideas along these lines, and I plan to
get to work on this in a couple of weeks, when I have some time.
>--- Ben ---
>
>dav...@melody.CS.Berkeley.EDU (David T. Blackston) writes:
>
>> I'm currently having some trouble getting the squelch-on-walk-on
>> code to interact correctly with the various pickup options. When
>> I figure out how best to do this I'll notify you of the new patch.
Regards,
Dave
Lev Zakrevski
"David T. Blackston" wrote:
>
> In article <390C8CC2...@bu.edu>, Lev Zakrevski <za...@bu.edu> wrote:
> >>
> >First, would like to mention that I strongly support the idea of the
> >discussed patch, since I have found to spend about 1/3 of the playing
> >time
> >trying to destroy unwanted objects. Usually, I use some sort of
> >fire/acid
> >ball attack to reduce the number of them, but this technique is very
> >crude
> >and will destroy many useful things...
> >
> >The most useful (for me) would be "squelch by name" approach. To
> >increase
> >it efficiency, without coming into cheating area, I would suggest the
> >following switches, which can be used with "squelch by name" method:
> >
> >1) do not destroy weapons with unusual base damage (1d5 dagger, etc).
> >2) do not destroy unique drops.
> >
> >Both switches do not give any new information to player, so I would not
> >consider them a cheat.
> >
> >On the other side, when "squelch by name" is being used for long swords,
> >artifact swords with unmodified base damage should not be generated.
> >
> >Lev Zakrevski
>
> The squelch-on-walk-on semantics will probably give you just
> about everything you want here.
No, not quite, for the following reasons:
1) at the late game, I will auto-supress almost everything. If
"squelch by name" appoach is being used, all cool items will be
seen at once, which is really useful when you are fighting crowds
of summoning dragons etc. Usually, I use "l"ook command in such
situations, and here "squelch-on-walk-on" will not help.
2) The same with detect object and light the whole level spells. I use
them a lot, then look, if there are cool items around.
3) I like to play combat weak characters, and one of my favourites
is telekinesis spell...
4) I don't see, how at "The squelch-on-walk-on" approach my second
proposition "do not destroy unique drops" will work.
The first proposition "do not destroy weapons with unusual base damage
(1d5 dagger, etc)." can work, however.
> Instead of acid-bolting the
> pile, you walk over it and all the junk magically disappears.
It is good, but not as good as "squelch by name at creation" would be.
> I've been playing it for a while now and it seems to work pretty
> well.
>
>
> Regards,
>
> Dave
Thank you for nice patch!
Lev Zakrevski
Matthias Kurzke
>
>dav...@melody.CS.Berkeley.EDU (David T. Blackston) writes:
>
>> When I have time I do plan to add some file i/o so that squelch settings
>> can be saved and loaded.
>
>Make sure to do them as user pref options.
>
>Personally, I would recommend simply having an array of "char"
>of size "MAX_K_IDX", where the "char", if non-zero, says what
>to do when walking on an object of that type (if aware), with
>"k" being "destroy", "E" being "eat", "g" being "get", etc.
>
>That would allow "auto-squelch" to actually be even more powerful
>than it is already....
>
>Plus, it would be easy to save in the user pref files, as, say,
>"I:<num>:<cmd>".
>
That sounds absolutely great and much better than using the savefile. Auto-drink
stat gain potions until you're through with stat gain. The possibilities
are incredible..
Matthias
--
`The question is,' said Humpty Dumpty, `which is to be master--that's all.'
Matthias Kurzke
>David T. Blackston <dav...@melody.cs.berkeley.edu> wrote:
>> In the squelch-on-walk-on semantics things get a little messy. Suppose
>> you're a mage with the identify spell playing with autopickup off since
>> you have a macro to identify things on the ground. You come across an
>> unidentified ring and identify it as a RoL. Yay! Unfortunately, if
>> you have the squelch vals set as in the previous paragraph it is
>> not possible to pick up the ring. If you type 'g', it gets squelched
>> before it can be picked up.
>
> Hmm.... this may concern you, but most people arn't going to know
>enough about how Squelching works to risk squelching items that they want,
>thus they'll turn it off for all items that they do. The way I play, I
>unsquelch everything except the cursed items with each new character, then
>squelch things as I get annoyed of seeing them.
>
> What I'm trying to say is that having the first item behave differently
>from all the rest is going to be a hack no matter how you approach it.
>Trying to make the code not squelch 'first items' that are in the squelch
>list is going to be wobbly code and will confuse most people that don't
>play the way you play.
>
I hacked up something for my personal use: an 'auto-pickup unknwon items' option. This makes me pick
up more or less what I really want to pickup (weapons and armor for pseudo-ID) - things I don't know
yet. I should probably change it so that it doesn't pick up unIDed but aware staffs/wands, but I'm
too lazy now. But really, auto-suqelching should maybe be merged with auto-pickup in some ways. Make
you automatically pickup (*Healing* potions), ignore (Restore stat potions) or destroy (broken
sticks) what you walk over, thus getting closer to optimal user interface.
I also have written a change to ID that only lets you ID unIDed items. That means, if you have a
stack of three unIDed weapons on the floor, you just cast (ID macro) - three times, until everything
is identified. How would the auto-squelcher interact with this?
shren
If you had the action set for *all* of the items, you'd start to feel
like a gelatinous cube, leaving a clean sweep of the dungeon behind you.
But you might want to make 'process items I'm standing on' a button
instead of an automatic process, or you could waste a lot of time running
over a pile of stuff. Imagine - you're being chased by a Dracolisk and
you run over a pile of three gain stat potions:
"You feel stronger!"
"You feel more wise!"
"You feel more intelligent!"
"The Dracolisk breathes nether!"
"You Die."
Actually, you could use the "am I in danger" code that sleep uses to
determine if you pickup or in any other way interact with objects on the
ground. If you see danger, you ignore the loot. If you see no danger,
then you process what you're standing on. Although that could be
dangerous if you are running away with a monster just out if sight.
Maybe it could be an option like 'Searching' - 'Looting' - you flip it on
and you pick up stuff/drink stuff/destroy stuff/whatever your list says to
until a monster causes it to flip off. When the hackin's done, you flip it
back on and walk over to the loot.
Chris Kern
the following:
>The "x" vs "l" key thing alone is a good reason why "x" is a bad idea
>(roguelike vs original).
Besides, I've used "x" as my orb of draining/magic missile key for
years now :)
-Chris
Jason Willoughby
> (FWIW squelch-on-generation also has a couple of balance issues, even
> if done right. In Z, for example, you won't have potions on the ground
> shattering if the type has been squelched.)
Just a couple questions, since it 2am (again! It seems to happen almost
daily) and I don't have time to check myself:
1. Spoilers. Is the squelch menu smart enough to not tell players about
items they might not know about?
2. Stacking. With stacking off, is there a gameplay advantage to
squelching? If so, how much of one?
And to reiterate, I think squelch-on-walk-on is a bad idea. I don't
want a dozen different types of squelching, I want squelch on
*know*. Whether it's on generation, psuedo-id, id, or the second
Tuesday of May, as soon as I could know (and not a turn before) that an
item isn't worth my time, the autosquelcher should get it the hell out
of my dungeon.
Jason Willoughby
Heathen. 'x' is obviously for the light area macro.
David T. Blackston
Jason Willoughby <jwil...@gate.net> wrote:
>David T. Blackston, a beast of pure hatred with purpose malign, wrote:
>> (FWIW squelch-on-generation also has a couple of balance issues, even
>> if done right. In Z, for example, you won't have potions on the ground
>> shattering if the type has been squelched.)
>
>Just a couple questions, since it 2am (again! It seems to happen almost
>daily) and I don't have time to check myself:
>
>1. Spoilers. Is the squelch menu smart enough to not tell players about
> items they might not know about?
Not currently, though this was the case for the oldest version of
the patch (no longer available). I would consider putting something
in like monster memory, where if the player (not the character)
has ever seen and identified a flavored object, then that object's
name will appear in the list. Otherwise a blank string will
appear. This still allows for the thrill of discovery without
significantly changing the number of times the menus must be
accessed.
>
>2. Stacking. With stacking off, is there a gameplay advantage to
> squelching? If so, how much of one?
>
I don't think there's an advantage. Certainly with sq-on-walk
there's no difference in the dungeon so there's no advantage.
With sq-on-g, the object generation probabilities are not changed,
and failure to place an object simply results in a blank floor
square, not another attempt, so I don't thnk there'd be
any advantage.
>
>And to reiterate, I think squelch-on-walk-on is a bad idea.
I disagree that it's a bad idea -- it's simply a different idea
and for better or worse it's the one that the devteam wants to
consider.
The gameplay difference between the two patches is noticable
but slight. Both speed up the game and remove a lot of the tedium.
>I don't
>want a dozen different types of squelching, I want squelch on
>*know*. Whether it's on generation, psuedo-id, id, or the second
>Tuesday of May, as soon as I could know (and not a turn before) that an
>item isn't worth my time, the autosquelcher should get it the hell out
>of my dungeon.
Regards,
Dave
Chris Kern
<jwil...@gate.net> posted the following:
No, no, no, that's CTRL+L. 'x' is orb, 'n' is detect, ',' is identify
on ground, F1 is prot. from evil, and F2 is clairvoyance.
-Chris
R Dan Henry
jl...@fragment.com (Julian Lighton) transmitted thus:
>In article <8eh545$59d$1...@newsg3.svr.pol.co.uk>,
>Jonathan Ellis <jona...@franz-liszt.freeserve.co.uk> wrote:
>> And then what happens when, as I said, you meet a vault and want to
>>know whether it is worth taking on the monsters there? If you can
>>already see what's there (or, if you squelch on generation, isn't
>>there), there's no reason to enter it at all.
>
>You can already do this with the look command.
And that should be changed, IMO.
--
R. Dan Henry
danh...@inreach.com
Trained Philosopher: Will Think For Food
Julian Lighton
Jason Willoughby <jwil...@gate.net> wrote:
>David T. Blackston, a beast of pure hatred with purpose malign, wrote:
>> (FWIW squelch-on-generation also has a couple of balance issues, even
>> if done right. In Z, for example, you won't have potions on the ground
>> shattering if the type has been squelched.)
>
>Just a couple questions, since it 2am (again! It seems to happen almost
>daily) and I don't have time to check myself:
>
>1. Spoilers. Is the squelch menu smart enough to not tell players about
> items they might not know about?
>
> squelching? If so, how much of one?
Well, Angband doesn't let you turn off stacking anymore, but there
would be a considerable gameplay advantage to squelching if you could,
since worthless items wouldn't be taking up the floor space needed for
good items.
--
Julian Lighton jl...@fragment.com
"Height, Hell, Time, Haste, Terror, Tension
Life, Death, Want, Waste, Mass Depression"
-- Metallica
Julian Lighton
>Matthias Kurzke <kur...@ms45.hinet.net> wrote:
>> "Ben Harrison" <be...@phial.com> wrote:
>> That sounds absolutely great and much
>> better than using the savefile. Auto-drink
>> stat gain potions until you're through with stat gain. The possibilities
>> are incredible..
>
> If you had the action set for *all* of the items, you'd start to feel
>like a gelatinous cube, leaving a clean sweep of the dungeon behind you.
>But you might want to make 'process items I'm standing on' a button
>instead of an automatic process, or you could waste a lot of time running
>over a pile of stuff. Imagine - you're being chased by a Dracolisk and
>you run over a pile of three gain stat potions:
>
>"You feel stronger!"
>"You feel more wise!"
>"You feel more intelligent!"
>"The Dracolisk breathes nether!"
>"You Die."
>
> Actually, you could use the "am I in danger" code that sleep uses to
>determine if you pickup or in any other way interact with objects on the
>ground. If you see danger, you ignore the loot. If you see no danger,
>then you process what you're standing on.
There is no "am I in danger" code. Some things happening will disturb
you, breaking rests. I suppose one could create some sort of queue of
actions to do, which gets flushed on disturbance, (I suppose you could
stick things into the input buffer, but that would be nasty.) but at
least some things that would happen from auto-quaff will disturb you
by themselves.
--
Julian Lighton jl...@fragment.com
"Why do your people always ask if someone is ready right before you
are about to do something massively unwise?"
"Tradition" -- Babylon 5
Matthias Kurzke
>On Mon, 01 May 2000 01:44:32 GMT, the disembodied brain of
>jl...@fragment.com (Julian Lighton) transmitted thus:
>
>>In article <8eh545$59d$1...@newsg3.svr.pol.co.uk>,
>>Jonathan Ellis <jona...@franz-liszt.freeserve.co.uk> wrote:
>
>>> And then what happens when, as I said, you meet a vault and want to
>>>know whether it is worth taking on the monsters there? If you can
>>>already see what's there (or, if you squelch on generation, isn't
>>>there), there's no reason to enter it at all.
>>
>>You can already do this with the look command.
>
>And that should be changed, IMO.
>
Why? To make us ASCII lovers convert to graphics?
Jason Willoughby
> jl...@fragment.com (Julian Lighton) transmitted thus:
>>Jonathan Ellis <jona...@franz-liszt.freeserve.co.uk> wrote:
>>> And then what happens when, as I said, you meet a vault and want to
>>>know whether it is worth taking on the monsters there?
>>
>>You can already do this with the look command.
> And that should be changed, IMO.
Turn off expanded look and color. There, now you can't.
James W Sager Iii
BEangband OWNS! by David T. Blackston@melod
> In article <wt37mqG00...@andrew.cmu.edu>,
> James W Sager Iii <sag...@andrew.cmu.edu> wrote:
> >
> >The squelch menu should not even have a primary squelch menu for any
> >item that has the ability to be an artifact.
> >
>
> Disagree. If I don't want to deal with broken daggers then I shouldn't have
> to.
Idea 1)
I don't understand where you're coming from on this one. Simply expand
the secondary squelch menu out:
daggers(V)
broken daggers (A)
swords(V)
broken swords(A)
Now you'll need to pseudo-id your broken daggers and daggers before
squelching them.
> >By saying squelch everything but the artifacts, you can abuse the
> >autosquelcher.
> >
> >
> >look at this scenerio:
> >EVERYTHING IS SQUELCHED.
> >
> >Then you only see artifacts on the dungeon.
> >By using enlightenment and the 'L'ook command you can find every artifact
> >because thats the only thing seen.
> >
> >bad bad bad
>
> I agree that this is a bad thing, and that's why I changed the
> semantics from squelch-on-generation to squelch-on-walk-on.
idea(2)
Now, if you want primarily have squelching enabled on broken daggers.
I propopse ONLY weapons/armor/anything with possibility of being an
artifact needs to be walked on before squelching since they are the only
things that have this 'special' need. Other stuff without 'quality'
flags can be autosquelched via a distance and on creation.
By forcing squelch on walk on with elf skeletons, there is much more
pile clutter in the dungeon, and you can't look from a distance to
things under piles.
With all the extra clutter in the dungeon, instead of saving the user
lots of time. by just ignoring a monster drop, the user has to do this
walking motion over all the items dropped, only saving the cognitive
processes of looking at items, and the keypress associated with
squelching. This proposed 'walk on' squelch causes the user a bunch of
extra keystrokes to move over items.
James W Sager Iii
> >UGH! Squelching on walking.
> >Thats a hideous thing. Why the heck would you want to maul something
> >that works? Is there a single good reason why you'd want squelching
> >when walking on objects? Riddle me this.
>
> Of course, and if you'd been paying attention you'd know that.
> Hitting "k-" * 100,000 takes up a lot of time.
>
And if you'd been paying attention, I was the one who originally
proposed the idea, and the math behind it.
Time wasted in cleaning out a room:
Key strokes to walk on item.(small part)
Cognitive process of looking at item and determining if its bad. (big part)
Macro keypress to destroy it.(small part)
Time wasted in looking through a *detected* dungeon
Keystrokes to 'L'ook at each item.(big part)
Cognitive process of determining if its worth walking towards.(small part)
Extra cognitive processes of seeing it again later in the dungeon.
(decent part)
Loss of functionality to see what is under a stack long distance(hard to
determine)
Squelch on walk on proposal:
Time wasted in cleaning up a room is truncated down to a small part...
Better
Time wasted in looking through a *detected* dungeon
Not helped at all. All problems still present.
One can invoke a new dungeoning technique of just walking to every room
and on items to minimize annoying cognitive processes based on a bad
interface in the
game.
Modified walk on squelch proposal:
Only squelch on walk on for weapons/armor/items with possibility of
being artifacts.
Time wasted in cleaning up a room is truncated as much as squelch on
walk on, in addition, you are saved an extra amount of keystrokes such
that you don't have to walk over skeletons and slime molds and the like.
Personally I only use quality squelch, and since most of the game I'm
searching for better weapons and armor, as a warrior, all I need to do
is pick up the equipment and walk around with it.
People who use squelch on item name could do the same, without ever
checking broken daggers and broken swords. Anyone who's ever gotten a
broken dagger(defender) early game, prolly won't squelch these.
Modified walk on squelch proposal:
There is no time wasted searching through a *detected* dungeon sifting through
mushrooms of disease and slime molds.
Also the weakness of the 'L'ook command of seeing through stacks, is
minimized since
there are less items in stacks in general.
Of course no game play problems are introduced as all items with
'quality' flags
are generated still.
The only game play problem obvious is that if a vibration hound breathes
on a potion of healing(other stuff), and it shatters, stuff would get
healed. if you squelch potions of healing then this wouldn't have
happened.
In all other respects you could just have ignored the item on the floor
and it would be the same as destroying it by hand, aside from cluttering
up the interface.
James W Sager Iii
BEangband OWNS! by sh...@io.com
> > item that has the ability to be an artifact.
>
> > autosquelcher.
>
> > look at this scenerio:
> > EVERYTHING IS SQUELCHED.
>
> > Then you only see artifacts on the dungeon.
> > By using enlightenment and the 'L'ook command you can find every artifact
> > because thats the only thing seen.
>
> > bad bad bad
>
> > squelching. Personally I never used this option anyway as I never saw
> > any use for it.
>
> You are making it blatantly obvious that you haven't actually USED the
> autosquelching code. There's two levels of squelching.
And you're making it blatantly obvious you don't understand what I meant.
Why do you always make your posts like a personal attack too?
I used the autosquelcher, I never touched code, but I came up with most
of the theory behind it.
Its called abuse of the auto-squelcher due to its primary squelch menu ability
you are able to an abusive play of angband that shows only artifacts on
each level.
Just click everything squelched in primary.
Then nothing is generated: except artifacts. See the notes Dave made in
the code.
All but artifacts are squelched.
So you can just jump up and down a single set of stairs some artifact
rich level.
Casting a spell that detects the whole level.
Bam, its abused... Please try and read my post next time before flaming me.
> 1) Blocked generation. This is done on a type of item. I can squelch
> *all* longswords, or all potions of poision (If I've ided a potion of
> poison.) If I squelch all daggers, I'll *never* see any dagger in the
> dungeon. If I don't, then I'll see every dagger that I would see with
> normal Angband. I can squelch potions by type, but you can see from
> across the screen what type a potion is, anyway.
>
> 2) Auto-removal from backpack upon identify. All this does is
> automatically get rid of items that you don't want, *once you know what
> they are*. If you picked up a longsword, and your pusedo id kicks on and
> tells you that it's cursed, and you squelch cursed objects, then it will
> automatically be destroyed. There is no substantial possibility of game
> inbalance here - all it is saving you from is using the destroy command by
> hand.
>
> I think autosquelching balances game balance and tedium removal really
> well. If you are playing a warrior with the good pusedoid they get, then
> you could turn on autopickup and grab everything, then the crap would be
> thrown out as you spot it. Autosquelching makes it concievable that
> people might play with autopickup on past 500', because you can keep the
> utter crap, obviously cursed (identifited wands of haste monster, potions
> of lose memories) from being generated, and you can pickup all those
> unidentified weapons and armor secure in the knowledge that the sucky ones
> will be thrown out automatically.
>
> Mathias has 3 small pickup options that would almost assure that you can
> do this, in combination with the squelching code.
James W Sager Iii
> In article <8egnsv$u82$1...@newsg3.svr.pol.co.uk>,
> Jonathan Ellis <jona...@franz-liszt.freeserve.co.uk> wrote:
> >Julian Lighton wrote in message ...
> >>With stacking and the ability to look at the contents of a stack from
> >>a distance, (a feature from Oangband I've been missing in 2.9) squelch
> >>on generation is just (in theory), saving you the time it takes to
> >>check whether the stack's worth bothering with,
> > Which is exactly *WHY* you shouldn't squelch on generation. Imagine
> >this: you set this option to squelch all known item types. Now, nothing
> >can be generated except artifacts (which of course cannot be destroyed.)
> >So you can see IMMEDIATELY how many artifacts are in a vault.
> > Squelch on walking over the items, fine. Squelch on generation so
> >that you never even see the item, no.
>
> No, that's "Don't do squelch-on-generation wrong." If you don't want
> the game to tell you about daggers, the game should not tell you about
> daggers. Period. Dagger (+0,+0)? Nope. Dagger of Westernesse?
> Nope. Rilia? Nope, and mark it as generated if preserve's off.
>
> It automates the ability to ignore daggers yourself. Not destroy.
> That requires you to possibly take a turn or two to do it. It
> replaces 'l'looking across the room, noticing that the objects over
> there are a dagger and a potion of slime mold juice, and continuing on
> your way.
Exactly...
My original proposal said that you should be able to ignore all objects
via an ignore menu. One could turn a filter on and off... So if you
normally don't need food, but you want to start seeing it, you could
toggle the filter, and see the food again.
Due to many people's explainations of the object limit and how items get
randomly destroyed when too many items are generated on the level, I
switched my stance to autodestroyed instead of autoignored. I also
proposed that if someone really wanted to do above and beyond extra
work, they could do destroy on quality... Somewhere in the vague realm
of moving from regular to quality, the squelch all but artifacts in the
primary setting occured.
As Julian says, if you're going to ignore daggers, all dagers should be
ignored. Simply take the clause:" destroy all but artifacts" and change
it to: destroy all.
In fact I'll take full responsibility for this bug as I told Dave to put it in.
I won't get into the reasoning as to why I asked for it to be in, as it
was clearly flawed logic.
James W Sager Iii
BEangband OWNS! by Julian Lighton@fragment.
> >around 1000'-1500', when I would normally prefer other weapons to the
> >'thancs.) No thanks. And indeed, no 'thancs... Artifacts HAVE to be
> >excluded from autosquelching.
>
> To stop people from shooting themselves in the foot? Maybe it's
> because I'm a C programmer, but I see no reason to protect people from
> their own stupidity. (I do think "squelching items" should be changed
> to "ignoring items" though, just to make it clear.)
Perhaps he would rather use the secondary squelching menus.
I prefer the secondary menu myself.
Simply set daggers to artifact only.
You see all the daggers, but have to manually id them, just like you do now.
Its pretty cool with psudeo id too.
It allows warriors to enter the dungeon with less than 80 id scrolls.
Its a new play style
Have 6 slots open in your warrior, and pick up every piece of armor and
weapon, and what you don't want is auto squelched(player gets an extra
turn, but I can apply a proof to show its negligable, one of the earlier
posts had it)
James W Sager Iii
> Not everybody plays with the "let me look through walls" option, though
> personally, I cannot imagine being such a person....
>
> --- Ben ---
>
> James W Sager Iii <sag...@andrew.cmu.edu> writes:
>
> > You can look at any object from a distance and determine what it is.
> > There is no gameplay affect noticed through a destroyed item anyway.
> > Therefore nothing is changed. Alot of the bad stacking interface code
> > is actually improved with autosquelch.
> >
> > You can look through walls and see what an item is because you can
> > 'detect' through walls with spells. No extra information is gained, it
> > just increases the speed in which you sort through items IE not wasting
> > the players time picking through trash.
Ok, this was one of the things that I had troubles justifying personally too...
I eventually found it was 'one of those things' Like player energy on
autopickup...
I figured that since you can *detect* through walls items. And you can
see their color, and place them into a category of 2 types of potions...
You might as well be able to see what it is. After all you determined
that it was a potion there.
If it was supposed to be completely ambiguous, the colors of stuff you
id should be grey...
Thats how I just went to the conclusion that I should be able to see em
through walls...
Not to get into too many personal prefs things... It may be pretty cool
if you couldn't tell exactly what an item was through a wall by color
coding it to white. I have no idea what ramifications it would cause...
but it'd be different.
James W Sager Iii
>I think people are confused.
>Unless the code is broken, you are *supposed* to be able to hit "r"
>when you see a pile of items to see the complete list (if using the
>"easy_floor" option) or else hit "return" to see the next item (if
>not using the "easy_floor" option). Or is this broken?
>--- Ben ---
>>James W Sager Iii <sag...@andrew.cmu.edu> writes:
>>
>> So you really love the stacking code that was put in a couple months ago
>> with the ability to only look at the item on the top from afar.
Yeah, I didn't know that stuff.
As a weaker claim, I can say that it takes extra keypresses to see the
items below :)
Much weaker claim
I like the easy floor, but I have troubles making macro destroys for em
so I turned em off.
Chris Kern
<sag...@andrew.cmu.edu> posted the following:
>Time wasted in looking through a *detected* dungeon
If you are not playing a priest, a *detected* dungeon (presuming you
mean Enlightenment) is sufficiently hard to get that I think
squelch-on-walk is still useful.
-Chris
Mårten Woxberg
wrote:
>On Sun, 30 Apr 2000 15:42:58 -0400, Lev Zakrevski <za...@bu.edu> posted
>the following:
>
>> Btw, does anybody know, if Zangband development will
>>continue? There have been no changes in development version for a long
>>time...
>
>Yes, a new development version should be out fairly soon.
The Auto-destroy option in Zangband is that the same as the squelsch
patch??
Anyway.. I have a grudge against that option...
it destroys staffs of summoning and scrolls of summoning..
possibly potions that you can throw to confuse/stun/blind/poison
monsters with too.. other than that its good..
I think the game should automaticly sense that you dont want to pickup
broken skulls and skeletons.. (if you do not practice black magic in
the new spell system..)
>-Chris
>
/Marten
David T. Blackston
Mårten Woxberg <ma...@telia.junk.com> wrote:
>On Sun, 30 Apr 2000 20:29:53 GMT, ke...@grinnell.edu (Chris Kern)
>wrote:
>
>>On Sun, 30 Apr 2000 15:42:58 -0400, Lev Zakrevski <za...@bu.edu> posted
>>the following:
>>
>>> Btw, does anybody know, if Zangband development will
>>>continue? There have been no changes in development version for a long
>>>time...
>>
>>Yes, a new development version should be out fairly soon.
>
>
>The Auto-destroy option in Zangband is that the same as the squelsch
>patch??
No, it isn't. The squelch patch allows the user a lot more control
of the automatic destruction of items.
>
>Anyway.. I have a grudge against that option...
>it destroys staffs of summoning and scrolls of summoning..
>possibly potions that you can throw to confuse/stun/blind/poison
>monsters with too.. other than that its good..
>
>I think the game should automaticly sense that you dont want to pickup
>broken skulls and skeletons.. (if you do not practice black magic in
>the new spell system..)
>
>>-Chris
>>
>
>/Marten
>
Regards,
Dave
James W Sager Iii
>
> If you are not playing a priest, a *detected* dungeon (presuming you
> mean Enlightenment) is sufficiently hard to get that I think
> squelch-on-walk is still useful.
>
> -Chris
I am not arguing that squelch on walking isn't useful.
I'm suggesting there is a more eloquent way of doing things, and its
easier to code.
Ben Harrison
So go ahead and turn off the "expand_look" option. For some reason
(presumably convenience) Robert defaulted it to "on" in 2.9.0. Then
you will only be able to "look" at objects in line of sight.
--- Ben ---
R Dan Henry <danh...@inreach.com> writes:
> >> And then what happens when, as I said, you meet a vault and want to
> >>know whether it is worth taking on the monsters there? If you can
> >>already see what's there (or, if you squelch on generation, isn't
> >>there), there's no reason to enter it at all.
> >
James W Sager Iii
> In squelch-on-generation this works well. Simply set RoL's to be squelched
> and when you come across the first one you can pick it up, but all the
> future ones will be squelched on generation. Everyone's happy.
>
> In the squelch-on-walk-on semantics things get a little messy. Suppose
> you're a mage with the identify spell playing with autopickup off since
> you have a macro to identify things on the ground. You come across an
> unidentified ring and identify it as a RoL. Yay! Unfortunately, if
> you have the squelch vals set as in the previous paragraph it is
> not possible to pick up the ring. If you type 'g', it gets squelched
> before it can be picked up.
>
> (annoying) or by using autopickup (also annoying). What I'd really
> like is for the 'g' command to perform a get-without-squelch
> command so that the first item of each type can be picked up if
> desired even if the item type is set to be squelched. Alternatively,
> I could add a line to the identify command that asks the player
> if they want to pick up the item once it has been identified, but this
> also seems to be messy.
Bleh, say screw it and don't do squelch on walk on.
Squelch on walk on is the spawn of satan, don't go with it.
Booo :)
Ed Cogburn
>
> Excerpts from netnews.rec.games.roguelike.angband: 30-Apr-100 Re:
> BEangband OWNS! by David T. Blackston@melod
> >
> > semantics from squelch-on-generation to squelch-on-walk-on.
>
> idea(2)
> Now, if you want primarily have squelching enabled on broken daggers.
>
> I propopse ONLY weapons/armor/anything with possibility of being an
> artifact needs to be walked on before squelching since they are the only
> things that have this 'special' need. Other stuff without 'quality'
> flags can be autosquelched via a distance and on creation.
Steven has ruled out squelch-on-generation, that's why David did
squelch-on-walkon.
>
> By forcing squelch on walk on with elf skeletons, there is much more
> pile clutter in the dungeon, and you can't look from a distance to
> things under piles.
You can do this with easy_floor.
>
> With all the extra clutter in the dungeon, instead of saving the user
> lots of time. by just ignoring a monster drop, the user has to do this
> walking motion over all the items dropped, only saving the cognitive
> processes of looking at items, and the keypress associated with
> squelching. This proposed 'walk on' squelch causes the user a bunch of
> extra keystrokes to move over items.
Agreed, but squelch-on-generation was ruled out, talk to the DevTeam.
--
"It is dangerous to be right when the government is wrong." - Voltaire
Ed C.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----