[bf1942] Disconnecting after every round
Forrest Thiessen
thiessen at alum.mit.edu
Sat Jun 25 17:56:04 EDT 2005
I'm grateful that they did it that way, because it gives unparalleled
flexibility to people like us. . . but you're not kidding when you say
it's "odd".
I rather suspect that in the first patch we'll see some of this
functionality moved out of Python, and into the core game engine, away
from prying eyes and idle hands. . .
--Forrest
Nigel Smart wrote:
> 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 <mailto:thiessen at alum.mit.edu>
> *To:* bf1942 at icculus.org <mailto: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.
>>>
>>>
>>
>>
>
>
>
>
More information about the Bf1942
mailing list