ToME WikiKhymChanur: For some items, a simple ID should learn some or all of its flags. For instance, if you ID a Ring of Speed, it that should tell you what the speed flags are, but if you idnetify an artifact, it should take an *ID* to learn what the speed flags are. This could be taken care of by having a LEARN_ON_ID flag, which would be a flagset of flags to be learned on ID.
There are also some flags that should be learned when an item is worn. Wearing a Ring of Speed should tell you what the speed increase is, since you can feel how much the speed boost is. This can be taken care of by a LEARN_ON_WEAR flag. But we might want to be able to list some flags that are always learned when the item is worn, like speed, so we don't have to repeat it for each item/ego defintion. So we could have a learn_flag_on_wear() function to register flags which should be learned when worn.
NeilStevens: Do it in a module first, I say. That way lies Nethack.
KhymChanur: Okay, the learning-on-wearing thing is Nethackish, but what about the learn-on-id? The way things are right now, you have to do an *ID* on a Ring of Speed to learn what its speed modifiers are, but a simple regular ID should give you info like that.
NeilStevens: Make the speed bonus of a speed ring an obvious flag then, if that's what you want.
KhymChanur: I tried that, and that makes it so that, once one Ring of Speed is identified, the speed is automatically known for all Rings of Speed, even if its lying on the ground and hasn't been identified.
NeilStevens: Oops, right. What we need then is a semi-obvious flag settings, for lack of a better name, to make a distinction between powers that need identified, and the old 'hidden powers' that need *identified* like Angband has.
KhymChanur: We could make a FLAG_FLAG_ID_LEARN, or something, but that would require changing the flags field of flag_node from byte to u16b, since all 8 bits are already occupied by the existing FLAG_FLAG_FOO definitions.
NeilStevens: That's not how obvious flags work. After reading engine/info.lua, and doing a lot of grepping, I've found that the obvious flags appear to be implemented by taking a lua tagging feature and using it for our own purposes. We just need a semi_obvious() and corresponding TAG_SEMI_OBVIOUS to follow that model, right?
Semi-obvious flags would be automatically learned on identify, just as obvious flags are learned on creation.
Another thought: Alternately, if you do go with your list-of-flags option, I think it'd make sense to convert the existing obvious flags system to use it as well, so that we get some consistency in the way we item list writers specify obvious, semi-obvious, and hidden flags.
KhymChanur: Yes, it uses the Lua tag system, but as an intermediary step: first it tags, then it uses TAG_OBVIOUS to decide if it should call flag_learn() and flag_learn_all(). In grab_flags():
if tag(vv) == TAG_OBVIOUS then
obvious = true
vv = vv.val
end
...
if obvious then flag_learn(flags, ff, true) end
So even if we use the tag system, we still have to have a way to store the information into the object's flags.
NeilStevens: Well, I would say go with your original idea then, adding a LEARN_ON_IDENTIFY flag. But, please also add a LEARN_AUTOMATICALLY flag to replace the obvious flag system. thanks!
DarkGod: beware, obvious() works EVERYWHERE, that is even in flags embeded in flagsets embeded in flagsets, a LEARN_ON_* flagset system needs to be as flexible. It seems it will be a chore to maintain the info files this way though .. what about a new parameter to obvious() that sets when it is obvious(basically filling the LEARN_ON_* sets automatically)?
Orvin: Maybe, the chance that you learn a flag on IDing should depend on how often you have seen that flag before? So, if you have had in your inventory many speed rings with known pluses, maybe it should be easier for you to learn the plus of an unidentified speed ring.