More thoughts on v4

[fizzix]

But does it even make sense for hates-fire to be a rune if it's a property of the material of the item? I don't see a rune on my wooden table that gives it the property of being usable to heat the room when my gas runs out.

I think this goes back to the basics of obvious "runes" and hidden runes. It was one of the motivations for my proposal of splitting prefixes into make, material and quality. And making them all obvious. So an iron dagger is clearly iron on inspection. It doesn't need an iron rune and it should not have a rune for slay demon, since that is a property of the iron, not a magical enchantment.

This would be different to a weapon of slay demon, which looks like a normal weapon but has a magical slay demon property. This item would have a magical property that would not be known until you learn what the rune means.

[Magnate]

I think this goes back to the basics of obvious "runes" and hidden runes. It was one of the motivations for my proposal of splitting prefixes into make, material and quality. And making them all obvious. So an iron dagger is clearly iron on inspection. It doesn't need an iron rune and it should not have a rune for slay demon, since that is a property of the iron, not a magical enchantment.

This would be different to a weapon of slay demon, which looks like a normal weapon but has a magical slay demon property. This item would have a magical property that would not be known until you learn what the rune means.

I can see where you're coming from, but that's very painful to implement.

There are two separate axes here:

1. Not every object flag should be a rune. We already accommodate this - all the internal flags like SHOW_MODS and EASY_KNOW are not runes, so there's no problem with making HATES_FIRE not be a rune either, if people want to keep runes restricted to 'magical' stuff.

2. Some stuff should be obvious, other stuff shouldn't. This is much trickier, *especially* if you end up saying that the *same* flag should be obvious if it arrived on the item from one affix, and not obvious if it came from a different affix. It's not impossible, but it's heading towards a substantial rewrite of the ID code. But now I come to think of it, maybe that's what we need - it's a bit like the randart code - it's served us well, but it's really showing its age now, and is needing quite a lot of tweaking and massaging. Refactor mercilessly and all that.

So if we're going to do that, let's open up the discussion to what people want to see changed or improved about ID-by-use.

[fizzix]

I can see where you're coming from, but that's very painful to implement.

There are two separate axes here:

1. Not every object flag should be a rune. We already accommodate this - all the internal flags like SHOW_MODS and EASY_KNOW are not runes, so there's no problem with making HATES_FIRE not be a rune either, if people want to keep runes restricted to 'magical' stuff.

I think I'm misunderstanding something. My proposal works as follows.

Some affixes should have a flag, let's call it "OBVIOUS," that automatically displays all characteristics on pickup (or sight, or detection?), and have no associated runes. In this case the affix "iron" should have the OBVIOUS flag and on sight you should know both that it is iron and that it slays demons. An iron sword does not have any runes associated with it. This may be already covered by EASY_KNOW and SHOW_MODS. I'm not well versed in their functionality. In my mind, all the affixes that fall under make, material, or quality should be OBVIOUS.

Other affixes that don't have the OBVIOUS flag, have associated runes, one per affix (?). For example, the affix "slay demon" is not obvious, so inspecting a weapon with "slay demon" would show you one unknown rune.

There's a bit of an annoyance with the case of an "iron sword of slay demon". In this case, there is an unknown rune, but it does not improve the weapon. The rune should probably be ID'd in the normal way.

[Malak Darkhunter]

Just updated my character Titan on the ladder, found what seems to be a pretty powerful morningstar, but it's a little confusing to understand, reading it makes you think it grants either:

A: gives you resistance to the elements like a normal defender weapon or

B: gives you immunities to the elements, because it has the ignore properties on the item.

Not sure what to make of it.

[Derakon]

Just updated my character Titan on the ladder, found what seems to be a pretty powerful morningstar, but it's a little confusing to understand, reading it makes you think it grants either:

A: gives you resistance to the elements like a normal defender weapon or

B: gives you immunities to the elements, because it has the ignore properties on the item.

Not sure what to make of it.

It provides resistances and itself cannot be damaged by those elements. There should probably be an "It" in front of the "Cannot" in the "Cannot be harmed by acid, electricity, fire, cold." portion of the description; that should clear up the ambiguity.

[Malak Darkhunter]

looking at my own dump file it is not giving the full discription, the full discription fills nearly a page, see if i can reproduce.

" this items known runes are: stealth, tunneling, extra blows, sustain charisma, acid resistance, electric resistance, fire resistance, cold resistance, feather falling, regeneration, see invisible, free action, ignore acid, ignore electricity, ignore fire, ignore cold, hates acid, hates fire.

