A complaint about the move to ID-by-use
The Wanderer
nightly builds - and on what I've read recently in skimming the Web
forum. It's faintly possible that some of it is obsoleted in more recent
builds, but from what I've read I don't think that's very likely.
I like the idea of ID-by-use in principle, and I would like having it
available as an option. However, pretty much all discussion of the move
towards ID-by-use seems to involve the removal - or drastic reduction in
availability - of other forms of ID, and I don't like that at all. There
are at least three problems with it:
* ID-by-use is not - or at least, by my understanding, not yet - as
comprehensive as other forms of ID (in that other forms of ID give you
all of an item's properties at once, whereas my understanding is that
ID-by-use - in at least some cases - gives you only the properties
you've already had a chance to notice);
* ID-by-use is not as convenient as other forms of ID (for equipment, in
that you have to swap out one item in order to try to ID another which
would go in the same slot, and then - aside from the unlikely case where
the new item is obviously better - swap back, regardless of whether you
learned anything; for non-equipment, in that you have to find some
appropriate context to try the item);
* ID-by-use is risky (for equipment, both because of curses and because
of the chance of being attacked while trying out unIDed equipment; for
non-equipment, both because of the possible effects of the item and
because the item - or, in the case of wand or staff, a charge - is lost
by the use), where other forms of ID are not.
This last point is the most important of the three. Many - if not most
or even all - of the people involved in these discussions seem to think
of that added source of risk as being a good thing. From my perspective,
it is very much a bad one.
For me, the ready availability of reliable, risk-free ID is an absolute,
non-negotiable requirement.
If ID-by-use can be both risk-free and reliably effective, then it
should be just fine (though there is, inherently, at least a minor risk
involved in e.g. swapping out armor - or any resist-providing item -
while in the dungeon). If it can't, then there must be some other means
of reliable ID which is both risk-free and commonly available.
I do not insist on it being practical to "identify all items before
equip/use". I do, however, insist on it being practical to "identify all
items before discard" if I so choose, as well as the "no risk" factor
mentioned above. (I don't mind if there is a risky approach available,
but there must be a risk-free fallback which can be relied upon if I
want to do so.) Note that, for these purposes, pseudo-ID as "average" or
(if implemented so that I'd agree with the assessment) "bad" counts as
ID, if achieved in time.
Even in current - or, for that matter, earlier - release versions of the
game, almost the only way I've been able to find of fulfilling these
requirements is to play nothing but mages. I'm not necessarily happy
about that, since it leaves out much of the potential variety of the
game, but nothing else seems capable of getting the job done. The
addition of ID-by-use should have the potential to fix that problem, by
adding ways to let other classes be able to fulfill those requirements;
instead, because people seem intent on adding the risk factor instead of
trying to eliminate it - and then compensating for the new ID method by
reducing the availability of other forms of ID - it actually seems as if
it is making the problem worse.
I *have* found one way of achieving "ID all items before discard"
without the Identify spell, but it's tedious and inconvenient - and
while it's more fun than playing without reliable risk-free ID at all,
it's little enough fun that I wouldn't bother playing the game at all if
it were the only practical means of achieving that goal. (It's also 100%
impossible in e.g. an Ironman game.)
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
Eddie Grove
> and then compensating for the new ID method by
> reducing the availability of other forms of ID - it actually seems as if
> it is making the problem worse.
I am not aware of any compensation to make other forms of ID less common.
That's not to say it hasn't been done, but I don't know of it.
I am aware of a change to make them more common, by increasing ?id drops
from single items to stacks.
The real problem is the overall reduction in consumables, and that applies to
all consumables from restore potions to identify scrolls. That change is
because people cannot accept squelch as the answer, and insist on mucking with
drops instead.
As to your main point, if you want cheap risk-free ID, there seems little
point in requiring ID in the first place. IMO you should play with the need
for ID mostly removed from the game. There was a recent post on oook about
someone who is planning a patch or variant with that goal.
http://angband.oook.cz/forum/showthread.php?t=2572
Eddie
The Wanderer
> The Wanderer <wand...@fastmail.fm> writes:
>
>> and then compensating for the new ID method by reducing the
>> availability of other forms of ID - it actually seems as if it is
>> making the problem worse.
>
> I am not aware of any compensation to make other forms of ID less
> common. That's not to say it hasn't been done, but I don't know of
> it.
It's possible that it hasn't been done yet, but I am positive that I
have repeatedly seen discussion of increasing the rarity of ?ID (and, I
think, removing it from stores or at least making it more expensive),
exactly because ID-by-use - and, possibly, improved pseudo - mean that
otherwise ID is considered too easy. I was fairly sure that past mention
of that had indicated that it had already been done, but it's possible
I'm remembering wrong on that point.
I'll keep my eyes open and make sure to note down the next time or three
that I see it happen, so that I have somewhere to point to if this
subject comes up again...
> I am aware of a change to make them more common, by increasing ?id
> drops from single items to stacks.
Unless they will be common enough to use on essentially every item,
dropped ?ID isn't good enough except in the short term.
> The real problem is the overall reduction in consumables, and that
> applies to all consumables from restore potions to identify scrolls.
> That change is because people cannot accept squelch as the answer,
> and insist on mucking with drops instead.
I don't know if I'd accept squelch as *the* answer, but it's certainly a
very nice improvement. (One problem with squelch is that it doesn't kick
in on equipment before the equipment is IDed or at least pseudo'ed,
which makes it notably less useful compared to not having the bad item
drop in the first place. Another is that there doesn't seem, at least in
3.1.1, to be a way of defining a set of "default" squelch settings that
don't have to be manually recreated with each new character...)
> As to your main point, if you want cheap risk-free ID, there seems
> little point in requiring ID in the first place.
The point, or at least one point, is to still have that layer of
complexity in the game, as a way to help keep it interesting. (Even with
mages who have learned the Identify spell, IDing everything I care to
still has an in-game cost - it requires me to rest far more often than
many people would consider reasonable. I just happen to think of the
IDing as worth that tradeoff.)
In ADoM (the only other roguelike I've played very much), ID is still
necessary but is handled fairly satisfactorily, by having an
essentially-unlimited inventory (mitigated by burden) and a simple if
not trivial way of getting scrolls which will identify everything you're
carrying. That requires the resource management of obtaining ID, but
doesn't make it difficult to achieve if you spend the effort on it. (The
game also includes a readily-available - but not always-on-hand - means
of determining cursed vs. uncursed status, and a similar but less easily
accessible means of removing curses for non-nequipped items, which makes
ID-by-use much more practical.)
That approach wouldn't work for Angband, for obvious reasons, but it
does indicate that there are ways of getting the job done while still
including that layer of complexity. (Angband even has one already, if a
tedious and inconvenient one; just go back to town and buy sources of ID
whenever your inventory gets too full. There are definitely problems
with that approach, though, as I'm sure you can see probably even better
than I can.)
> IMO you should play with the need for ID mostly removed from the
> game. There was a recent post on oook about someone who is planning
> a patch or variant with that goal.
>
> http://angband.oook.cz/forum/showthread.php?t=2572
That does look interesting. It seems very wrong to the part of me that
wants things to fit thematically and/or in terms of rationalization, but
I'm not sure that's not just a matter of my being used to the current
rationalizations; the only objective problem I see with it is the loss
of that level of complexity, and thus to some degree of interest. I
think I could get used to that, and even possibly prefer it, but that
doesn't mean it's automatically a good idea.
Seebs
> I don't know if I'd accept squelch as *the* answer, but it's certainly a
> very nice improvement. (One problem with squelch is that it doesn't kick
> in on equipment before the equipment is IDed or at least pseudo'ed,
> which makes it notably less useful compared to not having the bad item
> drop in the first place. Another is that there doesn't seem, at least in
> 3.1.1, to be a way of defining a set of "default" squelch settings that
> don't have to be manually recreated with each new character...)
I also wish it could distinguish between "any torch whatsoever" and "any
torch which lacks special qualities". An everburning lantern could be a big
deal...
> The point, or at least one point, is to still have that layer of
> complexity in the game, as a way to help keep it interesting. (Even with
> mages who have learned the Identify spell, IDing everything I care to
> still has an in-game cost - it requires me to rest far more often than
> many people would consider reasonable. I just happen to think of the
> IDing as worth that tradeoff.)
I have a ranger who, at level 30, can cast a single identify spell which
has a nominal 50% chance of failure. (And which often fails five times
in a row...) But it's still usually worth it, though she's just now
gotten to the point where it's not rewarding to identify merely-magic
weapons and armor.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
The Wanderer
> On 2009-12-06, The Wanderer <wand...@fastmail.fm> wrote:
>
>> I don't know if I'd accept squelch as *the* answer, but it's
>> certainly a very nice improvement. (One problem with squelch is
>> that it doesn't kick in on equipment before the equipment is IDed
>> or at least pseudo'ed, which makes it notably less useful compared
>> to not having the bad item drop in the first place. Another is that
>> there doesn't seem, at least in 3.1.1, to be a way of defining a
>> set of "default" squelch settings that don't have to be manually
>> recreated with each new character...)
>
> I also wish it could distinguish between "any torch whatsoever" and
> "any torch which lacks special qualities". An everburning lantern
> could be a big deal...
Interface-wise, it would seem as if the simple way to fix that would be
to add a "Light Sources" section to the quality-squelch section.
However, if light sources aren't considered equipment in the same way as
the other things in that section, that might not be practical to
implement.
>> The point, or at least one point, is to still have that layer of
>> complexity in the game, as a way to help keep it interesting. (Even with
>> mages who have learned the Identify spell, IDing everything I care to
>> still has an in-game cost - it requires me to rest far more often than
>> many people would consider reasonable. I just happen to think of the
>> IDing as worth that tradeoff.)
>
> I have a ranger who, at level 30, can cast a single identify spell which
> has a nominal 50% chance of failure. (And which often fails five times
> in a row...) But it's still usually worth it, though she's just now
> gotten to the point where it's not rewarding to identify merely-magic
> weapons and armor.
I infer, from your mention of "merely-magic" items, that you're waiting
to cast the spell till after pseudo-ID. I don't wait; unless in the
middle of a fight, I ID the item before even picking it up. Even with
recent improvements, pseudo-ID - at the CLs I usually reach - takes far
too long to be practical.
Seebs
For ranger, identify is a huge pain -- 50% or higher failure (in theory,
from reading the code, it must be 50%, but it succeeds on the first try
pretty rarely, but fails two or three times quite often, experientially...
Probably just confirmation bias), takes more than half of total mana,
etcetera, but pseudo-ID is quite fast.
Eddie Grove
> I infer, from your mention of "merely-magic" items, that you're waiting
> to cast the spell till after pseudo-ID. I don't wait; unless in the
> middle of a fight, I ID the item before even picking it up. Even with
> recent improvements, pseudo-ID - at the CLs I usually reach - takes far
> too long to be practical.
My current char is a mage, down to DL 98, and occasionally I carry an item for
a while. I have not pseudoed anything the entire game. It appears that, for
practical purposes, mages are incapable of recognizing magic.
Eddie
The Wanderer
And I think we can agree that this is a bad thing.
(Interesting - last time this subject came up in conversation between us
on the newsgroup, you pointed to the fact that pseudo-ID improves
greatly at higher levels as an answer to my complaint that it was far
too slow to be useful. Apparently, at least for mages, the improvement
isn't great enough...)
Eddie Grove
> On 12/06/2009 05:13 PM, Eddie Grove wrote:
>
> > The Wanderer <wand...@fastmail.fm> writes:
> >
> >> I infer, from your mention of "merely-magic" items, that you're
> >> waiting to cast the spell till after pseudo-ID. I don't wait;
> >> unless in the middle of a fight, I ID the item before even picking
> >> it up. Even with recent improvements, pseudo-ID - at the CLs I
> >> usually reach - takes far too long to be practical.
> > My current char is a mage, down to DL 98, and occasionally I carry an
> > item for a while. I have not pseudoed anything the entire game. It
> > appears that, for practical purposes, mages are incapable of
> > recognizing magic.
>
> And I think we can agree that this is a bad thing.
IMO mages should get pseudo on pickup at CL 20, pseudo in LOS at CL 30, and ID
on pickup at CL 40. And of course they should get the fastest pseudo of all
classes before CL 20. Except that I don't think pseudo should even exist.
I'll have to have an argument with myself I guess.
> (Interesting - last time this subject came up in conversation between us
> on the newsgroup, you pointed to the fact that pseudo-ID improves
> greatly at higher levels as an answer to my complaint that it was far
> too slow to be useful. Apparently, at least for mages, the improvement
> isn't great enough...)
Yup. With low str, you have to use the ID spell rather than run around slowed
forever, and by the time your str is high enough ID is so cheap there's no
point not using it.
Eddie
The Wanderer
> The Wanderer <wand...@fastmail.fm> writes:
>
>> On 12/06/2009 05:13 PM, Eddie Grove wrote:
>>> My current char is a mage, down to DL 98, and occasionally I
>>> carry an item for a while. I have not pseudoed anything the
>>> entire game. It appears that, for practical purposes, mages are
>>> incapable of recognizing magic.
>>
>> And I think we can agree that this is a bad thing.
>
> IMO mages should get pseudo on pickup at CL 20, pseudo in LOS at CL
> 30, and ID on pickup at CL 40. And of course they should get the
> fastest pseudo of all classes before CL 20.
Most of which wouldn't affect me, since it's vanishingly rare for me to
even get a character to CL20 much less CL30. But that doesn't affect
your point.
> Except that I don't think pseudo should even exist. I'll have to have
> an argument with myself I guess.
(I thought I was the only one who did that. Not that I do it much
anymore...)
I do think pseudo should exist, and I don't think that mages should
necessarily be the best at it. They should be the best at recognizing
*magic*, yes, but they should not necessarily be as good as the more
directly martial classes at recognizing more mundane characteristics -
in which category, for this purpose, I think I would include to-hit,
to-dam, and AC bonuses; only ego enchantments and beyond would be a
mage's purview.
The trouble is that pseudo (and, relatedly, auto-ID) is currently not
divided up that way, and I don't know if I see any obvious way to so
divide it without making things unwieldy.
Matthew Vernon
> Yup. With low str, you have to use the ID spell rather than run
> around slowed forever, and by the time your str is high enough ID is
> so cheap there's no point not using it.
As a mage, I ID everything the minute I pick it up; the bit of the
game before being able to cast ID always irks me a bit.
Matthew
--
Rapun.sel - outermost outpost of the Pick Empire
http://www.pick.ucam.org
The Wanderer
> Eddie Grove <eddie...@hotmail.com> writes:
>
>> Yup. With low str, you have to use the ID spell rather than run
>> around slowed forever, and by the time your str is high enough ID
>> is so cheap there's no point not using it.
>
> As a mage, I ID everything the minute I pick it up; the bit of the
> game before being able to cast ID always irks me a bit.
I do much the same thing (ID even *before* pickup), and it's possibly
even worse, in that I don't usually make it that far in the first place.
I no longer recall for certain, but prior to moving up to recent
versions, I think I'd managed to get to the point where I could make it
to the Identify spell at least one game out of three. Nowadays, it
doesn't seem to happen more than half that often, if even that much.
Matthew Vernon
> I no longer recall for certain, but prior to moving up to recent
> versions, I think I'd managed to get to the point where I could make it
> to the Identify spell at least one game out of three. Nowadays, it
> doesn't seem to happen more than half that often, if even that much.
I dive relatively quickly until getting ID; I've learned to avoid
dragons, but other than that my hit-rate is pretty good, I think. What
kills you?
Magnate
> On 12/06/2009 04:03 PM, Seebs wrote:
>> On 2009-12-06, The Wanderer <wand...@fastmail.fm> wrote:
>>
>>> I don't know if I'd accept squelch as *the* answer, but it's
>>> certainly a very nice improvement. (One problem with squelch is
>>> that it doesn't kick in on equipment before the equipment is IDed
>>> or at least pseudo'ed, which makes it notably less useful compared
>>> to not having the bad item drop in the first place.
This isn't going to change unless pseudo goes away completely.
>>> Another is that
>>> there doesn't seem, at least in 3.1.1, to be a way of defining a
>>> set of "default" squelch settings that don't have to be manually
>>> recreated with each new character...)
This one is on my to-do list, under the heading "improved pref file
management and sensible default preferences".
>> I also wish it could distinguish between "any torch whatsoever" and
>> "any torch which lacks special qualities". An everburning lantern
>> could be a big deal...
>
> Interface-wise, it would seem as if the simple way to fix that would be
> to add a "Light Sources" section to the quality-squelch section.
> However, if light sources aren't considered equipment in the same way as
> the other things in that section, that might not be practical to
> implement.
This is a nice idea and if I remember I'll create a ticket for it tonight.
It shouldn't be too hard to add a tval for lights to the quality squelch
menu. There are no {good} lights, but you could squelch bad / average / all
but artifacts. (I'm not sure if there are any bad lights yet, but I'm sure
there will be one day ...)
Wanderer: For me, the ready availability of reliable, risk-free ID is an
absolute,
non-negotiable requirement.
Eddie: As to your main point, if you want cheap risk-free ID, there seems
little
point in requiring ID in the first place. IMO you should play with the need
for ID mostly removed from the game.
>>> The point, or at least one point, is to still have that layer of
>>> complexity in the game, as a way to help keep it interesting. (Even with
>>> mages who have learned the Identify spell, IDing everything I care to
>>> still has an in-game cost - it requires me to rest far more often than
>>> many people would consider reasonable. I just happen to think of the
>>> IDing as worth that tradeoff.
Well, I can't claim that Wanderer's opinion is unique, as there appear to be
two views emerging here:
- ID adds enjoyment to the game if it's risk-free, but detracts from it if
there are risks. (This is a paraphrase of what Wanderer said, but I hope it
captures the view.)
OR
- ID may as well not be in the game at all if it's risk free, as that adds
nothing but tedium, but ID with some risk does add spice and enjoyment to
the game.
I am firmly with Eddie in the latter camp. I infer that Takkaria is too,
otherwise we wouldn't have gone down the road of ID-by-use. Takkaria removed
annoying light-but-sticky curses on wearables, leaving only the rare heavily
cursed items as a risk to those IDing by use (and these can now be removed
by enchantment). He also removed instadeath potions, so that ID-by-use is
mildly risky but never instantly fatal. (That said, you can still be
instakilled by a scroll of Summon Undead, but we're working on making sure
that @ gets the first move.) There is obviously more work to do, but the
direction is set and magical ID will get rarer and more expensive as
ID-by-use gets better. (Not sure what will happen to pseudo - it's not
entirely orthogonal but has a slightly different set of issues.)
If anyone really believes that ID must be risk-free, the simplest thing is
just to maintain a two-line patch to stores.txt and object.txt, which makes
?ID always for sale at a cost of 1gp. I maintain a similar patch to increase
the rarity of all Zs, and it makes my playing experience just fine (and
saves me lots of ranting time about how Zs need to be nerfed).
CC
The Wanderer
> "The Wanderer" <wand...@fastmail.fm> wrote in message
>
>> On 12/06/2009 04:03 PM, Seebs wrote:
>
>>> On 2009-12-06, The Wanderer <wand...@fastmail.fm> wrote:
>>>
>>>> I don't know if I'd accept squelch as *the* answer, but it's
>>>> certainly a very nice improvement. (One problem with squelch is
>>>> that it doesn't kick in on equipment before the equipment is
>>>> IDed or at least pseudo'ed, which makes it notably less useful
>>>> compared to not having the bad item drop in the first place.
>
> This isn't going to change unless pseudo goes away completely.
I wasn't really expecting it to; this was more a point against what I
saw as Eddie's position that squelch is the answer to TMJ, and that
messing around with drops is therefore not necessary.
>>>> Another is that there doesn't seem, at least in 3.1.1, to be a
>>>> way of defining a set of "default" squelch settings that don't
>>>> have to be manually recreated with each new character...)
>
> This one is on my to-do list, under the heading "improved pref file
> management and sensible default preferences".
Yeah, I thought I'd read somewhere that this was pending.
>>>>>> For me, the ready availability of reliable, risk-free ID is
>>>>>> an absolute, non-negotiable requirement.
>>>>>
>>>>> As to your main point, if you want cheap risk-free ID, there
>>>>> seems little point in requiring ID in the first place. IMO
>>>>> you should play with the need for ID mostly removed from the
>>>>> game.
>>>>
>>>> The point, or at least one point, is to still have that layer
>>>> of complexity in the game, as a way to help keep it
>>>> interesting. (Even with mages who have learned the Identify
>>>> spell, IDing everything I care to still has an in-game cost -
>>>> it requires me to rest far more often than many people would
>>>> consider reasonable. I just happen to think of the IDing as
>>>> worth that tradeoff.
>
> Well, I can't claim that Wanderer's opinion is unique, as there
> appear to be two views emerging here:
>
> - ID adds enjoyment to the game if it's risk-free, but detracts from
> it if there are risks. (This is a paraphrase of what Wanderer said,
> but I hope it captures the view.)
I might say "unavoidable risks", but otherwise, that seems to summarize
my position pretty neatly.
> OR
>
> - ID may as well not be in the game at all if it's risk free, as that
> adds nothing but tedium, but ID with some risk does add spice and
> enjoyment to the game.
>
> I am firmly with Eddie in the latter camp. I infer that Takkaria is
> too, otherwise we wouldn't have gone down the road of ID-by-use.
As I said, I don't disagree with or dislike ID-by-use; in fact, I don't
think it's necessarily incompatible with risk-free ID, to within the
limits of how I define the term. The problem is that it doesn't seem to
be being implemented that way.
<snip>
> There is obviously more work to do, but the direction is set and
> magical ID will get rarer and more expensive as ID-by-use gets
> better.
And that is exactly what I'm objecting to. Unless ID-by-use can
substitute for magical ID in all respects (including being risk-free),
magical ID - or something which *can* so substitute - needs to remain
reliably available.
Hmm. Brainstorming a bit now.
ID can be risky, or risk-free.
ID can be limited, or unlimited.
ID can be inconvenient to access, or conveniently accessible.
Existing ID is risk-free, limited (except by way of the Identify spell,
which is viable only for mid-game-and-later mages), and inconvenient
(again, except for the Identify spell for mages).
ID-by-use - as it seems to be being implemented - is risky, unlimited,
and sometimes convenient but sometimes inconvenient.
I want ID to be risk-free, unlimited and convenient. (Convenience is of
course a spectrum. Exactly how convenient would be enough to satisfy me
varies depending on a number of factors; the reason it's so stringent in
this case is because of how limited Angband's inventory is.)
You seem to say that you want ID to be risky, unlimited and - I think -
convenient.
Have I missed anything (e.g. other possible characteristics of ID). left
anything out, or gotten anything wrong?
Are there other possible forms of ID which would have different
permutations of the possible characteristics?
What are the arguments for or against each side of each of the possible
characteristics?
> If anyone really believes that ID must be risk-free, the simplest
> thing is just to maintain a two-line patch to stores.txt and
> object.txt, which makes ?ID always for sale at a cost of 1gp.
That would be a workaround, but would be inconvenient (having to spend
an inventory slot and add burden just for ID, among possibly other
things) and less than entirely satisfactory. It may be the best of a
number of bad options, however.
Ray
> I want ID to be risk-free, unlimited and convenient. (Convenience is of
> course a spectrum. Exactly how convenient would be enough to satisfy me
> varies depending on a number of factors; the reason it's so stringent in
> this case is because of how limited Angband's inventory is.)
You've said that you want ID in the game, but I hear you objecting
to all of the ways ID can add interest (read: difficulty, ambiguity,
risk, management of limited supplies, tactical decisions based on
limited information, etc) to the game. The essence of interest in
a game, to me, is that there are interesting decisions to make. The
ID game in Angband poses such questions *by* being in various degrees
and in various tradeoffs risky, limited, and inconvenient. If it
were otherwise, then it would become a "no-brainer." Something you
never have to make a real choice about because there is always
one right answer ceases to add interest to the game.
And if there's always one right answer, why bother to make the user
do all the extra typing to identify everything? Why not just
streamline the interface, abstract away the no-brainer, and make
ID automatic? The instant you see a wand across the room, you know
it's a "wand of fireballs (4 charges)." No Staffs of perception, no
scrolls of ID, nothing like that required.
Would instant, automatic, effortless ID make the game a better game?
Seriously, it seems like half or more of the problems people have are
trying to fix various ID mechanics - just tossing the whole thing and
making ID automatic would put an end to all of that, in the way a nuke
puts an end to a bunny. It would be a fundamentally different game.
Would that different game be as fun, or more fun, on its own merits?
Bear
konijn_
> Would instant, automatic, effortless ID make the game a better game?
> Seriously, it seems like half or more of the problems people have are
> trying to fix various ID mechanics - just tossing the whole thing and
> making ID automatic would put an end to all of that, in the way a nuke
> puts an end to a bunny. It would be a fundamentally different game.
Meh. Not really, definitely not after I have all ego or better
equipment which is usually at clevel 30. I usually tend to try to
destroy anything I find ( talking about armor/weapons/lights/jewelry/
wands/staves ). Anything that survives is an artifact and worth
consideration. Having instant id would just relieve me from pressing
my kill macro ;)
Its probably more of a mercy killing for that bunny.
> Would that different game be as fun, or more fun, on its own merits?
Hellband has birth signs, one of them is the birthsign of Plutus ( god
of Wealth ), it gives instant pseudo id early on, id at level 15, *id*
at level 30.
Playing with a character born under Plutus for me is a different
experience and as least as fun as playing with id. It puts more focus
on combat, less on looting.
T.
>
> Bear
Paul Murray
> I am firmly with Eddie in the latter camp. I infer that Takkaria is too,
> otherwise we wouldn't have gone down the road of ID-by-use.
> that @ gets the first move.) There is obviously more work to do, but the
> direction is set and magical ID will get rarer and more expensive as
> ID-by-use gets better. (Not sure what will happen to pseudo - it's not
> entirely orthogonal but has a slightly different set of issues.)
What happened to variants? What happened to vanilla, for that matter?
What is the point of vanilla if it makes the same sorts of changes
that would previously have been made in variants, and only included
in vanilla after being widely tested and accepted.
Paul Murray
> Would instant, automatic, effortless ID make the game a better game?
> Seriously, it seems like half or more of the problems people have are
> trying to fix various ID mechanics - just tossing the whole thing and
> making ID automatic would put an end to all of that, in the way a nuke
> puts an end to a bunny. It would be a fundamentally different game.
> Would that different game be as fun, or more fun, on its own merits?
Automatic ID would be closer to Vanilla Angband that the current
suggestions of mainly or entirely ID-by-use. We'll be dropping rings
down fountains next.
Derakon
> Would instant, automatic, effortless ID make the game a better game?
> Seriously, it seems like half or more of the problems people have are
> trying to fix various ID mechanics - just tossing the whole thing and
> making ID automatic would put an end to all of that, in the way a nuke
> puts an end to a bunny. It would be a fundamentally different game.
> Would that different game be as fun, or more fun, on its own merits?
>
> Bear
I made a quick one-line patch that auto-*ID*'d every item in the game
except for special artifacts. Playing that way is very quick; you can
instantly examine all the loot being generated and decide what to keep
and what to leave on the floor. I admit I haven't experimented with ID-
by-use (my last experience with Vanilla was 2.9.something, if I recall
correctly), but on the whole I think that this play method is worth
trying, and it should certainly, with some refinements, be added as a
cheat option if nothing else. The big changes I see with this style of
play:
* No more destroying all the loot that gets dropped so you can prune
out the artifacts
* No more carrying around a bunch of possibly-junk items in the early
game because you can't tell what's worth selling (possibly fixed by ID-
by-use)
* No more relying on the stores to ID potions and scrolls for you
* No more having to hoard *ID* scrolls to find out what the high-
resists are on your gear this time around
* Gameplay flow is much smoother
The first and the last points bear elaboration and emphasis. I always
felt that having to destroy loot was immensely silly, and it has major
weaknesses when there are powerful ego-items that you'd consider using
if you only knew they were there. Boots of Speed and Heavy Crossbows
of Extra Shots leap to mind. So sure, you could just destroy
everything *except* the boots and crossbows...but then what about
getting a Shield of Elvenkind with a good high resist? Or Gloves of
Power? Et cetera. So we're left with rewarding tedium: players who are
willing to sit there and identify every item that might be useful are
more likely to find those items than players who just destroy the lot.
And tedium should never, IMO, be rewarded in a game.
As for smoother gameplay flow, without auto-ID, my games tend to
consist of "Kill a group of enemies. Examine loot. Find items that
might be interesting. ID items, resting to recharge mana / rods of
perception as needed. Find next group of enemies. Repeat." With auto-
ID, though, it's "Kill a group of enemies. Examine loot. Find next
group of enemies. Repeat." And this is looking at higher-level
characters with access to unlimited ID. With lower-level ones, I have
to rely on scrolls and staves instead, which are limited-use, which
means I have to pseudo-ID items before IDing them to tell if they're
worth wasting a charge on (otherwise, I run out of ID early and have
to return to the town -- even more flow-breaking!).
Even if I have unlimited cheap ID, though, I still have to manually
cast it on each item in the pile of loot. What's that really adding to
the gameplay? Much more straightforward to just automatically know
what the items are from the start.
So, yes, I'm a big proponent of eliminating ID. My proposed form,
which I haven't even really started working on a patch for yet, was to
have looked like this:
* All bad, average, and good equipment are automatically ID'd,
always. Un-ID'd equipment is therefore an ego-item or artifact.
* Once you ID one ego-item of a given type (e.g. Slay Animal,
Resistance), you automatically ID all other ego-items of that type.
Ditto for wands and staves (so you automatically know how many charges
a wand has once you know what it does).
* Flavored items (potions, scrolls, etc.) work as they currently do.
However, having played with the auto-*ID*-everything patch, I'm not
certain I'd be satisfied with this. You still have to have some access
to ID under this system, after all, and how much does it really add to
not know what type of ego-item you just picked up? The main change is
in the flavor items, which, past a certain depth, I wouldn't use un-
ID'd anyway, if for no other reason than that they're situational and
I wouldn't want to waste e.g. a potion of Healing.
For what it's worth, the one-line change is to add this to make_object
() in obj-make.c, right after calling apply_magic():
/* Identify the object */
object_notice_everything(j_ptr);
The Wanderer
> On Dec 7, 10:04 am, Ray <b...@sonic.net> wrote:
>
>> Would instant, automatic, effortless ID make the game a better
>> game? Seriously, it seems like half or more of the problems people
>> have are trying to fix various ID mechanics - just tossing the
>> whole thing and making ID automatic would put an end to all of
>> that, in the way a nuke puts an end to a bunny. It would be a
>> fundamentally different game. Would that different game be as fun,
>> or more fun, on its own merits?
>
> I made a quick one-line patch that auto-*ID*'d every item in the game
> except for special artifacts. Playing that way is very quick; you
> can instantly examine all the loot being generated and decide what to
> keep and what to leave on the floor.
I've been playing with this patch (in latest-SVN versions), and while
it's not quite the same game I'd gotten used to and I'm not sure I
entirely like the change, it does make things flow much more smoothly;
I've been making it deeper faster, easier and with fewer trips, without
compromising my play style or (directly) my enjoyment of the game.
I have, however, just noticed one problem with this patch as it exists
which may make it a nonstarter for me: artifact loss.
In preserve mode, which IIRC is on for all characters now, artifacts can
be re-generated if they have not yet been IDed. This means that if you
miss one on a given level, it can turn up again, and you are therefore
guaranteed to be able to find all artifacts if you invest enough time in
the effort. With this patch, however, since everything is IDed as soon
as it's generated, I think that guarantee is gone.
I'm about to start testing the attached patch (against latest SVN),
which I think should ID only non-artifact items - though I can't be
certain before testing, since the code isn't documented as clearly as
I'd like... and of course confirming "works" vs. "doesn't" will require
actually finding an artifact, which hasn't happened for me in some time
now. Combine that with the already-added change which makes ?ID provide
*ID*, for when an artifact *does* turn up, and I think it should address
the issue.
The Wanderer
> On 12/09/2009 10:52 PM, Derakon wrote:
>
>> On Dec 7, 10:04 am, Ray <b...@sonic.net> wrote:
>>
>>> Would instant, automatic, effortless ID make the game a better
>>> game? Seriously, it seems like half or more of the problems
>>> people have are trying to fix various ID mechanics - just tossing
>>> the whole thing and making ID automatic would put an end to all
>>> of that, in the way a nuke puts an end to a bunny. It would be a
>>> fundamentally different game. Would that different game be as
>>> fun, or more fun, on its own merits?
>>
>> I made a quick one-line patch that auto-*ID*'d every item in the
>> game except for special artifacts. Playing that way is very quick;
>> you can instantly examine all the loot being generated and decide
>> what to keep and what to leave on the floor.
> In preserve mode, which IIRC is on for all characters now, artifacts
> can be re-generated if they have not yet been IDed. This means that
> if you miss one on a given level, it can turn up again, and you are
> therefore guaranteed to be able to find all artifacts if you invest
> enough time in the effort. With this patch, however, since everything
> is IDed as soon as it's generated, I think that guarantee is gone.
>
> I'm about to start testing the attached patch (against latest SVN),
> which I think should ID only non-artifact items
Just found Paurhach, and the patch seems to have worked as expected.
(Admittedly I was hoping for something more useful from Wormtongue, but
for the sake of the test this is good enough.)
Derakon
Neat! I definitely support getting this added as a cheat option.
Thanks for the added refinement.
Dave_Smith354
I still play 3.0.6 (and I've got a copy of 2.7.9 hanging around). If
you're uncertain about Takkaria's changes you could always revert to
an earlier version. Otherwise "development" becomes simply "bug-
fixing". I know people have worked long and hard on these updates
after wide-ranging and long-lasting discussions on these boards.
You're entitled to your opinion of course, but if you want a version
of the game that doesn't incorporate these changes, the older versions
haven't gone anywhere.
This isn't meant to be a flame, please don't take it as such.
Paul Murray
My point is that this is not how Angband development has worked up to now.
Vanilla was just that, plain vanilla, well tested, well playtested, a
good safe option to point new users towards, where currently known major
bugs had been fixed.
It wasn't the place for brand new untested or non playtested code. That is
what variants were for. Someone wanted to try out skills, so SAngband was
born. New combat functions, OAngband, and so on.
Once an idea had been played and tested, it might be folded back into
vanilla, or might not, depending on whether it was generally accepted.
Now the code is being developed on the fly, which is great way of adapting
to user response, but as a variant, not part of the main code base.
Nick McConnell
> My point is that this is not how Angband development has worked up to now.
> Vanilla was just that, plain vanilla, well tested, well playtested, a
> good safe option to point new users towards, where currently known major
> bugs had been fixed.
Earlier on in it's development (particularly before the variant
explosion), I understand Angband did change quite rapidly.
A counter point to your opinion is that Angband had stagnated and needed
some work.
Takkaria discusses some of the issues here:
http://takkaria.org/angband-develop-or-maintain.html
You certainly have a valid opinion, and discussion is good :)
Nick.
Timo Pietilä
> On 7/01/10 11:51 PM, Paul Murray wrote:
>
>> My point is that this is not how Angband development has worked up to
>> now.
>> Vanilla was just that, plain vanilla, well tested, well playtested, a
>> good safe option to point new users towards, where currently known major
>> bugs had been fixed.
>
> Earlier on in it's development (particularly before the variant
> explosion), I understand Angband did change quite rapidly.
Not this rapidly. There was a lot of new versions, but changes were
generally quite small. Ben did some rearrangements for townsfolk and
changed monster symbols and stuff like that, but generally changes were
small. One of the biggest were removal of invulnerability for mages,
which lead to "mage spells are wimpy" -complaints.
Also Chaos resistance went thru series of changes and elvenkind shields
disappeared at some point (and aman cloaks were introduced).
Compared to what now is happening those all were small changes except
JLE changes and mage spell list rework in late Robert era.
> A counter point to your opinion is that Angband had stagnated and needed
> some work.
I would emphasize that "some" at your text. Now there are changes coming
in nearly all aspects of the game:
1) game mechanisms (shooters)
2) game mechanisms (ID by testing)
3) items (artifact rework, brand giving non-weapon equipments)
4) monsters (non-dice-based randomness of HP, maybe more)
5) game mechanisms (monster drops, floor items)
6) game mechanisms (curses)
7) game mechanisms (aggravation)
etc.
There is not much community testing going on, only tiny group of early
adopters that play potentially unstable nightly releases.
I don't say that those changes are bad, I just say that these changes
are fast, and can potentially be very bad in long run because they don't
get tested long enough, and testing in general is made by tiny group of
early adopters which basically contains mostly people that are making
those changes, and as such gives very biased feedback to maintainer.
"stagnation" is not bad when status quo is OK. There is not point making
changes just for making changes.
Timo Pietil�
Nick
> I don't say that those changes are bad, I just say that these changes
> are fast, and can potentially be very bad in long run because they don't
> get tested long enough, and testing in general is made by tiny group of
> early adopters which basically contains mostly people that are making
> those changes, and as such gives very biased feedback to maintainer.
This is a good point, and I'm inclined to agree, at least partially.
> "stagnation" is not bad when status quo is OK. There is not point making
> changes just for making changes.
...but equally making no change just for the sake of making no change
is bad.
In any case, I don't think either of these is happening; I do think
there may
be a bit too much "Here's a wacky idea - let's implement it", though.
I'm sitting on the fence, as usual...
Nick.
Ray
It looks like the game is getting simplified in some ways
and accelerated in others. The problem is that with rare
exceptions, difficulty + spoilers = tedium. When Mr. Sidwell
sets out to eliminate tedium, in the knowledge that complete
spoilers will exist, it is very hard to do it without
eliminating difficulty. Any kind of difficulty that some
application of patience will correct (for example, cursed
items and ID) becomes tedium to a spoiled player and
therefore worthwhile to eliminate.
Addressing that problem, I think, requires changing something
so fundamental in Angband that the result would be a completely
different game. Making these difficulties into actual difficulty
rather than just tedium requires eliminating the applicability
of patience as a sovereign remedy for solving them. And that
means removing the ability to generate dungeons at the same
level more than once. Yep. Persistent dungeons. No new stuff
when you come back to the same level.
See, that? That's sufficiently radical that I think it would
need a variant to explore and balance. You have players making
caches instead of losing stuff when they leave the level, but
you don't have an infinite supply of stuff to pick from. And
a lack of ?ID for example, becomes difficulty again rather
than just tedium to be removed.
Also, I think the perception that 99% of stuff is "junk" comes
mainly from players accustomed to picking only one item out of
every 100 they see in an infinite supply of stuff. When the
supply is no longer infinite, you have to use what you find
so, magically, it ceases to be junk.
Finally, I think V needs to adopt some kind of methodology that
allows patches (of at least some types of things) collected
from many sources to succeed in any combination. There needs
to be a set of interfaces that people can write code to, such
that they can make a minimal and trivial (scriptable) change
to the V codebase (such as adding one line to the make file
at a spot where such lines can come in any order) that causes
unchanged parts of V elsewhere to make the appropriate calls
to the added code when they need to do so. And that "minimal
change" should never cause any other code written to the same
interface to be unable to make *its* minimal change.
That's a hard(ish) problem, but do-able. It's a lot like what
Ben Harrison did for monster definitions, but applied to code
rather than data.
That would lead to another variant explosion, I think.
Bear
Magnate
news:4b46bf05$0$1615$742e...@news.sonic.net...
>
> Finally, I think V needs to adopt some kind of methodology that
> allows patches (of at least some types of things) collected
> from many sources to succeed in any combination. There needs
> to be a set of interfaces that people can write code to, such
> that they can make a minimal and trivial (scriptable) change
> to the V codebase (such as adding one line to the make file
> at a spot where such lines can come in any order) that causes
> unchanged parts of V elsewhere to make the appropriate calls
> to the added code when they need to do so. And that "minimal
> change" should never cause any other code written to the same
> interface to be unable to make *its* minimal change.
>
> That's a hard(ish) problem, but do-able. It's a lot like what
> Ben Harrison did for monster definitions, but applied to code
> rather than data.
>
> That would lead to another variant explosion, I think.
I think this is what Takk has in mind with a planned move to hg (a DVCS).
So my question for Timo / Nick / Paul is this: if the current changes are
being made and tested by too small a group of people, and therefore a group
unable to give unbiased feedback to Takkaria - what is the solution? Do we:
1. Get more people involved in testing changes? IMO there is quite a big
crowd on Oook testing nightly builds, so not sure how you could go about
this.
2. Introduce some sort of cooling-off period between discussing a change and
implementing it? By and large most changes are implemented after discussion
on Oook reaches some sort of consensus, but it wouldn't hurt to formalise
this.
3. Introduce some sort of automatic revert mechanism so that changes have to
be explicitly confirmed by Takkaria and/or some sort of community poll?
As you can probably tell from the above, I'm struggling to understand the
problem we're trying to solve. The whole point about nightly / dev versions
is that they're testing grounds for new ideas. So to complain about the
implementation of new ideas in them is kind of silly, especially given the
practice of discussing changes on Oook first and seeking support. Perhaps
the real issue is that not enough of these wacky new ideas are reverted by
Takkaria as insufficiently tested - is that the problem? It's not as if dev
versions are becoming official releases at a rate too fast to comprehend -
this happens about twice a year, so that should be plenty of time for new
changes to be tested. (We do have a sort of unwritten policy of not
introducing any significant changes as we near a release date.)
CC
Paul Murray
> So my question for Timo / Nick / Paul is this: if the current changes are
> being made and tested by too small a group of people, and therefore a group
> unable to give unbiased feedback to Takkaria - what is the solution? Do we:
>
> 1. Get more people involved in testing changes? IMO there is quite a big
> crowd on Oook testing nightly builds, so not sure how you could go about
> this.
>
> 2. Introduce some sort of cooling-off period between discussing a change and
> implementing it? By and large most changes are implemented after discussion
> on Oook reaches some sort of consensus, but it wouldn't hurt to formalise
> this.
I part of the problem is the jilted lover that is r.g.r.angband.
Lots may be happening on Oook, I don't know.
Things *used* to happen on r.g.r.angband.
The ergonomics of web site forums are just so horrible compared to a good
usenet reader (not Google Groups), that I have no interest in going there.
> 3. Introduce some sort of automatic revert mechanism so that changes have to
> be explicitly confirmed by Takkaria and/or some sort of community poll?
>
> As you can probably tell from the above, I'm struggling to understand the
> problem we're trying to solve. The whole point about nightly / dev versions
> is that they're testing grounds for new ideas. So to complain about the
> implementation of new ideas in them is kind of silly, especially given the
A question: What is the current stable supported build that has no major
know and unfixed bugs?
> practice of discussing changes on Oook first and seeking support. Perhaps
> the real issue is that not enough of these wacky new ideas are reverted by
> Takkaria as insufficiently tested - is that the problem? It's not as if dev
> versions are becoming official releases at a rate too fast to comprehend -
The difference is that previous something would be tested in a variant and
only incorporated into vanilla if there was widespread acceptance. Now things
are added directly and then considered for removal if they seem obviously
broken. Defensive vs aggressive change management, I guess.
I have no objection to any of the development being done, I just don't think
it should be called vanilla, because it isn't.
Andi Sidwell
> On 2010-01-18, Magnate<n...@receiving.here> wrote:
>> So my question for Timo / Nick / Paul is this: if the current changes are
>> being made and tested by too small a group of people, and therefore a group
>> unable to give unbiased feedback to Takkaria - what is the solution? Do we:
>>
>> 1. Get more people involved in testing changes? IMO there is quite a big
>> crowd on Oook testing nightly builds, so not sure how you could go about
>> this.
>>
>> 2. Introduce some sort of cooling-off period between discussing a change and
>> implementing it? By and large most changes are implemented after discussion
>> on Oook reaches some sort of consensus, but it wouldn't hurt to formalise
>> this.
>
> I part of the problem is the jilted lover that is r.g.r.angband.
> Lots may be happening on Oook, I don't know.
> Things *used* to happen on r.g.r.angband.
> The ergonomics of web site forums are just so horrible compared to a good
> usenet reader (not Google Groups), that I have no interest in going there.
That's not going to change, sadly. The dynamics of people on the web
have changed a lot since r.g.r.a had its peak in traffic and the
community is now mostly based on web forums.
>> 3. Introduce some sort of automatic revert mechanism so that changes have to
>> be explicitly confirmed by Takkaria and/or some sort of community poll?
>>
>> As you can probably tell from the above, I'm struggling to understand the
>> problem we're trying to solve. The whole point about nightly / dev versions
>> is that they're testing grounds for new ideas. So to complain about the
>> implementation of new ideas in them is kind of silly, especially given the
>
> A question: What is the current stable supported build that has no major
> know and unfixed bugs?
There isn't one and that's never been the model Angband used anyway.
3.1.1.1626 is pretty decent though not perfect, and 3.0.9b is reasonable
too.
>> practice of discussing changes on Oook first and seeking support. Perhaps
>> the real issue is that not enough of these wacky new ideas are reverted by
>> Takkaria as insufficiently tested - is that the problem? It's not as if dev
>> versions are becoming official releases at a rate too fast to comprehend -
>
> The difference is that previous something would be tested in a variant and
> only incorporated into vanilla if there was widespread acceptance. Now things
> are added directly and then considered for removal if they seem obviously
> broken. Defensive vs aggressive change management, I guess.
>
> I have no objection to any of the development being done, I just don't think
> it should be called vanilla, because it isn't.
Feel free to not call it Angband if you like, but most people call it
Angband and I'm not changing the name. And I take your point about
changes always having been tested in variants beforehand, except that
they haven't. Nor am I (though I can't speak for others) interested in
being involved in the development of a game where that is the case.
Andi
Matthew Vernon
> > A question: What is the current stable supported build that has no major
> > know and unfixed bugs?
>
> There isn't one and that's never been the model Angband used
> anyway. 3.1.1.1626 is pretty decent though not perfect, and 3.0.9b is
> reasonable too.
I have some sympathy for the question. Given changing versions can
muck up save-files, having a stable released version would be nice
(not least so we can make sure it gets into the next release of Debian
;-)
Cheers,
Christophe Cavalaria
> The difference is that previous something would be tested in a variant and
> only incorporated into vanilla if there was widespread acceptance. Now things
> are added directly and then considered for removal if they seem obviously
> broken. Defensive vs aggressive change management, I guess.
That's some interesting nothing, but as far as I remember Vanilla
development and changes, when was the last time any feature has been
tested in a variant to be incorporated in Vanilla later? Did it ever
happen really?
Timo Pietilä
What is basically happening now is testing unbalanced version and
comparing it to another unbalanced version. (nightly vs beta).
> 2. Introduce some sort of cooling-off period between discussing a change
> and implementing it?
That would be nice. There is very little balancing being done and not
enough information what is being done.
> By and large most changes are implemented after
> discussion on Oook reaches some sort of consensus, but it wouldn't hurt
> to formalise this.
>
> 3. Introduce some sort of automatic revert mechanism so that changes
> have to be explicitly confirmed by Takkaria and/or some sort of
> community poll?
>
> As you can probably tell from the above, I'm struggling to understand
> the problem we're trying to solve. The whole point about nightly / dev
> versions is that they're testing grounds for new ideas. So to complain
> about the implementation of new ideas in them is kind of silly,
> especially given the practice of discussing changes on Oook first
There's the first problem I find. I for example has not seen any
discussions about small levels or not much about item generation. I
don't read oook very often.
In addition to this there isn't any clear roadmap or planned
features-page anywhere. If there is I don't know where it is.
> and
> seeking support. Perhaps the real issue is that not enough of these
> wacky new ideas are reverted by Takkaria as insufficiently tested - is
> that the problem? It's not as if dev versions are becoming official
> releases at a rate too fast to comprehend - this happens about twice a
> year, so that should be plenty of time for new changes to be tested. (We
> do have a sort of unwritten policy of not introducing any significant
> changes as we near a release date.)
I think you have done quite a few "significant" changes between 3.0.9
and 3.1.2 dev.
Timo Pietil�
Paul Murray
From some very quick checking:
3.0.4:
Rods, wands, and staves with different charges can now be stacked. (based on
the NPPAngband version that in turn is based on Leon Marrick's rod/wand
stacking in OAngband.
Added artifact descriptions. The texts are mainly taken from OAngband and
other variants. (Jonathan Ellis)
Added a better character selection screen with support for using the cursor
keys, display of info about the various race and class choices, and context
sensitive help. The code is based on the EyAngband's birth screen that again
is probably based on ZAngband's birth screen.
Allow text to be copied from the game window in the X11 port. (modified
version of the code in Kieron Dunbar's sCthangband 1.0.10)
I suspect there are lots of others that aren't credited in this way. For
example a change listed as contributed by Diego Gonzalez and Jeff Greene
is almost certainly from NPP.
Magnate
> On 2010-01-18, Magnate <n...@receiving.here> wrote:
>> So my question for Timo / Nick / Paul is this: if the current changes are
>> being made and tested by too small a group of people, and therefore a
>> group
>> unable to give unbiased feedback to Takkaria - what is the solution? Do
>> we:
>>
>> 1. Get more people involved in testing changes? IMO there is quite a big
>> crowd on Oook testing nightly builds, so not sure how you could go about
>> this.
>>
>> 2. Introduce some sort of cooling-off period between discussing a change
>> and
>> implementing it? By and large most changes are implemented after
>> discussion
>> on Oook reaches some sort of consensus, but it wouldn't hurt to formalise
>> this.
>
> I part of the problem is the jilted lover that is r.g.r.angband.
> Lots may be happening on Oook, I don't know.
> Things *used* to happen on r.g.r.angband.
> The ergonomics of web site forums are just so horrible compared to a good
> usenet reader (not Google Groups), that I have no interest in going there.
I used to think the same as you. I still think that a good newsgroup UI
beats a web forum hands down - but we have to work with the world as it is,
not as we would like it to be. Most active players are on Oook, not on rgra.
That's just how it is and we have to deal with that. After holding out for
about two years, I started to use Oook regularly. A lot of rgra regulars
have migrated to Ooook - even Timo now posts there.
>> 3. Introduce some sort of automatic revert mechanism so that changes have
>> to
>> be explicitly confirmed by Takkaria and/or some sort of community poll?
>>
>> As you can probably tell from the above, I'm struggling to understand the
>> problem we're trying to solve. The whole point about nightly / dev
>> versions
>> is that they're testing grounds for new ideas. So to complain about the
>> implementation of new ideas in them is kind of silly, especially given
>> the
>
> A question: What is the current stable supported build that has no major
> know and unfixed bugs?
All versions have bugs. 3.1.0 has a game-breaking heavy curse bug.
3.1.1.1626 has no showstoppers as far as I can recall, so I guess that's the
current supported version (but it is still part of the 3.1 beta series, so
not officially "stable"). We are very close to the release of 3.1.2, which
will be another fairly stable supported beta, hopefully with no major bugs.
>> practice of discussing changes on Oook first and seeking support. Perhaps
>> the real issue is that not enough of these wacky new ideas are reverted
>> by
>> Takkaria as insufficiently tested - is that the problem? It's not as if
>> dev
>> versions are becoming official releases at a rate too fast to
>> comprehend -
>
> The difference is that previous something would be tested in a variant and
> only incorporated into vanilla if there was widespread acceptance. Now
> things
> are added directly and then considered for removal if they seem obviously
> broken. Defensive vs aggressive change management, I guess.
Nick covered this: it's Takkaria's response to the stagnation of development
under previous maintainers. It's also related to the fact that there are
fewer active variants and they have their own agendas, they are not vassals
of V development ready and willing to test anything that V wants tested. So
the old method is no longer available.
> I have no objection to any of the development being done, I just don't
> think
> it should be called vanilla, because it isn't.
It is. It just doesn't fit your perception of how V should develop. That's
fine - as Nick said, your opinion is valid, but it happens not to match
Takkaria's, that's all. Unless he changes the name, it's still Vanilla.
CC
Timo Pietilä
Which I blame Pav. Creation of web forum pretty much killed the
newsgroup. I hope his server never dies, because if it does there goes
angband. Maybe there are more newbies, but problem for development is
just newbies. They don't see the big picture, they don't know the
history behind some things and they want everything now, now, faster, now.
There are also at least two *VERY* loud divers promoting diving in every
turn. As a persons they are very reasonable, but I think they do not see
another ways to play this game very well, and I think they have too big
impact of the game nature as it is.
>>> 3. Introduce some sort of automatic revert mechanism so that changes
>>> have to
>>> be explicitly confirmed by Takkaria and/or some sort of community poll?
>>>
>>> As you can probably tell from the above, I'm struggling to understand
>>> the
>>> problem we're trying to solve. The whole point about nightly / dev
>>> versions
>>> is that they're testing grounds for new ideas. So to complain about the
>>> implementation of new ideas in them is kind of silly, especially
>>> given the
>>
>> A question: What is the current stable supported build that has no major
>> know and unfixed bugs?
>
> There isn't one and that's never been the model Angband used anyway.
> 3.1.1.1626 is pretty decent though not perfect, and 3.0.9b is reasonable
> too.
3.0.9b is the one. Another is buggy dev-version that had gone thru
multitude of small and not so small changes that have not been tested
very well.
Timo Pietil�
Christophe Cavalaria
True, that's some features that were imported but that track record is
hardly impressive. Of the four features you mentioned, one is a minor
gameplay feature and 3 are largely meaningless cosmetic features that
have abslutly no effect on gameplay and are in no way justified to test
in a variant first anyway.
Paul Murray
> Paul Murray wrote:
>> On 2010-01-18, Christophe Cavalaria <chris.c...@free.fr> wrote:
>>> Paul Murray wrote:
>>>> The difference is that previous something would be tested in a variant and
>>>> only incorporated into vanilla if there was widespread acceptance. Now things
>>>> are added directly and then considered for removal if they seem obviously
>>>> broken. Defensive vs aggressive change management, I guess.
>>> That's some interesting nothing, but as far as I remember Vanilla
>>> development and changes, when was the last time any feature has been
>>> tested in a variant to be incorporated in Vanilla later? Did it ever
>>> happen really?
> hardly impressive. Of the four features you mentioned, one is a minor
> gameplay feature and 3 are largely meaningless cosmetic features that
> have abslutly no effect on gameplay and are in no way justified to test
> in a variant first anyway.
It was just the first changelog I came across.
If you want some more major changes, the first three items in the 3.0 changelog:
Added Jonathan Ellis' JLE patch that adds a new player race ("Kobold"), many new
artifacts, vaults, monsters, objects, and ego-items; rebalances the gameplay; and
adds a new color scheme for monsters.
Added some new object flags ("kill demon", "kill undead"), activations, monster
attacks ("cause halluzination") and monster spells/abilities (summon animal, throw
boulder) for the JLE patch.
Replaced the Mage, Rogue, and Ranger spell-lists with the spell-list from Greg
Wooledge's GWAngband. This gives magic-users a much broader range of attack-spells
to choose from including chaos, nether, sound, shards, and gravity effects. Other
big changes are the removal of the 'Globe of Invulnerability' and the addition of
'Rune of Protection'. The new spellbooks are more "themed" with 9 books specialized
on 'detection', 'teleportation', 'protection', ... plus a beginner book containing
a mix of spells similar to the good old "Magic for Beginners". The depths where the
spellbooks are common and the prices for spellbooks were changed accordingly.
Wally the Grey
> I think this is what Takk has in mind with a planned move to hg (a DVCS).
By which you mean switching to Mercurial as your version control system?
If so, then I was able to parse it but I'd argue you stated it in a
manner that was needlessly obscure; and if I'm way out in left field,
then whatever you *did* say, you *definitely* were obscure.
Nick
> So my question for Timo / Nick / Paul is this: if the current changes are
> being made and tested by too small a group of people, and therefore a group
> unable to give unbiased feedback to Takkaria - what is the solution?
Well, I'm going to use this as an excuse to philosophise a bit (with
subheadings), and I hope that partially I answer the question.
1. Forum vs Newsgroup
No matter what the rights and wrongs of this, we now have two places
where
things get discussed. The forums have brought in a lot of new people
to the
Angband discussion. Some of these have never used newsgroups; some
are
actually long time players who were never aware of the newsgroup.
IMHO
expanding the community is a clear win, even if it has meant splitting
the
location.
And if Pav or his server gets hit by a bus, I'm sure the community
will
work out a way to get by.
2. What is Angband?
This depends on who you ask. Takkaria has done a brilliant job of
getting
the community involved in development. I have no problem with the
direction he is taking the game, or the speed it is moving; and I
like
ID by use so much I'm doing my own take on it for FAangband.
That said, I think we need to be careful that the game is not getting
too
narrow. In particular, there is a danger (and the competition rather
fosters this) that it is optimised to favour the "quick game, low
turncount" approach over roleplayers, completists, dilettantes, etc.
I should emphasise that I have seen little evidence of this
happening.
But not none. And discussions like this need to be had to prevent a
sort
of groupthink developing.
I guess it's easy for people developing to think "we're working hard
on
improving the game, why do people keep sniping at us?", and for
people
not developing to think "the developers are just doing what they want
and not listening". I see this whole process as creative tension, and
a
Good Thing. A lot of people care about the game.
Nick.
The Wanderer
> Andi Sidwell <an...@takkaria.org> writes:
>
>>> A question: What is the current stable supported build that has
>>> no major know and unfixed bugs?
>>
>> There isn't one and that's never been the model Angband used
>> anyway. 3.1.1.1626 is pretty decent though not perfect, and 3.0.9b
>> is reasonable too.
>
> I have some sympathy for the question. Given changing versions can
> muck up save-files, having a stable released version would be nice
> (not least so we can make sure it gets into the next release of
> Debian ;-)
Off-thread-topic tangent from which:
I just installed Angband via the Debian package on my new laptop, and it
fails to start in -mx11 mode (the default) because it can't find the
10x20 font, although all of the font files seem to be in place in
/var/games/angband/xtra/font/. The game runs fine with -msdl or -mgcu,
but I'm not really comfortable with the interface differences in those.
My first guess is that the game searches for its font files in
particular locations relative to $PWD (that is, where the user was when
they launched the program), since I know it seems to do that for e.g.
the edit files at least in my non-global installs, but if that were the
case I don't see how the Debian install could work at all - and it
doesn't seem to have been touched since August, so presumably it does
work for most people.
None of the reports I've found online of similar problems seem related
as far as I can tell, and I haven't so far noticed any existing Debian
bug reports (and for some reason it didn't occur to me to file one until
just now). Any ideas what might cause this sort of thing?
The Wanderer
> "The Wanderer" <wand...@fastmail.fm> wrote in message
>>>> Another is that there doesn't seem, at least in 3.1.1, to be a
>>>> way of defining a set of "default" squelch settings that don't
>>>> have to be manually recreated with each new character...)
>
> This one is on my to-do list, under the heading "improved pref file
> management and sensible default preferences".
Any progress on this, or has it gotten neglected in favor of other
priorities?
Nick McConnell
> I just installed Angband via the Debian package on my new laptop, and it
> fails to start in -mx11 mode (the default) because it can't find the
> 10x20 font, although all of the font files seem to be in place in
> /var/games/angband/xtra/font/. The game runs fine with -msdl or -mgcu,
> but I'm not really comfortable with the interface differences in those.
I don't have a solution, I'm afraid, but I would suggest giving the
imsdl option a try out. IMHO it is better than -mx11 in every way
(unless you need to have the game broken into separate windows).
Nick.
pete m
> On 22/01/10 3:52 AM, The Wanderer wrote:
>
> > I just installed Angband via the Debian package on my new laptop, and it
> > fails to start in -mx11 mode (the default) because it can't find the
> > 10x20 font, although all of the font files seem to be in place in
> > /var/games/angband/xtra/font/. The game runs fine with -msdl or -mgcu,
x11 fonts belong in the X11 fonts directory, not in angband fonts.
You should be able to query what fonts are available, although it's
been a while since I used X.
The Wanderer
> On 01/18/2010 09:41 AM, Matthew Vernon wrote:
>> I have some sympathy for the question. Given changing versions can
>> muck up save-files, having a stable released version would be nice
>> (not least so we can make sure it gets into the next release of
>> Debian ;-)
>
> Off-thread-topic tangent from which:
>
> I just installed Angband via the Debian package on my new laptop, and
> it fails to start in -mx11 mode (the default) because it can't find
> the 10x20 font, although all of the font files seem to be in place in
> /var/games/angband/xtra/font/. The game runs fine with -msdl or
> -mgcu, but I'm not really comfortable with the interface differences
> in those.
Found a fix and apparent answer.
To start out with, despite installing all those fonts, Angband
apparently doesn't actually use them by default in -mx11 mode; it simply
uses whatever fonts X will provide to it. In theory one could probably
configure X to use that directory as part of the font path, but it
certainly doesn't pick them up automatically.
On Debian, the fonts Angband needs are provided as part of the
xfonts-base package, which for whatever reason doesn't seem to get
installed as a dependency by either X or Angband (or anything else I
happened to already have). Install it and restart X, and the problem is
gone.
I'm going to file a bug report with Debian about that, but I also wanted
to mention the fix here so it's potentially findable for the next person
to have the same problem.
Magnate
> On 01/21/2010 11:52 AM, The Wanderer wrote:
>> On 01/18/2010 09:41 AM, Matthew Vernon wrote:
>
>>> I have some sympathy for the question. Given changing versions can
>>> muck up save-files, having a stable released version would be nice
>>> (not least so we can make sure it gets into the next release of
>>> Debian ;-)
@Matthew:
Er, 3.1.1.1626 is already in Debian. I am hopeful that 3.1.2 will make it
into squeeze before squeeze freezes, as it were - but 3.1.2 is no more
"stable" than 1626 - just different. Do you find that 3.1.1.1626 crashes
much?
>> Off-thread-topic tangent from which:
>>
>> I just installed Angband via the Debian package on my new laptop, and
>> it fails to start in -mx11 mode (the default) because it can't find
>> the 10x20 font, although all of the font files seem to be in place in
>> /var/games/angband/xtra/font/. The game runs fine with -msdl or
>> -mgcu, but I'm not really comfortable with the interface differences
>> in those.
>
> Found a fix and apparent answer.
>
> To start out with, despite installing all those fonts, Angband
> apparently doesn't actually use them by default in -mx11 mode; it simply
> uses whatever fonts X will provide to it. In theory one could probably
> configure X to use that directory as part of the font path, but it
> certainly doesn't pick them up automatically.
>
> On Debian, the fonts Angband needs are provided as part of the
> xfonts-base package, which for whatever reason doesn't seem to get
> installed as a dependency by either X or Angband (or anything else I
> happened to already have). Install it and restart X, and the problem is
> gone.
>
> I'm going to file a bug report with Debian about that, but I also wanted
> to mention the fix here so it's potentially findable for the next person
> to have the same problem.
@Wanderer:
Thanks muchly for spotting this and for the solution. I'll make sure that
angband depends on xfonts-base in the next release.
Regards,
CC
Magnate
Not really. Almost all the developers and testers have experience of earlier
versions. Only a small number of new players have not played any version
prior to 3.1.0beta.
>> 2. Introduce some sort of cooling-off period between discussing a change
>> and implementing it?
>
> That would be nice. There is very little balancing being done and not
> enough information what is being done.
Ok. Outline for me a process which takes us from the end of a discussion
here or on Oook - from the point at which one of the devs would then
implement his/her vision for that particular change - to the delayed
implementation. What needs to happen in the new gap between those two
things? Currently devs just do stuff (after checking with Takkaria) and see
what happens. If you want us to pause before doing stuff, what needs to
happen before it can be done? More discussion? Voting? Forking the code?
>> By and large most changes are implemented after discussion on Oook
>> reaches some sort of consensus, but it wouldn't hurt to formalise this.
>>
>> 3. Introduce some sort of automatic revert mechanism so that changes have
>> to be explicitly confirmed by Takkaria and/or some sort of community
>> poll?
>>
>> As you can probably tell from the above, I'm struggling to understand the
>> problem we're trying to solve. The whole point about nightly / dev
>> versions is that they're testing grounds for new ideas. So to complain
>> about the implementation of new ideas in them is kind of silly,
>> especially given the practice of discussing changes on Oook first
>
> There's the first problem I find. I for example has not seen any
> discussions about small levels or not much about item generation. I don't
> read oook very often.
Well small levels were implemented and then switched off after a host of
problems were discovered in testing - a perfect example of how this
development model works. The code to generate small levels is there but we
need more ideas to solve the problems before it gets switched back on.
(It was discussed extensively ok Oook, albeit perhaps not here.)
> In addition to this there isn't any clear roadmap or planned features-page
> anywhere. If there is I don't know where it is.
There's a Roadmap page on trac.rephial.org, though I'm not sure how
up-to-date it is. Not sure if there is also one at the main rephial.org
site - there is certainly a development page which points to the trac site.
>> and seeking support. Perhaps the real issue is that not enough of these
>> wacky new ideas are reverted by Takkaria as insufficiently tested - is
>> that the problem? It's not as if dev versions are becoming official
>> releases at a rate too fast to comprehend - this happens about twice a
>> year, so that should be plenty of time for new changes to be tested. (We
>> do have a sort of unwritten policy of not introducing any significant
>> changes as we near a release date.)
>
> I think you have done quite a few "significant" changes between 3.0.9 and
> 3.1.2 dev.
Indeed - and that's, what, two years? That doesn't strike me as too fast a
pace of change.
CC
Magnate
You are somewhat hoist by your own petard here: none of the JLE patch
changes were ever tested in any variant. They went straight into V.
Magnate
> On 12/07/2009 09:17 AM, Magnate wrote:
>> "The Wanderer" <wand...@fastmail.fm> wrote in message
>
>>>>> Another is that there doesn't seem, at least in 3.1.1, to be a
>>>>> way of defining a set of "default" squelch settings that don't
>>>>> have to be manually recreated with each new character...)
>>
>> This one is on my to-do list, under the heading "improved pref file
>> management and sensible default preferences".
>
> Any progress on this, or has it gotten neglected in favor of other
> priorities?
Only the release of 3.1.2 - as soon as that's out (any day now), it's one of
my top way-too-radical changes for 3.1.3
CC
Paul Murray
I may be misremembering, but ISTR that the JLE patch was independently
distributed and used for quite some time before it was introduced to
Vanilla.
The dates on an Angband archive suggest that the JLE patch was distributed
from late 2000/early-mid 2001, and Angband 3.0, which incorporated it,
was not released until mid-2002. Google Groups shows that there were many
posts made with similar to [V+JLE] in the title, suggesting that people
were playing with the patch applied. It is reasonable to think that ~10
years ago a greater proportion of those playing angband would be compiling
their own versions. Subject to those dates being correct, it suggests that
the JLE changes were available for a long time, and used by quite a few
people, before being incorporated into Vanilla, even if there was no
separately named variant for them.
It was also discussed and criticised during this period, by those using
the patch, as eg.
http://groups.google.com/group/rec.games.roguelike.angband/browse_thread/thread/3bf6869760c8e1e/a578801d3c8d1619?q=jle+group:rec.games.roguelike.angband#a578801d3c8d1619
In particular, from Robert Ruehlmann, the maintainer at the time:
"I think Jonathan Ellis did a great job on the JLE patch. The main reason
that it isn't included in Angband yet is that I check every single change
and decide if I like it or not. That takes a while ...
I'm about 1/3 done with the monster changes and so far I followed the JLE
patch in most cases. The main differences at the moment are in the monster
descriptions. I simply don't like some of the new ones. I've also tried
not to include any new references to possible Tolkien-trademarks in the
descriptions, just to be on the safe side.
Some, but not all, of the changes to objects and additions to ego-items have
been applied (like poison branded weapons/ammo). The additions to artifacts
and objects are not in yet, since I still have to decide if I'll support
compatibility with randart savefiles."
and later
"I mentioned that I didn't plan any big gameplay changes because I'm
"not a very good Angband player" (let's just say I suck) and that I
"will have to rely on the comments of Angband veterans" for such changes.
Fortunately there are many of these here in r.g.r.a, so over time the
game balance will be optimized (like it's happening with the JLE patch)."
So I think it is fair to say that the patch was widely available and tested,
and that discussion and debate took place, before it was incorporated into
Vanilla.
I like to make the point that as I think with most non-face-to-face
discussions, it probably appears a lot 'fiercer', for want of a better word,
than it actually is. What I am saying is that I don't personally like the
new style of development, that is definately not the same as saying that
the new style is wrong. It may well be that the userbase has changed so that
the best way to get feedback is indeed to add things and see if they work,
rather than expect that there is a group of users who will take early patches,
compile them themselves and provide feedback.
To quote from the same thread again:
"What will make it into official Vanilla is, fortunately, something which
isn't decided by any democratic process, but just by the MAINTAINER
HIMSELF"
You (as a group, not you personally) have taken over the development, and
are free to take it in whichever direction you feel is best. If I didn't
like it enough I could get off my behind and do some coding myself. That
doesn't meant I can't express my views though. (And to prevent any
misunderstanding, nor do I think you are saying that I can't.)
Timo Pietilä
> "Timo Pietil�" <timo.p...@helsinki.fi> wrote
>> In addition to this there isn't any clear roadmap or planned
>> features-page anywhere. If there is I don't know where it is.
>
> There's a Roadmap page on trac.rephial.org, though I'm not sure how
> up-to-date it is. Not sure if there is also one at the main rephial.org
> site - there is certainly a development page which points to the trac site.
Thanks. That is helpful.
>> I think you have done quite a few "significant" changes between 3.0.9
>> and 3.1.2 dev.
>
> Indeed - and that's, what, two years? That doesn't strike me as too fast
> a pace of change.
In my point of view it is. At least when you are changing practically
everything in the game during that time.
Timo Pietil�
Wally the Grey
> I may be misremembering, but ISTR that the JLE patch was independently
> distributed and used for quite some time before it was introduced to
> Vanilla.
It was.
> Google Groups shows that there were many posts made with similar to [V+JLE]
> in the title, suggesting that people were playing with the patch applied.
> It is reasonable to think that ~10 years ago a greater proportion of those
> playing angband would be compiling their own versions.
As I recall, the JLE patch took the form of a drop-in replacement for
the edit files; no compiling necessary. So the number of people using it
would have been even larger than you're probably supposing.
Angband 3.0 added some coding changes, but the JLE patch actually
exploited some older code changes that had created the possibility of
custom player races in the edit files (such as kobolds) and poison
branded items, and also (I think) changes to confusion and chaos
resistance (chaos resistance no longer automatically granting protection
from the confusion status, as I recall), but Angband 2.9.x's edit files
didn't actually use these to make any changes from earlier versions (and
had even explicitly added confusion resistance to items that had only
chaos resistance of the two before). JLE's replacement edit files
provided some items with the new capabilities.
To be sure, read more of the old archived threads from that time period.
The announcement post for the patch itself should contain more details.
The Wanderer
As mentioned in the Debian bug report, because Angband *is* usable
without that package (if you use -msdl, use -mgcu, or modify your X
config so that Angband's font directory is in the font path), I think it
would make more sense to Recommend xfonts-base than to Depend on it. (By
default, Recommended packages are installed automatically, but that
setting can be changed and people can explicitly override it if they
want to.)
Ray
> On 01/25/2010 10:28 AM, Magnate wrote:
>
>> "The Wanderer" <wand...@fastmail.fm> wrote
>>> On Debian, the fonts Angband needs are provided as part of the
>>> xfonts-base package, which for whatever reason doesn't seem to get
>>> installed as a dependency by either X or Angband (or anything else
>>> I happened to already have). Install it and restart X, and the
>>> problem is gone.
>>>
>>> I'm going to file a bug report with Debian about that, but I also
>>> wanted to mention the fix here so it's potentially findable for the
>>> next person to have the same problem.
>>
>> @Wanderer: Thanks muchly for spotting this and for the solution. I'll
>> make sure that angband depends on xfonts-base in the next release.
>
> As mentioned in the Debian bug report, because Angband *is* usable
> without that package (if you use -msdl, use -mgcu, or modify your X
> config so that Angband's font directory is in the font path), I think it
> would make more sense to Recommend xfonts-base than to Depend on it. (By
> default, Recommended packages are installed automatically, but that
> setting can be changed and people can explicitly override it if they
> want to.)
>
FWIW, if it's b0rked when starting up in its "default" mode
in the absence of the font package, I would call it a "dependency."
To get to the point of "recommends" instead of "depends", I think
it should, by default, start up without attempting to use the font
package.
In the best case, of course, it would first detect the font it wants
to use, and use it (unless given command line arguments to the contrary)
if and only if it's installed. But that's a lot of code that depends
on a particular system. You could do it with an additional makefile
target I suppose.
Bear
The Wanderer
> The Wanderer wrote:
>
>> On 01/25/2010 10:28 AM, Magnate wrote:
>>> @Wanderer: Thanks muchly for spotting this and for the solution.
>>> I'll make sure that angband depends on xfonts-base in the next
>>> release.
>>
>> As mentioned in the Debian bug report, because Angband *is* usable
>> without that package (if you use -msdl, use -mgcu, or modify your X
>> config so that Angband's font directory is in the font path), I
>> think it would make more sense to Recommend xfonts-base than to
>> Depend on it. (By default, Recommended packages are installed
>> automatically, but that setting can be changed and people can
>> explicitly override it if they want to.)
>
> FWIW, if it's b0rked when starting up in its "default" mode in the
> absence of the font package, I would call it a "dependency."
When speaking in general so would I, but the Debian package relationship
terminology is a bit more precise than that, and isn't necessarily quite
equivalent to the general-usage meanings.
In addition, I suspect that -mx11 is the default *only* when starting
from an already running X environment; if launched from a console or
over a SSH connection or the like, I suspect that the default would be
-mgcu.
> To get to the point of "recommends" instead of "depends", I think it
> should, by default, start up without attempting to use the font
> package.
With a "Recommends", unless the system administrator has changed
settings (or the system is a holdover from about four releases back,
which is most of a decade if not more), the package will be installed
exactly as with a "Depends", and the default mode will work just as well
either way - except that the user can manually override a "Recommends",
which they can't do with a "Depends". Thus, using Recommends would mean
that someone who *does* only want to use something other than -mx11 can
avoid needing to have xfonts-base package installed.
Since the packagers don't know what context you're intending to use the
program in, they shouldn't be forcing you to have something which is a
dependency only for optional functionality. -mx11 may be the default in
the most common case, but it is very definitely optional, and so its
dependencies should not be forced for the program as a whole unless
there is no other way to achieve the desired goal. Since there is - the
use of a Recommends line - I see no reason to do so.
Magnate
> On 01/26/2010 02:12 PM, Ray wrote:
>> The Wanderer wrote:
>>> On 01/25/2010 10:28 AM, Magnate wrote:
>
>>>> @Wanderer: Thanks muchly for spotting this and for the solution.
>>>> I'll make sure that angband depends on xfonts-base in the next
>>>> release.
>>>
>>> As mentioned in the Debian bug report, because Angband *is* usable
>>> without that package (if you use -msdl, use -mgcu, or modify your X
>>> config so that Angband's font directory is in the font path), I
>>> think it would make more sense to Recommend xfonts-base than to
>>> Depend on it. (By default, Recommended packages are installed
>>> automatically, but that setting can be changed and people can
>>> explicitly override it if they want to.)
>>
>> FWIW, if it's b0rked when starting up in its "default" mode in the
>> absence of the font package, I would call it a "dependency."
>
> When speaking in general so would I, but the Debian package relationship
> terminology is a bit more precise than that, and isn't necessarily quite
> equivalent to the general-usage meanings.
In fact, Debian policy prevents *anything* depending on xfonts-base, so the
only option is Recommends.
> In addition, I suspect that -mx11 is the default *only* when starting
> from an already running X environment; if launched from a console or
> over a SSH connection or the like, I suspect that the default would be
> -mgcu.
Sadly it's not quite that intelligent. AFAICT the way angband works is this:
- if Gtk is compiled in, it will default to -mgtk (even in a terminal, where
it will say "unable to open any display module")
- if Gtk support is not present, it will default to -mx11 (I'm not certain
if it will sensibly defaul to -mgcu in a terminal - haven't tested recently)
Since the 3.1.2 Debian package includes gtk support, that will be the
default if people just type "angband". That's not ideal, so next time I
package a version I'll include menu entries for -mx11 and -msdl.
CC
Matthew Vernon
> - if Gtk support is not present, it will default to -mx11 (I'm not
> certain if it will sensibly defaul to -mgcu in a terminal - haven't
> tested recently)
It does fallback to -mgcu correctly if gtk isn't compiled in but X11
is (that's my setup).
Matthew
--
Rapun.sel - outermost outpost of the Pick Empire
http://www.pick.ucam.org
Wally the Grey
> In fact, Debian policy prevents *anything* depending on xfonts-base, so
> the only option is Recommends.
How silly. What if something really does truly require xfonts-base, and
will not run without them? Not just an optional feature or one mode, but
the whole shebang. "Recommends" is then inappropriate, yet you'd be
forced to use it anyway?
Magnate
I am fairly confident that a comprehensive and rational answer to this is
contained in the archives of the debian-policy mailing list, where these
things get decided. They didn't do it arbitrarily.
CC
The Wanderer
I'd have expected that myself, but I don't see any such thing in the
searchable archive under lists.debian.org - neither via their on-site
search tool, nor via a that-site-only Google search.
Wally the Grey
> On 02/16/2010 06:17 AM, Magnate wrote:
>> "Wally the Grey" <hpar...@usa.net.nospam.invalid> wrote
>>> Magnate wrote:
>>>> In fact, Debian policy prevents *anything* depending on
>>>> xfonts-base, so the only option is Recommends.
>>> How silly. What if something really does truly require xfonts-base,
>>> and will not run without them? Not just an optional feature or one
>>> mode, but the whole shebang. "Recommends" is then inappropriate,
>>> yet you'd be forced to use it anyway?
>> I am fairly confident that a comprehensive and rational answer to
>> this is contained in the archives of the debian-policy mailing list,
>> where these things get decided. They didn't do it arbitrarily.
> I'd have expected that myself, but I don't see any such thing in the
> searchable archive under lists.debian.org - neither via their on-site
> search tool, nor via a that-site-only Google search.
Of course you don't. Since there can be no rational answer to this, it
is unsurprising that you are unable to find one, with Google or otherwise.
This seems to happen to all human endeavors. Once they grow above a
certain size they turn into bureaucracies and start acting the part.
Governments, scientific projects, businesses ... open source projects
are, unfortunately, no exception, though Eric S. Raymond would no doubt
find this fact to be disappointing.
The Wanderer
> The Wanderer wrote:
>
>> On 02/16/2010 06:17 AM, Magnate wrote:
>>> I am fairly confident that a comprehensive and rational answer to
>>> this is contained in the archives of the debian-policy mailing
>>> list, where these things get decided. They didn't do it
>>> arbitrarily.
>>
>> I'd have expected that myself, but I don't see any such thing in
>> the searchable archive under lists.debian.org - neither via their
>> on-site search tool, nor via a that-site-only Google search.
>
> Of course you don't. Since there can be no rational answer to this,
> it is unsurprising that you are unable to find one, with Google or
> otherwise.
Actually, now that I go looking (so that I have somewhere to reference
when asking for clarification about this on the debian-policy mailing
list), I don't see this rule mentioned anywhere at all; Google doesn't
find it in the online Debian policy manual, and the copy of the
debian-policy package I just installed doesn't seem to mention
xfonts-base anywhere, not even in the gzipped files.
Magnate, can you specify where in the Debian policy this restriction is
located?
Magnate
> On 02/16/2010 02:51 PM, Wally the Grey wrote:
>> The Wanderer wrote:
>>> On 02/16/2010 06:17 AM, Magnate wrote:
>
>>>> I am fairly confident that a comprehensive and rational answer to
>>>> this is contained in the archives of the debian-policy mailing
>>>> list, where these things get decided. They didn't do it
>>>> arbitrarily.
>>>
>>> I'd have expected that myself, but I don't see any such thing in
>>> the searchable archive under lists.debian.org - neither via their
>>> on-site search tool, nor via a that-site-only Google search.
>>
>> Of course you don't. Since there can be no rational answer to this,
>> it is unsurprising that you are unable to find one, with Google or
>> otherwise.
>
> Actually, now that I go looking (so that I have somewhere to reference
> when asking for clarification about this on the debian-policy mailing
> list), I don't see this rule mentioned anywhere at all; Google doesn't
> find it in the online Debian policy manual, and the copy of the
> debian-policy package I just installed doesn't seem to mention
> xfonts-base anywhere, not even in the gzipped files.
>
> Magnate, can you specify where in the Debian policy this restriction is
> located?
Sadly not. When preparing a Debian package, you run a program called lintian
to check your newly-built package for policy conformance. When I added the
dep on xfonts-base, lintian told me off. I'm afraid I didn't make a note of
the reference, I just changed it to a recommendation and rebuilt the
package.
It's interesting that a search of policy doesn't find any references to
xfonts-base. My guess is that the rule is worded to refer generically to a
certain type of package (font packages? -base packages?). I can't imagine
anyone on the debian-policy ML getting upset with a simple enquiry though,
especially as you have done homework with google and with policy itself - it
seems a fair question to ask.
CC
The Wanderer
> "The Wanderer" <wand...@fastmail.fm> wrote
[Debian policy: do not Depend: on xfonts-base]
>> Actually, now that I go looking (so that I have somewhere to
>> reference when asking for clarification about this on the
>> debian-policy mailing list), I don't see this rule mentioned
>> anywhere at all; Google doesn't find it in the online Debian policy
>> manual, and the copy of the debian-policy package I just installed
>> doesn't seem to mention xfonts-base anywhere, not even in the
>> gzipped files.
>>
>> Magnate, can you specify where in the Debian policy this
>> restriction is located?
>
> Sadly not. When preparing a Debian package, you run a program called
> lintian to check your newly-built package for policy conformance.
> When I added the dep on xfonts-base, lintian told me off. I'm afraid
> I didn't make a note of the reference, I just changed it to a
> recommendation and rebuilt the package.
That was enough of a clue for me to find it.
The lucky Google hit on 'lintian xfonts-base' leads to a page about the
relevant lintian rule, which contains a link to the relevant section of
the Debian policy manual, 11.8.5.
The actual rule statement is part of 11.8.5.1, and is explained in a
footnote:
"This is because the X server may retrieve fonts from the local file
system or over the network from an X font server; the Debian package
system is empowered to deal only with the local file system."
IOW, because the fonts might be available to X without being locally
installed, you aren't allowed to require that they be locally installed.
(Or that's my interpretation of this, anyway.)
Incidentally, Magnate, based on the wording of other parts of that
section of the policy manual I think that the Angband package may be out
of compliance with Debian policy; if the fonts which Angband includes
are in fact of a type which is supported by the X Window System, rule
11.8.5.1 would seem to require that they be in a separate package. Other
rules under 11.8.5 may also apply.
Magnate
> The actual rule statement is part of 11.8.5.1, and is explained in a
> footnote:
>
> "This is because the X server may retrieve fonts from the local file
> system or over the network from an X font server; the Debian package
> system is empowered to deal only with the local file system."
>
> IOW, because the fonts might be available to X without being locally
> installed, you aren't allowed to require that they be locally installed.
> (Or that's my interpretation of this, anyway.)
Mine too - and makes excellent sense.
> Incidentally, Magnate, based on the wording of other parts of that
> section of the policy manual I think that the Angband package may be out
> of compliance with Debian policy; if the fonts which Angband includes
> are in fact of a type which is supported by the X Window System, rule
> 11.8.5.1 would seem to require that they be in a separate package. Other
> rules under 11.8.5 may also apply.
Yes. I actually had another lintian warning about too much
architecture-independent data in /usr/share (more than 50% of the package),
which leads to the same conclusion.
For 3.1.3 I will be producing an angband-data package which contains the
contents of /lib/xtra, /lib/file, /lib/help and /lib/info - all the things
which go in /usr/share/angband after a default install. With luck I will
also produce the non-free angband-audio package with Dubtain's sounds.
This doesn't entirely solve the font issues, but I'm not ready to go there
yet - it's quite possible that the x11 and gtk ports will eventually be
deprecated in favour of the SDL port, in which case the font requirements
will change yet again. So I won't be making an angband-fonts package just
yet.
CC
The Wanderer
> "The Wanderer" <wand...@fastmail.fm> wrote
>> Incidentally, Magnate, based on the wording of other parts of that
>> section of the policy manual I think that the Angband package may
>> be out of compliance with Debian policy; if the fonts which Angband
>> includes are in fact of a type which is supported by the X Window
>> System, rule 11.8.5.1 would seem to require that they be in a
>> separate package. Other rules under 11.8.5 may also apply.
>
> Yes. I actually had another lintian warning about too much
> architecture-independent data in /usr/share (more than 50% of the
> package), which leads to the same conclusion.
>
> For 3.1.3 I will be producing an angband-data package which contains
> the contents of /lib/xtra, /lib/file, /lib/help and /lib/info - all
> the things which go in /usr/share/angband after a default install.
> With luck I will also produce the non-free angband-audio package with
> Dubtain's sounds.
>
> This doesn't entirely solve the font issues, but I'm not ready to go
> there yet - it's quite possible that the x11 and gtk ports will
> eventually be deprecated in favour of the SDL port, in which case the
> font requirements will change yet again. So I won't be making an
> angband-fonts package just yet.
I think you could also make a good case for "because we need the fonts
for non-X-related purposes, we should be allowed to Depend on
xfonts-base anyway", and then just create symlinks in an Angband package
to the xfonts-base fonts. That would require discussion on
debian-policy, though, since strictly it would necessitate changing the
wording of the policy.