[bf1942] Disconnecting after every round
nigel.smart at tranceairwaves.com
Sat Jun 25 17:53:45 EDT 2005
While we're on the subject of python, ive taken a look at most of the python scripts, and come across some things that were a little odd.. for instance, the scoring system, how many point you get per kill, death, team kill etc, is all editable in the python files, no wonder EA restricted the ranked servers, anyone can edit these files to give more points per kill etc etc .. just slightly odd that DICE have made these files so easily "moddable"? if thats the right word to use.
----- Original Message -----
From: Forrest Thiessen
To: bf1942 at icculus.org
Sent: Saturday, June 25, 2005 10:34 PM
Subject: Re: [bf1942] Disconnecting after every round
--On Saturday, June 25, 2005 9:50 PM +0100 Paul Bowsher <paul.bowsher at gmail.com> wrote:
Yeah, it's VERY annoying that you have to restart the server for the
new python to take effect. Anyone know if there's an ACTUAL reason for
It's probably like Perl: The code is tokenized and "compiled" to p-code when initially loaded, and it's the p-code that's "executed". The file on disk is never looked at again until the interpreter is reloaded.
That's all correct, but not why the server has to be restarted. . .
Python does indeed "compile" programs when they are first loaded
(sometimes you'll see ".pyc" files instead of the regular ".py"
files--those are programs that have been saved after having been
However, Python is a dynamic language, and one property of such
languages is that you can change their code during runtime, while they
are executing. So, theoretically, there is no reason why you can't have
changes to Python code take effect immediately.
The trick is that you have to write your code with the intention of
allowing this, if it's what you want. Because people don't normally
change running programs on the fly, Python gains some efficiencies by
assuming you're not going to do it. For example, if you want to run
code in another module you first have to "import" it. Python only
imports any given module once--on the assumption that it's not going to
change--so if you do change it and want the changes to take effect, you
can't just import it again; there's a separate "reload" statement that
you have to use if you want to tell Python that the module has changed
and it really should look at your module again.
Part of the problem, too, is that the architecture DICE used assumes
static code; they only import and instantiate objects like
bf2.playerManager once, when the server first starts up, so even if you
change it, and change it's import statement to a "reload", the
bf2.playerManager object has already been created, so changing it's
class has no effect.
There are still ways through this maze--bf2.playerManager, for example,
is just a pointer to an object, so you can assign it to point to a
different object while the program is running, if you want, and then all
method calls against it will go to your new, revised object, like
magic. This all starts to get pretty twisted, though. . .
So, rather than rewriting everything in tricky ways so that you can
dynamically change the code, given the overall architecture DICE set up,
it's a lot easier (if annoying) to just restart the server.
> --On Saturday, June 25, 2005 9:50 PM +0100 Paul Bowsher
> <paul.bowsher at gmail.com> wrote:
>> Yeah, it's VERY annoying that you have to restart the server for the
>> new python to take effect. Anyone know if there's an ACTUAL reason for
> It's probably like Perl: The code is tokenized and "compiled" to
> p-code when initially loaded, and it's the p-code that's "executed".
> The file on disk is never looked at again until the interpreter is
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf1942