+1 tunneling, attack speed
+2 stealth
provides resistance to acid, lightning, fire, cold
cannot be harmed by acid, electricity, fire, cold
sustain charisma
feather falling, speeds regeneration, prevents paralyzes, grants the ability to see invicible things."

you notice it clearly states resistance to the acid and fire, but it says hates acid and fire as well.

[fizzix]

There should be a hierarchy.

hates < ignores < resists < provides immunity for.

In your case you have resist, so there should be no need to display ignores or hates.

[Nomad]

There should be a hierarchy.

hates < ignores < resists < provides immunity for.

In your case you have resist, so there should be no need to display ignores or hates.

Yep, this is my view. If you learn it's got a better rune, that should replace the previous information.

[Magnate]

I think I'm misunderstanding something. My proposal works as follows.

Some affixes should have a flag, let's call it "OBVIOUS," that automatically displays all characteristics on pickup (or sight, or detection?), and have no associated runes. In this case the affix "iron" should have the OBVIOUS flag and on sight you should know both that it is iron and that it slays demons. An iron sword does not have any runes associated with it. This may be already covered by EASY_KNOW and SHOW_MODS. I'm not well versed in their functionality. In my mind, all the affixes that fall under make, material, or quality should be OBVIOUS.

Other affixes that don't have the OBVIOUS flag, have associated runes, one per affix (?). For example, the affix "slay demon" is not obvious, so inspecting a weapon with "slay demon" would show you one unknown rune.

There's a bit of an annoyance with the case of an "iron sword of slay demon". In this case, there is an unknown rune, but it does not improve the weapon. The rune should probably be ID'd in the normal way.

Ok, yes, I see the problem now. The fundamental concept behind rune-based ID is that an object property such as Slay Demon is represented by a rune. (That's not a good example because x2/3/5 slays all have different runes, but anyway.)

So, every item that gives Slay Demon(x2) will have the same rune on it. Doesn't matter whether it's iron or not.

If we don't do that, rune-based ID becomes kind of pointless, because whether or not a property has a rune will be kind of arbitrary - i.e. it will depend on the item's OBVIOUS properties, which are random.

So I don't think your suggested implementation of OBVIOUS is compatible with rune-based ID as it stands - unless we're all happy for all the runes of obvious affixes to be immediately known and displayed. I guess that's possible.

There should be a hierarchy.

hates < ignores < resists < provides immunity for.

In your case you have resist, so there should be no need to display ignores or hates.

This works fine when the item is fully known, but what about when it's unIDd? Do you show all the unknown runes and then have the ones lower in the hierarchy simply disappear on ID? Or do you not show them, and leak information?

IMO if we're going to stick with rune-based ID we need to accept that runes are visible things and find a way to deal with that in the 'I'nspect details. I really don't like the idea of hiding runes from the player, even if they're redundant runes.

Separately, I've now realised why I have a problem with takkaria's issue of hates fire being a physical property of the material not a magical property of the item. Let's take IGNORE_FIRE instead: sometimes it's a natural property of the material (i.e. mithril), and sometimes it's a magical property of the item (e.g. Defenders). It makes no sense to me that a given property would sometimes be a rune and sometimes not be, just as with iron/Slay Demon above.

[Nomad]

Ok, yes, I see the problem now. The fundamental concept behind rune-based ID is that an object property such as Slay Demon is represented by a rune. (That's not a good example because x2/3/5 slays all have different runes, but anyway.)

So, every item that gives Slay Demon(x2) will have the same rune on it. Doesn't matter whether it's iron or not.

Yeah, the slay aspect of the iron and silver affixes bugs me for exactly this reason. The same property conveyed in two different ways with different names just seems untidy and counter intuitive to me. (And the way my semi-working ego naming system is set up, it would render it "an Iron <item> of Slay Demon" and pretty much pretend it was the same as an item with the Slay Demon rune in any case.)

I'd rather see the slay removed from silver and iron entirely, honestly, and have materials and makes only affect the combat bonuses on the weapons, never the flags. (Digging on Gnomish/Dwarven/Orcish weapons bugs me too.) For a start, it makes ego squelch less of a pain because you don't have to set squelch for multiple redundant versions of the same thing.

This works fine when the item is fully known, but what about when it's unIDd? Do you show all the unknown runes and then have the ones lower in the hierarchy simply disappear on ID? Or do you not show them, and leak information?

IMO if we're going to stick with rune-based ID we need to accept that runes are visible things and find a way to deal with that in the 'I'nspect details. I really don't like the idea of hiding runes from the player, even if they're redundant runes.

I can see your point, but the paragraph of known runes ends up huge, difficult to read and full of redundant information. Maybe Inspect should only list unknown runes, and known runes can just be covered by the descriptive text that follows? I mean, "Known runes: slay evil" followed by "It slays evil creatures." is pretty redundant already.

[Magnate]

Yeah, the slay aspect of the iron and silver affixes bugs me for exactly this reason. The same property conveyed in two different ways with different names just seems untidy and counter intuitive to me. (And the way my semi-working ego naming system is set up, it would render it "an Iron <item> of Slay Demon" and pretty much pretend it was the same as an item with the Slay Demon rune in any case.)

I'd rather see the slay removed from silver and iron entirely, honestly, and have materials and makes only affect the combat bonuses on the weapons, never the flags. (Digging on Gnomish/Dwarven/Orcish weapons bugs me too.) For a start, it makes ego squelch less of a pain because you don't have to set squelch for multiple redundant versions of the same thing.

I'm afraid I disagree with this. I don't think the design should be constrained by the implementation details. If we need to change implementation, I'm fine with that, but saying that makes and materials can never have slay flags would be very wrong IMO. I'm happy to continue looking for a solution to the runes issue that allows the properties of Iron to be obvious while magical demon-slaying isn't.

I can see your point, but the paragraph of known runes ends up huge, difficult to read and full of redundant information. Maybe Inspect should only list unknown runes, and known runes can just be covered by the descriptive text that follows? I mean, "Known runes: slay evil" followed by "It slays evil creatures." is pretty redundant already.

Yes, that's a good idea. Known runes can also be looked up in the knowledge menu, so 'I'nspect displays only unknown runes is the way to go.

[Nomad]

I'm afraid I disagree with this. I don't think the design should be constrained by the implementation details. If we need to change implementation, I'm fine with that, but saying that makes and materials can never have slay flags would be very wrong IMO. I'm happy to continue looking for a solution to the runes issue that allows the properties of Iron to be obvious while magical demon-slaying isn't.

I suppose my issue is not so much that they have flags as that they duplicate existing flags redundantly. But I guess that's a philosophy of item flavours thing. I see introducing a property that is functionally identical to another property but under a different name as a bad thing; it's adding flavour for no reason other than to have more flavour, which is not something I personally like. My design instinct is to restrict flavours to something as close as possible to the Vanilla ego set, only adding new names when they're essential to communicate something that doesn't exist in V.

Which is not necessarily the guiding principle other people see for v4, so fair enough.

[buzzkill]

I suppose my issue is not so much that they have flags as that they duplicate existing flags redundantly.

Well that's an aspect of randomly generated environment that you have to deal with, or restrict generation, so that redundancies never occur.

I think the correct solution is that physical properties are obvious and trump identical magical runes (so they need not be displayed), or have them stack... do they stack? An iron sword of slay demon > a sword or slay demon or a plain iron sword.

I hope I added something, but I fear I just repeated what had already been stated.

[Nomad]

Well that's an aspect of randomly generated environment that you have to deal with, or restrict generation, so that redundancies never occur.

I think the correct solution is that physical properties are obvious and trump identical magical runes (so they need not be displayed), or have them stack... do they stack? An iron sword of slay demon > a sword or slay demon or a plain iron sword.

I suppose my view is that the random generator should not have two things it can generate that do the same thing in the first place. There should be a "Slay Demon" affix that slays demons, or there should be an "Iron" affix that slays demons, but there shouldn't be both a "Slay Demon" and an "Iron" affix that do the same thing. That's like having a random ice-cream dispenser that can dispense both "chocolate" flavour and "choc-o-tastic" flavour but will still give you a scoop from the same ice-cream box regardless of which one it picks. One-to-one flavour labelling seems like a much better idea to me personally. Different names for different things, the same name always for the same thing.

[buzzkill]

I suppose my view is that the random generator should not have two things it can generate that do the same thing in the first place. There should be a "Slay Demon" affix that slays demons, or there should be an "Iron" affix that slays demons, but there shouldn't be both a "Slay Demon" and an "Iron" affix that do the same thing.

Then.. you either don't need physical properties or you don't need magical properties (probably physical). That's a big loss of flavor. Personally, I'd rather they stack (and replicate the old *super slay*). Chocolate ice cream in chocolate flavored cone with chocolate syrup on top > a scoop of chocolate ice cream in styrofoam cup with little plastic spoon.