David Delbecq wrote:
This gets especially messy if say 10 object types are complex enough that
they
really should be in their own module. So now you have those 10 separate
modules
+ common module for other 90 types. This then starts to get away from
making
things easy to find (is it in the common module, or one of those other 10)
Let's say i've got a problem with a buggy trap. This is how i see it:
1) i do a 'dump' in dm mode to get info on buggy archetype. Server says me
type xyz (the trape type) and maybe also in the dump the is a list of plugins
linked to this object.
2) i go in the code of this (or those) module and start trying to fix the
bug :)
(please note, currently to fix an object, the procedure is something like dm
-> get type -> open define.h -> get the associated #TYPE for this type ->
issue a grep on this type to find where there is specific code.)
Well, one could change that behavior without resulting to plugins - to give
meaningful names to object types just requires an array that has the names.
And for everyone out there currently using grep - download cscope and use that
- it is a vastly superior solution (even going to plugins or whatever else,
cscope is a very handy tool - just run 'cscope -R' in the top level directory.
Also, having a simple document of which module does what would be
interresting. It's easy to manage (a module X -> description chapter and a
item type -> module chapter)
But that sort of sidesteps the point, doesn't it? Isn't one of the issues
right now that code is hard to find? If we have to document the new code, that
doesn't seem to be going in the right direction - for that matter, a document
could be written right now of 'these are steps to do to make a new object'.
While current code isn't particularly well organized, at the same time, it is
only in a few files, so it is not like you have to visit 30 files.
True. However, I'd think that to do this by true plugins, the
objects/archetypes have to get updated, eg, hooks added for describe item,
apply
item, etc. My poor mans version avoids that.
Or we can have a plugin, in initialisation code do a 'plug those callbacks to
type x, thosr to type y, and those to skill z'. Ideally, in this idea, if you
omit the 'traps' plugin from server code, you can have a server which knows
nothing about traps :p (an we could imagine the traps module handling trap
objects and trap related skills :p). If you omit the all spells modules, you
could have a server in which casting spells is impossible (only bash and
crash)
True, but that goes more back to my 'poor mans version' of plugins.
At some level, I think a poor mans version with callback registration is
actually more flexible.
One could have a registration function like:
set_type_callback(object_type, event_type, callback())
The advantage of registration of that form (instead of true event plugs in the
object) is that adding new event type callbacks doesn't require any change to
the objects.
Another advantage is that registration above sort of provides a self
documentation of what function is going to be used just in that callback
function (and presumably, proper function naming, can be pretty clear where
function is located, eg apply_.. would be in apply.c, describe_.. in describe.c,
etc).
Lastly, it could be very easy (even within the game) to disable certain
plugins, eg, just a call like:
set_type_callback(.., .., NULL)
Where with true plugins, I don't think there would be any easy way, as you'd
need to update all the objects with event_.. hooks (or keep a table someplace
saying to ignore hooks, but that would seem to get pretty messy).
Another question is whether a plugin can call another plugin - that in
itself
could perhaps limit the ability of some things to be in plugins.
Very good point.
Plugins put aside for a few seconds, in modular project, there is usually a
notion of modules dependencies (module X depends on module Y and core, module
Y depends on core). I think we need to handle this dependencies system or we
lose a bit part of interest in modularization. Back to plugins, that means we
need plugin X to be able to do calls on plugin X. This shouldn't be difficult
to do. Simply a plugin would link a list of callback in initialization but
would also provide core a list of 'public callback' (that is a list a named
method). Core will the provide every plugin depending on X the possibility to
access them.
That is one consideration. Another is whether the any of the plugin logic
itself would prevent proper re-entry (eg, static values in wrapper functions, in
case of python plugin, is there anything to prevent two python scripts from
running properly at the same time, etc).
Of course, ideally, in all cases, the answer should be no - if/when crossfire
becomes multithreaded, those things would likely need to be fixed anyways.
_______________________________________________
crossfire mailing list
[email protected]
http://mailman.metalforge.org/mailman/listinfo/crossfire
