Changes between Version 1 and Version 2 of PvalHandling


Ignore:
Timestamp:
04/25/11 18:15:12 (8 years ago)
Author:
magnate
Comment:

Update post-#120 and #1404

Legend:

Unmodified
Added
Removed
Modified
  • PvalHandling

    v1 v2  
    22 
    33Do we persist with the concept of a pval representing the total effect on the object of its related flags? 
     4 
     5-- yes, we did. 
    46 
    57If we do, we need a function to rearrange pval flags and pvals during ego and randart creation, like 
     
    1416   - if so, put flag on a new pval and increment it, and remove it from other pvals[[BR]] 
    1517   - if not, work out what its new value should be and add/move it to the closest pval[[BR]] 
     18 
     19-- this is now object_add_pval in pval.c, and is called from ego_apply_magic. It will also be called from randart.c. It isn't necessary for standarts, because artifact pval details are copied wholesale, as artifact definitions are assumed to overwrite anything on the base item. N.B. #120 was completed first. 
    1620     
    1721This is currently impossible due to the way object_flags and object_pval_flags work, and can only be done once o_ptr->flags is canonical. But that's on the radar (see http://angband-dev.blogspot.com/2011/03/so-i-finally-managed-to-refactor.html), so this is possible. There are two other possibilities though (and maybe more):