> ===== Original Message From Mark Wedel < mwedel at sonic.net > ===== > I have some general questions about the plugin supports: > > What is the long term idea behind the plugins? It seems to me that if I am > designing a new map, I'm less likely to use features from the plugins unless I > know they exist in the servers that will be using my map. > > This then leads me to think that longer term, you end up with two main > possiblities: 1) Most every server has a set of core plugins they support, in > which case these are not really plugins anymore, but main features of the game, > or 2) Different servers may have completely different sets of plugins, > potentially creating very different game play enviroments. > For #1: I use the term "plugin" to name a piece of code that is not directly part of the main executable file and can be added or removed at any time. The fact that some plugins may become "canon" and be distributed with every decent crossfire server does not mean they are not plugins anymore. It is of course indeed true that some plugins may prove so interesting that they could become "main features" needed by a lot of maps. But making plugins optional functionalities was not what I got in mind when I started developing this. The main idea behind the plugin concept was to allow easier server updates for work-in-progress functionalities (you previously needed to rebuild the whole server, stop the old one, and restart the whole stuff - it was also difficult to desactivate a faultly beta-stage code once it was integrated into the main code). As a side effect, it also means that you could imagine very different gaming environments using different plugins. It also means that you could say "I have a brilliant idea, but I don't know how players will react to it" and make your code as a plugin that could be easily tested without requiring you to put your code in the core just to see that lots of people don't like it. > #2 of course leads to all sorts of possibilities - if most everything currently > in the server directory becomes plugins, then choosing your plugins (and > archetypes) could really determine the type of game you have. The only downside > I see on this is a pretty big fragmentation of developers - some may like one > environment more than the other. > I don't understand why it should make the development process more fragmented that it is now. The plugin system simply means that you can develop your own piece of code without bothering about what others are doing/have done. I think the increased freedom in the development process allowed outweights the fact that anyone could go in a different direction - this is already more or less the case. > My other potential concern is basically the current status of the clients - a > bunch of different people write different plugins, but some fundamental code > change is made (say changing one of the structures), and now there are a bunch > of plugins that need to get updated (a lot of work). > Isn't it already the case for the core code ? If you make some big changes in the core (say, in object structure for example), it implies that quite a lot of code needs to be changed anyway (and I don't even speak about the clients-update problem here). And don't forget the plugin interface is based on an interface less dependent of the server/crosslib internals (by the use of hooks). Maybe I could go further on the abstraction layer problem to prevent compatibility break ? Chachkoff Y. ----------------------------------------- Visit http://www.chachkoff.f2s.com for a journey into a fantastic world ! (But don't expect too much...) -----------------------------------------