On 01/21/12 12:13 AM, Nicolas Weeger wrote:
Is the way you see doing this is that the archetype contains the
unidentified values? I'm just curious as to how the unidentified
name/face is determined.
If I implement like the patch suggests, the archetype will contain in the
"name", "face" and "animation" fields the unidentified values. And there will be
keys for "identified_name", "identified_face", "identified_animation" (and
related values like speed).
The "object_give_identified_properties()" function, called from "identify()"
and some other places, would ensure those "identified_" values are copied over
to the item when needed.
So we'd alter archetypes to be unidentified by default.
That sounds like it would work out fine.
I didn't look at things closely, but one thing I would suggest would be
identified/unidentified entries for value of the object. Right now, I believe
the code just says unidentified value is some percentage of base archetype
value, which I don't think is great.
The complication here is that when an item is granted additional properties
(for example, pluses added to the sword), the treasure code uses the base value
to determine the new value, and stores that new value away (in ob->value) - so
to rework that is a bit more effort, so a simpler thing may just to add an
'unidentified_value' to the archetype, and the code can just use that when asked
for price.
Another reason to have values coded in is if one is really trying to obscure
the object, one needs to obscure the value. Otherwise, in the example of
potions where the face is the same, one could get the estimated price of two
unidentified potions, and get different values, and potentially be able to
figure out what the potion is from the value given. If the character has no
idea what they are, then they should get the same value for all potions.
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
