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