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

crossfire-devel at archives.real-time.com crossfire-devel at archives.real-time.com
Thu Apr 8 02:15:08 CDT 2004


Nicolas Weeger wrote:
>
     
     
     >
     
     
     >
     
      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
     
     
  Yeah, the time difference is likely very trivial.  On each object, it would be 
some overhead.  However, most objects on maps don't change the type field, so 
it'd only really be a bigger hit on the archetype processing.

  My one concern about it being the collect script is that developers would need 
to know to updated it.


>
     
     
     >
     
      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 :)
     
     
  In most cases, not much.

  But for player save files, or perhaps unique maps, it could be very handy to 
have a more readable form of what is actually saved than seeing something is 
'type 27', and then having to look up what type 27 is.  But as said, object type 
tends not to get changed too often, so probably not that big an issue.

  The other advantage of having an array of the type->name mapping is that it 
would be useful for debugging.  Eg, one might dump the object structure in the 
debugger and see it is type 18.  Now instead of having to look at what object 18 
is, I could do something like 'print type_names[18]' and get my answer more 
immediately.



>
     
      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 ^_-
     
     
  certainly true.  But not positive how big an issue it is.  If personally not 
found it much an issue, but I'm just one person.




>
     
      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.
     
     
  I'd certainly prefer for it to be in the actual C code - that seems more 
logical, and also provides a way to save it - for things like spellpaths and 
attacktypes, it could be very handy to look at those values in the save file/maps.


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


More information about the crossfire mailing list