More thoughts on v4

[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]

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]

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.

[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.

[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.

[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]

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.

[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.

[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]

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.

[takkaria]

But then you'd have extra knowledge if you saw e.g. some leather armor missing its usual hates-fire rune.

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.

[Magnate]

But then you'd have extra knowledge if you saw e.g. some leather armor missing its usual hates-fire rune.

That - and some players would ask why some runes were shown but not others etc. This is one of those areas where it's not possible to please everyone.

[Derakon]

But then you'd have extra knowledge if you saw e.g. some leather armor missing its usual hates-fire rune.

[Nomad]

But what you're seeing is the runes, and both runes are still there. It's just that one of them is overridden by the other.

I think that overridden runes should be hidden too, so that you only see the best one an item has out of Immunity/Resists/Ignores/Hates. It's redundant information and the rune list already ends up epic enough on artefacts that have a ton of different properties.

[Magnate]

He's saying there are items that have 'hates fire' and 'cannot be destroyed by fire' on the same item. It needs to be one or the other, or they shouldn't be able to be on the same item...

Well, if the base object type (arrow) has HATES_FIRE, and yet the actual object (mithril arrow) has IGNORE_FIRE, then you do end up with both on the same item. This isn't a problem, providing that the description code knows how to handle it. Which it does, now. It no longer says "can be destroyed by fire" if the object has both flags, it just says "cannot be harmed by fire".

But what you're seeing is the runes, and both runes are still there. It's just that one of them is overridden by the other.