EyAngband item prefixes

[jens]

As seen in the thread:

http://angband.oook.cz/forum/showthread.php?t=4494

For ego_item.txt:
Add minor ego types based on EyAngband prefixes. There are also a whole bunch of new ego types suggested in this thread.

I am not sure that you are interpreting the ticket the same way that takkaria meant it.

Nowhere on the ticket are ego items mentioned, and the milestone is set to 4.0. If it was ment as a simple addition of ego items I feel it would have been formulated differently? I have not played EyAngband, but I looked through the spoilers. Some of the prefixes in the spoilers are prerequisites for certain ego types. Which implies they are not the same in EyAngband...

My interpretation is that takkaria meant something like: a layer of items between ordinarily enchanted items and ego items. Governed by a text file 'prefix.txt' that gives a name and some modifiers that can be applied to all weapons/armors.

If it is ego items we are talking about a few names can be taken from EyAngband, not much more. Some prefixes would seem to work as ego items, but ego_items.txt does not allow negative values, weight modifier does not work, etc.

Just creating new, low level, ego items is easy. And borrowing a few names from EyAngband might be a good place to start. But I just don't see that this would resolve the ticket...

All that aside I have to say I enjoy ego items, and will probably cook some up ;-) But please clarify the dev position...

Add A: lines to ego_item.txt - although the code has yet to support this, it would be very helpful if someone put these in first, with carefully balanced min and max depths for each ego type, and the alloc_prob.

I might well do this, because I really want this functionality to get into ego_items.txt, plus I could smuggle a few other improvements into the file ;-)

I suppose that lines the parser does not understand are ignored, so the file would still work?

How much work would you say is left to do after the allocation lines have been added to ego_items.txt?

[Magnate]

You are right that the original ticket was not about adding the Ey prefixes as ego types - that was an interpretation of mine which would incorporate them in a way which required minimal coding. I was compiling a list of things people could do without coding, so it seemed sensible at the time. It may indeed be better to have a layer of prefixed item types between standard items and ego items - by analogy with Diablo II, these would be the blues between whites and yellows. But if we were going to do that, one would seriously consider junking ego templates altogether and re-writing nonartifact item generation from scratch, which is a lot of coding work.

So in the meantime adding some of the easier Ey prefixes as ego types might be a useful approach. You can now specify negative pvals btw (by leaving min_pval at 0), and you've always been able to specify negative to-hit, to-dam and to-ac.

When the A: lines are added, it should be as simple as adding a single parse_e_a function to the parse_ego code, to get them read in. Actually using them then requires some changes to the code in make_ego_item, but it shouldn't be too much work.

[jens]

You are right that the original ticket was not about adding the Ey prefixes as ego types - that was an interpretation of mine which would incorporate them in a way which required minimal coding. I was compiling a list of things people could do without coding, so it seemed sensible at the time. It may indeed be better to have a layer of prefixed item types between standard items and ego items - by analogy with Diablo II, these would be the blues between whites and yellows. But if we were going to do that, one would seriously consider junking ego templates altogether and re-writing nonartifact item generation from scratch, which is a lot of coding work.

Not that it matters, but when would the ticket in question be considered to be resolved? After adding a few new ego items, or first after a big rework of item generation?

I've been thinking about writing up a whole bunch of minor ego items. Say that I would post an edited ego_item.txt in a weeks time with say 40 new entries in it. I'm thinking it would need some time in nightlies to adjust game balance before getting into V, so I feel I should wait with it until after 3.3 is out. Any thoughts on that?

So in the meantime adding some of the easier Ey prefixes as ego types might be a useful approach. You can now specify negative pvals btw (by leaving min_pval at 0), and you've always been able to specify negative to-hit, to-dam and to-ac.

