Nicolas Weeger | 18 Jan 2012 23:26
Favicon

Patch proposal: unidentified generic faces

Hello.

I've been playing with having items hide their "real" face unless they are 
identified.

So for instance potions would keep their generic face when not identified.

Here's a patch that makes that behaviour.

Right now it's only the face (and animation-related parameters), but I was 
thinking of doing that for the name too. So eg unidentified skill scrolls could 
have a generic blank face and name until they are identified.

Would that behaviour change be ok?

The code relies on key-values containing "identified" properties (see 
common/item.c:object_give_identified_properties for more details).

Regards

Nicolas
--

-- 
Mon p'tit coin du web - http://nicolas.weeger.org
Attachment (faces-identify.patch): text/x-patch, 5330 bytes
_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire
(Continue reading)

Mark Wedel | 19 Jan 2012 07:56
Favicon

Re: Patch proposal: unidentified generic faces

On 01/18/12 02:26 PM, Nicolas Weeger wrote:
> Hello.
>
>
> I've been playing with having items hide their "real" face unless they are
> identified.
>
> So for instance potions would keep their generic face when not identified.

  In the distant past, potions used to work that way - generic face until 
identified.

>
>
> Here's a patch that makes that behaviour.
>
>
> Right now it's only the face (and animation-related parameters), but I was
> thinking of doing that for the name too. So eg unidentified skill scrolls could
> have a generic blank face and name until they are identified.

  Yes - this makes sense.  Using key/value or other abstraction vs coding in 
those values makes a lot more sense.  I suspect that is the reason that skill 
scrolls do not work that way - when they were put in, the code was not modified 
to hide their names.

>
>
> Would that behaviour change be ok?

(Continue reading)

Otto J. Makela | 19 Jan 2012 12:01
Picon
Picon
Favicon

Re: Patch proposal: unidentified generic faces

On 2012-01-19 08:56, Mark Wedel wrote:

>> The code relies on key-values containing "identified" properties (see
>> common/item.c:object_give_identified_properties for more details).
> 
>  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.

I've been meaning to ask for an addition to the "drop" command
(which already has provisions for "all", "cursed", "unpaid" and some
similar group properties) to have "identified" and "unidentified"
added to the possible groups lists.

For symmetry, the "take" command should also have similar properties,
I tried and it doesn't even seem to recognize "all" in current versions.

And the online documentation (given with "help drop", "help pick" etc)
should be expanded to explain this.

Maybe the identified/unidentified status should be given more thought,
it seems a bit strange to have no need to identify jewels but that the
jewelry skill is required specifically for gold nuggets?

Currently there are a few things (gold nuggets, lock picks, bottles...)
which will fetch more money in the store when identified, but for which
neither the face nor seemingly the functionality change when id'd.

Zathras: Yes, yes, Zathras is used to being beast of burden to other
  people's needs. Very sad life. Probably have very sad death, but at
(Continue reading)

Nicolas Weeger | 21 Jan 2012 09:13
Favicon

Re: Patch proposal: unidentified generic faces

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

Regards

Nicolas
--

-- 
Mon p'tit coin du web - http://nicolas.weeger.org
_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire
Mark Wedel | 23 Jan 2012 08:12
Favicon

Re: Patch proposal: unidentified generic faces

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 
(Continue reading)

Nicolas Weeger | 28 Jan 2012 12:47
Favicon

Re: Patch proposal: unidentified generic faces

Hello.

I've committed the patch.

Regards

Nicolas
--

-- 
Mon p'tit coin du web - http://nicolas.weeger.org
_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire
Nicolas Weeger | 28 Jan 2012 14:25
Favicon

Re: Patch proposal: unidentified generic faces

Hello.

I've also changed various scrolls' properties (skill scrolls, improve weapon 
and enchant armor) so they are regular scrolls by default.

I removed their "identified 1" line.

This probably means some maps in which those scrolls appear and should be 
identified will need updating (adding the "identified 1" in the map should do 
the trick).

Regards

Nicolas
--

-- 
Mon p'tit coin du web - http://nicolas.weeger.org
_______________________________________________
crossfire mailing list
crossfire@...
http://mailman.metalforge.org/mailman/listinfo/crossfire

Gmane