David Seikel wrote: > Now that I have the chance, lets deal with my Python problems. > > Note, I really know very little about Python programming. I am a zen > programmer though, which is how I managed to modify the IPO scripts and > write my night club script. My main reason for changing the IPO scripts is > that the shelve thingy used in the original wouldn't work here. I had a > quick look, and the shelve stuff looked fine to me. However, I reasoned to > myself, the rest of Crossfire is based on text files, why use a DB for IPO? > Well I like using shelf because it is very simple and easy to do, also perhaps better performance. I did write a text file for housing in the past and found it was a pain to do while using the shelf was so simple it was almost hard to understand it at first. I would say if you are storing data and you don't need manual access (like the admin to modify it by hand) to it then a shelf database is the right way to go - that's what they are for. Plus I think it would have been used more in the server if it was as easy to us in c as it is in python ;). I had a problem with the shelf module as well but I think it was because the Python plugin was using the older version of python.h (this was on REDHAT and redhat 7.1 and that came with (relied on having) python 1.5 - the plugin used to go with the lower version first - and not the python2 I had installed to actually work on stuff. I know IPO requires python 2.x... I believe that was fixed and now the plugin looks for the newer version first, but at the time I used the "--with-includes=I/usr/..." to force it to use a specific python header- you might try that when configuring to point the plugin to my python2 (python 2.1 I think to make the shelf work). You can also read the log file for when the plugin loads for error messages... Nothing in the bigworld should be assumed to work with less than python 2.0 anyway so far as I know.. > > I've unpacked a fresh copy of crossfire 1.5 server from the release > tarball. > I've tracked down the /usrlocal/ problem you mentioned and fixed it. > > Relevant part of ./configure output - > > checking Python.h usability... no > checking Python.h presence... no > checking for Python.h... no > checking /usr/include/python/Python.h usability... yes > checking /usr/include/python/Python.h presence... yes > checking for /usr/include/python/Python.h... yes > checking for PyArg_ParseTuple in -lpython... no > checking for PyArg_ParseTuple in -lpython2.2... no > checking for PyArg_ParseTuple in -lpython2.1... no > checking for PyArg_ParseTuple in -lpython2.0... no > checking For python lib in various places... configure: creating > ./config.status > > In the above, the last "checking For..." and the "configure: creating..." > are on the same line, it just got wrapped by my mail system, and might get > wrapped more by yours. Looks like it found Python, but didn't like what it > found. The python plugin was not compiled during the subsequant make. > > > now about the scripts you sent in, One thing right off, you shouldn't need to make your own mail class and mail storage system - you can use the existing mail class or even sub class it for an alternate mail system (courier service, local mail?) but if we have many different scripts doing the same thing different ways it will likely become a problem (files everywhere). The argument could be made that a scripting language shouldn't be able to create permenant files and this sort of thing (banking, mail file storage) should be done in the server code so we don't want to abuse it. If shelf doesn't work on SUSE we should try to fix it instead of having a mail db file for IPO and then your mail system using a text file storage. The same could be said of banks, slotmachines or any other basic mechanisims or what have you. First off I would get the newer python directory out of CVS and see how it has been laid out. Of course if you make yor own classes, try to make the classes as reusable/modular as possible. There are all the common 'modules' under Python - then the more custom scipts in their own folders which call on them. Also you might update your IPO scripts as they have been changed to use the plugin directory finding code so there are no hardcoded paths (so they need no changes to work). > In case you are wondering, a zen programmer tries to clear his mind of all > actual knowledge of any particular programming language, and tackles > programming from first principles. Thus he can program in any language, > with no knowledge of the language required. I've been doing this for > decades. On the other hand, I've done many years of Java and C > programming, so I do know a few things about them B-). Go on, ask me how > many languages I have programmed in... > > > I am more of a virtual zen programmer - I seem to do less actual coding. ;) I do however think that does not make my thoughts on these things useless. I did think about this plugin stuff a lot though and have done some changes to make things tick better I think. I think that as the plython plugin gets used more it will be important to keep things neat in there and follow some similar guidelines like: all python scripts should break properly when the plugin isn't installed/running, code should be modular and reuseable (let's leverage those objects eh), no admin intervention should be required to install or use script stuff (use the pathfinding in the plugin...no special file/directory permissioin changes...) changes to existing stuff shouldn't be done without a consenesus clean up after yourself (don't leave unused junk in the player files or in the var directory..) These rules should only be broken with a good reason... _______________________________________________ crossfire-devel mailing list crossfire-devel at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/crossfire-devel