Re: [crossfire] 2.0 object-type refactoring
Alex Schultz wrote: For a while now I've been throwing the idea of separating the server's object-type-specific code by object types. Currently things are rather disorganized with code for how an object type works being spread all around the code. I plan to begin to implement the plan on the following wiki page soon if nobody has any objections: /http://wiki.metalforge.net/doku.php/dev_todo:refactor/ Also, would be nice for some others to help a bit once it's started :) Just a note, since my original mailing list posting, made a small revision to the page/plan based on IRC discussion. http://wiki.metalforge.net/doku.php/dev_todo:refactor?rev=1162054825do=diff Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Client-side scripting
Just a thought, I'm thinking that perhaps the LUA patch should be put in trunk for 2.x but not in 1.x. Also, to me it would make a bit of sense to also remove the current scripting system in 2.x in favor of that provided that the LUA engine can be supported on all platforms and is built-in. While the old scripting system is nice, I would say it is somewhat unintuitive and perhaps not worth keeping in 2.x if the LUA engine is built-in. Fine for me to put in 2.x (aka trunk) and add a --with-lua configure switch (but I'll need some wizard's help ;p). Removing existing scripting, well, I'm not too eager, I think people are used to it... Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Client-side scripting
On 10/29/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: ... Removing existing scripting, well, I'm not too eager, I think people are used to it... I have a strange feeling that this might evolve into a plugin system. :-/ -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 object-type refactoring
Few questions: Use form of server/types/foo.c or server/types/foo/bar.c depending on if the object type requires multiple C files to be clean. With the fact that the SVN repository is called server, it is unclear exactly what server refers to. If we include the repository name, is it: server/server/types server/common (example of existing directory) Or server/types common/ (being the exististing directory) IMO, I'd prefer the second form - put the types directory at the top level, relative to the server directory. This is how the socket code is, doesn't have any real disadvantage, but could have some advantages (better for unit tests? Better for stand alone program that does simulations, etc?) Function pointers: It's not specifically mentioned on how the callbacks are registed. I see one of two ways: register_apply_callback(type, funcpointer); or register_callback(type, funcpointer, callback_type) Both have pros and cons. The first case has the advantage that the compiler can do actual type checking on funcpointer. The second has the advantage you don't need as many callback functions, and it makes it easier to add new callbacks (add the new callback_type #define, update the number of callback types, and recompile. One could even do things like: callbacks[ob-type][CALLBACK_TYPE]() It's also not really mentioned on how the callbacks themselves are registered (that code has to be someplace). And rather than having a single function that registers all the callbacks for all the object types, I'd suggest that each type file has something like init_callbacks_weapons (or something). Then in some other place, you have that function that calls all the init_callbacks - having a function of MAX_TYPES lines longer is much better than one of MAX_TYPES * MAX_CALLBACK_METHODS lines long. The other advantage of this is that the individual types files themselves can then declare all the functions except the init function static, so that it can't be called by other functions. I suppose that one could use various system function calls to try and look up the function names and call them (presuming a standard naming scheme, like init_callbacks_46, where 46 is the type number for that object), but that may be overly complicating things. Other thoughts: It may be better working on getting all of this infrastructure/callback methods in place, and implementing one type of object using them instead of focusing on the specific callback method (the web page mentioned doing all the apply stuff). Why? That way, if someone does write code for a new object type, all the pieces are in place so they can use the new method. If only the apply callback is implemented, they can use that logic, but are left using old coding method for the other areas, that then needs to be converted down the road. Also, by doing all the different callback methods, it provides better coverage of the callback logic, eg, if there are issues with any of the methods, they will be found sooner vs later. Second, if we're going to be writing all new functions, we should use some other 'best practices'. In particular, for anything that would return a string value, they should be modified so that a string pointer (and length of that pointer) is passed in, instead of using static return buffers. This will assist if we ever thread the server, but it will also help prevent a few bugs (related to this, sprintf, strcat, and strcpy should never be used, but rather snprintf, strncat, and strncpy instead) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 object-type refactoring
Mark Wedel wrote: snip IMO, I'd prefer the second form - put the types directory at the top level, relative to the server directory. This is how the socket code is, doesn't have any real disadvantage, but could have some advantages (better for unit tests? Better for stand alone program that does simulations, etc?) I was originally thinking of as a subdirectory of the server directory as in the first form, but now that I think of it, what you suggest I think is a bit better. Function pointers: It's not specifically mentioned on how the callbacks are registed. I see one of two ways: register_apply_callback(type, funcpointer); or register_callback(type, funcpointer, callback_type) snip I'm currently thinking of using the first form, largely so it matches what I plan on using for calling the callback itself. I decided on using ob_apply() ob_drop() instead of my old idea of cf_method(ob, type, ...) primarily due to compiler type checking. It's also not really mentioned on how the callbacks themselves are registered (that code has to be someplace). And rather than having a single function that registers all the callbacks for all the object types, I'd suggest that each type file has something like init_callbacks_weapons (or something). Then in some other place, you have that function that calls all the init_callbacks - having a function of MAX_TYPES lines longer is much better than one of MAX_TYPES * MAX_CALLBACK_METHODS lines long. Yes, that makes sense and was my original plan to use such init functions. Good idea with how everything except the init could be static, that is a nice bonus I didn't think of. snip Other thoughts: It may be better working on getting all of this infrastructure/callback methods in place, and implementing one type of object using them instead of focusing on the specific callback method (the web page mentioned doing all the apply stuff). Why? That way, if someone does write code for a new object type, all the pieces are in place so they can use the new method. If only the apply callback is implemented, they can use that logic, but are left using old coding method for the other areas, that then needs to be converted down the road. Also, by doing all the different callback methods, it provides better coverage of the callback logic, eg, if there are issues with any of the methods, they will be found sooner vs later. Well, my original thinking, was that if I were to do it by completing an object type, instead of a callback type, then it would be somewhat of a pain to make it redirect to legacy methods for other object types not yet implemented in the new system. What's your view on that issue? Second, if we're going to be writing all new functions, we should use some other 'best practices'. In particular, for anything that would return a string value, they should be modified so that a string pointer (and length of that pointer) is passed in, instead of using static return buffers. This will assist if we ever thread the server, but it will also help prevent a few bugs (related to this, sprintf, strcat, and strcpy should never be used, but rather snprintf, strncat, and strncpy instead) Well, I wouldn't say necessarily writing all new functions: I believe some existing functions can be tweaked fairly easily to fit into the new system. However I believe that when moving functions that map well over, we should hand review them anyways, and perhaps use a checklist of things such as those issues you mention like avoiding static buffer returns. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
