[CF-Devel] more proposals

crossfire-devel-admin at archives.real-time.com crossfire-devel-admin at archives.real-time.com
Sat Jun 21 13:07:50 CDT 2003


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
     
     
    


More information about the crossfire mailing list