Changes between Version 12 and Version 13 of NewEgos


Ignore:
Timestamp:
10/13/11 15:42:14 (7 years ago)
Author:
magnate
Comment:

Italicised function names for easier reading

Legend:

Unmodified
Added
Removed
Modified
  • NewEgos

    v12 v13  
    3131N.B. There is no base item called "Blade", so the "of Chaos" affix can be applied to the top three swords (Katana, Zweihander and Executioner IIRC). Though there's no reason not to allow Daggers of Chaos, if we want to. 
    3232 
    33 === make_object and make_artifact === 
    34 Having improved the type and reduced the egos down to simple affixes, I set about changing object generation. First I rewrote kind_is_good to look for OF_GOOD, so that powerful items like DSMs are automatically considered "good" and never "average". This doesn't actually have much impact on the obj_alloc_great table though, since all armour and weapon types were already in it (but see below for more thoughts on this).  
     33=== ''make_object'' and ''make_artifact'' === 
     34Having improved the type and reduced the egos down to simple affixes, I set about changing object generation. First I rewrote ''kind_is_good'' to look for OF_GOOD, so that powerful items like DSMs are automatically considered "good" and never "average". This doesn't actually have much impact on the obj_alloc_great table though, since all armour and weapon types were already in it (but see below for more thoughts on this).  
    3535 
    36 Then I sorted out artifact generation, combining special and normal artifacts. This distinction only ever existed because all normal artifacts were only ever generated after the object kind was chosen, and specials were attempted before. Now make_object tries for an artifact first, and make_artifact now creates an allocation table of all possible artifacts (i.e. not yet created, in-depth, out-of-depth checks etc.) before choosing one. If the kind is already chosen (e.g. from specified monster drops) then the allocation table looks a lot smaller because it only contains artifacts legal for that kind.  
     36Then I sorted out artifact generation, combining special and normal artifacts. This distinction only ever existed because all normal artifacts were only ever generated after the object kind was chosen, and specials were attempted before. Now ''make_object'' tries for an artifact first, and ''make_artifact'' now creates an allocation table of all possible artifacts (i.e. not yet created, in-depth, out-of-depth checks etc.) before choosing one. If the kind is already chosen (e.g. from specified monster drops) then the allocation table looks a lot smaller because it only contains artifacts legal for that kind.  
    3737 
    3838Please note: artifact generation will need quite a bit of balancing, because not only did I unify the generation functions (which will fundamentally change how many are generated), but I also recalibrated the alloc_prob scale to 1000 rather than 100, and reflected the fact that these are now checked independently of base items. So Bladeturner's old rarity accounted for the fact that its base item was very rare: now it has to be even rarer. I implemented multiple A: lines for artifacts, so we now have finer control over their findability (because they can have different rarities at different depths). 
    3939 
    4040=== Choosing and applying affixes === 
    41 So, if we're not an artifact we now set the number and quality of an object's affixes in apply_magic. Note that the call to apply_magic from make_object deliberately sets allow_artifacts to FALSE, because we've already tried for an artifact there. But if it's called directly (for a specified item), then we still get a shot at becoming an artifact. 
     41So, if we're not an artifact we now set the number and quality of an object's affixes in ''apply_magic''. Note that the call to ''apply_magic'' from ''make_object'' deliberately sets allow_artifacts to FALSE, because we've already tried for an artifact there. But if it's called directly (for a specified item), then we still get a shot at becoming an artifact. 
    4242 
    43 One important change is that *all* items can now get "good" affixes. This is because apply_magic_weapon/armour() have been removed, and plusses now come from first-grade affixes (Quality, Sharp, Brutal etc.), but you can now get minor abilities like Feather Falling on what would previously have been just "good" items. Forced-great items automatically get access to great affixes, and good items do so 25% of the time. There's also a depth-dependent chance for increment, so uber affixes are (i) only available on good or great drops and (ii) much less likely early on.  
     43One important change is that *all* items can now get "good" affixes. This is because ''apply_magic_weapon/armour()'' have been removed, and plusses now come from first-grade affixes (Quality, Sharp, Brutal etc.), but you can now get minor abilities like Feather Falling on what would previously have been just "good" items. Forced-great items automatically get access to great affixes, and good items do so 25% of the time. There's also a depth-dependent chance for increment, so uber affixes are (i) only available on good or great drops and (ii) much less likely early on.  
    4444 
    4545The number of affixes is a function of depth (0 to (1 + lev / 25)), plus one or two if good, or three or four if great (minus one if we have OF_GOOD). These numbers can be rebalanced, of course. There might not actually be many "great" drops, so we might want to be more generous to normal or good items, and tone down the great items to only a couple of extra affixes. But note that "normal" drops get much more interesting with depth, so this may not be necessary. 
    4646 
    47 I haven't done a lot of renaming yet, but I've renamed make_ego_item to obj_add_affix because it wasn't called from anywhere else except apply_magic. It checks that we're not trying to add an affix to an artifact, a themed item, or an item with max affixes already. It also does that weird GREAT_EGO level boost, for a one-in-20 chance of a potentially huge level boost (though that doesn't boost the affix level yet - if it did, this would create interesting possibilities for randarts, noted below). Importantly, we copy the object, so we don't have to worry about affixes creating broken items - if that happens we just roll back and don't add anything. 
     47I haven't done a lot of renaming yet, but I've renamed ''make_ego_item'' to ''obj_add_affix'' because it wasn't called from anywhere else except ''apply_magic''. It checks that we're not trying to add an affix to an artifact, a themed item, or an item with MAX_AFFIXES already. It also does that weird GREAT_EGO level boost, for a one-in-20 chance of a potentially huge level boost (though that doesn't boost the affix level yet - if it did, this would create interesting possibilities for randarts, noted below). Importantly, we copy the object, so we don't have to worry about affixes creating broken items - if that happens we just roll back and don't add anything. 
    4848 
    49 We choose which affix to apply in obj_find_affix, which is ego_find_random renamed and rewritten to allow for the new T: lines above. Like make_artifact, it builds an allocation table from the affixes which are legal for this item at this depth and affix level.   
     49We choose which affix to apply in ''obj_find_affix'', which is ''ego_find_random'' renamed and rewritten to allow for the new T: lines above. Like ''make_artifact'', it builds an allocation table from the affixes which are legal for this item at this depth and affix level.   
    5050 
    51 We actually apply the affix in ego_apply_magic (which I didn't rename yet 'cos it's called from a few places) - it deals with the extra stuff outlined above (base ac / weight / dice / sides, and random flags) but is otherwise recognisable. We now check minima both before and after application, to ensure that a min_pval of 2 gives correct results when applied to an existing pval of, say, -1. We also check flags at the end, to remove contradictory elemental flags (RES_FOO and VULN_FOO etc.), and to strip lots of mods off ammo (so that we don't have to replicate affixes and themes for ammo). Oh, I fixed #1531 as well. 
     51We actually apply the affix in ''ego_apply_magic'' (which I didn't rename yet 'cos it's called from a few places) - it deals with the extra stuff outlined above (base ac / weight / dice / sides, and random flags) but is otherwise recognisable. We now check minima both before and after application, to ensure that a min_pval of 2 gives correct results when applied to an existing pval of, say, -1. We also check flags at the end, to remove contradictory elemental flags (RES_FOO and VULN_FOO etc.), and to strip lots of mods off ammo (so that we don't have to replicate affixes and themes for ammo). Oh, I fixed #1531 as well. 
    5252 
    5353If we didn't break anything, we look to see if the object can now get a theme. 
     
    5656Without themes, we can have very powerful items, but they're like randarts - random collections of attributes. Themes allow us to decide, during an item's creation, that it's going down a particular path. So I wrote ego_themes.txt, which sets out what these themes are. At the moment they're all recognisable, because they're the high-end/compound egos I removed from ego_item.txt earlier on. 
    5757 
    58 Themes[] are a global array like e_info[], which have N: and D: lines exactly like ego_item.txt. They also have T: lines, but these only have tval, svals and depths - no "level" or "commonness". So far so obvious. obj_find_theme builds an allocation table of legal themes just like make_artifact and obj_find_affix, checking depth and tval/sval.  
     58Themes[] are a global array like e_info[], which have N: and D: lines exactly like ego_item.txt. They also have T: lines, but these only have tval, svals and depths - no "level" or "commonness". So far so obvious. ''obj_find_theme'' builds an allocation table of legal themes just like ''make_artifact'' and ''obj_find_affix'', checking depth and tval/sval.  
    5959 
    6060But there the similarity ends - themes don't have an inherent commonness, they have a number of component affixes, each of which has a weighting. We check the object to see if it has any of these affixes already, and record their weight. Then we multiply by the proportion of total weight to get the actual likelihood of acquiring that theme. These weightings were chosen very carefully, because often only one theme will be available to an object, and we have to have an absolute percent chance of getting it, as well as an allocation table if there are several to choose from. The total weight of the relevant affixes on the item is multiplied by (itself x 4 / total weight of all affixes in the theme) to get the percent chance (in the code we use x8 and use randint0(200) so we're using half-percent granularity). 
     
    6666If we have two of the resists, we have a total weight of 14. The percent chance of acquiring the theme is (14*14*4)/(34*100) = 23%.  
    6767 
    68 If we have three of the resists, we have weight of 21.  The percent chance of acquiring the theme is (21*21*4)/(34*100) = 51.5%. 
     68If we have three of the resists, we have weight of 21. The percent chance of acquiring the theme is (21*21*4)/(34*100) = 51.5%. 
    6969 
    7070If we have all four resists, we have a (28*28*4)/(34*100) = 92% chance of acquiring the theme. (If we tweaked the weightings of Durable and Reinforced down to 2 and 1 respectively, this would be over 100%, which is probably what we want.) 
     
    7474Another example worth mentioning is Gloves of Power - a theme which has only two affixes. Both have weights of 100, so if we get them, we will automatically get this theme. Similarly lanterns of True Sight, and Blessed weapons.  
    7575 
    76 Blessed weapons have three affixes, but one of them has a weighting of zero (of Dweomercraft, the one which provides the random ability - also on Gondolin and *Slay* Evil weapons, Lothlorien bows etc.). This means it doesn't contribute to the weighting, but it is applied in obj_apply_theme after the theme is chosen. This function simply cycles through all the affixes in the theme and applies all the ones that aren't already on the item. Since you can specify the same affix more than once in a theme (e.g. for extra combat bonuses, or extra random flags), we allow the second and subsequent ones to be applied.  
     76Blessed weapons have three affixes, but one of them has a weighting of zero (of Dweomercraft, the one which provides the random ability - also on Gondolin and *Slay* Evil weapons, Lothlorien bows etc.). This means it doesn't contribute to the weighting, but it is applied in ''obj_apply_theme'' after the theme is chosen. This function simply cycles through all the affixes in the theme and applies all the ones that aren't already on the item. Since you can specify the same affix more than once in a theme (e.g. for extra combat bonuses, or extra random flags), we allow the second and subsequent ones to be applied.  
    7777 
    78 Note that obj_apply theme doesn't actually set the o_ptr->affix for the affixes it applies. This is deliberate: many themes have more than MAX_AFFIXES. Also, once we acquire a theme we're unable to modify the item further (like an artifact), so it doesn't really matter too much. Note also that branding spells *will* (currently) work on non-themed items, providing they have < MAX_AFFIXES. I like this, but others might not (more below). 
     78Note that ''obj_apply_theme'' doesn't actually set the o_ptr->affix for the affixes it applies. This is deliberate: many themes have more than MAX_AFFIXES. Also, once we acquire a theme we're unable to modify the item further (like an artifact), so it doesn't really matter too much. Note also that branding spells *will* (currently) work on non-themed items, providing they have < MAX_AFFIXES. I like this, but others might not (more below). 
    7979 
    8080=== ID, naming and saving === 
    81 ID-by-use works reasonably well for affixes, though I had to write object_affix_is_known to check from first principles whether we know all about an affix. The IDENT_ flags don't work because we don't know how many affixes we're trying to know, and I decided against recording o_ptr->known_affixes in favour of working it out on the fly. object_theme_is_known is just a wrapper which makes sure that we know all the affixes in a theme. This is pretty basic but actually seems to work ok - both magical ID and ID-by-use seem to work ok, and the ego knowledge menu shows affixes once they're known (it doesn't talk about the new mods to weight/base AC/dice/sides, but otherwise works ok).  
     81ID-by-use works reasonably well for affixes, though I had to write ''object_affix_is_known'' to check from first principles whether we know all about an affix. The IDENT_ flags don't work because we don't know how many affixes we're trying to know, and I decided against recording o_ptr->known_affixes in favour of working it out on the fly. ''object_theme_is_known'' is just a wrapper which makes sure that we know all the affixes in a theme. This is pretty basic but actually seems to work ok - both magical ID and ID-by-use seem to work ok, and the ego knowledge menu shows affixes once they're known (it doesn't talk about the new mods to weight/base AC/dice/sides, but otherwise works ok).  
    8282 
    8383Finally, with noz's help, we sorted out the prefix and suffix names of the object, which are the theme or the best affixes in the absence of a theme (so you can get Emerald weapons of Gondolin, or Broken ones, etc.). There is still some thinking to do here in relation to ID and naming, some of which was discussed on IRC (d_m/fizzix suggested "synthetic" affixes which change the name but no properties - this seems like a good solution, but it would be a shame to lose all the flavour of the affix names). 
     
    9494 
    9595=== Knowledge and ID === 
    96 The knowledge menus need sorting: first they need to show details of the new mods from affixes (base AC / weight / dice / sides - random flags should already work). Then we need a new "theme knowledge" menu about themes - I don't think I have the skill to do this, yet. Also, theme->everseen is not currently set anywhere. Come to think of it, neither is affix->everseen, so I'm not sure how the knowledge menu is still working for affixes! (Also, fizzix reports that the object knowledge menu crashes now - fixing this is a priority.) 
     96The knowledge menus need sorting: first they need to show details of the new mods from affixes (base AC / weight / dice / sides - random flags should already work). Then we need a new "theme knowledge" menu about themes - I don't think I have the skill to do this, yet. Also, theme->everseen is not currently set anywhere. Come to think of it, neither is affix->everseen, so I'm not sure how the knowledge menu is still working for affixes! (Update: it isn't, it's using old everseen data. Will fix this.) 
    9797 
    9898We need description/flavour text for affixes and themes. (There was very little for any existing ego types anyway, so this has long been the case.) 
     
    100100IMO we should no longer show the base AC or dice of an object, because these are no longer so static - lots of the Ey prefixes change one or the other. This fits nicely with reducing the amount of info available and forcing people to walk over a fetch stuff. Interested in people's thoughts on this (and see also #1551). 
    101101 
    102 We also need to refine the IDing of affixes and themes, but this needs discussion after both Eddie's patch improvements and rune-based ID. I have defined IDENT_PREFIX and IDENT_SUFFIX, but these aren't used yet (we use obj_affix_known instead). One question is whether we should display the best *known* prefix or suffix, rather than not display any unless the best is known. It would seem odd for an item to change its name as you discovered more about it, but maybe that's preferable to the current behaviour. 
     102We also need to refine the IDing of affixes and themes, but this needs discussion after both Eddie's patch improvements and rune-based ID. I have defined IDENT_PREFIX and IDENT_SUFFIX, but these aren't used yet (we use ''obj_affix_known'' instead). One question is whether we should display the best *known* prefix or suffix, rather than not display any unless the best is known. It would seem odd for an item to change its name as you discovered more about it, but maybe that's preferable to the current behaviour. 
    103103 
    104104=== Naming and base items === 
    105105We need to agree a strategy for naming items with multiple affixes. Personally I favour adopting the position that an object's displayed name does not give you complete information about all its properties, but others may disagree. Also, affixes can be applied more than once (meaningless for flag affixes, but important for hit/dam/ac etc.). I like the idea of Sharp, *Sharp* and {{{**Sharp**}}} or something, to denote multiple applications of an affix. 
    106106 
    107 We also need to agree a strategy for the names of base objects for armour slots. Weapons are now all sorted (there are no prefix-like adjectives in weapon names, and no "of"s). But we are significantly limited in the kinds of affixes we can invent for Leather items, for example, because material adjectives would make no sense. And Mithril is already an affix for body armour (from Ey), but we still have Mithril shields/boots/gauntlets etc. IMO it should be an affix available for all armour pieces, but that means re-thinking the names of most base armour items. We could make Ethereal an affix, and Alchemist's. We could remove Elven Cloaks too and use Eleven as a cloak affix and not a weapon one. The whole issue of "Elvenkind" stuff needs some thought - at the moment it appears on all of base items (cloaks), affixes (swords, bows) and themes (body armour, boots - both different). There is also no reason why DSMs cannot be implemented as a base item with a "<colour> Dragon Scale" prefix. This way you could have other dragon scale armour items ... 
     107We also need to agree a strategy for the names of base objects for armour slots. Weapons are now all sorted (there are no prefix-like adjectives in weapon names, and no "of"s). But we are significantly limited in the kinds of affixes we can invent for Leather items, for example, because material adjectives would make no sense. And Mithril is already an affix for body armour (from Ey), but we still have Mithril shields/boots/gauntlets etc. IMO it should be an affix available for all armour pieces, but that means re-thinking the names of most base armour items. We could make Ethereal an affix, and Alchemist's. We could remove Elven Cloaks too and use Elven as a cloak affix and not a weapon one. The whole issue of "Elvenkind" stuff needs some thought - at the moment it appears on all of base items (cloaks), affixes (swords, bows) and themes (body armour, boots - both different). There is also no reason why DSMs cannot be implemented as a base item with a "<colour> Dragon Scale" prefix. This way you could have other dragon scale armour items ... 
    108108 
    109109=== Randarts and randomness === 
     
    118118 
    119119=== Balancing === 
    120 Finally, of course, there's a ton of balancing tweaking to be done. Some affixes are available on items which weren't before (e.g. of Warding), and others aren't (e.g. of Dweomercraft), purely because of what I was testing when I added them. Doing this balancing means adjusting the stats code to record affix and theme indeces (it already records all the actual item info). I am quite happy for people to crawl all over ego_items.txt and ego_themes.txt and adjust all the T: lines, as I have not spent long checking what affixes are available on which items at which depth and affix level: mithril shields don't seem to be able to acquire any affixes at all!  
     120Finally, of course, there's a ton of balancing tweaking to be done. Some affixes are available on items which weren't before (e.g. of Warding), and others aren't (e.g. of Dweomercraft), purely because of what I was testing when I added them. Doing this balancing means adjusting the stats code to record affix and theme indices (it already records all the actual item info). I am quite happy for people to crawl all over ego_items.txt and ego_themes.txt and adjust all the T: lines, as I have not spent long checking what affixes are available on which items at which depth and affix level: mithril shields don't seem to be able to acquire any affixes at all!  
    121121 
    122122But please note that I *have* spent quite a long time ensuring that the themes are generatable with roughly the same relative rarity as their predecessor ego types, and any changes to the affix weightings on the A: lines need careful thought.