Changes between Initial Version and Version 1 of PvalHandling

04/22/11 15:43:40 (9 years ago)

first draft


  • PvalHandling

    v1 v1  
     1Ok, #1404 has thrown up an interesting dilemma:  
     3Do we persist with the concept of a pval representing the total effect on the object of its related flags? 
     5If we do, we need a function to rearrange pval flags and pvals during ego and randart creation, like 
     7add_pval(object_type *o_ptr, int pval, int flag) 
     9which needs to:[[BR]] 
     10 - check if flag is already on the object[[BR]] 
     11   - if so, check if other flags are associated with the same pval[[BR]] 
     12     - if not, increment it and return[[BR]] 
     13 - check MAX_PVALS to see if we can create a new one[[BR]] 
     14   - if so, put flag on a new pval and increment it, and remove it from other pvals[[BR]] 
     15   - if not, work out what its new value should be and add/move it to the closest pval[[BR]] 
     17This 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, so this is possible. There are two other possibilities though (and maybe more):  
     191. Eddie suggested that pvals should always be +1, +2, +4 and flags assigned to them to create any value from +1 to +7. With a fourth pval this would cater for up to +15. This would make the add_pval function simpler, but it still can't be done until object_flags is fixed. Theoretically this gets us 15 possible pvals for the space of four, but lots of object display code would need rewriting. 
     212. FA does away with pval_flags altogether and uses an array for all granular flags. Going down this route means either making o_ptr->flags an array of bytes, or making a total separation between pval flags and binary flags. I would definitely favour the first, if only I understood the ramifications for all the bitflag manipulations (of which there are hundreds). 
     23Grateful for any comments.