> Sorry, in the initial post I presumed it would be python, but a C plugin > seems like a reasonable idea.
Yep, I easily understand the confusion, given that for the most part, the Python plugin was the only one widely used (Actually, it is the Crossfire-Python "bridge" itself that is the plugin, not the scripts it allows to run). > For one thing, I can't imagine a C plugin ever not being able to be installed (unlike python where people could be lacking the libraries) 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. > That said, trying to figure out what is optional or not is difficult. I'd > venture to say a lot of people would say the random maps really are not > optional (or if those are optional, what else is optional, like shops, > monsters, etc) Well, I don't think we should actually draw a line between what is optional or not in gaming terms, because basically nearly everything actually in the server code could be considered as "core" in that respect. 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. > 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) > That said, the plugin itself won't fix all the ills. That's true. It is a way to make some things easier, but it is definitely not a magical answer to all problems. My opinion is that it would make the code cleaning/maintenance easier, but it will certainly not do that maintenance by itself. > To do that, more radical changes are needed in the basic functions as is, and that will break things. 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. > all that said, I do think it is fair to discuss other work to be done - if > you have limited resources, it makes sense to discuss where those resources > go. Indeed, it does - as long as it stays a reasoned discussion attempting to find the best solution, and not a collection of ignorant rants and ridiculous analogies. I'm tired of having to read such useless things, which (un)surprizingly always come from the same person. > Yet at the same time, given this is a volunteer project, one can't really > force anyone to do anything. Yes, although I understand the urge that many people have to see some funny/interesting ideas implemented. Simply, there is a civilized way to ask for those, a way that unfortunately not everybody seems to have understood. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
