All items have a single type associated with them except gems (including skulls). Gems have the additional type2 column filled containing their quality level.
The bitset portion of this issue is simple: I've added support for this by creating additional factory methods within Type to create a new instance that is a logical oring of the bits from type and type2. I also took the time to optimize and return const references to all possibilities within the existing code (Cartesian product of gem types and gem quality). This will log an error in production or throw an assertion error if it doesn't exist to keep me in check.
The hard part, which I'm unsure of the repercussions, is to support checking the type2 entry when necessary. E.g., when checking if the weapon is throwable, only the type entry is checked. Or when checking for InvGfx, only the type entry is checked. Same deal with moving or equipping inventory items.
I don't anticipate this being an issue for the time being. I spot checked the code and all current use-cases are covered by just checking type entry. I'm not going to fix this until it needs to be fixed, which will probably involve resolving return values from both type and type2 into a value.
Obviously I don't know for sure how this is used, but it looks hacked onto the existing system for this specific use-case (applying gem quality and gem type to gem base items chipped ruby is type=ruby and type2=chipped)
All items have a single
typeassociated with them except gems (including skulls). Gems have the additionaltype2column filled containing their quality level.The bitset portion of this issue is simple: I've added support for this by creating additional factory methods within
Typeto create a new instance that is a logical oring of the bits fromtypeandtype2. I also took the time to optimize and return const references to all possibilities within the existing code (Cartesian product of gem types and gem quality). This will log an error in production or throw an assertion error if it doesn't exist to keep me in check.The hard part, which I'm unsure of the repercussions, is to support checking the
type2entry when necessary. E.g., when checking if the weapon is throwable, only thetypeentry is checked. Or when checking forInvGfx, only thetypeentry is checked. Same deal with moving or equipping inventory items.I don't anticipate this being an issue for the time being. I spot checked the code and all current use-cases are covered by just checking
typeentry. I'm not going to fix this until it needs to be fixed, which will probably involve resolving return values from bothtypeandtype2into a value.Obviously I don't know for sure how this is used, but it looks hacked onto the existing system for this specific use-case (applying gem quality and gem type to gem base items
chipped ruby is type=ruby and type2=chipped)