Autosquelch -- the next version...
David T. Blackston
Hi all,
I've really enjoyed the debate that's been going on over the squelch
patch. In the next version of the patch I think I'm going to include
the following.
1: Support for both squelch-on-generation and squelch-on-walk. This
will be set by a flag that can be toggled in the main squelch menu.
Squelch-on-generation will squelch artifacts if their type has been
squelched. Squelch-on-walk will act as a free "destroy junk" when
walking over an item, and artifacts will survive this process. This
should keep everyone relatively happy and will allow people to test
both methods so that an evental winner can be determined.
2: I'll add an "object memory" feature so that the squelch menus will
only show the name of a flavored object if the player has seen and
identified an object of that type. This will be persistent across
deaths in the same way that monster memory is, so that the player
can eventually build up a complete list of objects in the game.
3: I'll add some sort of file io so that the squelch settings can
be saved to a prf file. (An aside -- are there any conventions
that I should follow when creating or naming a file?)
I have a few other ideas, but they will have to wait for a future
version...
This patch should be released towards the end of May. (I'm pretty
busy for the next couple of weeks.) I plan on developing the patch
first for V290 and possibly porting to the other variants.
Does anyone have any other suggestions?
Dave
Jason Willoughby
> 2: I'll add an "object memory" feature so that the squelch menus will
> only show the name of a flavored object if the player has seen and
> identified an object of that type.
Why only flavored items? Some of the high level weapons and armor can
be quite spoily...
David T. Blackston
Programming ease. I plan to implement this by using the
"aware" flag of the object kind. The high level armors and
weapons already have the "aware" flag set and I'd rather
not go code diving to try to figure out when an object is
encountered for the first time.
Dave
James W Sager Iii
-- the next ver.. by David T. Blackston@melod
> will be set by a flag that can be toggled in the main squelch menu.
> Squelch-on-generation will squelch artifacts if their type has been
> squelched. Squelch-on-walk will act as a free "destroy junk" when
> walking over an item, and artifacts will survive this process. This
> should keep everyone relatively happy and will allow people to test
> both methods so that an evental winner can be determined.
yay! You da man.
And if there is an option in the menu, who needs to have a winner... aside from
a pain in maintaining...
> 2: I'll add an "object memory" feature so that the squelch menus will
> only show the name of a flavored object if the player has seen and
Cody Hatch
rec.games.roguelike.angband said:
>
>Hi all,
>
>I've really enjoyed the debate that's been going on over the squelch
>patch. In the next version of the patch I think I'm going to include
>the following.
>
>1: Support for both squelch-on-generation and squelch-on-walk. This
>will be set by a flag that can be toggled in the main squelch menu.
>Squelch-on-generation will squelch artifacts if their type has been
>squelched. Squelch-on-walk will act as a free "destroy junk" when
>walking over an item, and artifacts will survive this process. This
>should keep everyone relatively happy and will allow people to test
>both methods so that an evental winner can be determined.
Excelent. I think this is probably the best solution. To disallow
squelch-on-generation entirely would be to ignore the potential benefits to
be gained when you simply do not want to be bothered with some type of
object. OTOH, to keep artifacts from being squelched would be to grant a
little too much information--there *IS* no way to distinguish an artifact
from a normal item from a distance except a ball spell which destroys
items, and those a hard to come by, and easy enough to use to use if you
CAN come by them that further automation is unnecesary. And as for
squelch-on-walk, to destroy artifacts would be ludicrous, since it's fully
possible to distinguish between artifacts and non-artifacts when the item
is underfoot or in iventory.
The only query I have is whether it's possible to mix the types of
squelching--for example, to squelch-on-generation all daggers, but only
squelch (on walk, of course) broadswords of good or lower quality?
Cody
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d-(pu) s+:+ a18>? C++++ US++>++++L- P+>P++++ L+>- E--- W+++$ N++
o+>++++ K--$>++++ w++ !O--- !M-- V? PS+++(---)@ PE+++ Y+>+++ PGP->+++ !t--
5? !X-- R* !tv b++++ !DI+++ !D+++ G+++ e>+++ h* r->++ y++
-----END GEEK CODE BLOCK-----
David T. Blackston
There's no way to do this in the current system. Actually, you
can't do a squelch-on-walk based on quality. The only quality based
squelching occurs when an object is ided or pseudoided.
>
>
>Cody
>--
>-----BEGIN GEEK CODE BLOCK-----
>Version: 3.12
>GCS d-(pu) s+:+ a18>? C++++ US++>++++L- P+>P++++ L+>- E--- W+++$ N++
>o+>++++ K--$>++++ w++ !O--- !M-- V? PS+++(---)@ PE+++ Y+>+++ PGP->+++ !t--
>5? !X-- R* !tv b++++ !DI+++ !D+++ G+++ e>+++ h* r->++ y++
>-----END GEEK CODE BLOCK-----
Regards,
Dave
Werner Baer
David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote in message
news:8eniku$ih3$1...@agate.berkeley.edu...
>
> Hi all,
>
> I've really enjoyed the debate that's been going on over the squelch
> patch. In the next version of the patch I think I'm going to include
> the following.
>
> 1: Support for both squelch-on-generation and squelch-on-walk. This
> will be set by a flag that can be toggled in the main squelch menu.
> Squelch-on-generation will squelch artifacts if their type has been
> squelched. Squelch-on-walk will act as a free "destroy junk" when
> walking over an item, and artifacts will survive this process. This
> should keep everyone relatively happy and will allow people to test
> both methods so that an evental winner can be determined.
I consider squelch-on-generation to be a cheat option.
But i think i'll give squelch-on-walk a try.
BTW could you rename this to 'auto-destroy' or 'auto-ignore' ?
'Squelch' isn't very intuitive for non-natives.
Werner.
David T. Blackston
Werner Baer <werne...@ascor.de> wrote:
>
>David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote in message
>news:8eniku$ih3$1...@agate.berkeley.edu...
>>
>> Hi all,
>>
>> I've really enjoyed the debate that's been going on over the squelch
>> patch. In the next version of the patch I think I'm going to include
>> the following.
>>
>> 1: Support for both squelch-on-generation and squelch-on-walk. This
>> will be set by a flag that can be toggled in the main squelch menu.
>> Squelch-on-generation will squelch artifacts if their type has been
>> squelched. Squelch-on-walk will act as a free "destroy junk" when
>> walking over an item, and artifacts will survive this process. This
>> should keep everyone relatively happy and will allow people to test
>> both methods so that an evental winner can be determined.
>
>I consider squelch-on-generation to be a cheat option.
>But i think i'll give squelch-on-walk a try.
S-o-g changes the balance in some small ways, but I'd personally
hesitate to call it a cheat. Your mileage may vary, of course.
In any case, s-o-w will likely be the form in which the patch
gets integrated into the code (if it does get integrated) so
it's sort of moot anyway.
>
>BTW could you rename this to 'auto-destroy' or 'auto-ignore' ?
>'Squelch' isn't very intuitive for non-natives.
I'd prefer not to rename it at this time. "auto-destroy" is already
the name of an option in Z and "auto-ignore" doesn't reflect all of
the properties of the patch.
>
>Werner.
>
>
Regards,
Dave
Lev Zakrevski
"David T. Blackston" wrote:
>
> Hi all,
>
> I've really enjoyed the debate that's been going on over the squelch
> patch. In the next version of the patch I think I'm going to include
> the following.
>
> 1: Support for both squelch-on-generation and squelch-on-walk. This
> will be set by a flag that can be toggled in the main squelch menu.
> Squelch-on-generation will squelch artifacts if their type has been
> squelched. Squelch-on-walk will act as a free "destroy junk" when
> walking over an item, and artifacts will survive this process. This
> should keep everyone relatively happy and will allow people to test
> both methods so that an evental winner can be determined.
>
> 2: I'll add an "object memory" feature so that the squelch menus will
> only show the name of a flavored object if the player has seen and
> identified an object of that type. This will be persistent across
> deaths in the same way that monster memory is, so that the player
> can eventually build up a complete list of objects in the game.
>
> 3: I'll add some sort of file io so that the squelch settings can
> be saved to a prf file. (An aside -- are there any conventions
> that I should follow when creating or naming a file?)
Nice job!
>
> I have a few other ideas, but they will have to wait for a future
> version...
>
> This patch should be released towards the end of May. (I'm pretty
> busy for the next couple of weeks.) I plan on developing the patch
> first for V290 and possibly porting to the other variants.
>
> Does anyone have any other suggestions?
>
Just 2 suggestions I have made before (for squelch-on-generation):
1) do not destroy items with unusual hit dice (they are easy to see from
a distance)
2) do not destroy armor/weapons dropped my uniques.
Lev Zakrevski
> Dave
David T. Blackston
Thanks for the suggestions. I will implement them if I can think
of a clean way to do it. I need to code dive to check out whether
these would be feasible.
>
>Lev Zakrevski
>
>
>> Dave
Regards,
Dave
Cody Hatch
rec.games.roguelike.angband said:
>In article <8F29CB83...@132.181.30.48>,
>Cody Hatch <co...@chaos.net.nz> wrote:
>>
>>The only query I have is whether it's possible to mix the types of
>>squelching--for example, to squelch-on-generation all daggers, but only
>>squelch (on walk, of course) broadswords of good or lower quality?
>
>There's no way to do this in the current system. Actually, you
>can't do a squelch-on-walk based on quality. The only quality based
>squelching occurs when an object is ided or pseudoided.
Bah. I was just trying to distinguish it from squelch-on-generation.
Although actually, you might be wrong about that--the Tk versions (and
GSNband, if memory serves) implement some sort of fairly bizare option that
allows you to TRY and pseudo-ID items on the floor. It takes place
immediatly, but a failed attemp makes the item permenatly un-pseudo-ID-
able. I personally dislike the option, but in combination with the
autosquelch patch, it would allow a squelch-on-walk based on quality.
Matthias Kurzke
I have to agree with Werner... I saw the word 'squelch' for the first
time in my life in this thread.
Matthias
--
`The question is,' said Humpty Dumpty, `which is to be master--that's all.'
Julian Lighton
David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote:
>In article <8epm1l$40l$4...@news.rz.uni-karlsruhe.de>,
>Werner Baer <werne...@ascor.de> wrote:
>>BTW could you rename this to 'auto-destroy' or 'auto-ignore' ?
>>'Squelch' isn't very intuitive for non-natives.
>
>I'd prefer not to rename it at this time. "auto-destroy" is already
>the name of an option in Z and "auto-ignore" doesn't reflect all of
>the properties of the patch.
auto-ignore sounds like a good description of squelch-on-generation to
me.
squelch-on-walkover sounds like it should supercede Zangband's current
auto-destroy option.
--
Julian Lighton jl...@fragment.com
"Can I play with madness?" -- Iron Maiden
David T. Blackston
Julian Lighton <jl...@fragment.com> wrote:
>In article <8epmni$c1$1...@agate.berkeley.edu>,
>David T. Blackston <dav...@melody.CS.Berkeley.EDU> wrote:
>>In article <8epm1l$40l$4...@news.rz.uni-karlsruhe.de>,
>>Werner Baer <werne...@ascor.de> wrote:
>>>BTW could you rename this to 'auto-destroy' or 'auto-ignore' ?
>>>'Squelch' isn't very intuitive for non-natives.
>>
>>I'd prefer not to rename it at this time. "auto-destroy" is already
>>the name of an option in Z and "auto-ignore" doesn't reflect all of
>>the properties of the patch.
>
>auto-ignore sounds like a good description of squelch-on-generation to
>me.
True, but it doesn't accurately describe the squelch-on-(pseudo)identify
aspect of the patch. It also doesn't really reflect my intent in the
patch.
>
>squelch-on-walkover sounds like it should supercede Zangband's current
>auto-destroy option.
I'm guessing that something like this is what will eventually happen.
>--
>Julian Lighton jl...@fragment.com
>"Can I play with madness?" -- Iron Maiden
Regards,
Dave
Chris Kern
Kurzke) posted the following:
>dav...@melody.CS.Berkeley.EDU (David T. Blackston) wrote:
>
>>In article <8epm1l$40l$4...@news.rz.uni-karlsruhe.de>,
>>Werner Baer <werne...@ascor.de> wrote:
>>>
>>>BTW could you rename this to 'auto-destroy' or 'auto-ignore' ?
>>>'Squelch' isn't very intuitive for non-natives.
>>
>>I'd prefer not to rename it at this time. "auto-destroy" is already
>>the name of an option in Z and "auto-ignore" doesn't reflect all of
>>the properties of the patch.
>>
>I have to agree with Werner... I saw the word 'squelch' for the first
>time in my life in this thread.
It's a somewhat suitable word for the on-generation version.
"Squelch" does not mean destroy. It's like "supress", with
connotations that the thing being "squelched" is undesirable or bad.
You often hear of rumors being squelched,
-Chris
Ed Cogburn
>
> 2) do not destroy armor/weapons dropped my uniques.
>
Why? This would be a little complicated to do, so is there a real
pressing reason for this? A bad object is bad no matter who dropped
it.
--
"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! =-----
Lev Zakrevski
Ed Cogburn wrote:
>
> Lev Zakrevski wrote:
> >
> > 2) do not destroy armor/weapons dropped my uniques.
> >
>
> Why? This would be a little complicated to do, so is there a real
> pressing reason for this? A bad object is bad no matter who dropped
> it.
Well, if I am playing high-level character, I usually do not inspect
all robes all soft leather boots laying around. But, if Sauron will drop
one, I will try to identify it! Unique drops are good, and have a high
probability to be excellent...
Lev Zakrevski
Ed Cogburn
So make sure that a) you are not suppressing robes outright from the
main squelch menu (under [e] Body Armor) because that will squelch all
robes, even artifacts. b) on your secondary squelch menu (which
handles id of weapons/armor in player's backpack), you select "good or
below" for "soft armor" (at the bottom). Once in your inventory use a
scroll of id, or your pseudo-id to find out what the robes are, bad
ones will be auto-destroyed. This will means only ego and artifact
robes will be left. Nothing great dropped by a Unique will be lost or
missed.
Frank Schmitt
<dav...@melody.CS.Berkeley.EDU> wrote:
>
>Hi all,
>
>I've really enjoyed the debate that's been going on over the squelch
>patch. In the next version of the patch I think I'm going to include
>the following.
>
>1: Support for both squelch-on-generation and squelch-on-walk. This
>will be set by a flag that can be toggled in the main squelch menu.
>Squelch-on-generation will squelch artifacts if their type has been
>squelched. Squelch-on-walk will act as a free "destroy junk" when
>walking over an item, and artifacts will survive this process. This
>should keep everyone relatively happy and will allow people to test
>both methods so that an evental winner can be determined.
>
>2: I'll add an "object memory" feature so that the squelch menus will
>only show the name of a flavored object if the player has seen and
>identified an object of that type. This will be persistent across
>deaths in the same way that monster memory is, so that the player
>can eventually build up a complete list of objects in the game.
>
>3: I'll add some sort of file io so that the squelch settings can
>be saved to a prf file. (An aside -- are there any conventions
>that I should follow when creating or naming a file?)
>
Sounds good to me
>
>Does anyone have any other suggestions?
It seems to me that classes with weak pseudo-id have a problem if the
secondary sqelch is set to "destroy good or below".
Since excellent and special items are pseudo-id'd as "good", too, they
will get squelched (not sure about artifacts, don't know if you just try
to destroy them or do sth else).
Apart from that, it's a feature i've longed for since beginning to play
Angband, and it speeds up gameplay a lot.
greetings
frank
--
Problem not.
Frank Schmitt (franks...@gmx.de)
http://frankschmitt.homepage.com
Phone: +49 931 884677
Gwidon S. Naskrent
>Bah. I was just trying to distinguish it from squelch-on-generation.
>Although actually, you might be wrong about that--the Tk versions (and
>GSNband, if memory serves) implement some sort of fairly bizare option that
It's called easy_sense.
>allows you to TRY and pseudo-ID items on the floor. It takes place
>immediatly, but a failed attemp makes the item permenatly un-pseudo-ID-
>able. I personally dislike the option, but in combination with the
>autosquelch patch, it would allow a squelch-on-walk based on quality.
Or even squelch-on-look (easy_sense also works from a distance).
GSN
James W Sager Iii
Autosquelch -- the next.. by Cody Ha...@chaos.net.nz
> Although actually, you might be wrong about that--the Tk versions (and
> GSNband, if memory serves) implement some sort of fairly bizare option that
> immediatly, but a failed attemp makes the item permenatly un-pseudo-ID-
> able. I personally dislike the option, but in combination with the
> autosquelch patch, it would allow a squelch-on-walk based on quality.
>
There is some confusion I believe...
There are two different ideas of squelch on walk on.
One concerns itself with auto-destroying things based on quality from a
mere step on...
I think this is what the poster is refering to. And this one greatly
changes the game dynamics.
The other that was being proposed and took me a while to figure out
myself is generating everything, and only squelching things as you step
on them, does not destroy things based on quality, but by name type. Ie
elf skeletons.
Cody Hatch
rec.games.roguelike.angband said:
>On 3 May 2000 23:10:00 GMT, co...@chaos.net.nz (Cody Hatch) wrote:
>
>>Bah. I was just trying to distinguish it from squelch-on-generation.
>>Although actually, you might be wrong about that--the Tk versions (and
>>GSNband, if memory serves) implement some sort of fairly bizare option
>>that
>
>It's called easy_sense.
Ah yes.
>>allows you to TRY and pseudo-ID items on the floor. It takes place
>>immediatly, but a failed attemp makes the item permenatly un-pseudo-ID-
>>able. I personally dislike the option, but in combination with the
>>autosquelch patch, it would allow a squelch-on-walk based on quality.
>
>Or even squelch-on-look (easy_sense also works from a distance).
Hmm...squelch-on-sense? Be an interesting compromise between squelch-on-
generate and squelch-on-walk/pseudo-ID/whatever you want to call it.
Of course, what would be REALLY interestingly cool would be to create a
ball form of the Identify spell. Could fit quite well with some of the
bandied modifications to the Identify and *Identify* system.
Matthias Kurzke
>Gwidon S. Naskrent sneezed, and the green bits that splattered on
>rec.games.roguelike.angband said:
>
>>On 3 May 2000 23:10:00 GMT, co...@chaos.net.nz (Cody Hatch) wrote:
>>
>>>Bah. I was just trying to distinguish it from squelch-on-generation.
>>>Although actually, you might be wrong about that--the Tk versions (and
>>>GSNband, if memory serves) implement some sort of fairly bizare option
>>>that
>>
>>It's called easy_sense.
>
>Ah yes.
>
>>>allows you to TRY and pseudo-ID items on the floor. It takes place
>>>immediatly, but a failed attemp makes the item permenatly un-pseudo-ID-
>>>able. I personally dislike the option, but in combination with the
>>>autosquelch patch, it would allow a squelch-on-walk based on quality.
>>
>>Or even squelch-on-look (easy_sense also works from a distance).
>
>Hmm...squelch-on-sense? Be an interesting compromise between squelch-on-
>generate and squelch-on-walk/pseudo-ID/whatever you want to call it.
>
>Of course, what would be REALLY interestingly cool would be to create a
>ball form of the Identify spell. Could fit quite well with some of the
>bandied modifications to the Identify and *Identify* system.
>
But only give it to Rogues... if at all...
shren
> But only give it to Rogues... if at all...
I was thinking that rogues should have sort of an 'advanced' id which
actually discovers the cash value of the item. Every time you puesdo-id
the item successfuly, and you are a rogue, then you get a wild guess at
the price. (say, between 1000% and 10%.) However, if the item already
has a price guess, then the guess is only updated if it is *better* than
the last one, so the appraisal converges on the real price. This would
give rogues a distinct advantage, especially with random artifacts. (hmm,
I'm wearing a 21271 gp set of body armor, and I have a 72521 gp set in my
bag. swap!)
However, "It breaks", all at once now, "savefile compatibility." Unless
you store the data in the inscription (say, <$72521>), and that *is* a
hack.
Ben Harrison
Personally, I would recommend saving "squelch" savings in a
standard user pref file, just like all the other preferences.
Pick a letter, say, "I", and use entries like "I:<num>:k" to mean
"apply kill (k) to object kind <num> when walked on (or, if you must
allow squelch-on-generation, then when generated)". This way, no
matter how you actually use this information, you can later, with
no external changes, implement "auto-get" as "I:<num>:g", and even
"auto-eat", "auto-quaff", etc, once the energy story is worked out.
You will need a new command to interact with these settings, say,
for the sake of argument, "$", since this option never affects any
objects with the "$" symbol, and because all other symbols are taken.
Look at the other related commands ("@", "%", "&", "=" come to mind)
to see how you should set up the primary screen, including the way in
which "load user pref file" and "append auto-actions to user pref file"
are implemented.
There are several patches floating around, and I keep meaning to make
a clean one myself, to automatically dump a complete "<PLAYER>.prf"
file based on *all* macros, colors, visuals, options, and such when
the savefile is saved, so if you really think you want that behavior,
consider doing it as two separate things (i.e. your stuff, plus a
separate thing for maintaining a user pref file on savefile saves).
Note that you will not need to do any filename choices, since the
user pref mechanism should take care of that for you.
Finally, note that there is already an "object memory" screen, it
is currently under the "~" command. Note that the "aware" object
flag is automatically set for non-flavored object kinds. That is,
your menus can show *all* object kinds for which "aware" is true.
You *might* want to actually show all entries, with "(unaware)"
in the slots of unaware objects, just so the player has the same
letters for each entry each time they use the menus. See also the
"wizard mode" commands for object creation, you may be able to use
the same "pick tval" and "pick sval" code.
--- Ben ---
dav...@melody.CS.Berkeley.EDU (David T. Blackston) writes:
> Hi all,
>
> I've really enjoyed the debate that's been going on over the squelch
> patch. In the next version of the patch I think I'm going to include
> the following.
>
> 1: Support for both squelch-on-generation and squelch-on-walk. This
> will be set by a flag that can be toggled in the main squelch menu.
> Squelch-on-generation will squelch artifacts if their type has been
> squelched. Squelch-on-walk will act as a free "destroy junk" when
> walking over an item, and artifacts will survive this process. This
> should keep everyone relatively happy and will allow people to test
> both methods so that an evental winner can be determined.
>
> 2: I'll add an "object memory" feature so that the squelch menus will
> only show the name of a flavored object if the player has seen and
> identified an object of that type. This will be persistent across
> deaths in the same way that monster memory is, so that the player
> can eventually build up a complete list of objects in the game.
>
> 3: I'll add some sort of file io so that the squelch settings can
> be saved to a prf file. (An aside -- are there any conventions
> that I should follow when creating or naming a file?)
>
> I have a few other ideas, but they will have to wait for a future
> version...
>
> This patch should be released towards the end of May. (I'm pretty
> busy for the next couple of weeks.) I plan on developing the patch
> first for V290 and possibly porting to the other variants.
>
> Does anyone have any other suggestions?
>
> Dave
David T. Blackston
>
>Personally, I would recommend saving "squelch" savings in a
>standard user pref file, just like all the other preferences.
>
>Pick a letter, say, "I", and use entries like "I:<num>:k" to mean
>"apply kill (k) to object kind <num> when walked on (or, if you must
>allow squelch-on-generation, then when generated)". This way, no
>matter how you actually use this information, you can later, with
>no external changes, implement "auto-get" as "I:<num>:g", and even
>"auto-eat", "auto-quaff", etc, once the energy story is worked out.
This is a cool idea -- I'll definitely play around with it.
>
>You will need a new command to interact with these settings, say,
>for the sake of argument, "$", since this option never affects any
>objects with the "$" symbol, and because all other symbols are taken.
Easy enough...
>
>Look at the other related commands ("@", "%", "&", "=" come to mind)
>to see how you should set up the primary screen, including the way in
>which "load user pref file" and "append auto-actions to user pref file"
>are implemented.
>
>There are several patches floating around, and I keep meaning to make
>a clean one myself, to automatically dump a complete "<PLAYER>.prf"
>file based on *all* macros, colors, visuals, options, and such when
>the savefile is saved, so if you really think you want that behavior,
>consider doing it as two separate things (i.e. your stuff, plus a
>separate thing for maintaining a user pref file on savefile saves).
Check.
>
>Note that you will not need to do any filename choices, since the
>user pref mechanism should take care of that for you.
>
>Finally, note that there is already an "object memory" screen, it
>is currently under the "~" command. Note that the "aware" object
>flag is automatically set for non-flavored object kinds. That is,
>your menus can show *all* object kinds for which "aware" is true.
>You *might* want to actually show all entries, with "(unaware)"
>in the slots of unaware objects, just so the player has the same
>letters for each entry each time they use the menus. See also the
>"wizard mode" commands for object creation, you may be able to use
>the same "pick tval" and "pick sval" code.
Actually, the squlch menu setup was modeled after the wiz "create item"
command. I did combine a few things to make it look nicer but
the original code was almost identical to the wiz-mode stuff.
Also, I want the flavored object memory to be persistent across
death. This is simple enough to do with the current savefile format.
I was planning on denoting flavored items that have never been
seen with something along the lines of "(unaware)" or "?" or something
similar. I'll just have to see what looks best.
>
>--- Ben ---
Thanks for your input!
Regards,
Dave
Julian Lighton
>
>Personally, I would recommend saving "squelch" savings in a
>standard user pref file, just like all the other preferences.
>
>Pick a letter, say, "I", and use entries like "I:<num>:k" to mean
>"apply kill (k) to object kind <num> when walked on (or, if you must
>allow squelch-on-generation, then when generated)".
Does this mean I can quaff-on-generation? :)
>This way, no
>matter how you actually use this information, you can later, with
>no external changes, implement "auto-get" as "I:<num>:g", and even
>"auto-eat", "auto-quaff", etc, once the energy story is worked out.
I really don't think anything beyond auto-kill and auto-pickup will or
should be implemented. If it doesn't take energy, it's probably
abusable. If it does, it can get you killed.
>See also the
>"wizard mode" commands for object creation, you may be able to use
>the same "pick tval" and "pick sval" code.
That code is pretty nasty, IMO.
--
Julian Lighton jl...@fragment.com
"Elementary penguins singing Hare Krishna
Man you should have seen them kicking Edgar Allen Poe"
-- The Beatles
Ed Cogburn
>
> Personally, I would recommend saving "squelch" savings in a
> standard user pref file, just like all the other preferences.
>
> Pick a letter, say, "I", and use entries like "I:<num>:k" to mean
> "apply kill (k) to object kind <num> when walked on (or, if you must
> matter how you actually use this information, you can later, with
> no external changes, implement "auto-get" as "I:<num>:g", and even
> "auto-eat", "auto-quaff", etc, once the energy story is worked out.
>
I don't see how you could make this useful. Nobody's going to use
auto-eat or auto-quaff since these are settings which would change on
a frequent basis. A player would have to disable auto-eat because
he's already gorged, for example. What potions would a player always
want to drink? Most potions the player finds of value will be saved
until a certain situation which requires that specific potion.
auto_get could be useful, but only if I can control it by in-game
menus, and not a pref file.
I'd rather have the in-game menus for squelching instead of a pref
file, too.
James W Sager Iii
Autosquelch -- the next.. Julian Lighton@fragment. (1160)
> >Pick a letter, say, "I", and use entries like "I:<num>:k" to mean
> >"apply kill (k) to object kind <num> when walked on (or, if you must
> >allow squelch-on-generation, then when generated)".
> Does this mean I can quaff-on-generation? :)
You walk down the set of staircases.
You feel very smart.
You feel very strong.
You are gorged.
You are gorged.
You die. -more-
Joe bob dies from anti-starvation.
Ben Harrison
All of the user pref file stuff *also* has in game menus. The user
pref file is just the way in which those settings can be preserved
from one session to another (or sent to friends).
--- Ben ---
Ben Harrison
Thus, my comment "once the energy story is worked out".
--- Ben ---
jl...@fragment.com (Julian Lighton) writes:
> >This way, no
> >matter how you actually use this information, you can later, with
> >no external changes, implement "auto-get" as "I:<num>:g", and even
> >"auto-eat", "auto-quaff", etc, once the energy story is worked out.
>
Julian Lighton
>jl...@fragment.com (Julian Lighton) writes:
>> >This way, no
>> >matter how you actually use this information, you can later, with
>> >no external changes, implement "auto-get" as "I:<num>:g", and even
>> >"auto-eat", "auto-quaff", etc, once the energy story is worked out.
>>
>> I really don't think anything beyond auto-kill and auto-pickup will or
>> should be implemented. If it doesn't take energy, it's probably
>> abusable. If it does, it can get you killed.
>
Yes, but I suspect that the energy story will prove intractable. It
only works for auto-pickup because that loophole's always been there,
and for auto-kill because it's really more a convenience than anything
else.
--
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
Julian Lighton
Ed Cogburn <ecog...@greene.xtn.net> wrote:
>Ben Harrison wrote:
>>
>> Personally, I would recommend saving "squelch" savings in a
>> standard user pref file, just like all the other preferences.
>>
>> "apply kill (k) to object kind <num> when walked on (or, if you must
>menus, and not a pref file.
> I'd rather have the in-game menus for squelching instead of a pref
>file, too.
Any decent (and most indecent) implementation would do both; make your
choices in an in-game menu, and let you dump it out to a pref file.
--
Julian Lighton jl...@fragment.com
"Is it dark when the moon is down?
Is it dark with a single flame?" -- Savatage
Ben Harrison
I doubt it will prove intractable, if done "right"....
Simply saying that picking up an object from the floor, in any way,
costs 50 energy, whether done via "select from floor", or "auto-get",
or the "stay still command" when on top of something, etc, would do
the trick. Of course, then people who hate the 10% sales tax would
start yelling about the "pick up penalty", and how they should not
have to pay it.
I really doubt people will even notice, in the long run.
Though some people did yell bloody murder when I threatened to make
it cost 141 energy to move "diagonally". I somehow forgot to put that
in as an option, like I intended. Very odd to have everything in the
diagonal be treated as "1.4" grids, *except* for the cost of moving.
--- Ben ---
Julian Lighton
>jl...@fragment.com (Julian Lighton) writes:
>> Yes, but I suspect that the energy story will prove intractable. It
>> only works for auto-pickup because that loophole's always been there,
>> and for auto-kill because it's really more a convenience than anything
>> else.
>
>
>Simply saying that picking up an object from the floor, in any way,
>costs 50 energy, whether done via "select from floor", or "auto-get",
>or the "stay still command" when on top of something, etc, would do
>the trick. Of course, then people who hate the 10% sales tax would
>start yelling about the "pick up penalty", and how they should not
>have to pay it.
>
>I really doubt people will even notice, in the long run.
Until they get killed by auto-pickup. Still, it's probably the best
solution to the energy loophole, and at 50 energy, it's less likely
that something will get a double move on you.
Auto-quaff (or whatever) would still have to take as long as doing it
by hand, otherwise it would be abusable. At 100 energy for it, it
raises a real chance of something killing you when you step on a pile
of loot while running.
>Though some people did yell bloody murder when I threatened to make
>it cost 141 energy to move "diagonally". I somehow forgot to put that
>in as an option, like I intended. Very odd to have everything in the
>diagonal be treated as "1.4" grids, *except* for the cost of moving.
It'd be nice, but it still raises the chance of something nasty
getting a double move. (perhaps if the energy cost for a "normal"
action were 140, and moving (but not attacking) in a straight line
cost only 100, but that would likely have its own consequences.)