Le Mardi 17 Janvier 2006 08:00, Mark Wedel a écrit : > Yann Chachkoff wrote: > > > > > Well, it really depends on what the C code requires as dependencies - the > > Python plugin has one with the python libs for example. But stuff that was > > initially in the server code would have no such external dependencies indeed. > > True. I imagine dependencies to be fairly standard C dependencies. But I > could imagine someone writing a plugin in C++ with appropriate wrappers. > > > > > On the other hand, I think splitting the code in "logical entities", more or > > less independent of the others, would be a path of thinking to try. As such, > > random maps would appear as a good target for modularization, since it > > doesn't really depend on anything else, apart from very basical operations, > > and is called only at a few places. Alchemy would be another good candidate - > > both are very important in the game, yet are working very much like "black > > boxes" - complex code with relatively limited interactions with the rest of > > the code. > > Agree. And in fact, any object that does something 'interesting' when applied > could be a plugin, since most such objects are also very well self contained. > > However, I'd counter that if it is just 20 lines of C code to do that > 'whatever', it could be more convenient to just add that 20 lines to apply.c > > I say this because I imagine plugins would probably be organized by > plugin/C/<plugin_name>. Maybe have one directory for basic plugins (one in > which the entier plugin is in one file). But if plugin grows to the extent that > there are 50 'trivial' plugins, one could say finding the code there isn't any > more convenient than having it sit in apply.c
Nothing would prevent all those 'basic plugins' to be gathered together. eg all kind of current exit in a module along with walls, grounds, name this module 'basicLayout' anotherone for movment stuffs another module regrouping monster stuffs anotherone for all kind of traps ... Common lifecycle is 'add new feature in existing code, when it becomes lots of line, move it to it's own module', unless of course you know from the start it will contain lots of code ;) > > > > >> I'd think that if there is a C plugin, aside from the different passing in > >> of the values, and using appropriate callbacks for functions instead of > >> calling > > them directly, it could access the function data directly? Eg, it should need > > to do a plugin callback to set the dam of an object, it could just set > > ob->dam? > > > > Theorically, yes: there's nothing preventing such a thing. Wrapping such > > access behind functions was basically to allow checking that the values > > passed were in the correct range, and to provide encapsulation of the data > > (so that a plugin wouldn't get tempted to directly change fields it wasn't > > supposed to change without a high risk) > > I'd imagine it is more important for the plugin wrapper to provide a > consistent interface to the various functions, so that if a function handling > changes in the C code (say a function now takes another argument), that all the > plugins don't have to be rewritten - they can keep using the existing code, with > the wrapper just passing in some default value. principles of methods polymorphism in object oriented programming ;) > > > > > Sure ! But I think such changes would be easier to make if the code was, in a > > way or another, "split" into smaller entities, so that they affect only a > > limited part of it. And indeed, a lot of functions would benefit from some > > in-depth rebuilding. Also, part of the problems of code debugging/maintenance > > come to how things are distributed all around the code - finding where to > > add/change things is a rather complex task. Making small changes to make the > > code more "readable" and "editable" would thus be another important point to > > achieve, IMHO. > > True - some functions have grown a bit in complexity and could certainly use a > rewrite. And I could envision doing some things as plugins would make some > things easier/more modular (Going back to what someone said, objects that the > player uses are complicated - need to update the apply code, but depending on > the object, may also need to update the code that actually describes the item - > I could see with appropriate plugin support, all that could be done in the > plugin, so all code related to that object is in one place) Well you put the finger on it. Adding a new object is generally adding a 2 lines code to apply which calls myObjectType_apply(). and same to describe, sometimes, also for some same to move_object(). Damn this looks to me like the pattern of registering listeners to some events :D > > > > _______________________________________________ > crossfire mailing list > [email protected] > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- David Delbecq Royal Meteorological Institute of Belgium - Pingouins dans les champs, hiver méchant _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
