> Presumably for that last point to work, all the functions the change > values in the plugin code would need to set some flag. Otherwise, I > don't see how the server can know an object changes.
Exactly. But remember plugin isn't supposed to access object's fields directly but use callbacks which can set such a flag. > I personally do think that the plugin should do basic checking - making > sure set values are valid, etc. I don't think that stuff is too hard. > And I think that may catch errors object comparison can't do. True, but for instance in the case of the Python plugin at what point? In the Python-C wrappers, ie Python plugin side, in the plugin_common code, or in the server-side code? 3rd case is the more foolproof, but can be a pain to propagate back (how will the C/Python code know the value is invalid? Special integer value for return? Parameter by reference?) > Another thing (unrelated to this) is plugin verification of > compatibility. More than once on my own working copy, I've done a make > but not done a make install, only to track it down to the plugin being > out of date. That could possibly be done. I'd then suggest sending those values at plugin init, or something like that - maybe have the plugin init function take a "long struct_size, struct* plugin_info". The structure contains basic info (version, some sizes), and the struct_size ensures you're compatible at least with the structure sent :) Nicolas _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
