Too darn many flags. :-(

[PaulBlay]

Messing about with the code on my probably doomed project I had to resort to splitting the object flags collection into four, instead of three, sets (as there were literally too many to fit into the three sets.

Needless to say this has left /* TODO */ comments and bugs spread liberally across the probject.

Anyway is there a better / more user/coder friendly way of handling all these object flags? C++ Bit fields looked promising, but I suppose Angband is too 'C pure' to handle them?

[Atarlost]

You could use lists instead of flags. It would dramatically increase memory usage and slow the game not to mention requiring you to rewrite all the object, player, and monster code, but it would be "nice and extensible".

This is what Langband would have done if it had ever been finished.

[PowerDiver]

Just wait on the obj flags. Sometime, hopefully soon, I will get some major changes into V, and a requisite was to rework the obj flags into a single enum. With luck you will be able to base on that and ignore the TR1/TR2/TR3 insanity by simply adding your new flags to the end of the list.

Real life intruded for a few months, but I will be back to the project any day now.

[Nick]

Just wait on the obj flags. Sometime, hopefully soon, I will get some major changes into V, and a requisite was to rework the obj flags into a single enum. With luck you will be able to base on that and ignore the TR1/TR2/TR3 insanity by simply adding your new flags to the end of the list.

OK, so I have just finished ripping all the TR* flags out of FAangband and replacing them with ... a new set of bit flags (which are mostly attached to actual objects, not just object kinds). My options appear to be:

1. Wait for V;
2. Do something similar myself or
3. Leave it as I have it now.

Eddie, can you give a rough outline of what you're planning?

[PowerDiver]

Eddie, can you give a rough outline of what you're planning?

I didn't want to break anything, so I just set up an enum with all of the flags in the same order. Then I added a table with flag properties, with enough info in it to do comparative squelching and to express when a particular flag is noticeable etc. Then, in the access routines, I put a pointer to the start of the flags, and use it as a general pointer to an array of chars storing bits, accessing individual bits in the obvious way.

So any old code accessing foo->flags2 & TR2_BAR still works, but all of my code looks like if (flag_is_on(&o_ptr->flags1, OBJ_FLAG_REGEN)) { ... } or at least it will, currently it says flag_extract which seems wrong to me somehow. Well, hopefully there is another level of indirection since I hope flags1 will go away. I have been separated from my angband development machine for some time. I did things quick and dirty, so everything needs to be rewritten cleanly now that I know how everything should fit together. Send me mail if you want my old dirty code as soon as I have access to it.

[Pete Mack]

This sounds like Flyweight Objects, is that right? It's a damn good idea on how to do flags.

http://en.wikipedia.org/wiki/Flyweight_pattern

EDIT: if you want to do programming in a serious way, the book Design Patterns is particularly useful. (It's generally on discount or available used.) And if you are planning on getting a job in software, it's non-optional.

[Nick]

Send me mail if you want my old dirty code as soon as I have access to it.

Thanks, but it looks like my changes are bigger than, and almost orthogonal to, yours (which look like the right thing to be doing). I'll take option 3 for now - I've already got enough big structural changes anyway.

[Magnate]

I didn't want to break anything, so I just set up an enum with all of the flags in the same order. Then I added a table with flag properties,

Hi Eddie - like Nick, I'm very interested in this, having started to mess with V's flags myself.

Did you do your changes off trunk (post r1285) or off 3.1.0beta? If the former, did you need to make any changes to slay_table? (Presumably not given that you left TR1 flags intact.) This was my solution to endless lists of

if flags1 & TR1_SLAY_FOO ...

... and I was going to do the same for RES_FOO ... but if you've set up a master table and code for extracting from it, I should probably wait to see what effect that has. I can probably do it from your new structure without needing separate tables, assuming the relevant string data can be incorporated.

[PowerDiver]

Hi Eddie - like Nick, I'm very interested in this, having started to mess with V's flags myself.

Did you do your changes off trunk (post r1285) or off 3.1.0beta? If the former, did you need to make any changes to slay_table? (Presumably not given that you left TR1 flags intact.) This was my solution to endless lists of

if flags1 & TR1_SLAY_FOO ...

... and I was going to do the same for RES_FOO ... but if you've set up a master table and code for extracting from it, I should probably wait to see what effect that has. I can probably do it from your new structure without needing separate tables, assuming the relevant string data can be incorporated.

What's a slay_table?

I started with 309, was just porting to r1224 when a family emergency got in the way.

Here's the entry in the table for the slay animal flag

{ OBJ_FLAG_SLAY_ANIMAL, FLAGCLASS_SLAY, ATT_NONE, 0, DAMAGE_EFFECT_DAM_BONUS_X1, RF3_ANIMAL, 0, PSEUDO_EXCELLENT, OBJ_OBV_NOT, OBVIOUS_FORMAT_NAME, "double damage vs animals" },

That's pretty inscrutable out of context, but shows the x2 multiplier as a bonus of damage * 1, and specifies a string for obj-info with a format type [some info needs to look at pvals etc]. The slay_animal flag is considered non-obvious, but there is a hook in my learning code [which I am not submitting at this time] from the damage routines to inform the player and learn the flag upon a hit on a monster matching RF3_ANIMAL.

This entry is also useful in object creation, where you could have an ego with a random slay, that looks through the table for items marked FLAGCLASS_SLAY, and might in addition worry about allowable damage effects if you want to keep executes separate from other slays.

It should also be easily upgradeable to O style [dam*.5 + 10] bonuses etc.

[Pete Mack]

@Eddie--
that slays table you've written is very nice.
Do you think it belongs in a .txt file? (as it is in ToME 3?)

Also, I did some quick-and-dirty analysis, and flyweights are a very good idea, so long as you reserve a slot in the object for random values. (You would need something like 400-500 flyweights, and they could be completely static.)