Changes between Version 24 and Version 25 of NewEgos


Ignore:
Timestamp:
11/04/11 10:42:16 (8 years ago)
Author:
magnate
Comment:

Update

Legend:

Unmodified
Added
Removed
Modified
  • NewEgos

    v24 v25  
    8989 
    9090=== Knowledge and ID === 
    91 Update: the ego knowledge menu now works properly, as does the object knowledge menu. We still need a new "theme knowledge" menu about themes - this is underway. An item's affixes are now listed in the 'I'nspect screen (this may or may not be desirable long-term, but is certainly useful for testing). Flavour text is also shown for all affixes. 
     91Update: the ego knowledge menu now works properly, as does the object knowledge menu. An item's affixes are now listed in the 'I'nspect screen (this may or may not be desirable long-term, but is certainly useful for testing). Flavour text is also shown for all affixes where it exists. 
     92 
     93Rune-based ID is now working, with a separate knowledge menu for known runes. Unknown runes will soon have random names (#1574), and both known and unknown runes will be listed on the Inspect screen. 
    9294 
    9395IMO 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 and fetch stuff. Interested in people's thoughts on this (and see also #1551). 
    9496 
    95 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. 
    96  
    9797=== Naming and base items === 
    98 We 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. 
    99  
    100 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 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 ... (lots more suggestions in http://angband.oook.cz/forum/showthread.php?t=5005) 
     98We 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. UPDATE: this is now the single most important outstanding issue. There is consensus that it is unrealistic to convey all information in the item's name, but no consensus on a naming hierarchy or categorisation. 
    10199 
    102100=== Randarts and randomness === 
     
    132130* affixes could change the display colour of an object (Ey has this, and fizzix thought of it too - #837) 
    133131* affixes could be used to generate ego jewelry, which allows re-thinking of what non-ego jewelry ought to be ... (it would be easy to regenerate the existing rings/amulets using affixes and themes, while enjoying the extra randomness) 
    134 * we should now seek to remove the INSTA_ART objects from object.txt. In fact I wonder if we can already just remove the flag, and leave the base items. Is there any need to remove the base items too? I guess this is related to the issue of ego jewelry above: currently a ring/amulet sval determines its properties (including artifact-ness), but that isn't necessary. 
    135132* allocation of kinds could use the alloc_entry struct (presumably it was written before that struct?) 
    136133* items with alloc_prob 0 should not appear in knowledge menus (the old Bronze DSM problem, now occurring with stuff like Adamantite Plate and Maces of Disruption) - not sure if this is related to fizzix's bug report 
    137 * speaking of Maces of Disruption, we can't currently generate Deathwreaker. It would be interesting to require artifacts to be generated from certain affixes, as well as from certain base items. i.e. You need a mace, with the Of Disruption affix, before you can generate Deathwreaker. 
    138134* should maxima really be sparse? z_info->e_max is set not as the number of e_info entries but the index of the highest. Is this necessary? 
    139135