[CF-Devel] 'type', stuff like that

[crossfire-devel at archives.real-time.com]

Nicolas Weeger wrote:
>
     
      I was thinking of tweaking server code to be able to write 'type KEY' in 
     
     >
     
      archetypes, to make it easier to remember stuff (could be expanded to 
     
     >
     
      other things, too).
     
     >
     
     
     >
     
      But then I found another idea: instead of tweaking the server code, what 
     
     >
     
      about changing the 'collect.pl' script to do the substitution when 
     
     >
     
      collecting archs? Instead of dumbly merging files, it could substitute 
     
     >
     
      'type KEY' to 'type whatever the value>'.
     
     >
     
      This could be expanded to other types, hard to remember without checking 
     
     >
     
      code.
     
     >
     
     
     >
     
      Only thing I see is, editor collects archs too, my idea would require 
     
     >
     
      tweaking it too, probably...
     
     
  And the editor would have to write out the archetypes in number form also, and 
not string form.

  Personally, if I were to do this, I'd do something like:

static char *type_names[LAST_ITEM_TYPE] = {
NULL,
"player",
NULL,
"rod",
"treasure",
....

}

  And then have some simple code in the loader - at the ^type check, do a simple 
check to see if the type is numeric, if so, simple assignment, if not, just a 
simple for loop to look through the type_names.

  The nice thing is that this makes it really easy to save the values - for 
times you want the type names saved, it is just a simple line like:

fprintf(outfile,"type %s\n", type_names[op->type]);

  Or the like.

  But as said before, the type names in archetypes never seems like that big a 
deal to me - pretty much, just based on the directory the archetype is in, or 
other context, you can pretty much know the context.  And even if it was 
confusiong, you could do something like:

# type 38 is a gravestone
type 38
...


  As said before, the ones I find really confusing are any of the bitmasks in 
which the bitmask is already calculated (attacktypes and spell paths).  And for 
those, certainly having the collect script parse those could make sense.  Not 
positive, but many not cause as many problems with the java editor either, 
because it would see something like:

attacktype fire|magic

  And just leave that data alone - it would be opaque.  In comparison, the 
editor would have to know how to parse the actual things like 'type rod', 
because it needs that info to know what template to bring up when setting the 
object attributes.

  One problem with it being in the collect script is also potential confusion - 
eg, player adds a new type, and now has to know/fix the collect script for his 
archetypes to work.  This might be a little confusing, vs the type names 
actually being defined in the code.

  At least for myself, I'd expect the load processing/conversion to be handled 
by the loader code, and thus would go there to look and make changes.


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel