Le Jeudi 19 Janvier 2006 07:44, Mark Wedel a écrit : > For example, there are probably about 100 different object types out there. > So if we take the module example, you either get 100 different modules for all > those objects, or a fairly big/complex module that handles those 100 different > object types.
I think there are more object types than this! > > It is unclear to me right now which is the better case. > none of both solutions :) > 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.) 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) > > 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) > > 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. > > > _______________________________________________ > 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
