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

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

>
     
       And the editor would have to write out the archetypes in number form 
     
     >
     
      also, and not string form.
     
     
Editor would just need to know how to load strings, but would save 
number. Note that editor already has some idea of item's type, it 
displays the numerical & string type in the status bar.

>
     
       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.
     
     
Yep, pretty easy. Though my idea of letting the collect script do it was 
to not impact (wouldn't prolly matter, in any case) server loading time.
Also wouldn't require server change at all, since conversion would be 
handled by collect.pl

>
     
       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.
     
     
I don't know what would be the point of saving the values in string, 
though, at least as far as game is concerned. But yes, that'd make it 
easy. I'd just add a check to print a warning if NULL type :)

>
     
       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
     
     >
     
      ...
     
     
True, but first you'd have to know the actual type. If someone were to 
parse archetypes to find something, s/he'd need to remember or check the 
type's meaning.
And it's neatier to see 'type GRAVESTONE' instead of '# type 38 is 
gravestone - type 38' everywhere ^_-

>
     
       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.
     
     
That's also why I was thinking of modifying the collect scipt. Since 
it's in perl, pretty easy to handle strings - that's what perl was 
designed for, I guess :)

>
     
       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.
     
     
Given the format of the define.h file, and others which contain some 
defines, I don't think it would be that hard to add a small parsing from 
collect to gather values/number pairs - but it would make collect.pl 
more than a simple & dumb collect tool.

>
     
       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.
     
     
I'll just add a small comment in define.h to say stuff will be parsed :)

I guess it basically depends on what we think is best, or more natural.
And my proposal extends to attacktypes, of course, and other numerical 
fields which could be hard to understand.

Nicolas

Nicolas

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