I haven't tried it recently, but in 3.2, when specifying negative values you got 256 - abs(value) instead. Or was that only when specifying negative min values? In any case, since min values could not go below 0 it was not possible to achieve negative values for anything (at least that was the case if you happened to use the 'M:' line anywhere early in 'ego_item.txt'. Which btw is manifested today as in no ego armor having a tohit penalty). I will check this out, but I'm going away for the weekend soon...

When the A: lines are added, it should be as simple as adding a single parse_e_a function to the parse_ego code, to get them read in. Actually using them then requires some changes to the code in make_ego_item, but it shouldn't be too much work.

OK, I'll try to write them in next week, and hope to have the functionality before 3.3 is released :-)

[Magnate]

Not that it matters, but when would the ticket in question be considered to be resolved? After adding a few new ego items, or first after a big rework of item generation?

This varies from ticket to ticket. For bugs it's easy, the ticket's closed when the bug is fixed (or when it's decided that this particular behaviour is acceptable). For changes, it depends what the original intention was. In this particular case, I think the intention was to add flavour - so that could be considered accomplished after adding a bunch of new ego types. If we then wanted to rewrite nonartifact generation, we could create a new ticket for that.

I've been thinking about writing up a whole bunch of minor ego items. Say that I would post an edited ego_item.txt in a weeks time with say 40 new entries in it. I'm thinking it would need some time in nightlies to adjust game balance before getting into V, so I feel I should wait with it until after 3.3 is out. Any thoughts on that?

I agree - it would be a good idea to do this after 3.3, so that the new egos get plenty of playtesting for 3.4.

I haven't tried it recently, but in 3.2, when specifying negative values you got 256 - abs(value) instead. Or was that only when specifying negative min values? In any case, since min values could not go below 0 it was not possible to achieve negative values for anything (at least that was the case if you happened to use the 'M:' line anywhere early in 'ego_item.txt'. Which btw is manifested today as in no ego armor having a tohit penalty). I will check this out, but I'm going away for the weekend soon...

If you had looked at http://trac.rephial.org/ticket/1394, you would have seen that this was fixed in [r821f59d] by making min_pval of 0 mean "apply no minimum". You can therefore specify negative pvals (with the caveat that there is some odd behaviour in random_value parsing, which will be addressed in #1451) without them being overridden. You cannot specify minima below 1 though.

[takkaria]

This varies from ticket to ticket. For bugs it's easy, the ticket's closed when the bug is fixed (or when it's decided that this particular behaviour is acceptable). For changes, it depends what the original intention was. In this particular case, I think the intention was to add flavour - so that could be considered accomplished after adding a bunch of new ego types.

FWIW, the intention was just to copy EyAngband's prefix system. If a similar effect can be realised using new minor ego types, that's fine too, but I don't think I'd consider the ticket closed (I'd want either the prefix system or a rewrite of object generation that did a similar thing).

In the meantime, minor ego types would be gladly accepted.

[Magnate]

FWIW, the intention was just to copy EyAngband's prefix system. If a similar effect can be realised using new minor ego types, that's fine too, but I don't think I'd consider the ticket closed (I'd want either the prefix system or a rewrite of object generation that did a similar thing).

Ah yes, I had forgotten the virtues of plagiarism. If we can just copy Ey's prefix system wholesale, that's a lot less work than rewriting item generation ... and would neatly add a layer of interest between magical and ego. If I can time it for just when rune-based ID is finished, it should drive Eddie plenty nuts ... ;-)

[jens]

So I'm about to start adding the A: line to ego_item.txt, just a quick question...

The allocation value is the reverse of the rarity right? i.e. we use that number directly when adding to the object list, rather than 100/r. And it can go beyond 100? Not saying it will, just checking the grounds before doing the work :-)

Will go for a run, to have a chance of an answer before I start ;-)

[Derakon]

As I understand it, each item gets allocated a number of slots equal to the number in its allocation line; then the game chooses a slot and generates the corresponding item. So bigger numbers are more common, and there shouldn't be any logical reason why the allocation couldn't go beyond 100.

[Magnate]

As I understand it, each item gets allocated a number of slots equal to the number in its allocation line; then the game chooses a slot and generates the corresponding item. So bigger numbers are more common, and there shouldn't be any logical reason why the allocation couldn't go beyond 100.

I honestly don't know whether alloc_prob > 100 would break anything. But it might be safe to treat it as a percentage scale (even though that isn't how the allocation table works).

[takkaria]

I honestly don't know whether alloc_prob > 100 would break anything. But it might be safe to treat it as a percentage scale (even though that isn't how the allocation table works).

I think it can go up to 255. But I wouldn't bother trying.

[jens]

Well the shoe-shop bug showed that over 100 is possible ;-) I know I did some experiments a few months ago where I put 400, or was it only 200 (trying out some egos). I don't think it crashes, but it might cap. But no worries, I will probably not go beyond 20 in any case...

Takes longer than I thought. Guess I think too much on each case, do some math, compare stuff, etc... Halfway there now...

[jens]

I have uploaded (just a few lines from having to zip it :-) a version of ego_item.txt which contains the A: line for all entries. Other than affecting rarity (which the change is all about), I have made no functional changes to the file, but I did some minor cleanup. Some notes can be of interest.

I have thought hard on every change in this file. If you see something that seems wrong, please ask and I will explain my resoning.


In general:

In the old system, the most common item was designated a 1, which in code was translated to 100 entries in the list to be generated. In the new system, you designate that number directly. I have chosen to make 20 (instead of 100) the base commonality. The only reason to use 100 is to ensure the possibility to make other items more rare in comparison. This scope of rarity was never used in the old system. Most objects in object.txt have a rarity of 20, so using the same baseline is consistent.

Egos that only apply to a subsection of the type they apply for often had an inflated rarity compared to similar egos. I have moved these rarities closer to the original intention. Generally I've tried to stay close to the old ratios of rarities where desireable, but some artistic/scientific license has been exercised as well.

I have tried to spread out the min dlvl and the max dlvl to avoid break points where you want to grind. Ego items that are only useful in the early game have a low max level. Sometimes the max level is higher than where the item would be deemed interesting, this is to balance the ratio of other egos of the same type.


Specifics:

Boots of stealth
- Removed 'metal' boot types. Increases rarity, and makes thematic sense.

Helmets and Crowns
- Removed/changed a few types, thus creating a clean split between helmets and crowns, so no ego item applies to both. This simplified the setting of allocations, and makes thematic sense.

Weapons
- Slays: no overlap in dlvl for specific slay - *slay* pair. Min lvls timed to arrive when you need them (and as warnings of dangers ahead), then gradually go away. Since ego weapons are so abundant, the 'slay' egos are the only egos where I've been able to be really agressive with max dlvl.

[Magnate]

Thank you - your reasoning looks sound, so we'll see how it plays. I can't guarantee that this will make it into 3.3 (I can't see anyone other than me coding it up, and not sure if I'll have time), but if not then I promise to introduce it early in 3.4

[Derakon]

Two things:

1) So you can't find Mithril Boots of Stealth any more? I always kinda assumed that mithril armor had all the advantages of both hard and soft armor, though I could be convinced otherwise.

2) I suspect this will decrease the frequency of junk egos later on since they have relevant max depth caps now. Not a huge issue so long as this isn't enabling really powerful egos to become significantly more frequent...

[jens]

Thank you - your reasoning looks sound, so we'll see how it plays. I can't guarantee that this will make it into 3.3 (I can't see anyone other than me coding it up, and not sure if I'll have time), but if not then I promise to introduce it early in 3.4

The earlier the better for me, then I can get to work on other stuff I want to do ;-) But there might of course be some balancing issues, so a week before 3.3 might be a bad time. As long as it doesn't get sitting for months, because then It might get obsolete by other changes to ego_item.txt.