About compacting
Joseph Oberlander
compacting, and I thought:
Why even have it? If we must have it, then make the limit a lot
higher than it currently is, as objects now stack and CPUs are no
longer what they were ten years ago.
I thin kwe can all agree that the time to increase this limit has come.
Gwyn Judd
say such a terrible thing:
Yeah I have to agree with you. It makes little sense to me to be going
around fighting with elves and trolls and stuff when all of a sudden you
get this voice come down "Compacting objects..."
--
Gwyn Judd (tj...@guvfybir.qlaqaf.bet)
My return address is rot13'ed
This is now. Later is later.
Matthias Kurzke
>I was shocked! How could Joseph Oberlander <ober...@pacbell.net>
>say such a terrible thing:
>>I was reading in another thread where people were complaining about
>>compacting, and I thought:
>>
>>Why even have it? If we must have it, then make the limit a lot
>>higher than it currently is, as objects now stack and CPUs are no
>>longer what they were ten years ago.
>>
>>I thin kwe can all agree that the time to increase this limit has come.
>
>Yeah I have to agree with you. It makes little sense to me to be going
>around fighting with elves and trolls and stuff when all of a sudden you
>get this voice come down "Compacting objects..."
>
I usually only get this in Angband when I'm clearing dragon pits... and
I'd wish object compacting would start by destroying all gold, which is
a big and boring part of the drop.
Matthias
--
`The question is,' said Humpty Dumpty, `which is to be master--that's all.'
Werner Baer
news:39229ee3...@netnews.hinet.net...
> tj...@guvfybir.qlaqaf.bet (Gwyn Judd) wrote:
>
> >>Why even have it? If we must have it, then make the limit a lot
> >>higher than it currently is, as objects now stack and CPUs are no
> >>longer what they were ten years ago.
I think the limit is memory requirements, no CPU.
And there may be systems where an array shouldn't exeed 64 kbyte.
> I usually only get this in Angband when I'm clearing dragon pits... and
> I'd wish object compacting would start by destroying all gold, which is
> a big and boring part of the drop.
I'd wish it first would compact the gold.
Compact all these different 'gold items' in a stack into one item.
(And leave all items with inscriptions alone)
Werner.
--
begin 755 This is not an attachment
I'm a signature virus. Please copy me into your .sig to help me spread!
end
jwk
<ober...@pacbell.net> wrote:
>I was reading in another thread where people were complaining about
>compacting, and I thought:
>
>higher than it currently is, as objects now stack and CPUs are no
>longer what they were ten years ago.
>
you are of course free to recompile your own copy after increasing
MAX_I_IDX in defines.h, but as long as vanilla angband is supposed to
run on 286 / old Mac's etcetera, I think you won't see it changed in
vanilla.
Jurriaan
--
The absence of alternatives clears the mind marvelously.
Henry Kissinger
GNU/Linux 2.2.15 SMP 3 users load av: 0.00 0.04 0.13
Joseph Oberlander
>
> you are of course free to recompile your own copy after increasing
> MAX_I_IDX in defines.h, but as long as vanilla angband is supposed to
> run on 286 / old Mac's etcetera, I think you won't see it changed in
> vanilla.
>
> Jurriaan
IIRC, a lowly 286 and the very first mac can easily handle a larger
array. This is a holdover from old 8-bit computers and should be changed.
Julian Lighton
Joseph Oberlander <ober...@pacbell.net> wrote:
>> >I thin kwe can all agree that the time to increase this limit has come.
>>
>> you are of course free to recompile your own copy after increasing
>> MAX_I_IDX in defines.h, but as long as vanilla angband is supposed to
>> run on 286 / old Mac's etcetera, I think you won't see it changed in
>> vanilla.
>
>array.
Depends on how much memory they have. (That said, we can probably
afford more spece. Looking at 2.8.5, I estimate each object_type at
52 bytes or less, depending on how much padding is required. (104 if
everything needs to be aligned to a 32-bit word.) That works out to
about 13K for the current size. Not insignificant, but we can
probably grow them some, maybe with a smaller size #ifdef
ANGBAND_LITE.)
The objective shouldn't be "no compaction ever", though. "No
compaction under normal circumstances" is enough. Stacking makes it a
bit too easy now. Double the size and it seems very unlikely. (How
much does your average multi-hued dragon pit drop, anyway?)
> This is a holdover from old 8-bit computers and should be changed.
No it isn't. Angband doesn't support 8-bit machines to begin with. I
don't think it ever has. You're talking about Apple II/Commodore
64-class machines.
--
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
Chris Kern
<ober...@pacbell.net> posted the following:
>IIRC, a lowly 286 and the very first mac can easily handle a larger
>array. This is a holdover from old 8-bit computers and should be changed.
What kind of "8-bit computers" did Angband ever support? Even the
lowly 8088 was 16-bit.
-Chris
Wim
Joseph Oberlander heeft geschreven in bericht
<392324EE...@pacbell.net>...
>IIRC, a lowly 286 and the very first mac can easily handle a larger
>array. This is a holdover from old 8-bit computers and should be
changed.
I think the mac could as its processor had IIRC 24-bit index registers.
The 8086 or 80286 has only 16 bit index registers and segment registers.
you can only have > 64 Kb arrays with elements that are a power of 2 in
size and using complicated pointer arithmetic.
Wim
Joseph Oberlander
> The objective shouldn't be "no compaction ever", though. "No
> compaction under normal circumstances" is enough. Stacking makes it a
> bit too easy now. Double the size and it seems very unlikely. (How
> much does your average multi-hued dragon pit drop, anyway?)
I never said it was - just that doubling it or quadrupling it would
make it much less likely to occur. Before stacking, it was unlikely, as
objects destroyed after a while, but now that you can have multiple
things in a space, you can very easily push this limit.
> > This is a holdover from old 8-bit computers and should be changed.
>
> No it isn't. Angband doesn't support 8-bit machines to begin with. I
> don't think it ever has. You're talking about Apple II/Commodore
> 64-class machines.
My bad. Make that 16-bit computers. I think we can handle a few more
K to keep everyone happy. We already have term windows and tiles and...
All of which suck up good amounts of ram.
tussock
> I was reading in another thread where people were complaining about
> compacting, and I thought:
Munchins, worried about loosing a broken stick. 8]
> Why even have it? If we must have it, then make the limit a lot
> higher than it currently is, as objects now stack and CPUs are no
> longer what they were ten years ago.
It's a memory limit (as others have said). But dude, who the hell wants
to sort through 20,000 items lying on the bloody dungeon floor. There's too
many now, thus the whole squelch idea.
> I thin kwe can all agree that the time to increase this limit has come.
The real trick is to have monsters drop less crap. Like auto-scumming,
auto-squelching is an ugly hack, the problem is the original generation
algorithms produce results that aren't wanted.
The problem should logically be fixed at it's core, useing code bloat
to undo something that you just finished doing has gotta be a bad concept.
--
tussock
Sarcasm is the lowest form of humor. 8]
James W Sager Iii
compacting by tus...@clear.net.nz
> auto-squelching is an ugly hack, the problem is the original generation
> algorithms produce results that aren't wanted.
Bleh, anyone who thinks auto-squelching as an ugly hack hasn't used it.
While it does solve some problems of a system with limits, that isn't
its primary function.
Chris Kern
<sag...@andrew.cmu.edu> posted the following:
>Bleh, anyone who thinks auto-squelching as an ugly hack hasn't used it.
You can't tell if something is a hack by playing with it, only by
looking at the code.
-Chris
David T. Blackston
tussock <sc...@clear.net.nz> wrote:
>
> The real trick is to have monsters drop less crap. Like auto-scumming,
>auto-squelching is an ugly hack, the problem is the original generation
>algorithms produce results that aren't wanted.
I maintain that _any_ generation algorithm will produce too much crap.
Once a character has a reaasonable set of equipment I would venture to
say that less than 5% of the objects generated are interesting in any
sense and this will be true regardless of the item generation scheme.
(If I'm wrong here, feel free to suggest an item generation scheme
that produces a reasonable percentage of useful items for characters
past stat gain. If you're unable to, then I suggest that auto-squelching
is useful regardless of the item generation scheme.)
Calling my code an "ugly hack" is an unfair characterization, IMO.
Have you even looked at it?
> The problem should logically be fixed at it's core, useing code bloat
>to undo something that you just finished doing has gotta be a bad concept.
>
>--
> tussock
>
>Sarcasm is the lowest form of humor. 8]
>
Regards,
Dave
shren
> The real trick is to have monsters drop less crap. Like auto-scumming,
> auto-squelching is an ugly hack, the problem is the original generation
> algorithms produce results that aren't wanted.
> to undo something that you just finished doing has gotta be a bad concept.
You know, I was thinking this playing Cthangband today - all of the
*shit* that I end up wading through. The generation algorithm looks sort
of like:
*
** **
*** ***
**** ****
***** *****
< shallower @ deeper >
So you get lots of local items, and items that are too high and too low
in about equal proportion. Maybe the scale needs to be crunched at one
end:
*
* **
** ***
*** ****
*** *****
< shallower @ deeper >
to force less shallow items.
Of course, that doesn't change the fact that a lot of *in depth* items
are crap.
shren
> Excerpts from netnews.rec.games.roguelike.angband: 25-May-100 Re: About
> compacting by tus...@clear.net.nz
>> auto-squelching is an ugly hack, the problem is the original generation
>> algorithms produce results that aren't wanted.
> Bleh, anyone who thinks auto-squelching as an ugly hack hasn't used it.
> While it does solve some problems of a system with limits, that isn't
> its primary function.
Well, I think hack is a quality of the code, not a quality of the
feature. So I can't tell, by merely playing the game, if the suqlch code
is a hack. I have to read the code to find out.
David T. Blackston
Chris Weisiger <jma...@inreach.com> wrote:
>James W Sager Iii wrote:
>>
>> Excerpts from netnews.rec.games.roguelike.angband: 25-May-100 Re: About
>> compacting by tus...@clear.net.nz
>> > The real trick is to have monsters drop less crap. Like auto-scumming,
>> > auto-squelching is an ugly hack, the problem is the original generation
>> > algorithms produce results that aren't wanted.
>>
>> Bleh, anyone who thinks auto-squelching as an ugly hack hasn't used it.
>> While it does solve some problems of a system with limits, that isn't
>> its primary function.
>
>of earthquakes waking monsters (in my personal version) is a hack. No
>matter how graceful it is when playing, the implementaion is still a hack.
>
>--
>enipykroP- ".tnenamrep wohon t'nia ti ,nos ,suoires os efil ekat t'noD"
>
>The Angband Newbie Guide: http://home4.pacific.net.sg/~jianson/tang/tang.html
>VaultMania: http://home4.pacific.net.sg/~jianson/vaults/vaults.html
Please define "hack" so that we are all on the same page here.
Also, in your opinion is any implementation of an "auto-squelch"-like
feature going to be a hack, or is there a non-hackish way of implementing
it?
Just curious,
Dave
Chris Weisiger
Jules Bean
>
> James W Sager Iii wrote:
> >
> > Excerpts from netnews.rec.games.roguelike.angband: 25-May-100 Re: About
> > compacting by tus...@clear.net.nz
> > > The real trick is to have monsters drop less crap. Like auto-scumming,
> > > auto-squelching is an ugly hack, the problem is the original generation
> > > algorithms produce results that aren't wanted.
> >
> > Bleh, anyone who thinks auto-squelching as an ugly hack hasn't used it.
> > While it does solve some problems of a system with limits, that isn't
> > its primary function.
>
> The implementation of the auto-squelch is a hack, just like my addition
> of earthquakes waking monsters (in my personal version) is a hack. No
> matter how graceful it is when playing, the implementaion is still a hack.
Conflict of notation here.
When I describe a `feature' as a hack, I mean that the feature is a
work-around for a gameplay bug (not a programmatical bug) and
furthermore is a hackish workaround.
If I describe a piece of code as a hack, then I am talking about the
code itself.
Hacks can be elegantly coded, and good games can be hackily coded. I
think this is the problem we're having.
Anyhow, as I understood it, the original allegation was that
auto-squelch was a *gameplay* hack, not a coding one.
Incidentally, what (exactly) does it do?
--
Jules Bean | Any sufficiently advanced
jules@{debian.org,jellybean.co.uk} | technology is indistinguishable
jm...@hermes.cam.ac.uk | from a perl script
David T. Blackston
Simply stated, it allows the user to define a set of objects
which are deemed worthless and these items are automagically
destroyed. They can be destroyed either upon creation (in
which case they are never placed in the dungeon) or when they
are walked on. There are checks to make sure that the player
is aware of an object before it can be destroyed.
Example: The player sees and identifies a potion of sickliness.
He decides that it is useless and marks it to be squelched.
All future PoSs that the game generates will either not be
placed in the dungeon or will be destoryed for free when the
player walks over them.
There's another type of squelching that occurs only for armor and
weapons and allows the user to specify qualities (i.e. "cursed",
"average") for objects. Objects failing to meet this quality check
will be destroyed (for free) once the user is aware of their
quality.
More details (and patches) are available at
htpp://www.cs.berkeley.edu/~davidb/angband/
That being said, I'd like to address the "hackiness" of my code...
The gameplay bug that I set out to address in this code is the
overwhelming amount of time that players spend sifting through
items most of which are useless. Although fixing the item
generation algorithm will reduce the amount of "junk" a player
sees, I still believe that any item generation algorithm will produce
a vast number of useless (even if in-depth) items and therefore a
feature that streamlines the user's interaction with these items
is a useful feature.
The code itself is certainly not perfect, but it is easily
extensible, and should probably only need changing when a
new object TVAL is added to the game. Thus, it works now and
it's easy to make it work in the future. I'd happily accept
any suggestions as to how to make the code better. Email's
probably best for this.
Regards,
Dave
Julian Lighton
Chris Kern <ke...@grinnell.edu> wrote:
>On Fri, 26 May 2000 06:16:50 -0400, James W Sager Iii
><sag...@andrew.cmu.edu> posted the following:
>
>>Bleh, anyone who thinks auto-squelching as an ugly hack hasn't used it.
>
>looking at the code.
Some things are hacks from the design perspective; it doesn't matter
how cleanly you code them. Auto-scum certainly fits the bill, and
auto-squelch probably does, too.
--
Julian Lighton jl...@fragment.com
"Guess kids these days can't tell their gravity from their rotating
frame of reference." -- _Consider Phlebas_
Gwidon S. Naskrent
Blackston) wrote:
>I maintain that _any_ generation algorithm will produce too much crap.
>Once a character has a reaasonable set of equipment I would venture to
>say that less than 5% of the objects generated are interesting in any
>sense and this will be true regardless of the item generation scheme.
The problem is not in the large percentage of useless items, but in
their abundance. An unique who summons dragons will leave over a
hundred or more items on the field when defeated. A dragon pit is
utterly ridiculous as regards the spoils. Note that dragons are among
the best droppers in ADOM, where most monsters never drop more than
one item, if any at all. But they don't get summoned there.
>Calling my code an "ugly hack" is an unfair characterization, IMO.
>Have you even looked at it?
I don't think he meant the way you executed it, but a general
principle. People are SO used to looking after results that they
cannot spot causes. So they end up striking the wrong target.
Gwidon S. Naskrent (nask...@artemida.amu.edu.pl)
GEU/J d- s+:+ a-- C+++ ULB++>++++ P- 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?
tussock
> In article <392CDC53...@clear.net.nz>,
> tussock <sc...@clear.net.nz> wrote:
> >
> > The real trick is to have monsters drop less crap. Like auto-scumming,
> >auto-squelching is an ugly hack, the problem is the original generation
> >algorithms produce results that aren't wanted.
>
> I maintain that _any_ generation algorithm will produce too much crap.
> Once a character has a reaasonable set of equipment I would venture to
> say that less than 5% of the objects generated are interesting in any
> sense and this will be true regardless of the item generation scheme.
> (If I'm wrong here, feel free to suggest an item generation scheme
> that produces a reasonable percentage of useful items for characters
> past stat gain. If you're unable to, then I suggest that auto-squelching
> is useful regardless of the item generation scheme.)
I do feel squelching is a very *good* fix from a gameplay perspective,
especially as others have mentioned the awkwardness of the generation code, and
the time that might take to re-write. I look foward to it being included as
standard.
> Calling my code an "ugly hack" is an unfair characterization, IMO.
> Have you even looked at it?
Apologies for any offence caused. The item and level generation code are
the least familiar part to me, I applied the term as it is used throughout, to
refer to things which should really be done another way, not to the code
itself.
_Item generation_ is IMO silly, a single room (dragon pit) can drop 250+
items, @ can only expect to carry out 10-20 at best. That plus a vault and a
couple of summoners, IME 500+ items on a level are not too unusual.
My original comment above seems correct, don't stick with code that does
unwanted things.
Changing the current generation scheme should require a fair rebalance, so
I don't expect it anytime soon, as it'll not be taken lightly.
Joseph Oberlander
> _Item generation_ is IMO silly, a single room (dragon pit) can drop 250+
> items, @ can only expect to carry out 10-20 at best. That plus a vault and a
> couple of summoners, IME 500+ items on a level are not too unusual.
> My original comment above seems correct, don't stick with code that does
> unwanted things.
>
> Changing the current generation scheme should require a fair rebalance, so
> I don't expect it anytime soon, as it'll not be taken lightly.
So, instead of rebalancing things, just increase the limit before compacting
occurs. Simple and effective for now.