[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