[bf1942] Disconnecting after every round

[Nigel Smart]

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.

Nigel
  ----- 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


  ScratchMonkey wrote: 
    --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 
      this? 

    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
tokenized, etc.).

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.

--Forrest


> --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
>> this?
    >
>
> 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.
>
>
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/bf1942/attachments/20050625/e1ae42e9/attachment.htm>