[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