tchize wrote: > I will suggest the following. adapt the collect script so it will notice line > in the form > smoothface XXXXX YYYYYY > rip it away from object and put a line in lib/smooth in the form > XXXXX YYYYYY That looks good. > Since some objects have animations, i think the script should be able to read > several time the smoothface instruction from one object. That also seems fine. > The counter part would be, if i put the same > smoothface XXX YYY > in two different files, or i write in 2 different files > smoothface XXX YYY > and smoothface XXX ZZZ > The pic the server will choose to smooth XXX (either YYY or ZZZ), will be > choosen randmoly according the the behaviour of the bsearch instruction on > the system (no duplicata detection). Should look at some of the code in the collect.pl that deals with things like the magicmap fields. It does duplicate detection, and prints an error. After all, a case like: smoothface XXX YYY in one file, and the same entry in another file is perfectly fine. It is only a problem if there is then a: smoothface XXX ZZZ but those are easy to detect. The collect script should just throw out the duplicate (after logging an error). The person runing collect should really notice that error and fix it. Much easier to actually have error checking so that developers can more easily find these errors. > > One last note, the smoothface instruction would be interpreted ONLY by > collect.pl, server will still rely on the lib/smooth file to get it's > instructions. It won't be possible to change the smoothface for an object (i > never intended to do it since it would consume to many bandwidth for now) Yep, that is fine, and just like some of the existing fields. > > Does this way conform to crossfire standards (info will be located in object's > .arc file, lib/smooth would be generated at the same time as the archetype > and face files, and it would be possible to have several smoothface entries > concerning the different faces involved in an archetype.) It all looks fine to me. _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel