[CF-Devel] questions about new skill object

Fri Sep 19 00:01:44 CDT 2003

Andreas Vogl wrote:
>

      Hi,

     >

     >

      This is all about the new skills.

     >

      I like the new skill system very much. Great work.

  Thanks.

>

     >

      While I was trying to update the "types.xml" for the CFJavaEditor,

     >

      some things about the SKILL object type (43) were unclear to me,

     >

      so I'd like to ask...

     >

     >

      1. "name" vs. "skill" attribute:

     >

         According to the documentation, those two strings should or

     >

         must be identical. They are used for skill matchings.

     >

     >

         I think having the two of them may simplify code, but it's quite

     >

         irritating for arch-builders and mapmakers.

     >

         Taking a glance at the code, it seems like most (/all?) of the

     >

         matchings are applied to the "skill" attribute and not the object name.

     >

         I think it would be worthwile to define only one attribute as

     >

         responsible for matchings. For example "skill" is for matchings,

     >

         and "name" doesn't matter. This can prevent errors too.

  I agree.  I'm actually not sure if there are any cases where there are any 
cases where we look at the skill name, other than when naming objects (eg, 
scroll of literacy).  I'm trying to remember why I did it that way.   In any 
case, if there are cases where op->skill is being against op->name, that is 
probably a bug that should be fixed.

>

     >

      2. "subtype" attribute:

     >

         This one seems to define the base functionality of the skill.

     >

         It is the "link" between skill archtype and skill functions in

     >

         the server, AFAIK.

     >

     >

         What I would have expected from this, is that I can define for example

     >

         three different literacy skills - each with literacy subtype, but

     >

         different stats. However, it turned out the server seems to

     >

         require that each subtype appears only once in one skill archtype.

     >

     >

         That's no problem, but I would like to know:

     >

         Why is this attribute in the arches at all? There seems to be no

     >

         additional information contained in it. The skill names are already

     >

         unique. The server code could just as well use the skill names

     >

         to identify skills, couldn't it?

     >

         Or the other way round: subtype could be used for all matchings,

     >

         and we don't need skill names. (The JavaEditor can associate subtype

     >

         numbers with names, so readability shouldn't be of concern.)

  Well, the idea of having multiple skills of the same subtype was something I 
wanted to allow for.  Thus, you can have 'beginning literacy' for example, which 
doesn't give you a bunch of bonuses or something, and go on some quest and get 
'expert literacy' which gives something extra.

  And I believe you can actually do this.  The problem is having multiple 
varieties of the same skill in the archetype.  The problem is that there are 
some cases in the code where we need to say 'hey, the player doesn't have skill 
lockpicking, and we need to give it to them.  So it then finds the skill 
lockpicking and gives it to the player.

  Where this comes up is in the case of skill tools (lockpicks, talismans, might 
be some others I'm forgetting).  Basically, the player is able to use and gain 
exp in the skill by getting that item, but isn't a skill they really have.

  Probably the right way to do this is put a flag or something in the archetype 
which says 'use this skill when we need to give them the skill in that case'. 
Thus, you could have multiple lock picking skills in the archetype.

  However, looking at the code, I notice the learn_skill just looks at the 
scroll->skill pointer - it should probably do something more like spells at look 
at the object inside the scroll and give that out.

  Also, there would be some trickery involved - I'd think that if you have 
different skills that do the same thing (eg, lockpicking and 'master 
lockpicking' for example), you'd have to know which is the one that is the 
better skill.  Eg, if you have lockpicking, and learn master lockpicking, that 
should basically replace the other skill (copying over exp and other bits).  If 
you have master lockpicking and try to learn lockpicking, it should say 
something like 'hey, you already know master lockpicking'.

>

     >

      3. double meaning of "exp" and "level":

     >

         When I understood the documentation correctly, the meaning of the

     >

         "exp" and "level" attributes is different depending on wether

     >

         the object is a default arch, or a map object.

     >

         Is this true?

  There is a difference in it being an arch and actual in use object.  In 
retrospect, probably not a good idea for many reasons.

  Basically, the archetype is determined how the reward works out for using the 
skill.  This unfortunately means that that if you want to make new varieties of 
skills, you would need an archetype, and see problem above.

  I really should have tossed those values into the object.

>

     >

         When I take a default skill arch and put it into the inventory

     >

         of a monster, does the meaning of exp and level suddenly

     >

         change? Do I not even need to correct the values then?

     >

         Or maybe the meaning won't change as long as I don't

     >

         edit the values on the map... uh oh.   

     >

     >

         If this is the case, I would strongly advise to split the

     >

         different meanings into different variables.

     >

         I wouln't even know how I can explain such a double-behaviour

     >

         in the JavaEditor without really confusing people.

  skills for monsters work a little bit differently - they don't always need 
skills.  But yeah, it should work more sanely.  I'll see about cleaning some of 
that up.

  Some was probably left behind since in some sense as it started out, it was to 
some extent a conversion of the older skill code, which didn't really have 
anything adjustable a an object level, so tossing it into the archetype didn't 
seem like a really bad idea at the time.

  I'd be interested in hearing on what plans people have for the skills, as it 
may make it easier to know what to design for.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel