Version 1 (modified by magnate, 9 years ago) (diff)

first draft

Ok, #1404 has thrown up an interesting dilemma:

Do we persist with the concept of a pval representing the total effect on the object of its related flags?

If we do, we need a function to rearrange pval flags and pvals during ego and randart creation, like

add_pval(object_type *o_ptr, int pval, int flag)

which needs to:

  • check if flag is already on the object
    • if so, check if other flags are associated with the same pval
      • if not, increment it and return
  • check MAX_PVALS to see if we can create a new one
    • if so, put flag on a new pval and increment it, and remove it from other pvals
    • if not, work out what its new value should be and add/move it to the closest pval

This 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):

  1. 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.
  1. 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).

Grateful for any comments.