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
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.
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)
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
